jds

The latest Real Player for Win9x is 10.5GOLD. Real Player uses different Codecs than Real Alternative uses, and the program's author, Real Media, does download additional Codecs, if available, and as needed. So, you might want to try Real Player 10.5, to see if it plays your newer Real Media files. Thanks, I'll give that a go. BTW, Real Player 6 tries to download an update, but then says the O/S is no longer supported, unless KernelEx is employed, in which case it says there's nothing available. I'm not sure if it's possible to download CODEC's per se from "real.com", the impression I get is that you have to update the whole package, as you've suggested. Pity the independent CODEC's aren't up-to-date. Joe.

Excellent technical discussion. I only have time to quickly address this particular question for now. The following is from the readme file from MDGx's modified driver. USBASPI.EXE is a modification of the recently released Panasonic native DOS USB driver USBASPI.SYS ver 2.28. I found a reference to that new version on a recent MSFN post: http://www.msfn.org/board/index.php?showtopic=40561 http://www.msfn.org/board/index.php?showtopic=114868&pid=753965 The modification was necessary as I experienced system lockups on PCs where the BIOS supports some USB mass storage devices, such as USB floppy drives, USB ZIP drives and USB CD-ROM drives, but, for example, not all USB memory sticks or hard drives. With the command line switch /w the driver now pauses *after* the USB controllers have been initialized. When USB mass storage devices are connected at that point, the lockups no longer occur. The original functionality, that is, the driver pauses *before* the controllers are initialized is still possible with the following command line switch: USBASPI.EXE /w /w Thanks! Sounds like a useful hack, however I'm still puzzled by the version numbering. The current official version is available via the web page : http://panasonic.co.jp/pcc/products/drive/other/f2h_usb.html (You can use 7-Zip to extract 'USBASPI.SYS' from 'f2h_usb.exe') This contains the string "Version 2.27 ©Copyright Panasonic Communications Co., Ltd. 2000-2008". [ Edit: The download page is now: http://panasonic.jp/com/support/drive/other/f2h_usb.html ] OTOH, the modified version (once you unpack it with UPX) contains the string "Version 2.28 ©Copyright Panasonic Communications Co., Ltd. 2000-2007". Trying to search for the origins of the modified version is unfruitful. However, it seems version 2.24 had the copyright "2000-2007", so that's a possibility ... Strange. As I said, I found both ASPIDISK.SYS and DI1000DD.SYS to only be stable for partitions less than 64G (although I didn't do exhaustive testing of primary vs. extended/logical partitions). Just partition accordingly and you don't need to hunt down a smaller disk (the extra space could be used for NTFS or EXT3, I suppose). True. But even if you decide to sell it and maybe get another one, perhaps smaller... or none at all, in any case, now you know all you need to partition / format your next HDD to suit perfectly your needs. During the 1 TB disk tenure with you you probably learned many things you'd never envisaged you one day would. So it's not a total loss. BTW, I'd give options (i) and (ii) a try. I think ASPIEHCI.SYS/GUEST.EXE may work. I tried GUEST.EXE again, this time I know it was version 8.5. No good. Assigns a drive letter OK (J:) but then constantly gives a nonsensical error message "Write protect error reading drive A:". Joe.

Workbit's NJ32DISK.SYS seems to be derived from Novac's DI1000DD.SYS (or an earlier work perhaps) and the dates I have for these files are 2002/04/03 and 2001/08/16, respectively. (This is contrary to your indication that DI1000DD.SYS is newer, perhaps you've found a newer version of this?) However, NJ32DISK.SYS only supports "superfloppy" format, whereas DI1000DD.SYS only supports "hard disk" format. They cannot be considered alternatives of each other! Adaptec's ASPIDISK.SYS supports both "superfloppy" and "hard disk" formats. FWIW, I have found both DI1000DD.SYS and ASPIDISK.SYS to be stable only with partitions up to 64G in size. I prefer ASPIDISK.SYS for its versatility and stability, however, it doesn't provide an INT13 interface, so if I want to use FDISK, then I revert to DI1000DD.SYS (however, there's a Catch 22 in that). I have never had any luck with IOmega's GUEST.EXE, although I don't know which versions I've tried. Does anyone know, what exactly was the modification mentioned above? While I found two links for "More Info" at MDGx's site, neither of them explained about this modification. Also a tip. The Panasonic driver works VERY well via a USB hub. So well in fact, that many USB drives that won't work when connected directly to the root hub, WILL work via an external hub. However, not all external hubs seem compatible (eg. I have two hubs based on two different NEC chips, one works beautifully, the other won't work at all). Find a hub that's compatible (most seem to be), and your success with different USB drives will improve dramatically. The latest ASPIEHCI.SYS that I have is dated 2003/05/28 and has a CRC32 of BE9DA061. It came from Ghost 2003 update file '1165278149jtun_ng2003b789_en.x86.full.zip'. Do you have a later one dated 2003/09/13 or is it the same (per CRC32)? Incidentally, Symantec dropped these IOmega drivers for Ghost 8.3.1331 (because they were unhappy with their hardware compatibility) and built USB support directly into Ghost and GDISK. For some strange reason, Ghost's inbuilt USB support doesn't work for me, yet with GDISK, it does! BTW, GDISK (8.3.1331) is what I now use to "FDISK" a new USB drive, since the USBASPI+DI1000DD combination (well, DI1000DD really) will crash if it doesn't like the existing partitioning. (Sometimes I also use the USBASPI driver by itself, read and write the MBR with a couple of my own utilities, and edit the MBR image with DISKEDIT from Symantec's 'ned_2001.exe'.) Joe. PS. @piikea: ASPIDISK .SYS is available in archives ASPIDOS.ZIP and DOSDRVR.ZIP, one or both of which should be available at Adaptec's site.

Is there a CODEC available for newer Real Media files, either via real.com or an independent CODEC? (The Real Alternative CODEC doesn't handle newer files.) Joe.

As a general observation, often HP will be missing a needed driver for one model, yet have the required driver available for a different model using the same chip. It takes some guesswork to find a compatible model, though. Dell have a combined driver package from Intel which includes the 82801AA (ICH) chip : ftp://ftp.dell.com/chipset/Z0377C01.exe Once that is installed, there may need to be an additional driver, since the 82801AA only provides a CODEC interface, so that's an additional chip. Try the Intel driver first, if any other is then required, at least you'll see what it is. Joe.

S&D seems to have exponential/hyperbolic memory & cpu needs as its malware database grows, such that soon enough, it needs to virtualize those memory needs. To make matters worse, it seems to shuffle memory around ad infinitum, you'd think it was bubble sorting those hundreds of megs of memory it seems to chew through, and remember, that's going to be all the more painful when it's virtual memory! Exasperating! That's why it slows to a crawl on your Vista PC, and I'm sure there's a limit to how much virtual memory W98 can handle before it crashes, which is what it's doing. Just my view of what S&D does ... take a look at your swap file size as it scans on your W98 machine. Joe.

It's surprising but there doesn't seem to be a copy at MDGx's site. You should try the author's e-mail address, given at (see 2010/12/07 blog entry) : http://ysai187.blogs.linkbucks.com/ Joe.

I beg to disagree. I never had any MAC address conflicts, and even if I had I would consider my privacy a higher good.If there is a conflict of MAC addresses, it's maybe an issue in the government computers recording information. Duplicate MAC addresses could be seen by government computers just like 2 persons having been assigned the same social security number, not my problem. Duplicate MAC addresses perhaps making it harder on government computers might be those in the vicinity, displayed in the site survery, etc of the WLAN card. If I remember right, there was a story about internet traffic going thru the computers of US agencies. Firstly, internet traffic can and does travel via a multitude of routes. If two devices have a conflicting MAC address and their traffic "crosses paths" somewhere (well, certainly at the ISP if they should happen to share this), then undefined errors and bugs will occur that impact on one or both of these devices. This has happened at least once before, to a NIC manufacturer that accidentally re-used some MAC addresses. Don't cause such troubles deliberately, else you really will get "unwanted" attention. Secondly, don't think that changing your MAC address will in any way prevent you from being tracked down. If the internet data packets can find you, so can whatever agencies may also wish to find you. To see the MAC address of your router (or any other device on your subnet), open a command shell and type : ping the_device_address_or_hostname arp -a Joe.

And, what version do you have? Can you share it with us? On closer inspection ... the dates are newer, but the files are the same - except for 'advpack.dll' which is 6.00.2900.2180 (rather than 5.00.2013.1301). No, there's no problem using the Panasonic + Various (eg. Adaptec) combination drivers for DOS, with USB drive partitions up to 64G. The issue here relates to individual files in the 2G-4G size range. BTW as you no doubt know, Ghost will split its image files so they don't exceed 2G [edit: I got that wrong, the split is just under 4G; I think Ghost works at a lower level and hence avoids this 2G bug]. Cool. Thanks for the clarification and thanks for the patch, Mr. Loew. Sigh! I miss her. Joe.

Hi, Just wondering, does anyone know if any version of Adobe Air can install in W98SE, with or without KernelEx? I've tried a bunch of versions from File Hippo and Old Apps, but no luck. BTW, this Adobe Air seems to be some sort of alternative to Javascript, from what I can figure. Or maybe even a bit like Java? Just what the world needs, yet another way of doing the same things as already exists, but with the extra opportunities for incompatibility and immaturity. Joe.

@jds: While not mandatory, I usually add the Unofficial Win 9x Stack Corruption, 98KRNLUP, which installs Krnl386.exe v. 04.10.00.2000, to the mix, too. This completes the available updates to Win 9x core files. That's right, those patches are installed (except for 98KRNLUP, since my DLL's seem newer than this). I can copy the file via Windows Explorer and I can open it with HashCalc (SlavaSoft), but any 16 bit application, including COMMAND.COM (eg. 'copy' and 'type') seems to fail. OK, downloaded these MS utilities and they work fine. However, these are 32 bit applications, so these go via the standard Windows functions that have the 2G patch, so that's to be expected. I tried to induce CRC.EXE to work in pure DOS with the help of the HX Extender, but no luck. They really don't want to work at all in DOS, do you know a way? (Similarly for FCIV.EXE, although I didn't bother trying HX with that.) BTW, don't forget that the 16 bit CHKSUM utility I use (sort of as a replacement for XDIR;-) worked with that large ISO image under FreeDOS (also under Vista), so the utility itself is fine. OK, I tried this and it didn't make a difference. Not surprising, since none of the things I tried would have had any reason to Seek other than from the beginning. BTW, note that your patched DLL is build 4.10.2225, whereas the version I was using was 4.10.2226. (No idea what that extra build stepping gives.) Joe.

FYI. Well, here's a new one (well, I don't recall reading about this anywhere before). I was investigating reliability of high-capacity Flash drives (I've experienced some occasional problems on my Medion USB stick where an 8K chunk within a file is junk; no errors reported when writing or later, when reading such files) and had copied a large ISO image [edit: I forgot to mention, it exceeded 2G] to my hard drive via Windows Explorer. This is on a W98SE system with the 2G Copy patch applied. I then tried to run Charles Dye's CHKSUM utility to verify the file from it's CRC32 value. This reported "--------" for the CRC32 and "0005" for the XDIR checksum, and said that 1 error had been encountered while reading the file. Strange. What did this all mean? Well, what it meant was that Runtime Error 5 (Access Denied) had been encountered when attempting to read the file. Yet, I had run the same CHKSUM utility on a Vista machine with the same file and it had worked OK there. So, the CHKSUM utility itself wasn't the problem. I then tried other 16 bit applications to access the file in question, and all of them failed with Runtime Error 5 or Access Denied. Even trying the internal "copy" and "type" commands produced the same result. Finally, I tried the same thing in pure DOS mode. Using MS-DOS 7.10, the same problem occurred. Using FreeDOS 1.0 (using the installation CD as a Live CD), no such problem. So it seems there's a 2G file size problem in MS-DOS 7.10, which also seems to affect (or perhaps it's yet a separate problem?) all 16 bit applications running under W98SE. Joe.

The link is to the archive.org as Geocities is now dead: http://web.archive.org/web/20091027011611/http://geocities.com/dalex_257/ The downloads for the binary and the source function. The source code seems to be licensed under "GPL V 2, or, at your option, later". I have not used it and have no opinion of it. Just thought someone might like to see it or try it. Edit: I may have spoke to soon as you can read it was designed for a specific product and doesn't emulate instructions, simply skips them. I guess it could still be of some interest. Yes, I found this too during my search (http://geocities.ws/dalex_257/ also has the last version of this site, and works better than good ol' Internet Archive) but unfortunately, this is coded for NT and doesn't work on 9X (I tried!); also my attempts to do similar "systems programming" ( see ) were a failure. From what this Dave fellow says, the SSE instruction that was causing trouble corresponded to an MMX instruction with a prefix, so what his driver did was intercept the illegal SSE instruction, skip the prefix, then execute the corresponding MMX instruction. Joe.

Changing it from the DOS prompt via the 'time' command is a more convenient way to do the same thing (that's one of the things that the 'time' command does for you, since about MS/PC-DOS 3.2 +/- 0.1). Changing it from Windows probably also updates the RTC, although I've never verified this. The RTC is only read at boot time. If the PC loses time while powered down, it's an RTC battery problem. If the PC loses time while running, it isn't. Joe.

Please DON'T. At least, not unless you get this MAC address from a NIC that you're scrapping. The last thing we need is conflicting MAC addresses to add to our internet woes. Joe.

Hardware decoding of MPEG2 by the DVD player itself, implies a video output directly from the DVD player. Do such (internal) players exist? If so, look for some sort of connector at the back of the player, find out its details, then check for a video card that has an input for whatever type of signal this may be (fibre optic???). Anyway, I've not heard of DVD players having such a capability. Joe.

Success! Printing and scanning are both now functioning on this Pentium MMX & PSC-1610. Thanks again for your help, Allen. PS. I had had a little setback that delayed things. The NVRAM/RTC (M48T86PC1) chose this time to finally exhaust its battery capacity. The PC kept saying something like "Checksum error, Flat battery, Reseting to factory defaults", even when rebooted with the power applied. Since these factory defaults have the USB controller disabled, it was impossible to connect either a flash drive or the PSC-1610. The M48T86PC1 appears to be discontinued, but fortunately, equivalents from Benchmarq (TI) and Dallas (Maxim) are still available. PPS. As for the original GPF handler attempt, it is clear now that if you swap the IDT, it only gets used for the current process, other processes still use the standard IDT. But if I try to modify the GPF handler address in the standard IDT, I'm back to those instant reboot problems. So, this approach (via an application) just seems impossible, maybe if I ever learn how to write a VXD it may work ...

The amount of available "Shared Arena" does not appear to be an issue. There is normally more than enough space to handle larger Partitions than these Programs can handle. The Registry Size issue is unrelated to this issue and appears to be related to usage of the first 16MiB of Physical RAM. Oops! I had thought the Shared Arena was the first 16M of RAM. From http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi/0650/bks/SGI_Developer/books/T_IRIX_Prog/sgi_html/ch03.html, we have this : So it sounds like the Shared Arena could be anywhere in RAM. Indeed, it sounds like there can be more than one Shared Arena. So it is no longer clear to me how such a restriction for the WinME (or Win98) defragger would arise, and indeed, I think you are saying that normally, it doesn't. Joe.

Thank you Allen, you have gone above and beyond the call of duty! I've downloaded and will report back on the success of this venture. Joe.

Hmmm ... In that case, I think the following is also required reading : Joe.

I have been informed that this is the reason why I am unable to install version 11 of Shockwave, but if this is indeed the case then how was I able to successfully install later versions of Flash player 9? and then 10? According to loblo, Well, you, me and Larry all can install later versions of Flash than above, and for some Flash content, it works fine, however for some Flash content, the result may be a crash, because our CPU's don't support SSE. Joe.

Hi again Allen, Yikes! Looking at the registry entries created or modified, there's a total of 4105 of them, which look like they'll add maybe 400kB to the registry. Out of control. Anyway, I notice in the list of new and modified files, that there are 38 with a date code of 21/11/10, which implies they are either created or modified by the software. I presume those hex numbers at the end of each line are a CRC32, so I'll see if the files in question can be extracted from the install software and if so, whether the CRC matches. If not, then I'll need to trouble you for a copy of these files, about 1.6MB uncompressed, no idea what size with compression. In addition, I'll probably need a "before and after" for WIN.INI, which is one of those 38 files. Thanks for your help, Joe. PS. After more testing of my Virtual Relativity experiment, I've come to the conclusion that Windows must be swapping out the Interrupt Descriptor Table when handing control to other tasks, so my little application is unable to do the GPF handling except for its own code, hence cannot provide a simulated RDTSC. Maybe I have to learn how to write a VXD to do this sort of thing.

@jds: While not mandatory, I usually add the Unofficial Win 9x Stack Corruption, 98KRNLUP, which installs Krnl386.exe v. 04.10.00.2000, to the mix, too. This completes the available updates to Win 9x core files. Thanks Den, So it's : Make sure to install the unofficial 'COPY2GB.EXE', 'SHELL98.EXE' and '98KRNLUP.EXE' updates, then the standard WinME defragger is perfectly fine to well beyond the "safe" 192G FAT32 partition size. I was reading somewhere (maybe one of the links earlier in this thread) that "fast" defraggers (eg the WinME one) achieve speed by omitting safety checks. So at the very least, run ScanDisk prior to using them (probably wise to do that regardless). Also mentioned was the vulnerability to (power) interruptions. Does anyone know if this means the slower Win98(SE) defragger has more safety checks than the WinME one? Joe.

Hey, thanks Allen! I'll try it out and let you know how it goes. Joe.

Hi Allen, The model is PSC 1610. No, I do not have any virtualisation software like vmware (nor do I have any experience with such). In times past, I have tried to install recalcitrant software on another PC and transferring the files to the true target, but soon realized that doesn't work due to registry entries and registering of DLL's (which I presume also involves the registry). From your comment, using virtualisation software provides a way to do this successfully? Joe.