The -W command-line option starts the IPC mode which includes:- web api running on the port specified with the -W option- named pipe IPC in byte mode on \\.\pipe\quickbms_byte- named pipe IPC in message mode on \\.\pipe\quickbms- mailslot IPC on \\.\mailslot\quickbms\send with \\.\mailslot\quickbms\recv open in write mode (create it on your tool)

These interfaces have been successfully tested on both Windows andLinux and the following is a quick set of examples for how using themfor decompressing data, those 302 and 1028 are only an example of inputand output size:

The IPC interface supports the encryption command too and otherfeatures and commands may be added in future.Currently the web API supports also /script and /file that are meantmainly for debugging an input script and an input file based on thescript previously provided. In the latter case there will be no outputfile generated just like with the -0 option (the TEMPORARY_FILE may bethe only exception).

If you need "code" it depends by your programming language, there are plenty of examples online since they are just a web API and a simple CreateFile+ReadFile+WriteFile(+CreateMailSlot for mailslots) which are the basis of Windows programming

Just a note about filexor/filerot/filecrypt because the current quickbms.txt documentation lacks the FILENUM field after OFFSET:filexor VAR [OFFSET] [FILENUM]

filexor is a command that works universally on all the files, that FILENUM is ONLY referred to the optional OFFSET field since it's used to calculate the position in the key you are using depending by the offset of the file.Now there is a very rare event (happened yesterday) in which you may need to use a MEMORY_FILE or a file different than the main one (0) and after you set OFFSET you notice that the decryption is a mess... that's caused by the missing FILENUM field which is mandatory in this rare situation, example:

Don't think that being the author of quickbms makes me remember all the commands, options, features, caveats and bugs of the tool I check quickbms.txt and even the source code of quickbms (damn "encryption random"...) very often...

The -W command-line option starts the IPC mode which includes:- web api running on the port specified with the -W option- named pipe IPC in byte mode on \\.\pipe\quickbms_byte- named pipe IPC in message mode on \\.\pipe\quickbms- mailslot IPC on \\.\mailslot\quickbms\send with \\.\mailslot\quickbms\recv open in write mode (create it on your tool)

These interfaces have been successfully tested on both Windows andLinux and the following is a quick set of examples for how using themfor decompressing data, those 302 and 1028 are only an example of inputand output size:

The IPC interface supports the encryption command too and otherfeatures and commands may be added in future.Currently the web API supports also /script and /file that are meantmainly for debugging an input script and an input file based on thescript previously provided. In the latter case there will be no outputfile generated just like with the -0 option (the TEMPORARY_FILE may bethe only exception).

If you need "code" it depends by your programming language, there are plenty of examples online since they are just a web API and a simple CreateFile+ReadFile+WriteFile(+CreateMailSlot for mailslots) which are the basis of Windows programming

Thx im gonna try it out, but do u have any idea when DLL will be released ? I sure u dont know exactly but roughtly ?

Most of them are known libraries (zlib, lz4, lzo and so on) or small algorithms easy to port to other languages.The encryption algorithms are all known libraries.

Yes it is for programmer like where i dont need to look for something, simply everything on 1 place and i believe that usage of the functions will be the same for all algos or compressions or at least very similar , so its also make thing easier.

In the meantime this is the output generated by a new feature of quickbms that can be invoked with the -t option and may be implemented in other fields in future (for example with the web api interface):

perhaps it would be better if quickbms had this kind of feature in which "log"/"clog" gets a "timecode" argument, such as if the "unix_timestamp" variable has this 32bit time value then said argument would need at least that variable so it can implement a "timecode" into the extracted fileif the "timecode" argument has nothing else to stick into then it'll be just assigned as "" or something

It's something that is rare and not useful in my opinion.Additionally there are tons of factors that would make it a hell to use and creating a simple "syntax": creation, modification or access time or all or a combo? unix 32bit time (from what year? many implemenations), 64bit Windows FILETIME, floating point timestamps, other variants of timestamps...

I try to avoid to add new commands for keeping the language as simple as possible.

Right, I have continued to fix and implement new stuff so I decided to postpone the new release.I guess it's better if I will release it in less than 2 weeks, just the time for checking if everything works correctly and no bugs have been introduced

saving the current offset, closing the file, open the new one, reopen the original file (FDSE2 is new), restore the offset

redirect all the operations of the current file to another one (file 1 in the example, it can work with MEMORY_FILEs too)

It's a feature that is useless in 99.9% of the scripts, but extremely useful when needed and it's also a good alternative (double alternative) to using a FILENUM variable for every instruction.

In case you are asking what is FDSE2, well it's the forced original input folder which is opposed to FDSE that is the folder of the current file, so if you open (for example) the TEMPORARY_FILE you will not be able to open files in the original folder, with FDSE2 you can.

And you can add a function so that when you reimport files, it skips all files that are larger than the original size at a time so that you do not press a button y every time. I know that the files should be smaller than the original size, but still I ask to add it. I would also like to trim a file if it is larger than the original size, but I think you do will not want to add this function.

In that case how can you know what files have been skipped?Maybe it has more sense to allow the existent -0 option (it's used in extraction) to be used with the reimport feature for "testing" the injected files, and it would tell you "file1.txt" is ok, "file2.txt" can't be reimported and so on.That would be easy to implement.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum