jds

I did some brief experimentation on MSW-ME over the weekend, and this seemed able to install drivers whose INF's had Section Names exceeding 31 characters. However, the WinXP-SP1-DDK had this to say : So, either the symptoms with MSW-ME are more subtle, or else it doesn't have the same limitation on length of Section Names, in which case the above DDK documentation is in error (at least regarding MSW-ME). Joe.

Might be relevant/helpful : Joe.

The point is that unless you can give more information about your wifi card, we cannot advise what connection software to use, normally this comes from the OEM with the driver. Joe.

I have tried this build. It is much worse than 2.0.0.20. I don't remember exact details, but it seems more unstable, has more troubles with extensions, and doesn't work with flash. Do try to remember! I use Bon Echo 22pre all the time, and the only issue I have with it, is unresponsive (slow) Javascript. Flash also works fine, so can you give more details on that problem too? That said, I now prefer the current version of Opera with KernelEx , not sure how 10.63 compares with this, if it's similar I would consider it for native W98. Joe.

Well, XP is more vulnerable to malware due to its inbuilt behaviour, not just its abundance. Anyway, if your machine is too feeble for XP, then you'd expect its hardware (eg. wifi card) are supported by an earlier version, such as W98SE or W2K. Try one of the utilities I mentioned here and get more details about your wifi card. Joe.

Yes, that is my understanding (once I managed to find the paragraph in the DDK documentation). Initially what I found was that "decorated" Section Names for NT (which are correspondingly longer than the "undecorated" ones) were preventing the driver loading in W98SE, when they exceeded 31 characters. The documentation says they should be no more than 28 characters, so I don't know if there are more subtle problems in the 29-31 character range. Joe.

It was once common practice to write device driver packages to support both W9X and NT. However, without proper testing, you may sometimes encounter issues with W9X compatibility. Here are two examples that I've encountered so far : 1. INF files are limited to just under 64KB with W9X. I first encountered this issue with a Ralink device driver where, as new OEM's had been added to the relevant INF file, this had grown beyond 64KB in size. Once I realized that was the problem, I removed the sections and models related to a few OEM's (not the one for my piece of hardware, of course), until the size was satisfactory. Then everything installed OK. 2. Section Names are limited to 28 characters with W9X. I've just encountered this issue with a Connexant driver that refused to install. The W2K DDK says "A section name has a maximum length of 255 bytes on Microsoft Windows 2000. On Windows 98, section names should be no longer than 28 characters. INFs designed to work on both platforms must adhere to the smaller limit." I can confirm that any Section Name exceeding 31 characters will prevent such a driver installing on W98SE. HTH Joe.

Of course, refer to for detailed information on installing the Reader ... Now, here's how to install new language fonts : 1. When Acrobat Reader 7 says it needs to download a font, click "OK". 2. Find and download the installer script : i) Look into file : %windir%\Application Data\Adobe\Acrobat\7.0\Updater\udlog.txt ii) Find URL text and download, eg. : http://update.adobe.com/pub/adobe/acrobat/js/7x/rdr/win/enu/DataScript.js 2. Find and download the font installer : i) Look into the above script file ii) Find URL text and download, eg. : http://ardownload.adobe.com/pub/adobe/reader/win/7x/7.0.5/misc/alf_jpn.exe 3. Start the font installer, eg. : alf_jpn.exe 4. Wait at error : "This application requires Reader 7.0 installed ..." (Note, with jumper's Kext (KStub) installed, you may succeed at this point, in which case, you can omit the remainder.) 5. Look for the font package in a subdirectory of %TMP% and copy to a safe place, eg. : %TMP%\_is5250\Adobe Reader Japanese Fonts.msi 6. Click "OK" on above error message, then click "Finish" 7. Create a temporary directory to extract the font package, eg. : md C:\temp.msi 8. Extract package using 'anti-msi.bat' (see note below) : anti-msi adober~1.msi C:\temp.msi 9. Copy directory contents of 'C:\temp.msi\Common' to 'C:\Program Files\Common Files' (Click "Yes to all" when prompted) 10. Copy directory contents of 'C:\temp.msi\program files' to 'C:\Program Files' (Click "Yes to all" when prompted) 11. Execute (start/double-click) : C:\temp.msi\adober~1.msi If the error "This application requires Reader 7.0 installed ..." appears : i) Using Orca, delete action 'IsReader70' from table 'InstallUISequence' ii) Save (beware of "Save As", it may omit stuff) and try it again. Note, here's a sample 'anti-msi.bat' file : @echo off if $%1==$ goto Usage if $%1==$/? goto Usage if $%2==$ goto Usage if $%2==$/? goto Usage %windir%\system\msiexec /a %1 /qb /L*v %TMP%\msiexec.err TARGETDIR=%2 goto End :Usage echo Usage : ANTI-MSI MSI_File Target_Directory echo. echo Note, Target_Directory needs to include the drive letter and path! :End Joe.

What is the native capability of IO.SYS, 512 bytes or 2K bytes? (The last part of that comment at least, implies 512 bytes.) BTW, I just purchased a cheap MP3/MP4 player whose sector size (via USB) is 1KB. I'm having some difficulties with it (in all O/S, from DOS to Vista), but that may be due to the quality (or lack thereof) of its Flash, rather than its sector size. It's formatted as a "Super Floppy" (sans MBR). Anyway, that's what led me to re-read this thread. Joe.

Which is all the more reason you need to consider flashing the updated BIOS! Sure, Dell may not document what they've fixed (especially for such an old product), but at least this sort of thing, I would expect them to have fixed. However, if you've done some tricks to get that second drive working, perhaps it won't after the update (just tread carefully with it). Your first drive should be fine, since you haven't needed any trickery for it. As regards your PCI card, sure I agree with the others, perhaps it's faulty. You should test it on a known machine to be sure. However, if it's simply the case that your BIOS has failed to allocate resources to it, then that would explain what's happening. (1) Check for some "non-PnP-O/S" or similar setting, (2)update your BIOS. (3) If that fails, try loading that 'DWCFGMG.SYS' driver in your 'config.sys' file (before the other USB stuff). Now, you may also want to play around with some PCI diagnostic utilities. Try : http://redir.no-ip.org/mirrors/members.datafast.net.au/dft0802/ http://www.sac.sk/files.php?d=13&l=P Joe.

Well, all PCI devices are PnP, so an MB supporting PCI must support PnP, I should think. The web page you referenced says "In the mid-1990s, PC vendors began to update their motherboards with a PnP BIOS", which is about the age of your MB, so that seems consistent. Don't forget to check for an updated BIOS, just in case of bugs in its PnP support. Now, I'm not familiar with 'DWCFGMG.SYS', and this may perhaps be for ISA-PnP support, but certainly the brief description suggests some sort of PnP support anyway. A search of the web reveals it's associated with 'ICU.EXE' from Intel, however, the URL "ftp://download.intel.com/design/motherbd/icu/" no longer points to anything. However, 'DWCFGMG.SYS' can be found in 'Driver20.cab' on the W98SE CD-ROM. Once you get this all going, I'd suggest ditching the floppy and have a boot menu in 'config.sys'. HTH, Joe.

Jorge, You should not manually assign IRQ's for PCI devices, only ISA devices, and even that would be only for non-PnP ones. What you may need to do, is set some BIOS setting to "non-PnP O/S" or some such. This would tell the BIOS that it's its job to assign resources for PnP devices, particularly PCI cards. Not sure if this would also handle ISA-PnP device resources, typically that is handled by a small utility after boot. The BIOS will exclude any IRQ you've manually assigned, when it's working out available resources for PnP devices. Joe. PS. Also check for a BIOS update for your MB.

H2testw 1.4 This is the recommended software to weed out fake-capacity USB drives, which sometimes are offered on eBay (and similar sites, I suppose). Runs in German or English modes. KEX 4.5.1, no special compatibility mode required. http://www.heise.de/software/download/h2testw/50539 Joe.

* His BIOS doesn't need to know anything about USB. In fact, it could complicate things if it did. * His BIOS doesn't need to know anything specific about his PCI card. The fact that it has PCI slots means the BIOS will know enough to assign appropriate resources (IRQ, I/O, memory addresses) to the card. From there, it's up to the 'usbaspi.sys' driver, to know and support the card's chipset. Joe.

I don't know which particular flavour of 'usbaspi.sys' is 'usbaspi1.sys', however, my recommendation is the Panasonic version, which from memory is available on their web site in a archive named 'f2h_usb.exe'. Then your next choice is which disk driver to run on top of this. My recommendation is one of : 1. 'di1000dd.sys' - supports fixed media format (MBR) only, provides an Int 13h interface. 2. 'nj32disk.sys' - supports removable media format (no MBR) only. 3. 'aspidisk.sys' - supports both media formats. Generally, I use #3, except if I need to use 'fdisk' on a fixed media format drive, in which case I use 'di1000dd.sys'. Actually, that's a lie, because if I need to use 'fdisk', it's usually because the MBR is broken, in which case 'di1000dd.sys' will usually crash anyway. So I use my own tools to read/write the MBR to/from a local (temporary) file and Norton's 'diskedit' to play around with the partition table within the local file. Now, here's an extract from my 'config.sys' : [DOS_USB] REM - Panasonic's universal USB-controller driver (formerly Novac) device=C:\ASPI_USB.DRV\PANASONC\USBASPI.SYS /v /w REM - Adaptec's ASPI disk driver (supports with/without partition table) device=c:\ASPI_USB.DRV\Adaptec\aspidisk.sys You need to check where your crash occurs, is it with 'usbaspi.sys' or 'di1000dd.sys'? One tip - The Panasonic 'usbaspi.sys' driver works very well with most (but not all) USB hubs. So much so, that the compatibility with various drives is almost 100% if you connect via such a hub, rather than directly via a root hub. Finally, there's no reason to dismiss WFW3.11 as a possibility here. It should work. Joe.

The thought I had was that it may be possible to load the USB drivers, then from DOS/MSW, bootstrap a suitable Linux kernel image with the help of 'loadlin' version 1.6c (or a later version, if such exists). A suitable kernel image would be one with inbuilt support for USB (you'll need to do some research on this). When I used to play around with Linux some time back (no time for such things at the moment, unfortunately), this is the command (via a batch file) that would do the trick: f:\linux\loadlin f:\linux\mandrake\vmlinuz root=/dev/hdb4 ro %1 (I think the 'root' option would need to point to your USB drive, in whatever form this would/will enumerate in Linux.) Good luck. Joe.

Yes, the first part is basically how I used USB Flash drives on W95. Worked OK, but very extensive data transfers would sometimes cause lock-ups. The second part depends on what you mean by OS. You basically boot MS-DOS 7.XX then bootstrap something else, like the MSW GUI. However, I've not tried using USB drivers in MS-DOS 6.2X. I can tell you they don't work with DR-DOS 6, although they do with DR-DOS 7. So your starting point is some recent version of DOS, from there you could boot Linux, maybe. Joe.

Impressive! Not as responsive as Opera, but doesn't have the random communications errors of Opera, either. Installed and working well on my P2 (using FineSSE29, not sure if that's relevant) and my P3. Needed to set the installer compatibility mode to W2000SP4, then needed to get the "msvc?90.dll" files from : http://www.microsoft.com/downloads/info.aspx?na=41&srcfamilyid=2051a0c1-c9b5-4b0a-a8f5-770a549fd78c&srcdisplaylang=en&u=http%3a%2f%2fdownload.microsoft.com%2fdownload%2f9%2f7%2f7%2f977B481A-7BA6-4E30-AC40-ED51EB2028F2%2fvcredist_x86.exe (security update KB973552; extracted using 7-Zip, renamed and copied to %windir%\system) Two problems so far : History doesn't work (brings up a page called "Library" instead). Java doesn't work (same problem as with Opera) : "Before Firefox can run Java applets you must have the Java plugin properly installed and enabled. Firefox also requires the new Java plugin included in Java 6 Update 10 or above." (I hope KernelEx can support this new-style plugin for Java, sometime soon.) Joe.

Well, thanks to this old MSFN thread : ... and the Internet Archive ... and a little sleuthing ... I'd suggest the following candidates for the W98 DDK and the above-mentioned SYM files : http://web.archive.org/web/20060511205951/http://www.arte.unipi.it/Public/Win32/win98ddk.exe http://web.archive.org/web/20060511193634/http://www.arte.unipi.it/Public/Win32/98RtSym7.exe Joe.

Yeah! You've done it, jumper! I've changed the VLC 1.1.9 desktop shortcut properties to : E:\Winstall\Patches\finesse29.exe -a6000 "E:\Program Files\VideoLAN\VLC\vlc.exe" Now I can start VLC, wait 6 seconds, then open and display any media files very nicely (I initially tried the "-a" option by itself, but that didn't work). A fantastic work-around for those pesky media files that don't work properly with alternative media players. BTW, there is a side-effect that invoking VLC in this way causes the Tools/Preferences menu to display Chinese/Japanese characters, so to fiddle with settings, just invoke VLC normally. Joe.

The last version to install natively on W98SE is 1.6u7. I previously used 1.5u21 and 1.5u22. I had uninstalled the MS Java from IE first, before starting with Sun. Opera is another matter. Seems it needs the "new style" plugin or something, which started at 1.6u10 or 1.6u11 (one of those two). However, AFAIK, the "new style" plugin is not compatible even with KernelEx, so I don't know what the solution is for Opera Java. Joe.

I can't help but shake my head when people ... adopt the herd mentality and accept cumbersome, boated, unsafe (thanks for all those "enhanced" features and back doors, eh) and incompatible OS ... Anyway, just a quick (and long overdue) update - KernelEx has come a long way since this thread was started, and UE 1.6 no longer presents a problem on W98. However, now we too can enjoy this old UE bug : What I found was that UE initially worked OK, but some time (months?) later, I noticed a problem opening ZIP or CAB files (however, UE is not first choice, so perhaps I'd never tried this before; BTW, I can't remember the error) but it worked OK for EXE files. Now some further time later (months?), it no longer works at all, due to the above bug. Is there a realistic solution, other than the suggestion to reformat the hard drive? Oh, and AutoIt by itself runs just fine, so it doesn't seem to be the culprit. Joe.

Have you tried W2K compatibility mode? I've found some app's are no good using XP compatibility mode, but are fine using W2K mode. Joe.

Hi jumper, Yes, KernelEx does a fine job running some (but not all) versions of VLC. I haven't tried them all, but prior to 1.1.9, the other version that ran well for me, was 1.0.3 (if I remember correctly). However, 1.1.9 doesn't run properly on my P2 and 1.0.3 swaps the red and blue colours (at least for 16-bit colour depth), so is a "last choice". Well, I finally figured how to do this with VC++ 4.2 (which is installed on my P3) : File Open Workspace File name : ~~~~\vlc.exe File of type : Executable Files Build Execute vlc.exe The above ran VLC normally. File Open Workspace File name : ~~~~\vlc.exe File of type : Executable Files Build Degug Go The above opened the main VLC GUI, but the menus could not be selected. It didn't open off-screen, but this might be video driver related or such. So it's somewhat similar to starting VLC via FineSSE. On exit, the following debug information was presented : First-chance exception in vlc.exe (KERNEL32.DLL): 0xC0000005: Access Violation. The thread 0xFFEC1C1D has exited with code 0 (0x0). The thread 0xFFEC1ADD has exited with code 0 (0x0). The thread 0xFFEC2019 has exited with code 0 (0x0). The thread 0xFFEC0A25 has exited with code -1 (0xFFFFFFFF). The program 'E:\Program Files\VideoLAN\Vlc\vlc.exe' has exited with code 0 (0x0). I couldn't find a way to "attach" VLC to the VC++ debugger after starting it. Maybe that's a feature only of later editions. Although there should be an automatic attachment to the debugger following a crash, VLC doesn't normally crash on this P3, and in any case, VLC would no doubt handle exceptions itself, just as when FineSSE is the system's debugger. Joe. PS. I've now repeated the VC++ debugger test on the P2. This exhibits the "open window off-screen" problem if ever the previous run of VLC was in windowed mode. For example, if VLC was run normally, in windowed mode, it would appear on-screen, but on a subsequent run in the debugger, it would be off-screen at some random location (once in a while, one window edge would be just visible). OTOH, if the previous run of VLC was a maximized window, then in a subsequent run via the debugger, it would again appear maximized. So this "off-screen" behaviour is indeed a side-effect of running VLC in a debugging session. PPS. Back to the P3, I first ran VLC normally, changed from a maximized window to a normal/resizeable one. After this, running VLC in a debugging session produced the same "off-screen" window behaviour as the P2. However, I found that the inability to select any menu could be overcome by using the keyboard. Pressing "Alt-H", then "Enter" produced a few Chinese or Japanese characters. Pressing "Alt-M", then "Enter" allowed me to open some JPEG files. After exiting, the VC++ debugger window showed : First-chance exception in vlc.exe (KERNEL32.DLL): 0xC0000005: Access Violation. The thread 0xFFEA5EF3 has exited with code 0 (0x0). The thread 0xFFEBA9B3 has exited with code 0 (0x0). The thread 0xFFEA586B has exited with code 0 (0x0). The thread 0xFFEC3E23 has exited with code 0 (0x0). The thread 0xFFEBCF63 has exited with code 0 (0x0). The thread 0xFFEB990B has exited with code 0 (0x0). The thread 0xFFEC139B has exited with code 0 (0x0). The thread 0xFFEC1C53 has exited with code 0 (0x0). The thread 0xFFEC2CDB has exited with code 0 (0x0). The thread 0xFFEC0307 has exited with code 0 (0x0). The thread 0xFFEC0757 has exited with code 0 (0x0). The thread 0xFFEC1A6F has exited with code 0 (0x0). The thread 0xFFEC0B13 has exited with code 0 (0x0). The thread 0xFFEC0DC7 has exited with code 0 (0x0). The thread 0xFFEC63A7 has exited with code 0 (0x0). The thread 0xFFEC658B has exited with code 0 (0x0). The thread 0xFFEC61F3 has exited with code 0 (0x0). The thread 0xFFEC569F has exited with code 0 (0x0). The thread 0xFFEC6F0F has exited with code 0 (0x0). The thread 0xFFEC5D9F has exited with code 0 (0x0). The thread 0xFFEC51AF has exited with code 0 (0x0). The thread 0xFFEC540B has exited with code 0 (0x0). The thread 0xFFEA6613 has exited with code 0 (0x0). The thread 0xFFEA63D3 has exited with code 0 (0x0). The thread 0xFFEA0A17 has exited with code 0 (0x0). The thread 0xFFEA56E3 has exited with code -1 (0xFFFFFFFF). The thread 0xFFEC787F has exited with code -1 (0xFFFFFFFF). The program 'E:\Program Files\VideoLAN\Vlc\vlc.exe' has exited with code 0 (0x0). BTW, the "Advanced settings" mode allows to select (via the GUI) different CPU features, such as SSE, however this doesn't seem to do anything.

Actually, no version of KernelEx has ever supported W95. Apparently, there's sufficient difference such that it would significantly add to the work required for KernelEx. So unless someone with the skills and time can port KernelEx to W95, you're out of luck. Joe.