jds

I don't have the mjpeg utilities so I don't know if CMOV Instructions are the issue. You would have to examine the Illegal Instruction Details to get the OP Codes of the failing Instructions. I have two versions of my software. 1. The Patcher discussed in this Thread that Patches the three Instructions known to cause problems with Flash. 2. The Emulator I wrote to handle GOM. It emulates CMOV Instructions and one specific PREFETCH Instruction. I don't know if either or both would handle the mjpeg utilities. @rloew : 1. The SSE issue is the same, I want to prevent Flash Player 9.0.280.0 crashing FireFox. 2. OK, I've now retested the mjpeg utilities, and my suspicions about the CMOV instructions seem to be confirmed (opcodes 0F 4x xx looks like CMOV). Dumps for two of the utilities are as follows : JPEG2YUV executed an invalid instruction in module JPEG2YUV.EXE at 0177:00403144. Registers: EAX=00000000 CS=0177 EIP=00403144 EFLGS=00010202 EBX=00000002 SS=017f ESP=008cf450 EBP=008cf478 ECX=00000000 DS=017f ESI=009f0489 FS=0d0f EDX=00000001 ES=017f EDI=008cf490 GS=0000 Bytes at CS:EIP: 0f 46 f2 89 34 24 e8 31 a1 02 00 8d 50 01 39 c6 Stack dump: 009f0489 0000005c 000003fe 0042f8e8 008cf8c4 00000000 00000000 008cf490 00000002 008cf890 008cf8a8 00402f82 00000002 008cf490 0042f8e8 008cf8c4 MPEG2ENC executed an invalid instruction in module MPEG2ENC.EXE at 0177:004167f5. Registers: EAX=ffffff00 CS=0177 EIP=004167f5 EFLGS=00210292 EBX=000000ff SS=017f ESP=007af940 EBP=007af948 ECX=000000ff DS=017f ESI=007afc10 FS=2bf7 EDX=00474960 ES=017f EDI=00474960 GS=0000 Bytes at CS:EIP: 0f 4e c8 83 c2 02 40 66 89 0f 3d 00 02 00 00 75 Stack dump: 007afc10 007afa18 007af978 0040591a 007afc18 007afa18 007af994 78001385 007c0000 00000000 00000200 00000000 008d057c 007afc10 007af9e8 004026eb @ CyberyogiCoWindler : "A BIOS flaw (that prevented PCI cards from preemtive multitasking)" wouldn't affect Linux, AFAIK. Linux likes to handle all the hardware itself, so either it too has this limitation, or it's a hardware issue. Just my 2c, based on limited knowledge. Joe.

Not even Beta. More like Alpha. Yes ... I chose my wording for discretionary reasons. <G> That one is not a Patch. CMOV Instructions would be very difficult to Patch dynamically. The Instructions are emulated. OK, here I chose my wording badly. I didn't mean to imply the executable code was being patched, rather I tend to use that word in a more general context to describe system tools that alter the behaviour of a system. Yes, you explained that because the CMOV instructions were emulated, there was a significant performace penalty. That's fine, the applications I want to try this on are not real-time anyway (they're the mjpeg utilities, which run on my Pentium II but not my Pentium MMX, so I figure it must be the CMOV stuff that's the problem). Joe.

@ rloew : Hi. Yes, I'm aware this is beta, I've no problem with that. BTW, I'd also be interested in trying your CMOV patch, that you concluded was too slow to be practical ... for an entirely different application, on an entirely different machine. :-) @ all : I'm wondering ... if copying the cached/running application (eg. the Flash plugin) may result in a patched version instead of the original, what happens to compressed applications? Wouldn't they be copied in their decompressed form? Or are these two situations different somehow? Joe.

Hi all, Very interesting discussion, this SSE dependency most likely explains the problems I've experienced with Flash on my Pentium II at home (mainly Yahoo Australia and some of the local media sites). Any chance I can get a copy of Mr Loew's patch to try? Joe.

Update - After trying Kaspersky 6.0.3.837 for a while, and finding this made my PC extremely unstable, I've now re-installed Symantec Antivirus 9.0 and can confirm that indeed, when the virus definitions of about September 2009 or later are installed, what breaks is the real-time scanning (Symantec seem to call this "auto-protect"). Manual scanning (eg. Explorer context menu) still seems OK, yet you can copy the Eicar test pseudo-virus onto your hard drive, and you can execute it (as eicar.com), without SAV detecting it. So a real virus would also go undetected as it gets copied onto your hard drive and/or executed! Joe.

Update - After trying Kaspersky 6.0.3.837 for a while, and finding this made my PC extremely unstable, I've now re-installed Symantec Antivirus 9.0 and can confirm that indeed, when the virus definitions of about September 2009 or later are installed, what breaks is the real-time scanning (Symantec seem to call this "auto-protect"). Manual scanning (eg. Explorer context menu) still seems OK, yet you can copy the Eicar test pseudo-virus onto your hard drive, and you can execute it (as eicar.com), yet SAV doesn't detect this. So a real virus would also go undetected as it gets copied onto your hard drive and/or executed! Joe.

Possibly, although writing is more likely to fail before damage occurs. Formatting or using SCANDISK is another story. I set it up and tested it before I posted. No. It ignores any LBA Partitions. It may even abort scanning, although I have not comfirmed this. I see what you mean. On such systems, all extended partitions might be ignored due to the patch. I'll try this out when time permits. Joe. Well, I've done some testing on an old 386SX (no LBA / Extended Int $13 support), and I can confirm that indeed the +206C patch has the effect of ignoring any extended/logical partitions. For this test, I simply created a boot floppy using the patched 'IO.SYS'. So, such old systems do not suffer from the 'IO.SYS' LBA bugs, do not benefit from the patches, and cannot see any extended/logical partitions if the +206C patch in particular is applied. Consequently, I have updated my 'IO.SYS' patch package to detect when it is being applied to such old systems lacking Extended Int $13 support, in which case it simply reports this fact and exits. I have also included a limited patch that only addresses the phantom drive enumeration bug, in case that's of any interest, as this can be used with systems old and new. Perhaps useful for use on boot floppies? If you've got a new system, you really need the full patch, if you've got an old (ancient) system, then none of these LBA bugs are relevant anyway. Again, see http://jds.com-t.com/general.html if you'd like to download. (Edit : Defunct URL. See below.) BTW, I also tested for the reported "can't access partitions that start beyond the 7.8G boundary" bug with the (fully) patched 'IO.SYS' and didn't encounter any problems. Although I didn't repeat this test with the unpatched 'IO.SYS' (since that would have been courting disaster), this suggests that the +206C patch may also fix this problem. Joe.

I agree, but it may apply only to people also using Windows NT who need to use non-standard Type '05' Partitions. No, as I don't use NT. The problems of LBA partitions being addressed as CHS and phantom enumeration occurred for me with W9X (98SE, to be precise). Possibly, although writing is more likely to fail before damage occurs. Formatting or using SCANDISK is another story. I set it up and tested it before I posted. No. It ignores any LBA Partitions. It may even abort scanning, although I have not comfirmed this. I see what you mean. On such systems, all extended partitions might be ignored due to the patch. I'll try this out when time permits. Then the Patch would only be of value to users of unmodified Windows NT as others have no need for Type '05' Partitions. No. There is an unrelated bug in IO.SYS that he didn't Patch. I have not evaluated the impact of the third Patch (+3A01). Joe.

The MS tools (ie. FDISK) always use the standard "05" extended partition ID following (chained from) the MBR "0F" LBA extended partition ID. Joe.

My hard drive contained an extended partition (type 05) that was about 30GB. This partition contained CHS accessible volumes before cylinder 1023 and others (NTFS and FAT32) from cylinder 1024 onwards. There was a FAT32 volume before cylinder 1023 and I would get a phantom drive in Win98 if I set this volume's type to 0C. A simple test to show the problem is to create an extended partition (type 05) on a drive and add a type 0C (FAT32 LBA) volume. IO.SYS will double the start key whereas the 32-bit disk code in Win98 gets it right. I realise that type 05 partitions shouldn't exceed cylinder 1023 but I had to use 05 not 0F for NT4 compatibility. Also, all LBA keys must be correct. I didn't see this as a problem because NT always uses LBA keys and my partitioning program ensured they were correct. But, this might cause problems in setups that rely/use CHS only. The recent comment that an LBA extended partition should contain only LBA volumes might explain why IO.SYS works the way it does. Cheers, Steven Saunderson Microsoft considers LBA the preferred access mode. Since a type '0F' Partition requires use of LBA, it is safe to assume that any Logical Partition contained within it can be accessed by LBA, regardless if LBA is specified. FDISK makes this assumption, so your Patch at +2072 breaks this. JDS removed this part of your Patch. Without the +2072 Patch, your Patch at +206C now causes all Logical Partitions to be set for LBA access. This would be a problem in any machine that does not support LBA. Without the +206C Patch, the value of using a Type '05' Partition with LBA Logical Partitions is severely diminshed. Besides needing your +3A01 Patch, you will be unable to define Partitions that start above 8GB. Type '05' Partitions were meant to be CHS only and there may ber even more issues. Basically what you have done is make a workaround for a problem that is basically a Windows NT problem not a DOS problem. Windows 98 has different code so it handles these nonstandard partitions differently, so you get the duplicate mounts. I think you would get much better results if you fix the problem in Windows NT instead. Since it can handle LBA, the modification should be relatively simple. The problem I found does not require CHS Partitions or non-standard Partitions, only the presence of NON-DOS Partitions, such as NTFS. I think you are being grossly unfair to Steven. His work fixes a definite problem with MS-DOS 7.XX / MSW 9X, whereby drives are enumerated incorrectly by IO.SYS. I'm sure that any attempt in MSW to write to the phantom drive letters so produced, will corrupt the drive. I'm not sure of your assertion that the "Patch at +206C now causes all Logical Partitions to be set for LBA access. This would be a problem in any machine that does not support LBA". Wouldn't IO.SYS detect machines without LBA support and consequently use CHS addressing? If there is a genuine problem, simply don't apply these patches to such machines, since these are no use to them anyway. I use a variety of machines with partitions (primary and logical) over the 1024 cylinder boundary (FAT16 and FAT32). With the two selected of Stevens patches, I can do so safely (in DOS or MSW), regardless how they've been defined. Joe.

@jds: You say in your read.me: I've determined that the change you reverted is (quoting Steven Saunderson's original w98bug.txt): Would you please elaborate on what problems did that particular change have, and why do you consider it a misfix? Sorry again for the delayed reply. Anyway, the misfix is as follows ... When an LBA extended partition is defined, all logical partitions within in should/must use LBA addressing, even if they're not explicitly defined as LBA types. With the above-mentioned change, IO.SYS will look only at the type ID of the logical partition itself, ignoring the type ID (and hence addressing mode) of the extended partition that contains it. If the logical partition in question is not wholely within the 7.8G CHS limit, disaster (due to wrap-around)! Joe.

The order in which MS-DOS (*) enumerates partitions is : a) First primary partition of each drive, in turn B) All extended partitions of each drive, in turn c) All remaining primary partitions of each drive, in turn Drives that are not recognized are not enumerated. * At least as far back as version 7.0, perhaps even 6.22 (earlier than that, only one primary partition was supported). Assuming NT uses the same rules, what you should do is make that 105G partition a primary partition. Then it will get enumerated last for NT, & ignored for DOS/W9X. So all other partition drive letters will match between the two O/S. BTW, if you get phantom drive enumeration or other LBA problems in W9X, you might want to try my revised patch for V7.10 'IO.SYS' (based on original patch by Steven Saunderson), available at : http://jds.com-t.com/general.html Joe. Thank you JDS (Joe) This sounds interesting to me, but am still a little confused here. If I make my G volume into a primary partition, then install NTFS on it, win98 won't see it, so then win98 will change the drive letters on my second hard drive, because there won't be a G volume on my first hard drive. Then what happens when I boot into XP, where it can see all volumes, to the letter assignment? Do you know if XP has to be installed on a primary partition? I have read XP will run from a logical drive as long as it can install it's drivers in the first primary partition of the hard drive. Another question, what is this V7.10 - IO.sys patch for? I downloaded all the win98 updates from MDGx web site and installed them in order to get my 250gb hard drive to run win98se, and so far everything is working great. This confused me even more. I believe what you said eariler made more sense to me, when you said to repartition my empty G drive into 2 partitions, so hard drive 0 will keep the drive letter G in place and it won't change drive 1 letter asignment. After doing this partition change on drive 0 it would make it C - D - E- F - G - H. and drive 1 would be I - J - k - L. Then install XP and NTFS onto G drive, which would hide it from w98 on Drive 0 making w98 just see it as C-D-E-F-G and in turn change drive 1 drive back to H - I - J - K. I don't understand why making the NTFS partition a primary partition matters, or am I missing something here. Sorry again for the delay and sorry too for causing any confusion. To be honest, your reply here confuses me. Did I ever mention splitting your empty "G" drive into two partitions? Anyway, I think your confusion might stem from an assumption you may have, that physical drives are enumerated in turn (in sequence). That is not the case. The second thing you need to realize, is that for all the drive letters to match up, all partitions common (visible) to both O/S must be enumerated first, the remainder (eg. your proposed 105G NTFS partition) must be enumerated last. So the idea is to arrange the partitions in such a way that, following the enumeration rules that I outlined in my first reply, the above enumeration sequence is achieved. For that, you would need to make the proposed 105G NTFS partition as primary, such that it is the SECOND primary partition on physical drive 0. I hope that explains things well enough. Just slowly go through those enumeration rules and you should end up with the logical drive letter assignments I've outlined. The caveat is that I've assumed the NT* family follows the same rules as the DOS/9* family (someone let me/us know if that's not the case, since I don't have an NT* machine to experiment on). BTW, in answer to your question on 'IO.SYS', I forgot to mention again the other/lesser bug, whereby phantom drive letters can appear in Windows (not a serious safety issue provided you don't write to those phantom drive letters). I don't remember the exact conditions under which this bug manifests, so I'm not sure if you will encounter it. However, it is also addressed in the patch available on my "general.html" web page. Joe.

Oh BTW, I forgot to mention one more detail : The real-time scan breaks first, so run or open the EICAR test file to be sure, don't just trust the manual scan as your test. Joe.

Beware! I have Symantec 9.0 (copyright is 2004) and it APPEARS to still update its virus definitions. However, in reality, new definitions (manually or updates via LiveUpdate) SILENTLY break it! Check with the EICAR test signature file, don't assume that because all appears well, that it actually is! Joe. PS. I wonder is KernelEx will solve the Avast 5 problem (I'm staying with 4.8 for the time being)? Hello: As I understand it, Norton Antivirus 2002 is no longer supported with new definition updates. It appears that Norton AV 2003 is the earliest version that is still receiving updates, and it seems that it doesn't support Windows 98/ME. (See: http://www.symantec.com/business/security_response/definitions/download/detail.jsp?gid=n95 .) Cheers, Jerry Don't believe everything you read on the internet. It still updates or at least gives the indication that it does. I know it states that it doesn't, but it still does. In fact upon completion of the update it it mentions that if you have older products you still need to use a different updater. Just thought I would pass it on, since it is being discussed.

Well, I've just updated the WAVEDIT utilities to include CUE file support (ImgBurn or directly compatible file format). Unless there are bugs to fix, that'll be the last update. Joe. Actually, I'm in the process of writing some DOS utilities that can cut and join WAV files of up to 2G in size (might work up to 4G, not sure yet). Sorry, no FLAC or CUE support is planned. No LFN support. No GUI. Cut time values are entered in seconds (decimal). So, they're fairly primitive tools. But they do handle files that are too large for the fancier tools. When the utilities are ready (should be within a week, depending on other priorities), they'll be available at : http://jds.com-t.com/general.html Joe.

Sorry for the delayed reply ... time is lacking. Anyway, if you assigned the unused 105G as a primary NTFS partition, this would be the end result (assuming as I stated, that NT* follows the same enumeration rules as MS-DOS) : Drive 0 (250G) = C: Primary/Active FAT32 35G (Both O/S) D-F: Extended/Logical FAT32 33, 30, 30G (Both O/S) K: Primary NTFS 105G (Normally, NT* only) Drive 1 (40G) = G-J: Extended/Logical FAT32 10, 10, 9, 9G (Both O/S) You will notice how the K: partition is enumerated last, so that even for O/S (that is, MS-DOS and W98) that can't see this partition (being NTFS), all other partitions get assigned the same drive letter. Beware that F: is partly beyond the 128/137G limit for LBA32, so you need to ensure LBA48 solutions are in place lest you corrupt C: due to LBA wrap-around! Same applies for K: which is entirely above this limit. Now, as for the W9* IO.SYS patch, this is for a separate problem. If you have a mixture of CHS and LBA partitions, MS-DOS 7.XX (W9X) and 8.00 (WME) will sometimes use CHS addressing for partitions beyond 7.8G, which must use LBA addressing, since otherwise CHS wrap-around will occur. In your case, all partitions will have been LBA types, which should mean you are safe from this bug. However, if you were to choose slightly smaller partitions on your second hard drive, you might still be vulnerable to this bug. As for the various service packs and updates from MGDx and other sites, beware some of these will restore the standard (ie. buggy) version of 'IO.SYS', so (if you had a mix of CHS and LBA partitions types) you would need to restore the patched version PRIOR to rebooting. Joe. The order in which MS-DOS (*) enumerates partitions is : a) First primary partition of each drive, in turn B) All extended partitions of each drive, in turn c) All remaining primary partitions of each drive, in turn Drives that are not recognized are not enumerated. * At least as far back as version 7.0, perhaps even 6.22 (earlier than that, only one primary partition was supported). Assuming NT uses the same rules, what you should do is make that 105G partition a primary partition. Then it will get enumerated last for NT, & ignored for DOS/W9X. So all other partition drive letters will match between the two O/S. BTW, if you get phantom drive enumeration or other LBA problems in W9X, you might want to try my revised patch for V7.10 'IO.SYS' (based on original patch by Steven Saunderson), available at : http://jds.com-t.com/general.html Joe. Thank you JDS (Joe) This sounds interesting to me, but am still a little confused here. If I make my G volume into a primary partition, then install NTFS on it, win98 won't see it, so then win98 will change the drive letters on my second hard drive, because there won't be a G volume on my first hard drive. Then what happens when I boot into XP, where it can see all volumes, to the letter assignment? Do you know if XP has to be installed on a primary partition? I have read XP will run from a logical drive as long as it can install it's drivers in the first primary partition of the hard drive. Another question, what is this V7.10 - IO.sys patch for? I downloaded all the win98 updates from MDGx web site and installed them in order to get my 250gb hard drive to run win98se, and so far everything is working great.

There are two utilities from MS, both called TZedit, which allow you to define/modify the DST dates for your time zone (one for W9*, the other for NT*). Search for file names 'tzedit.zip', 'tzedit.exe' or 'TZeditWin98.exe'. Instead of waiting for MS to update the DST def's each time the local administration changes those dates (you'll have a really long wait for W9*), you can just do it yourself. Note, if you run this utility and no time zone definitions show up, this means you've got the wrong version (NT* vs. W9*). The package archives I've got, have the following file sizes : NT* EXE = 69952, W9* EXE = 86016, W9* ZIP = 23626 (uncompressed = 51997 total). Hope that helps. Joe.

The order in which MS-DOS (*) enumerates partitions is : a) First primary partition of each drive, in turn b) All extended partitions of each drive, in turn c) All remaining primary partitions of each drive, in turn Drives that are not recognized are not enumerated. * At least as far back as version 7.0, perhaps even 6.22 (earlier than that, only one primary partition was supported). Assuming NT uses the same rules, what you should do is make that 105G partition a primary partition. Then it will get enumerated last for NT, & ignored for DOS/W9X. So all other partition drive letters will match between the two O/S. BTW, if you get phantom drive enumeration or other LBA problems in W9X, you might want to try my revised patch for V7.10 'IO.SYS' (based on original patch by Steven Saunderson), available at : http://www.geocities.ws/j_ds_au/general.html [Edit: Updated the URL] Joe.

Actually, I'm in the process of writing some DOS utilities that can cut and join WAV files of up to 2G in size (might work up to 4G, not sure yet). Sorry, no FLAC or CUE support is planned. No LFN support. No GUI. Cut time values are entered in seconds (decimal). So, they're fairly primitive tools. But they do handle files that are too large for the fancier tools. When the utilities are ready (should be within a week, depending on other priorities), they'll be available at : http://jds.com-t.com/general.html Joe.

Is there any way to hack a 1.5 & 1.6 hybrid together that can work with W98? Alternatively, using UE with KernelEx? I tried to use KernelEx to install 1.6, which seemed to work (install), but all it does is produce an empty file called "&1" and give an error like "I should be able to extract this, but something went wrong, so you want to view the log file?". There isn't a log file anyway. Interestingly BTW, the AutoIt v3 home page says "Compatible with Windows 95 / 98 / ME / NT4 / 2000 / XP / 2003 / Vista / 2008". Joe.

Update on KernelEx/ODFConverter compatibility : I had previously been forced to uninstall KernelEx 0.3.6a due to compatibility problems with the ODFConverter command line utility, per : http://www.msfn.org/board/index.php?s=&amp...st&p=824699 With KernelEx 4.0RC2 now available, it was time to try again! Well, although the previously reported exception problem still occurs, now I find that disabling KernelEx extensions for OdfConverter.exe (via the Compatibility tab in Explorer properties) is all that's required to fix the problem. (With KernelEx 0.3.6a, adding 'odfconverter.exe' to the [skip Modules] section of 'kexver.ini' was unsuccessful.) Congratulations, the new KernelEx is a great step forward! :-) Joe.

Actually, better rename the batch file (I had this earlier in my path than the executable, but you might not, so it's best the two don't share the exact same base filename) : OpenXMLView.bat : ------------------------- @echo off if $%1==$ goto Usage if $%1==$/? goto Usage if not $%2==$ goto Usage set COMMANDC=%COMSPEC% set COMSPEC=C:\BIN\COMMANDC.EXE OpenXMLViewer.exe %1 set COMSPEC=%COMMANDC% set COMMANDC= goto End :Usage echo Usage : OpenXMLView Document_Name echo. echo (Note, Document_Name needs to include the drive letter?) :End Joe.

Can't remember if I had the same problem (I've deleted OpenXMLViewer, after discovering that the ODFconverter command line tool with Go-Oo 2.4.15 gave better results), but you might try copying the DLL to your Windows\System directory. Other stuff you may find useful (stuff I wrote due to necessity) : OpenXMLViewer.bat : ------------------------- @echo off if $%1==$ goto Usage if $%1==$/? goto Usage if not $%2==$ goto Usage set COMMANDC=%COMSPEC% set COMSPEC=C:\BIN\COMMANDC.EXE OpenXMLViewer.exe %1 set COMSPEC=%COMMANDC% set COMMANDC= goto End :Usage echo Usage : OpenXMLViewer Document_Name echo. echo (Note, Document_Name needs to include the drive letter?) :End CommandC.pas : -------------------- PROGRAM run_it (input, output); {Dummy COMMAND.COM, expects parameters "/c some_command"} {$M $4000,0,0 } { 16K stack, no heap } USES dos; VAR path : DirStr; nam : NameStr; ext : ExtStr; args : string; i : integer; PROCEDURE error (code : integer; st : string); {Displays error message and halts, returning error code} BEGIN {error} writeln(st); halt(code) END; {error} FUNCTION execute (path, name, params : string) : boolean; {Attempts to execute an external program, starting at current directory} BEGIN {execute} SwapVectors; exec(name,params); SwapVectors; if (DosError <> 0) and (path <> '') then begin {then} SwapVectors; exec(path+name,params); SwapVectors end; {then} execute := (DosError = 0) END; {execute} BEGIN {run_it} {Check "/c" parameter ...} if (ParamStr(1) <> '/c') and (ParamStr(1) <> '/C') then error(1, 'Expected command parameter "/c".'); {Get command processor, arguments ...} if getenv('COMMANDC') <> '' then fsplit(getenv('COMMANDC'),path,nam,ext) else fsplit(getenv('COMSPEC'),path,nam,ext); args := '/c start "'; for i := 2 to ParamCount do args := args+ParamStr(i)+' '; args[length(args)] := '"'; {Okay, let's go ...} if not execute(path,nam+ext,args) then error(DosError,'Error - Could not execute parameters : '+args) END. {run_it} To build Commandc.exe (used by the batch file), download the free Turbo Pascal 5.5 compiler from "http://bdn.borland.com/museum" and use the 8.3 filename of your document (didn't bother adding LFN support;-). BTW, sorry but this HTML stuff kills the indentation in the source listing. Good luck. Joe.

Well, on a hunch, I uninstalled KernelEx and re-attempted an install of the FileFormatConverters package, using Orca to delete the LaunchCondition entry in the MSI file (per previously described recipe). Well, now 'msxml5.dll' shows numerous times in the registry, whereas previously I don't think it did. There's also an 'msxml5r.dll' entry there somewhere. So I presume that means it's now registered? OK, so now Word 2000 gives me an option to open a "Word 2007 Document (*.docx)" file, yet when it does so, it just gives me what appears to be a text import of the raw file (eg. first two characters are "PK"). It hasn't even tried to unpack the ZIP format. No error is reported now, though. As for Excel 2000, behaviour seems unchanged. Slight forward motion, but this stuff still can't walk. :-( Joe.

Thanks for all those lovely updates for IE6 (I was particularly interested in the KB960714 security update, BTW). However, there's one problem with the mdie6cu.exe (2.5a) bundle : It re-introduces a buggy version of 'mlang.dll' (dated 2004/10/15), which was the subject of previous correspondence, per below. I'm not sure which was the last good version of 'mlang.dll' before MS broke it for 9X, however I've now replaced this broken version with version 5.50.4807.2300 (dated 2001/07/23) and will wait and see if any of the problems resurface. The original 98SE version mentioned below is OK, of course. Joe. Previous correspondence on 'mlang.dll' follows : ...... snip ...... I'll keep in mind your experience with MLANG.DLL . ...... snip ...... Best wishes, MDGx ...... snip ...... > > I recently retro-graded my 'mlang.dll' file (was 6.00.2800.1599, > xpsp2.040919-1003) back to my W98SE CD original (5.00.2614.3500) > and not only has this fixed the problems with HTML e-mail in > Outlook (which apparently uses stuff from IE for HTML rendering), > it seems to have also helped considerably with the stability of > IE6. After I get a better "feel" for the stability of IE6 as it > is now, I'll then apply the SCR579X patch to see if that helps > too (particularly for JavaScript). > > Regards, > Joe. > ...... snip ......