Sfor

I've been playing around with a few Linux distributions. Most of them have problems with Polish national characters on Windows 98 network shares. I do not mean mounting network drives here. All I did was exploring the Windows SMB network from the file managers. I've tested a Slax, Debian and EasyPeasy. The last one is based on the Ubuntu, and the one I made most intensive testings on. To put things short: Polish national characters are recognized fine when accessing a Windows 2000 share. On the other hand Windows 98 shares are treated without proper Polish characters support. On the other end of this stick is Xandros I got with my Asus EeePC. There were no problems with Polish national characters while accessing any Windows version network share. So, what is the cause, Linux seems to treat differently Windows 2000 and Windows 98 network drives, when it comes to the national characters support? How to force Ubuntu or EasyPeasy to do the same the Xandros does? A note: I'm not particulary skilled with Linux ways.

As a matter of fact I did just that. The only difference in the plain DOS is the drive 3. As it is not available without GUI running.

It is not the BIOS limitation problem, I believe. It would not be possible to see the whole drive in DOS, 48-Bit LBA Support Test Version 5.1 Copyright (C) 2004-2006 by Rudolph R. Loew All Rights Reserved Drive 1: 500GB = 976773168 Sectors 48-Bit LBA Disk - 48-Bit Support Verified Drive 2: 1000GB = 1953525168 Sectors 48-Bit LBA Disk - 48-Bit Support Verified Drive 3: 0MB = 0 Sectors Not 48-Bit Disk

Recently I've encountered a problem with 250GB primary partition. The amount of data stored there was growing. When it reached about 200GB the system failed to boot one day. It looked like the system registry became corrupted. Restoration of the saved registry files did not helped. The boot failed in exactly the same way. I had a copy of Windows and Program Files folders stored at the same partition. So, I was able to get the system working in an instant. However, further experiment revealed interesting behavior. I tried to add another copy of the system folders on the primary partition, but trying to boot from the new copy was always ending with a blue screen and system registry corruption. Since the same file set was working perfectly at the same time, the only logical explanation was the system files were placed at different parts of the partition. The newest copy was placed at the end, while the older somewhere at the beginning. Finally I freed enough space and reduced the primary partition size below 128GB. I was able to add the third working copy of the system files, then. Before the failure of the main system folder set, everything was working perfectly with two SATA hard drives. The first one 500GB is connected through an SATA to ATA adaptor to Intel 845 motherboard with Intel Application Accelerator installed. The second one 1TB is connected to PCI SATA SiI 3512 controller. Both hard drives were fully accessible from Windows and DOS. So, 32bit mode drivers and BIOS were working correctly. No file system corruption happened, so far. It appears, there is some weak point during the kernel boot, when the system can crash if the primary partition size is greater than 128GB. If some system files are placed too high on the large partition it can cause the boot failure and registry corruption on otherwise fully functional system.

No, Opera 11 gives the same experience with password saving.

The problematic 1TB drive works perfectly with SiI 3512 PCI SATA controller. But, the driver package for SiI 3114 does not cover the SiI 3114CTU VEN_1095&DEV_3114&SUBSYS_71141095 ID. Apparently, not all SiI 3114 chip versions are Windows 98 compatible, as the driver development stopped at 1.0.0.8 version and does not cover newer SiI 3114 chip releases.

Well. I'm using a 500GB SATA drive connected through PPATA to SATA adapter along with a 1TB drive connected through a PCI SATA SiI 3512 controller. Intel chipsets with Intel Application Accelerator driver package do not use windows 98 ESDI_506.PDR. So no other software patches are necesary to get around the 137MB limit.. The PCI SATA controllers do have their own drivers and are not affected by ESDI_506.PDR 137GB limitation in general.

I've bought Unitek PCI-SATA-4r controller with SiI 3114CTU chip. It does have a HDD LED connector, so I was counting on an usable HDD activity LED. This particular feature works, all right. But... 1) The controller built in RAID BIOS does not work with just a single drive. I had to make a concatenation raid setup with a single drive selected. I was able to get the HDD working in DOS that way. 2) I'm unable to find a working driver for the Windows 98. The box says, the controller is Windows 98 compatible, but there are no proper driver on the CD. Apparently, the PCI device and vendor id does not match the INF file entries (VEN_1095&DEV_3114&SUBSYS_71141095&REV_02). It is possible to install a driver for the soft raid controller version, but it does not work correctly. It is enough to access a partition from the SATA drive for the Windows to hang completely. Forcing to install the driver from a proper folder does give the same result as the software raid version.

I have a running Opera 10.63, as well. It was a direct upgrade from 9.27. I do have a KernelEX installed on this computer. But, I did not tested if 10.63 is running without the KernelEX support. Obserwations, so far: 1) I'm running the Opera on 9" 1024x600 Asus EEE PC. I had to increase the font size because it is difficult to see anything with so small screen. Apparently, the many dialog boxes in Opera 10.63 are exceeding the screen bounds in such a case. There were no such problems with Opera 9.27. 2) The Opera 10.63 started to give me strange "I'm alive" pages, instead of the proper ones. The effect was happening after opening Opera with saved previous session. The workaround is to turn Opera Turbo function on. After refreshing the page everything started to work correctly. 3) I had a problem with crashes after closing Opera 9.27. It was reletad to browser file cache, probably. There are no such problems with 10.63. 4) There are some strange effects related to pages with password access. After entering the correct password, the same password entry page gets displayed. In case of the pages with the cookie authentication it is enough to click another link. Clearly, the password has been accepted, and the cookie was received, but the browser does not go to the next page by itself. It displays the same password entry page instead. I've noticed something like that on Windows XP, as well. The problem is somehow related to the page link cache, probably.

After some time spent with Ultra VNC it appears the client has a bug related to the file transfers. When receiving a file from a server everything works fine. On the other hand, file sending takes so much CPU attention, so the system gets unstable. There is a hack to get through this problem. When connecting using browser and java client, the file sending is working much better. On the other hand the java browser does not seem to support capital polish national characters. I've tested the nawest TightVNC 2.0.2 and Ultra VNC 1.0.8.2. Both require Windows 2000, but the clients are functional in Windows 98 with KernelEX installed. Unfortunately, the KernelEX is not enough for the server part to work correctly. TightVNC 2.0.2 is no longer compatible with the old 1.3.10 client, when it comes to file transfers. It is necesary to use the 2.0.2 client for that purpose. The java client does not support file transfers, as well. Another problem is national support. I've been unable to get polish national characters entered correctly through the VNC connection. UltraVNC 1.0.8.2 seems to be working the same as the 1.0.2 one. The server and client are working with older counterparts. I saw no apparent improvements from the Windows 98 compatible version, so far. The java clients of the TightVNC and Ultra VNC are deserving a separate description. It appears they are using the same code as the backbone, because both are unable to pass the capital polish national characters. They are looking almost exactly the same. But, the Ultra VNC client does have a working file transfer button.

In my case it's Bmpimp32.flt 4.0. BMP is only in the Import registry section. Anyways, the problems with printing are not related to the bitmap format. The problem remains the same, as long as the uncompressed bitmap exceeds 16MB. So, converting a file from BMP to JPG changes nothing, if the same resolution and color depth are used.

All hardware based ramdisk solutions have to be slower then software ones. The speed of the IO operations is limited by the construction of the IO buses, while the RAM controller and modules will always be faster. Still, it is visible, the NT based ramdisk is faster, than the DOS based one. But, I would like to test if the ramdisk would be faster than the Windows 98 file caching system. Right now I'm using the file cache setting of 800000. The script copies the file to the nul device, before launching video player. As the result, the whole file gets loaded to the file cache, and there are no hard drive operations during playback. I'm also curious, if the ramdrives are cached by the Windows. If so, there are no point in using ramdrives, in my case.

Ok. I have yet another update on the topic. Apparently, there are two versions of Google Picasa 2 available for download. The older one is Windows 98 compatible, but has less languages available. The newer one is for Windows 2000, supports Polish language and seems to be working fine with KernelEX. So, there is no need to use Picasa 3 in my particular case. The only bad side is, the Picasa is centered around album creation. So, it is not a perfect choice for someone who wants just to print a bitmap.

It does not seem to make any difference. SRDISK: http://www.msfn.org/board/index.php?showtopic=109574 http://www.msfn.org/board/index.php?showtopic=109574&st=13 http://sourceforge.net/projects/srdisk/ jaclaz I did not have much time to read through all the provided links, but the outcome is significally different in this particular case. I mean, I'm getting a following error message: "VFAT Device Initialization Failed A device or resource required by VFAT is not present or is unavailable. VFAT cannot continue loading." I had an opportunity to play the same video on two computers with the same single core P4 2.4GHz CPU. One was running Windows 98, the other a standard installation of Windows XP. As expected, the quality of output video on the Windows 98 was significantly higher. The output from the XP was quite a choppy one, while on Windows 98 video was freezing only during complicated scenes with both moving text and images blurring one to another. Apparently, CPU has to work much more during such scenes. As for all DOS based ram drives. In theory, they would require the CPU to switch between 16bit and 32bit modes in order to function. The construction of the single core P4 CPU should make every such a change to be a significantly long one. So, it is quite possible, loading the whole file in the windows file cache, could give better results, as the CPU mode switching would not be necesary. However, I was not able to prove the point, as I was unable to run Windows 98 with large enough ramdrive, so far.

Finally I've found some time to get back to this issue. The HIMEMX.EXE changed nothing, I'm afraid. Other time consuming tests will have to wait.

The ram drive is working and VOL command works correctly, all right. But the Windows stops on IOS device initialization (Bootlog.txt). ASD reports problem with reading ESCD data from PnP BIOS. I'm experimenting with Dell Optiplex GX260. I was unable to get Ati All In Wonder 9000 working with ACPI in this particular computer. So, I had to fall back to APM to get the grahics card working. The same problem happend with NVidia GPU, so it seems there are some BIOS related problems here. The problem with GUI booting along with the ram drive does not seem to be related to a specific GPU, as the same story happens with the onboard Intel 845 graphics controller. I'm using XMSDSK.EXE 1.9I I've noticed my MaxFileCache setting was a bit below 400000. So, less than a half of memory was used for file caching. I understand, why I had doubts in large file caching efficiency, now.

In my particular case the gui does not start, after loading XMSDSK.EXE 512000 from the AUTOEXEC.BAT. The CONFIG.SYS does contain just the FILES=240 statement and code page related settings. The AUTOEXEC.BAT contains just the XMSDSK,exe and some code page related entries, as well. The Microsoft ramdrive.sys is unusable, as it is unable to manage ram drives exceeding 32MB.

I want to do a few experiments related to CPU demanding video playback. I would like to compare the results while playing from ram drive and HDD. To be more specific, I would like to test the efficiency of the Windows 98 disk caching system. I'm curious if the ramdrive will be faster than the disk cache. Or rather which way saves more of the CPU power. The task demands to create a large ramdrive (512MB or so). I've tried XMSDSK.EXE so far, but I was not able to start GUI along with it. Are there any other suitable ramdrive solutions available? I do understand different ramdrive drivers can work with different efficiency. So, the DOS based ones do not seem to be a good choice, probably. The test computer does have Windows 98 SE SP 2.1 with 1GB of RAM. It works fine without any ramdrive for the time being.

It seems Google Picasa 3.6 works better, now. But, still, there are some problems left. The settings dialog works in general. There are no error messages, and the options are displayed, at last. But for some reason drop down lists are not working. Luckily it is possible to change values with keyboard up and down arrow keys. - the default KernelEX compatibility mode Everything seems to be working fine, except for the language selection option. For some reason this drop down list is disabled. The language is always set to english. - Windows 2000 and XP KernelEX compatibility mode The language selection drop down list is active, so it is possible to change the language. Also the default setting is "system default language". On the other hand, it is necesary to walk through initial settings dialogs (search folder selection and extension selection) every time the Picasa starts. Also there are some problems with built in Picasa folder exploration.

Nope. In my case it is Universal Vesa/VBE driver.

GOM Player works fine on Windows 98 without Kernel EX installed.

Looks like I have the same problem. When icons are set to 32 bit mode, some of them do have addidtional black edges. When set to 16bit or 4 bit mode, the edges are gone, but the icons are pale, instead. The best example seems to be the standard text/notepad explorer file icon.

I've installed the Picasa 3.6 in the Windows XP SP2 compatibility mode. The first run in the same mode worked correctly with the proper (Polish) language. But, then I tried to change the options. After that the Picasa returned to English, and the file exploration stopped working. I can change the language back to Polish, but exploration stopped working for good. There is some problems with the configuration changes of the Picasa 3.6 in Windows XP compatibility mode. Just change Options once and the settings are getting messed up. Reinstallation is required, to make file exploration work again.

Google Picasa 3.6 does work with KernelEX 4.5 RC1 in general. But there are some problems. One of them is invisible Tools - Options - General tab. - default compatibility mode - the language is forced to English, and it is not possible to change it since the Options - General tab is not visible. But, everything else seems to be working fine. While accessing Options an error message dialog appears with "Improper Access" message (the message is always in my local Polish language, I had to translate it from "Niewłaściwe dojście"). - Windows 2000 or newer compatibility mode - the language is automaticaly set to the local one. There are no error message when accessing Options dialog. The initial settings are not remembered. So, Picasa asks for them at every run. The file exploration does not work. It seems the Picasa 3 is the only completely free application (all others are just free for noncommercial use), able to print large bitmaps (over 16MB in size) in Windows 98, with Polish language support. The only problem is I can not turn the Polish language on, without sacrificing other functions.

Google Picasa 3.6 does support Polish language. It is possible to run it with KernelEX and it prints correctly. However, the language settings in Options - General tab are not visible. So, it is not possible to switch the language. The default language is English. The situation changes when switched KernelEX compatibility mode from default to Windows 2000 (or newer). By just accessing the General tab, and saving the settings language changes to Polish. However, Picasa does not seem to remember initial settings in this kind of KernelEX compatibility mode, and file browsing does not seem to work, as well.