Backing up and restoring Windows 98 system.

[Sfor]

It will not help. It is not possible to translate the ANSI table to DOS OEM table. Windows can not do it. Only Windows native applications are able to open files with such characters. A DOS application is not able to open such a file, so it will not be able to back it up, as well.

The characters affected by national code pages are handled correctly by LFNDOS, apparently. The Windows and LFNDOS are translating them to OEM and BAC without loosing any information. But, some characters not covered by national conversion tables are converted in one direction only.

An example: The ® character converted to OEM by windows will be R (LFNDOS will convert it to _). Conversion from OEM to ANSI of the R is also R (LFNDOS will also convert it to _).

So after restoring the file name Might and Magic® IX will be:

Might and MagicR IX - in Windows

Might and Magic_ IX - in LFNDOS

There is another difference between Windows and LFNDOS. Windows will not let ARJ to open "Might and MagicR IX" file. As it does not exist in the system. The LFNDOS will let to open "Might and Magic_ IX" and to make a copy of it. But, the proper name will be lost in the process.

------ edit -------

I've been playing with the backup utility supplied with the Windows 98SE. And, guess what it did,... it left some files behind. After restoring some files were missing, of course. ARJ is much better.

Edited July 21, 2007 by Sfor

[Fredledingue]

Slightly OFF topic but a good related tip:

It's a good idea to make a "dumb" copy of the Program Files folders onto a CD or DVD-R.

Like that you keep most of your customization settings and also, the plug ins you eventualy added but don't remember of.

[Sfor]

I never cared to check if the CD writing software handles the non OEM translatable ANSI characters correctly.

[Sfor]

I was using the LFN DOS extension service detection routine to check for Windows GUI running. It was enough to run ARJ32 safely, then. But the LFNDOS made a new condition possible. I mean, LFN DOS extension can be available without windows GUI running, and ARJ32 can not work in such a case. Now I need to find a way to detect the the Windows GUI running from a 16 bit DOS application, directly. And I have no idea, how to do it.

Well. I've found a nice way to detect windows kernel running. %windir% enviroment variable is created when Windows kernel starts. Checking if such a variable exists is quite a good way to test the Windows GUI presence. But, there is an exception. During the windows boot WINSTART.BAT script runs before the GUI, yet the %windir% variable exists, already.