jds

Perhaps you should rename the file PlainOldFavourites I was tempted, but the other available language options don't change the package name, so I decided not to take such liberties. Joe.

Can you explain more about this issue? (eg. How to test for it, what is the last version of Flash Player not affected?) Joe. I'm not sure how far back Flash Player has been installing a control panel applet. Version 10.3 r183 installs one. I've never managed to make it work. Depending on the Kernel Ex setting for it's real file, FlashPlayerCPLApp.cpl in the system folder, clicking it either gets an error message or does nothing at all. Interesting. I've got version 10,3,181,14 of this thing here, yet my Flash Player is version 10,1,82,76. I don't recall ever installing version 10.3.x.x of Flash Player. Strange. How does one test this thing? Joe.

Since I don't use this synch'ing stuff anyway, I decided to install Aurora 7. Seems fine so far, performance on a 1GHz P3 is acceptable (better than FF 2). Next was to install 'PlainOldFavorites'. This I modified per Steven W's instructions, then had to restart Aurora _twice_, before "Favorites" finally appeared in the menu. Favorites? Well, having already made a modification, time to make another ... attached is a quick hack, in which the original "en-US" package has been converted to "en-GB" (note, due to upload restrictions, you'll need to change the file extension to "xpi" before you can install it, via File/OpenFile from the menu). Joe. plainoldfavorites-1.2-fx-windows-GB.zip

Hmmm ... before being tempted to install this, read : Perhaps KAV still useful as an "on demand" (manual) scanner only, but even SAV 9 (or the NAV equivalent) with its broken "real time" protection can do that (just download the SAV 10 virus definitions every once in a while and run it). For the moment, Avast 4.8 is still the best complete solution, IMHO. Joe.

Thanks, Mr Loew. The one that Den reminded us of here, dated 2010/06/29, is that the original version, or the "more robust" version? Joe. The original one. I have only posted one version. Would you mind if I made available, a "combined" patch incorporating this (with appropriate attribution, of course) and my version of Steven's patch? Go ahead. Thank you, Mr Loew. (I'll put this together and make it available when time permits.) Joe.

Can you explain more about this issue? (eg. How to test for it, what is the last version of Flash Player not affected?) Joe.

I haven't been able to find version 2.5.197 anywhere. However, I did find a copy of 2.5.195, and I can confirm it crashes (unhandled exception) instantly when you select "Print" from the menu. Nothing shows in 'wintop', so it seems the crash is within the 'PDF XChange Viewer' package itself. In other words, 2.5.195 (and presumably 2.5.197) aren't entirely compatible, even with the help of KernelEx 4.5.1. Joe.

Works in Aurora 6 (about to download 7), Opera 11 and IE 6. However, it doesn't work in FF 2. Joe.

Oh, one more mistake you may encounter in dual-target drivers that haven't been tested properly on W9X : Unicode (UTF16) INF files. You'll need to convert them to ASCII or ANSI or whatever (eg. use "Save As" in wordpad and select DOS text). Joe.

To make things clear, if you set 'notepad.exe' to W2000SP4-compatibility-mode for KernelEx, is it able to print? Your use of the expression "of course" implies you have KernelEx installed, but haven't done any trickery with 'notepad.exe', because if you really do have a compatibility issue between KernelEx and your printer driver, then 'notepad.exe' won't be able to print in W2000SP4-compatibility mode. Joe.

Well, I can sympathize with you. I couldn't find much information on the RT2070, but have a suspicion it's related to the RT2870 and the RT3070. What I did find were some clues here : http://wiki.debian.org/rt2870sta This indicates the D-Link WUA-2340 is an RT2070 product. If you download its driver, you find that the INF file includes support for W9X, yet the package is missing a driver file called 'A5AGU9x.sys'. However, if you download the D-Link DWL-G132 driver, you will find a file with that name in its '98ME' directory. So perhaps you can try this file with the WUA-2340 drivers and perhaps it may work. You will also note that the DWL-G132 driver package also includes support for the WUA-2340 but under a different PID, perhaps this same model number has been used with two different chipset designs. BTW, you may need to persuade the Driver Installation Wizard that you are installing a WUA-2340. As for my Ralink adaptors, one is the Edimax EW-7108PCg (PCI, based on RT2500), the other is the Edimax EW-7318USg (USB, based on RT73). The latest W9X-capable drivers I could locate for these were : 'IS_AP_STA_6x_D-1.2.3.0_VA-2.1.0.0_2500_D-3.2.0.0_VA-3.2.0.0_RU-2.0.4.0_VA-2.0.4.0_AU-1.2.1.0_VA-1.0.4.0_101707_0.1.0.29.exe' and 'IS_AP_STA_7x_D-1.3.0.0_VA-3.1.4.0_2500_D-2.1.1.0_VA-3.1.0.0_RU-2.1.1.0_VA-2.1.1.0_AU-2.0.0.0_VA-2.0.0.0_030508_0.1.0.46.exe'. The latter's 'rt73.inf' file had to be pruned down, to under 64K, before it could install. Joe. PS. Confirmation that D-Link model number has been recycled : https://usb-ids.gowdy.us/read/UD/07d1 (Atheros drivers aint gonna work with Ralink silicon!)

I've just managed to fix the same problem here : HTH, Joe.

Yeah! Fixed it (well, at least for opening EXE files)! Edited '\Program Files\Universal Extractor\UniExtract.ini' and changed "globalprefs=0" to "globalprefs=1". Joe.

Sorry, Den. Over the years, the company I work for has supplied numerous pieces of software for our customers, which at one time, was distributed on floppy media. So we have (had) experience in copying many thousands of diskettes, sourced from a variety of vendors. Because it could be read by both types of drive, our practice was to standardize on the 720K format, even after 1440K drives became the norm. However, as 720K media became less common, we started to use 1440K media, unaware this would be a problem. So we learnt "the hard way" that this isn't reliable. Depending on the particular drive, and especially the make of diskette, we had the situation where HD diskettes would even fail the verification stage immediately after being copied (in 720K format). We might have assumed that this was a quality problem with the diskettes, except that these were actually from a very reputable manufacturer. So I raised this matter with the manufacturer, which is how I learnt about this coercivity issue. And just to confirm what manufacturer had said, we retested the "bad" diskettes in 1440K format, and they worked perfectly. I have physically seen myself a line of production for floppies that worked as above stated. I don't think that the manager of the factory rearranged the facility expecially the day I visited it in order to hide some manufacture secret. So, to be more exact, I have reasons (direct experience) to affirm that at least one factory in the world in a period approximately between 1994 and 1995 used the SAME magnetic media on both the 720 and the 1440 diskettes. Apart from the above, that may have been a black swan of some kind , and due to the fact that the period in which I have visited the factory was towards the end of the actual common use of the 720 floppies, and thus some "shortcuts" may have been used by the manufacturer, please read this: http://www.retrotechnology.com/herbs_stuff/guzis.html As you can see, the results in real life are controversial, and we have both a statement like: http://mdfs.net/Docs/Comp/Disk/Densities And one like: http://www.retrotechnology.com/herbs_stuff/guzis.html My personal experience is actually similar with the last quoted statement but I guess that there is also a factor connected to the actual hardware (floppy disk drive maker/model). jaclaz Hi jaclaz, Well, back in the day when we had both DD and HD diskettes from the same manufacturer, we could distinctly see a difference in the coating of the disks. So your manufacturer either didn't care (or was careless), or else they developed a compromise formulation that was somewhere between DD and HD and used this for both. Did you ever stop to think, why did the manufacturers introduce that extra hole in the shell to distinguish DD from HD? Do you think it's because they could charge a higher price for HD? No, it's because of similar issues encountered, and lessons learnt, from the 5.25" era. I can agree with your last sentence. So what's your definition of "reliable"? Joe.

jaclaz, dencorso, Sorry, if you think the difference between the 720K and 1440K media is just that extra hole in the shell, you are mistaken. The compatibility problem is due to the higher coercivity of the 1440K media compared to the 720K media. Those "bad clusters" you see after a time are due to this. When using 720K density, the magnetic field strength used by the drive is less (possibly by a factor of two, I'm not sure if it's a linear relationship) than when using 1440K density. So when you use 720K density on 1440K media, this doesn't get fully magnetised. Why is the coercivity different? Because you need to squeeze the magnetic domains closer together on 1440K media, without them affecting each other too much (also, without the drive head corrupting the adjacent domains), which means you need higher coercivity materials. Joe.

Ah, but the newer versions are much faster than the old ones (yeah, you don't hear that often)! Joe.

Well, you're probably right in suggesting that, because your drive has a 4 pin power connector, it probably follows the second (PC 700) pinout from the link you've given, rather than the third one (Aptiva 2165). However, I do recall a distant memory. Back in the earliest days of the PS/2 series, when 3.5" diskettes were a bizarre aberration, I do recall discovering that the PS/2 used an inverted Density Select signal on pin 2 of the floppy interface, as compared to the industry (Shugart, I believe) standard. These machines & drives supported 720K and 1.44M diskettes. So it is possible that this signal inversion persisted for future PS/2 models, and hence any floppy disk drives built to suit. That said, I have no specific knowledge of 2.88M drives. I see however from those pinouts, that pin 33 has joined pin 2 in selecting the drive density, which makes sense, as there are now at least three densities to support. It is possible that this additional density select line is similarly inverted (in the PS/2 range, as compared to the industry standard). So that might explain why you were unsuccessful. Alternatively, the drive may have been faulty. BTW, you must use the correct diskettes for the density you're using. This works (or doesn't) both ways. For example, don't think you can format 1.44M diskettes to 720M and get them to work reliably, if at all. Joe.

Have you tried the current version of VLC Player with KernelEx? Joe.

Can you clarify what you mean by "different formats"? Do you mean the interpretation of the Relative Sector field? BTW, I do recall reading some MS documentation stating that the partition ID for chained EBRs should always be 05, not 0F, the latter to be used only in the MBR, to point to the first EBR (if using LBA addressing, of course). Thanks, Mr Loew. The one that Den reminded us of here, dated 2010/06/29, is that the original version, or the "more robust" version? Joe. The original one. I have only posted one version. Would you mind if I made available, a "combined" patch incorporating this (with appropriate attribution, of course) and my version of Steven's patch? You can simply run my version of Steven's patch, then Mr Loew's. Alternatively, you can do the reverse. Same result. Joe.

Thanks, Mr Loew. The one that Den reminded us of here, dated 2010/06/29, is that the original version, or the "more robust" version? Joe.

Mr Loew, Would it be safe to combine your IO.SYS patches with Steven's patches (or more specifically, the two patches at 206C and 3A01)? BTW, for anyone interested, the best description I've found on hard drive partitioning is : http://technet.microsoft.com/en-us/library/cc977219.aspx (note, references to MS-DOS appear to be v6 or earlier). Joe.

What about KernelEx-enabled 'notepad'? Does that now print? If so, then you've got your printer driver working with KernelEx and now need to figure out what is happening with PDF XChange Viewer specifically. Try the 'wintop' trick with that, and see if there's anything else being invoked that you may want to try KernelEx-disabling. Joe.

One of Steven's patches introduces a bug, so all three patches is not the way to go. As for the "206C" patch in isolation, I think that's the one (if used in isolation) that's applicable for Non-Int-13x (Non-LBA) BIOSes only. (Edit: Actually, it's the patch at 3A01 that may be applied in isolation with such old BIOSes, so I'm not sure why you chose to apply the "206C" patch in isolation.) You should be applying two patches (206C and 3A01), per my version of Steven's patches. Joe.

Yes, I can confirm that too. I just downloaded PDF-XChange Viewer 2.5.197 portable and it works (opens PDFs) in KEx 4.5.1 Default Compatibility mode. Have either of you tried printing a doc? I seem to remember that was an issue in previous versions of PDF and KEx, and I don't have a printer to test with. I can't print. I' ve tested it on two machines. Have you tried? : Joe.

Well, I don't know what's suitable, but FWIW : MSVC++4.2 is (was) available for free download if you know someone with a subscription to MSDN. (I think that's 1999 vintage.) MSVC++6.0 is (was) available for free download if you know someone at an academic institution with access to the MSDNAA. (I think that's 2003 vintage.) Any idea if open-watcom might be suitable? Joe.