Some people seem to get this, I'm working on it but can't reproduce it. If you see this behavior, at least tell me about it and the version of the code you are running. Better yet if its not a huge archive and there is nothing proprietary in it maybe you can send me a copy to work with. CAUTION please don't do this without warning me, I want to be sure I get the mail with the attachment via a high speed link!
------------------------------------------------
comment: All I see in Windows is a black flash
This originally confused me cause I'm an old MSDOS user so I frequently work in "dos boxes". A Windows Console application, which is what I've created in the MSBKWIN distribution, has to run in a "dos box" (also know as "console mode"). If the program is not initiated from a dos box it creates one for the duration of the programs execution. Neither of my programs require any input as they display a usage message if there are no command line arguments. Hence if you click on one of these console applications from the GUI in windows it creates the "dos box", spawns the program in it, displays the intro message, exits the program, and finally closes the window again. All this happens so fast you just see a black flash on current machines. If this is new to you, ie you were trained on GUI interfaces, in Win9x go to the 'Start' menu, select 'Accessories', then 'Dos Prompt'. Do not use the 'Run' option in the 'Start' menu, it produces the behavior above. I assume its similar under XP, but don't own a copy. Once in the "dos box" you have to move around by typing MSDOS style commands which may also be unfamiliar. Sorry, but some of us gray haired programmers actually prefer this behavior. Once you get to the directory containing the executable you can run it with the appropriate command line arguments. Seems to me there may be a way to create a shortcut icon to do this but I can't remember the details (or was that back in the days of Windows 3.1).
------------------------------------------------
comment: What is a console application
Basically its an application that does not run in a graphical interface environment, ie WINDOWS or XWINDOWS under Linux. Instead it runs in console or command line mode. For the WIN32 environment this means a "dos box" as discussed above. You need to type the program name by itself to start it and get the list of options shown for MSQIC or NTBKUP. Type the name followed by a combination of the optional arguments to control operation as described below. If you are old enough to have used MSDOS this will all be familiar, if not look it up as its beyond the scope of this document!
------------------------------------------------
comment: How are the command line options parsed
The simple answer is sloppily! A common convention, which I did
not follow, is to have white space between the initiator and the
option. My programs require an archive file name as the first
argument. All other arguments are options which must start with
'-' or in one case the '@' character. The '-' is immediately followed
by at least one specification letter and often the argument as a single
string with no white space. In my usage description I often use angle brackets,
'<' '>'to indicate file names and paths. I use square brackets, '[' ']',
to indicate an optional argument. Given my simplistic parsing,
you need to quote the entire option if it contains a file name with spaces.
An example would be the archive "Test Archive.qic" which contains the
file "\test\Test file.txt". You would extract this as follows:
msqic "Test Archive.qic "-x\test\Test file.txt"
WARNING, my current logic assumes there will only be one period, '.', in
the file names. If the archive contains file names such as "test.file.txt"
I believe it will not be found if the full name is specified, and will
fail to open correctly with a wild card file name match. This could be corrected
and is related to the discussion of Unicode strings, the same routines would need work.
------------------------------------------------
comment: Are the file's time stamp and attributes preserved
Originally they were not. Since MSQIC Version 1.08 and NTBKUP version 1.02 I set the file date to the 'last modified' date from the archive when the file is extracted. That's the only time MSDOS retains. I believe both Unix and WIN32 maintain at least a file creation date that is distinct from the last modification date, although its available in the archive, preserving it required more OS specific programming than I wanted to do. For similar reasons I preserve the READ/WRITE attributes, but not the MSDOS hidden, system, or archive attributes. If directories are created, I preserve no time stamps nor attributes.
------------------------------------------------
Comment: How are Unicode names handled
Poorly.
Both *.QIC and *.BKF files store paths and file names in
unicode strings internally. In my current proof of concept programs
I assume these are ascii strings and use a brute force conversion.
This works fairly well when the string is ascii, but assumes every
other byte in the unicode string is zero. Character sets that require
both bytes to represent the character are NOT handled correctly.
This could be corrected fairly easily, but frankly I've never attempted
to deal with multi-national character sets.
------------------------------------------------
Comment: Are you going to add the ability to create archives
No.
I'm pretty burned out on this project, more importantly the concept doesn't have
much appeal for me. I was interested in helping people recover files
from these Microsoft/Seagate formats. The fact that Microsoft does not
maintain a link to the MTF_100a specification for *.BKF files and that
I've never found a *.QIC specfication are not good signs. I tried
to make my *.QIC archive decompression algorithm compatible with Seagates
MSBACKUP and was not successful. I can decompress an entire archive and
its associated files. Although I can read this decompressed archive with
MSQIC, MSBACKUP rejects it as an invalid archive.
I think its just too fussy about some of the flags I don't understand. Similarly
my NTBkUP program reads *.BKF files that NTBackUp rejects leading me to
believe there would be similar problems creating *.BKF files that NTBackUp
could read. Bottom line why not use a known public domain archive tool
like tar?
------------------------------------------------
comment: Is there a Mac (or ???) distribution
No one has actually asked this question except myself, but I read somewhere that there was a port of Microsoft's NTBackUp to the Mac OS. With any luck, it didn't catch on there, but I don't know. My understanding is that OS 10 is based on GNU/Linux at the lowest level. I think that means that gcc runs and you could build these applications from the source distribution. You'd have to program and run at the console level which implies you are more than a casual user. I don't know how to do any of this, but if anyone is interested I'm happy to post your input here.
I have compiled all the source under CYGWIN, and think that means DJGPP would work also. Basically any OS compatible with GNU gcc should be able to build the current executables from the source. Check the OS specific #ifdef sections at the beginning of the source files if you have problems and modify them for your environment. You probably also need to change the build file syntax.