Sfor

I'm using a polish language Windows 98 SE version. The Windows Update from the Start menu is working still.

A few facts: - user32.dll has country specific file paths hardcoded. It is not possible to use other language version of user32.dll file. - the LBA 48 path (large HDD support) does not require user32.dll library replacement. - the Microsoft Windows Update site works correctly if the newest java runtime enviroment is not installed. I do not know exactly what JRE versions are disturbing the Microsoft Windows Update, but JRE 6 patch distributed with the Open Office disables the Windows Update system, for sure.

It is possible to "personalize" the Windows Update. There is a switch box to add the link to the updates repository library. You will be able to browse the library and to download any updates you want to a folder of your choice.

The question is if the BIOS will let you to use the HDD of this size. Some old bioses hanged during detection of such a big drive, others clipped the size of it to the 137GB. With the Intel Application Accelerator you will be able to use the full HDD capacity, even if the BIOS clipped the disk size to 137GB. But if the BIOS is hanging during the drive size detection, you need the BIOS update. It's not a file system limitation, but an OS one. Win9x uses a 32-bit pointer for HDD addresses. Thanks to LLXX' patch, a 48-bit pointer is used. Well, it is not exactly the truth. The problem is with the generic IDE driver. Other large disks (without an IDE interface) will work without any patch. The 32bit pointer limits the size of a single file to 4GB. It has nothing to do with the LBA48 limit. In case of files accessed through the Windows 9x network interface the maximum file size is 2GB, only. Windows 98 can work with a single partition of 400GB and larger. But, the scandisk and some other disk utilities will not work correctly. Also the automatic swap file system can fail, as well. It's a strange one to me. I'm afraid to connect a Windows NT based system directly (without a NAT router) to the Internet. While I have no fear to do the same with Windows 98 (even without any firewall or AV protection). And that is because the Windows 98 does not have any server like security holes. A non IE browser (or a safe browser) is enough to make a Windows 98 computer a secure one.

I'm using polish language Windows and IE. So, I can not install every english language update, I'm afraid. The effect I've described happens on certain sites, as well. But in my case the links are oppening without any delay. After closing a child IE window the parrent IE window becomes locked. But, other IE windows started separately are working correctly, in the same time.

Well, it is buggy for sure. But, a lot of software depends on IE. Resolving this problem can improve IE dependant software as well.

I'm trying to create an empty (0 length) file with a batch script. The biggest problem is the fact DOS, Windows 98 and Windows 2000 do handle such situations differently. Windows 2000 will copy a 0 length file with a copy command. On the other hand the Windows 98 or DOS will display "0 files copied" message in such a case. Windows 98 is able to create an empty file with such a command: if>empty.txt Windows 2000 will just say the > character was unexpected here. I'm trying to find a solution working in DOS, Windows 95, 98 and 2000.

After oppening a link in another window through a SHIFT+click, then closing the child window, quite often the parrent window freezes for a while. In most cases the parrent window resumes in less than a minute. I've observed this behavior on many computers with Windows 98 SE USP 2.1a and IE 6 SP1.

The Print Screen key support is done in the computer BIOS. So, it is not possible to take advantage of it in the QBasic. Basicaly the Print Screen event is handled by the BIOS before the key press event is reported to the DOS. So, the QBasic is not able to capture the Print Screen key. In order to reroute the print screen key it is necesary to capture BIOS interrupt by own routine. QBasic can not do it. In case if the Windows is working, BIOS does not handle the print screen, any more. As, Windows handles the keyboard events without the BIOS. So, you should not to look for the standard DOS like Print Screen effect in Windows. Windows Print Screen sends the captured data to the system clipboard, instead of printing them. So, you will have to paste the data to a Notepad or Paint, then to print it by yourself.

Finally, I had an opportunity to test my theories. The SMC Barricade LPR/LPD driver I was using in the past with 9x systems failed to print to the Konica print server. On the other hand the HP software posted by j7n worked perfectly. Sadly, according to the licence agreement displayed by the HP installer it is not a freeware. So, I'm not sure if I have a right to use it. The conclusion is the standard IP port from Windows XP is something more than a plane LPR/LPD.

Please read,... then write.

Are you sure? I think that doing so you will have to re-partition the whole drive and erase all datas on it. This even if you just want to add a partition. Or does it depends on the partition/formating utility? The problem is to not let Windows to write anything above the 137GB barrier, before the patch is applied. That's all. So, you can partition the whole drive before the Windows is installed. Or you can englare the first partition with some partition manager (FDisk will certainly not do that) after the LBA48 patch installation. Or you can add more partitions with FDisk, leaving the first one unchanged. Repartitioning does not mean partitioning from the beginning. If the drive does have an unassigned space it is enough to add another partition and format just a newly added one. Changing the size of a partition is another story, because FDisk can not do it. But, still, the reformat and data loss is not necesary. As, there are partition managers able to manipulate partition sizes. The Partition Magic is the most famous one, I believe. But, versions before 7 were not able to handle LBA48 sized hard drives correctly.

It is not true. DOS does access disk drives using BIOS functions. So, DOS does support LBA48 if the BIOS does. It's a bit funny, but with many motherboards DOS supports larger hard drives then the unpatched Windows does. So it is possible to partition and format a large disk in DOS. The simplest way to install Windows on a big HDD is to make the first partition smaller than 128GB. Install the Windows on it, then apply a patch to access the whole HDD.

I've installed a Konica K-7130 with IP-422 controller drivers on two XP computers, today. The generic IP printing port was enough to access the printer through the network. Now, I have to do the same with a Windows 95 computer, and another one Windows 98 in the close future. I do not know much about the generic IP port printing in Windows XP. But, the most probable explanation how it is working, seems to be the through LPR/LPD protocol. Quite some time ago I had an SMC Barricade router with a built in LPT print server. The supplied driver was called SOHOmate, PRTmate, or something like that. The driver worked with every LPR/LPD print server. I'm qiute sure I could use the same driver with the IP-422 print server. The problem is I do not know, if it is legaly correct to use this driver with a none SMC print server. But, perhaps there is some other freeware driver available. Or, I'm very wrong, and will not be able to duplicate Windows XP generic IP printing port with an LPR/LPD driver.

So happens, I'm running Windows 98SE with GeForce FX 5200 graphics card, at the moment. The last ForceWare ment for Windows 98 was 81.98, I think. And, it does support FX 5200 cards.

I'm using 9x systems, because they are simple. And, simpler systems are much more easy to manage. The Flash Player compatibility forced me to move to Windows 98 on computers used for the Internet browsing purpose. All others with hard drives below 128GB are Windows 95, still. According to my experience, the best hardware platform for a 9x computer with DOS applications being used is PIII. P4 processors tend to slow down when a DOS application is working. So, with a DOS window opened a PIII or PII CPU is much faster than twice as fast (in clock) P4. A PIII computer with 256 or 512 MB of RAM and a Windows 98 running seems to be more than enough for a normal work station. Only heavy graphics, multimedia or gaming activity requires the CPU power the P4 class CPU can only deliver.

Ill start from the declaration the affected computer is not mine. The infection happened a few month ago, so it's a bit late, now. Also, the Steam Account Stealer is the name of the trojan like software. I know nothing about Valve game managers, but this is not the case, I believe. Well, it is highly possible the personal data was stolen, but there is no proof the trojan works good enough on the Windows 98 systems, as well. Since it left the trace to the FTP account it stores the stolen data on, it is safe to say it does not work without flaws in the Windows 98.

A suspecious looking file tmp.tmp.tmp was found on a Windows 98 computer. It looks like a config file of some sort. There was an FTP server URL, FTP account name and password in it. The FTP account is valid. I logged to the FTP server, and I've found several text files generated by Universal1337 Steam Account Stealer. Looks like the computer was attacked by a trojan. But, the trojan should not leave such critical data on the targeted computer, so I do believe it is not working correctly on a Windows 98 system. Still, remains an important question. Were the personal data stolen? Is the Universal1337 Steam Account Stealer able to retreive any data from an Windows 98 computer?

I do have a Windows 95 installed on a few computers. But, I had to move to windows 98 on every computer I'm using for Internet browsing. There are quite many portals using flash. Unfortunatelly, there are no proper flash player available for Windows 95. Older flash player versions are working quite well, but some Internet pages are not compatible with them. So, without a flash player 8 or 9 it is not possible to browse certain sites.

According to the license agreement this is a commercial application. It is forbidden to make copies of this application except of the archival purposes. So, it is not a shareware, for sure. The trial version excludes the commercial and public usage. So, it is ment for the private use, only.

Whait a minute! What kind of shareware is this? It is just an online converter, isn't it. It requires an E-Mail adderss to be supplied. I see a danger of being spammed after using this converter.

It doesn't make any sense to me, still. As, any DOS application can test for OS=Windows_NT enviroment variable. Also Windows 9x systems did not hide the %windir% variable, so hidding it in a newer systems does not seem to be a logical action. Going towards DOS 5 compatibility leaving DOS 9x system compatibility behind is a bad idea, I believe. It would be easier to test for just one variable, but testing for both %windir% and %OS% seems to work good enough.

The %windir% variable checking works very good with a Windows 9x. But, I found some problems with Windows 2000 and XP. The SET command displays the presence of the %windir% variable on 9x, 2000 and XP. But, a 16 bit application compiled with Borland Pascal does not detect the variable in windows 2000 and XP. I do not know where this strange phenomenon comes from.

Only the Novel edition of the OpenOffice is able to open DOCX files, as far as I know. So, it is hardly a solution, I believe.

Well. there are just three files responsible for the DOS boot. All are located outside of the Windows folder, by default. IO.SYS, MSDOS.SYS and COMMAND.COM. Other files used during boot will be listed in CONFIG.SYS and AUTOEXEC.BAT, but are not mandatory. It is possible to modify those files when DOS is running. The exception can be COMMAND.COM. It would be good to reboot the system right after changing the COMMAND.COM. As, it is loaded and unloaded dynamicaly by DOS. Quite often, Windows GUI kernel uses the COMMAND.COM from the Windows folder, instead of the one in the main folder. IO.SYS can use the one in the main folder, when the other one is not available. IO.SYS should not be deleted. It's first cluster has to remain in the same location. So, it is possible to just overwright it. The file has to be located in the main/root directory. There is a copy in the Windows\Command\EBD folder. But it is used just to create emergency boot disks by Windows. IO.SYS will check the registry settings during boot. If the registry file is damaged or missing it will display the boot menu with the "Safe Boot" option.