Sfor

Almost correct. But there is no bootstrap file in the first sector of the hard drive. This sector is called Master Boot Record. There is a partition table there, and a program responsible for selection of the partition and further boot actions. It is not a file, certainly. That's right. To be more specific, the code from MBR calls code from boot sector of some active partition. Then the system files are loaded. The code located in boot sector is put there during the OS installation. So, the code loading system files is different for each OS.

I can not remind a recycle bin related issue. I've been experimenting with the msvcrt.dll problem. It does not always happen at the first attempt. But, when it starts, all folders with msvcrt file are affected till computer is restarted.

So does the Windows say with the error message. But, this is not possible. I can move the same folder by copying it, then deleting the source files. I would not be able to delete a file used by Windows, isn't it? Also, how on earth Windows would lock all the msvcrt.dll files in all folders on all hard drives? I was testing the issue copying around the folder found on the Windows 98 SE CD: add-ons\pws. But, the same effect gives an attempt to move any folder with an msvcrt.dll file in it. I can move the same folders around without any problems, if the operation is made on the same partition.

I'm experiencing problems while trying to move folders to some other HDD partition. If there is a msvcrt.dll named file in the folder, the move operation stops on this file. I'm not sure how to translate the error message to english, anyways, it says the file is locked. In the target directory a msvcrt.dll file name is created (file is empty). Moving files operation stops at that moment. The work around procedure is to copy the folder, then to delete the source. Why the Windows 98 SE USP 2.1 (IE 6 SP1) acts so strangely? The effect is not limited to msvcrt.dll files. It happens in some other cases, as well.

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.

Check, if the CardBus devices are sharing the same IRQ line with the sound card.

Well, it should not solve the problem. The Windows 9x kernel takes direct controll over the hardware. So, the DOS layer can not do multi CPU support. If the DOS would support multi CPU cores, the support would stop in the moment the Windows 9x kernel is started.

I've been observing problems when some device shared IRQ with the ACPI controller. Looks like some devices do not want to share IRQ with others. Also, it is a good habbit to not to use IRQ 9 (ACPI controller is using it) if not necesary. Besides that, ACPI was not causing problems to me. My Windows 98 computers were working days without a crash, quite often. I do believe some boards or devices do have problems with ACPI or APM. But, I'm using Intel based boards mostly. The last ACPI related conflict was caused by using the same IRQ 9 by Intel hardware monitoring software and TV tunner card. It happened on Windows 95, as far as I remember. I moved the TV tunner to the other slot, and everything was working fine. The SCSI controller was working correctly on the same IRQ 9 line.

Checking for %windir% enviroment variable is woking quite good. It does have just one weak point. The %windir% variable is set during winstart.bat call. The Windows kernel works, but the GUI is still down, then. So, it is not possible to run a WIN32 application, then. It's a very good solution, anyway.

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

I'm looking for the best way to test a DOS real mode application is runing Windows GUI. I've been testing for DOS LFN extension services, so far. But, with the presence of the LFNDOS driver, it is possible to have LFN support without Windows GUI running. My application is a core of a backup/restore system and it should be aware if the GUI is present, before running any windows GUI utility. It is possible to run a WIN32 application waiting for an error result, but such a methode looks a bit crude. Some iterrupt based solution should be much more effective, I think.

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.

The LFNDOS appears to work correctly. But, ARJ can not handle file names with ANSI characters properly. ARJ32 is needed to do so, as it is not possible to translate all ANSI characters from ANSI to OEM and back. I'm curious how the LFNDOS will handle the ANSI characters. --------------- edit ----------- Yes, I was right. It is not possible to backup and restore files with some ANSI codes in their names. Just an example: Might and Magic® IX On the other hand LFNDOSMS seems to handle all Polish national characters correctly. So, it can be a very good tool, indeed. This new possibility makes another dilema. 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.

I'm using 3 Windows 98 computers in my LAN. Every one is fitted with IE and Firefox and/or Opera. The challenge is to take controll over the Favourite WEB pages links in such an enviroment. An automated way to synchronise favourite links across browsers and LAN is quite a task. It is not an urgent task for me, but I'm considering it to be useful in the future.

What can I say? To put it simply, WGET works as expected. The only downside is, it is not a part of the Windows OS, so I have to keep the EXE with the script. In my particular case it is not a problem. However it can be a problem in some other cases. I'm satisfied with the current solution, for now.

I've been playing with the FreeDOS last time, when it was in the beta stage still. It did not supported LFN, then. I'm unable to download the FreeDOS 1.0 ISO image. So, I can not play a bit with the newest version. But, did the FDOS kernel changed so much, so it is supporting LFN, now. As, the base distribution does not have drivers to support LFN, apparently. Also, I found no reference to the LFN support in FDOS, so far.

It is possible to say Win9x systems are DOS based and they are not DOS based, in the same time. Everything depends on what "based" word means to the person speaking in the particular moment. There are no "real" DOS in the NT based systems, except for the emulation. It is true the DOS is used to run the Win9x kernel. The DOS is still present in the memory while the 9x OS runs. The windows has a feature to shut down the kernel and run a DOS application, without a reboot. Also, all DOS drivers loaded before Win9x kernel starts are available when it is working. Windows can use DOS supported disk access if needed, as well. So, DOS is a part of the Windows 9x design. Windows 3.xx was more DOS based for sure. All disk and network acees was done trough DOS layer drivers (except for the 32bit disk acces feature, I think). In relation to the system boot and design, Windows 9x and 3.xx are DOS based. In relation to the system kernel operations only the Windows 3.xx is DOS based, I believe. Windows NT is not DOS based, for sure. What matters in the multi CPU systems is the hardware and memory access management. And, the windows kernel is the one holding both jobs, in the 9x systems.

The VBS script can be a solution, as well, I think. But, I do not have a skill in the VBS programming. The WGET seems to be a solution, as well. It is within my batch programming skill, also. I'll look in to the WGET a bit closer.

As far as I remember, every memory block does have the access rights. Each thread does have the rights to access certain memory blocks. If a thread tries to access wrong memory block a protection fault error condition is raised by the CPU. The system core has the access rights to all memory blocks, while higher level processes do have some limits. As the system kernel keeps the best access rights, the application running on the second core would not be able to work in the same manner, I think. The memory block list is maintained by the system core. The second CPU has to have the access to the memory block list, as a CPU can not work in protected mode without it. The protected mode virtual memory block system used in Windows makes the second CPU used by another application idea looking impossible. As, the second CPU would not have the access to the memory block list.

I was using FTP to download some files from batch scripts, so far. But, recently I encountered a problem. Some files are available through HTTP, only. I'm trying to create a new script able to download files using HTTP, this time. But, I do not know what to start from. I can start an URL using START command. But, it will display a dialog asking what folder the file should be saved in. So, I need to find a way to download a file without the confirmation dialog and I need it to be saved in a particular place.

Indeed. DOS running with Windows GUI is not the same as DOS running without GUI. I would rather say, the GUI DOS is just a DOS emulation. The DOS itself can not work with multiple CPU cores. But, it could be possible to run two DOS instances on two different CPU cores. Still there is a problem dividing the system resources (ports, graphics cards and other). The DOS can not do it by itself. A multitasking multi CPU enviroment, requires some OS layer between application and hardware resources. It is necesary to divide hardware between multiple threads. The windows 9x systems do provide such a layer. One of the kernel fuctions is thread managing through dividing the CPU time between threads. All it is necesary to replace is part of the kernel with a multi CPU one. This makes a multi CPU driver idea completely wrong, as the kernel core is responsible for the multi CPU support. Drivers are working on a higher layer then the CPU support. So, I see no possible solution with a multi CPU driver. As for replacing the Windows 9x kernel with NT kernel. I think it will not work. As, the NT kernel is a completely different design. The NT kernel does have some security features on the lowest layer, this makes it completely different than 9x kernel. NT based drivers are working on a higher layer than the 9x ones, as far as I know. This makes the system more stable, as a driver can not stop the system kernel. Also, nobody mentioned a non paralel multitasking feature such as a system kernel running on one CPU with all remaining application threads running on the other CPU. This could increase the system stability mainly. The speed can go up a bit, but not very much. Also, one CPU can do all the hardware access, while the other would do the other things. With such a solution, it would not be necesary to divide system hardware between two CPU cores. The kernel core can be much simpler, that way.

Interesting. I did not know Firefox can work with windows 95. It's official requirements is Windows 98, as far as I know. On the other hand, Opera is working in Windows 95, for sure.

Indeed it does work with the Kingston USBstick 1GB flash drive, I have. On the other hand it does not work with USB external 2.5" IDE case based on Myson Century chip. Both devices are using different communication systems, I think. I was able to connect the USB HDD using DOS driver, while the Kingston flash drive was not working with the same driver.

The windows 98 does not work well with memory amount exceeding 512MB. The problem is caused by a conflict with the graphics card memory adressing, as far as I undertand the problem. It is possible to get around the 512MB memory limit, but I never did it by myself. There are topics about this particular problem, on the forum.

Some graphic card drivers do not work without the Internet Explorer 5. I think both Nvidia and Ati drivers do have such a requirement. So, it is necesary to install IE before the graphics card drivers. The Nvidia drivers do not need a NET Framework, as far as I know.