jds

Yes, also true with 255 head geometry! [edit: actually, I'm not sure why I was thinking 4080x255x63 here, maybe needing sleep] [Historical trivia] The "native" drive geometry is 16 heads here because ATA aims to emulate ST-506, and the latter hardware interface had 4 head-select bits, hence a maximum of 16 heads. Normally, the BIOS is configured to provide LBA-to-CHS translation, using the "fake" 255 head geometry, where the 255 limit is mostly due to the maximum number of heads supported by the BIOS Int 13h software interface (256, from 0-255). Now, either someone at MS couldn't count, or else somewhere it was convenient to represent the number of heads in 8 bits, so instead of having a maximum 256 head geometry, we have 1 less. Without the above "slide of hand", the Int 13h software interface would only be able to support a maximum CHS geometry of 1023x15x63, or about 504MB (1024x16x63 sectors). With the "fake" geometry, the maxiumum capacity is about 7.8GB. Now, I don't know why sectors are numbered 1-63, since 0-63 would give a small increase in the maximum capacity via CHS addressing. [/Historical trivia] Now, it seems to me that restricting partition boundaries to multiples of 255x16x63 = 16x255x63 sectors shouldn't really be necessary, if we ensure that the BIOS is configured to provide the above LBA-to-CHS translation (which is standard practice anyway). Nobody these days would use "native" CHS geometry, surely? Yet reading this thread, that's what the Partition Logic utility seems to assume. I wonder if there's a way to make it support the "fake" CHS geometry, like all the other partitioning tools? That would have made this exercise (to align the partitions) simpler and more flexible. Sorry for rambling. I guess I'm just wondering if it's really necessary to be so strict with the partition alignment (if it weren't for the apparent limitation of the Partition Logic utility, as used here). Joe.

As far as I can tell, DU version 1.2 (40960 bytes, 2005-10-15 2:56pm) works OK. Aside : Reading that only 11 utilities in the current suite are OK, it seems that the current suite is becoming more and more an irrelevance. Reading about partial loss of functionality, bloat, undesirable "phone home" features and restrictive license conditions in later versions of some utilities (that otherwise still work), leads me to think that ultimately, what will be most useful, will be a list of "best version for 9X" for these utilities. (IMHO) Joe.

Well, with KernelEx 4.5RC4, you have the ability to run newer browsers, BUT this option is only for W98, W98SE and W98ME. Maybe can help, since this seems to mention being based on KernelEx, however a rather older version. Not sure if this Shell Update can help to make W95 suitable for KernelEx and thence for the newer browsers. So you can investigate the above, or upgrade to W98, then install KernelEx, etc. Joe.

Fixed. Try again, please! Thanking you!

BTW, the GDISK utility from Symantec Ghost 8.3.0.1331 is able to partition and optionally format USB drives in pure DOS, WITHOUT needing USB drivers. Ironically, GHOST itself, from the same version, which is also supposed to work directly with USB drives (without drivers), doesn't (well, at least for me). However, once you've partitioned and formatted such drives, you can then load third-party USB drivers and use Ghost that way. Note, although the GDISK utility is strictly command line only (no menu), it is surprisingly easy to use. I get the impression (albeit without rigorous testing) that Format in MSW only starts the formatting process, and that you NEED to run Scandisk to finish the job (complete the FAT1 + FAT2 entries). There must be something I'm overlooking. What's wrong with simply? : 255x16x63 = 257,040 x 512 = 131604480 (roughly 128M) 16x255x63 = 257,040 x 512 = 131604480 (roughly 128M) Such a minimum/multiple partition size should be OK, right? Joe.

Olá, Is there a newer link for this patched sysmon app? Rapidshare says the file's been deleted. Joe.

I'm a little confused by the "problem solved" in the title here, when reading the thread, things seem a little open-ended ... However, what comes to mind is that file transfer via the Xmodem protocol should be possible at the CPM end, and it's definitely supported by HyperTerminal (under "Send File", not "Send Text File"). I don't know if Kermit protocol is also a possibility with CPM, it's also supported by HyperTerminal. BTW, to redirect or copy a file from DOS (raw data), I think you need to ensure the CTS and DSR lines are active (high). You may also need the "p" MODE option as in (eg.) : mode com1:9600,n,8,2,p copy /b blah.xyz com1: Joe.

hottext, Thank you for the link -- interestingly, at 12.3MB the earlier IE 5.0 seems to be actually larger than IE 5.01 at 8.9 MB. --JorgeA That link is the one given by Mijzelf earlier in this thread. Is it the German version? Well, many moons ago, I downloaded 16-bit IE5.01 from 'tucows.com' and I think there's also one available in the 'evolt.org' archive. BTW, one thing I remember from that time, is that IE5.01 would refuse to install, without any error indicated, if it found COMMAND.COM from DR-DOS 6.0. I had to fool it (I no longer remember exactly how) with an MS version of COMMAND.COM, even though it wasn't active. Joe.

Just FYI (what's the plural of that?;-), I've found another program which needs KernelEx disabled (tried this with both 4.5RC1 and 4.5RC4) : Easy Assembler Shell (trial installation, from http://deepsoftware.com/eas/). Running either "eas5setup.exe" or "eas5inst.exe" (the former is a WinZip SFX containing the latter) results in the following crash : EAS5INST caused an invalid page fault in module KEXCOM.DLL at 017f:10002163. Registers: EAX=0082727c CS=017f EIP=10002163 EFLGS=00010202 EBX=81d552c4 SS=0187 ESP=0120ff40 EBP=0120ff44 ECX=00000000 DS=0187 ESI=10003168 FS=109f EDX=00000000 ES=0187 EDI=81d5d7dc GS=0000 Bytes at CS:EIP: 8b 01 52 ff 50 50 5d c2 08 00 cc cc cc 55 8b ec Stack dump: 00812080 0120ff64 0040254b 0082727c 00812080 81d5d7dc 004039bc 00813084 0082727c 0120ff84 004021d1 00812080 009102b4 00813084 00816090 81d5d7dc BTW, I haven't tried the application itself yet (30 day trial;-), just the above installation package. Joe.

I suspect the reason you've had no previous replies, is that no one has seen such a problem, nor can think of a cause. In cases such as this, the stock reply is typically "try scanning for malware" - well, it can't hurt to try. Oh, and check if the "foreign" text is genuine text, or just English text with the wrong character encoding (eg. check word lengths, sentence structure, etc.). Joe.

I've always needed to do this - are you sure you were able to do without, using 4.5RC1? @lama : And as for Vista/7 users, they are instead at the mercy of Redmond (never mind the XP folks, that are already being abandoned to their fate). Joe.

Firstly, as has been stated before (by Xeno86, I think), drivers are an entirely different "kettle of fish" that is well outside the scope of KernelEx. Yes, a new project to specifically deal with this issue would be extremely beneficial, however, we need someone with the skills and time necessary for such a project. Now, what I have found, is that for many hardware, W9X drivers DO actually exist. Unfortunately, the respective manufacturers have deleted them, for reasons that are explained here : http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&taskId=120&prodSeriesId=303776&prodTypeId=15179&prodSeriesId=303776&objectID=c01269023 Edit - Above page is now gone, here's a similar one in the Internet Archive : http://web.archive.org/web/20100808085037/http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?&objectID=c01093569 If you do some hunting, and it's not easy, you may be able to find a copy of those deleted drivers at some other site (taking all possible precautions to ensure they are legitimate, of course). For example, I have managed this for a HP printer, a HP all-in-one, a Ralink PCI WiFi card and a Ralink USB WiFi adaptor. Good luck. BTW, one think to look out for - W9X does not correctly parse INF files that exceed 64K. The first "tweak" to look out for, is to check the INF file sizes. For example, I had to edit one of the above Ralink INF's to fix just this problem (I simply deleted all the sections for one of the OEM's that was not required). Joe.

Well, I had the strange notion that perhaps standalone operation (which may or may not be the same as "pop out") used the ActiveX and embedded operation used the Plugin, but I guess that was "clutching at straws". All I can suggest now is to uninstall and re-install Firefox and the Plugin. (Having said that, the Plugin works fine for me with Firefox, yet the ActiveX doesn't work for me at all with IE, and I've yet to find a fix. I rarely use IE anyway, so it's just a minor nuisance.) Joe.

Well, the only way I know which P6 (aka 686) instructions are used by the mjpegtools, is from the crash dumps, so I can't know if there are more unsupported instructions beyond FUCOMI/FUCOMIP. CMOV was the first such instruction to be encountered, so as your P6CPU.VXD already addressed this, it was certainly worth while testing this with the mjpegtools, with the hope that this would be sufficient. I understand there are only a small number of P6-specific instructions anyway. The web page http://www.rcollins.org/p6/opcodes/P6OpCodes.html is instructive, with links at the bottom of the page for detailed information on individual P6 instructions. I'm sure the "undocumented" instructions which are included there are not relevant to the mjpegtools or any other applications that we are likely to encounter. So, if you'd like to add further "documented" P6 instructions to P6CPU.VXD for completeness, I can test this against the mjpegtools (this would at least exercise FUCOMI/FUCOMIP to some extent). However, you need to consider if it's worth the effort, as this is an application that I rarely use, and also as I've partially managed to re-build this to avoid the P6 instructions. As a separate exercise, I'd also be interested to test P3CPU.VXD against the Adobe Flash Player, of course. Joe.

Were did everybody go? Anyway, 1. I wonder what happened to Larry and his P3 transplant? 2. I've managed to re-build (re-compile) a couple of those mjpegtools utilities to avoid the P6 instructions, although this package is horrendous/impossible! So many errors trying to build the release sources, and even after dealing with them, some of the utilities, such as 'png2yuv' just don't work properly (at least, if you disable the P6 optimizations)! Arghhh! Anyway, it's a partial success here. It would be nice if P6CPU.VXD included those extra few instructions, but it's probably not worth Mr Leow's efforts. 3. If we've lost our guinea-pig, I'm willing to test P3CPU.VXD for the original Flash Player problem that started this thread. Joe.

FWIW, I once installed Win32 (many years ago) and it made everything so unstable I had to trash everything and do a fresh install. However, there is somewhere, a long, long list of what individual files you have to trash to uninstall Win32, but I didn't have that list at the time (nor do I have it now). Just a caution (albeit too late). Joe.

If I recall, there are two different types of Flash Player, the "Active X" for IE and the "Plugin" for Mozilla/Firefox. Have you installed both? Joe.

Probably because java uses "BIOS" not "DOS" services to write... I'ts a PITA, but, then again, it'd be fun if java relied on DOS, wouldn't it? Actually ... c:\djgpp\bin\redir -eo java -version > gotcha.txt Of course, you'll need to go here first : http://www.delorie.com/djgpp/ Joe.

Any idea where I could find the latest official versions for Windows 98? I'd like to replace the files on my boot disc with them. FDISK is at http://support.microsoft.com/kb/263044 Not sure where the updated FORMAT is. Both are in the unofficial service packs for W98SE (I think). However, be aware those service packs will revert your IO.SYS back to the buggy MS version, so if you install this, make sure to re-apply the above patch BEFORE rebooting. Joe.

It could be due to the LBA bugs that manifest under some combinations with multiple partitions. See discussion here : My primary site is down at the moment, so try my backup site at : http://jds.atbhost.net/general.html for the IO.SYS patch. Also, make sure to use the updated FDISK and FORMAT for W98 from MS, else try the FreeDOS equivalents. Joe.

Looks like I have the exact same issue trying to run Altium Viewer, DXP.EXE (using KernelEx 4.5RC1). Same DLL's, initial error is missing export NETAPI32.DLL:NetApiBufferFree. Anyway, I managed to find the ME version of NETAPI32.DLL (as you've suggested here), but alas, this produced the same error as the 98SE version. Looks like this problem needs a "NetApi32Ex" kinda solution. Joe.

Hi again, Mr Loew, Well I tried the above last night. The good news is that the CMOV crash is fixed. The bad news is that now it's some obscure instruction(s) called FUCOMI(P) that are new to P6 and are apparently also used in the mjpeg tools. Dumps are as follows : JPEG2YUV executed an invalid instruction in module JPEG2YUV.EXE at 0177:004026b7. Registers: EAX=008cf8a0 CS=0177 EIP=004026b7 EFLGS=00010202 EBX=009f05a0 SS=017f ESP=008cf880 EBP=008cf8b8 ECX=00000002 DS=017f ESI=00000007 FS=0cb7 EDX=00000000 ES=017f EDI=008cfd8c GS=0000 Bytes at CS:EIP: db e9 dd d9 76 13 dd 05 88 05 43 00 df e9 df c0 Stack dump: 008cf8b8 78015a5e 008cf8a0 009f051b 00000002 00000000 00000000 00000007 00000000 00000002 009f05a0 0042f068 00000000 40390000 008cfdd8 00401608 MPEG2ENC executed an invalid instruction in module MPEG2ENC.EXE at 0177:0040fbb9. Registers: EAX=00000002 CS=0177 EIP=0040fbb9 EFLGS=00210293 EBX=007afc18 SS=017f ESP=007af890 EBP=007af8b8 ECX=00000001 DS=017f ESI=007afa18 FS=0cdf EDX=000002ff ES=017f EDI=00000001 GS=0000 Bytes at CS:EIP: df e9 0f 83 4f 03 00 00 dd 05 28 91 46 00 d9 c9 Stack dump: 008d00f8 007aff68 7800ef03 7802e248 ffffffff 007af978 780012d9 007afc18 007afa18 00000001 007af978 0040afdb 007afc18 00000001 0000000f 00467afd JPEG2YUV executed an invalid instruction in module JPEG2YUV.EXE at 016f:00402767. Registers: EAX=000003e9 CS=016f EIP=00402767 EFLGS=00010216 EBX=009e05c0 SS=0177 ESP=008bf8c0 EBP=008bf8e8 ECX=00000002 DS=0177 ESI=00000007 FS=4317 EDX=00005dc0 ES=0177 EDI=008bfda4 GS=0000 Bytes at CS:EIP: db ea 0f 86 ae 01 00 00 dd 05 20 95 42 00 df e9 Stack dump: 00000002 00000000 00000000 00000007 00000000 00000002 008bfde8 00425d5a 009e05c0 00000007 008bfde8 0040168c 00000000 40390000 0042804e 9fdedddc Joe.

This has me curious: has anyone tried YouTube + Flash Player 10 on a Pentium II machine to confirm this? (If you're running Win98 you'll have to install KernelEx to test it, but the latest version is easy for even a novice to install - and to uninstall in case of problems.) Yep, I've tried 10.0.something (with KernelEx 4.5RC1) and the problem ISN'T fixed. Joe.

Thank you Mr Loew, I will try it tonight! Joe.

This is still unresolved. When larryb123456 installs his Pentium III and retests the Flash Player, I will be ready for the next step. Yes, it will be interesting to see the outcome of the P3 transplant. From what I've read, the P3 performance is similar to the P2 with the same clocking, so this will be a good indicator of patch (invalid instructions that don't throw an exception) vs. grunt (throughput) as responsible for the Flash artifacts. My bet is it's grunt that's lacking, which is the best-case outcome as far as the patch is concerned. In any case, Flash artifacts are of secondary importance to me, I just want to stop the lock-ups. My older P6CPU.VXD Emulator will handle these. Since it is not a Patcher, it will not affect any File Caches. I don't know if there are other instructions that would need emulating. Well, there's one way to find out if other instructions are required, and that's to try it (the patch). From what I've read, CMOV seems to be the main enhancement to the instruction set from P1-MMX to P2, although Linus says the CMOV instructions actually reduce performance in newer CPU's (so don't use them folks!). Joe.