Drugwash

We (people) do need a smile every now and then...

That's good news. You may send it to me by mail if you want, for separate testing. Yes sweetie, I could try that sometime.

For the project at hand, PatchAPI would be the safest way since - at least for deploying the packed drivers - one may use a vanilla system where msdelta.dll would not load. For other projects where KernelEx and/or KStub (and/or other enhancements) are installed, MSDelta would be more suitable. I'll look into patch creation with mspatchc.dll. In the mean time let's hear lloyd munga, the OP, as I feel we kinda hijacked his topic with our Delta talk.

All of the hotfixes mentioned by me above make use of the same version file as yours and they are all 26112 bytes in size. Just performed a random comparison between two of them and they are bit-identical although file dates differ significantly. One can only assume that this is the only safe version used in all hotfixes so we could easily use it in our own tool. I've also found the corresponding creation library mspatchc.dll v5.2.3760.0 in Platform SDK feb. 2003 and by the looks of it it may work as well since it only has a few kernel dependencies. But that's yet to be tested though. On the other hand, I just got ahold on msdelta.dll v6.0.5600.16384 and it has about six unsatisfied dependencies in advapi32.dll. I doubt it can be worked with on a 9x system. But that too has yet to be tested.

Yes, you could do that. Mine comes from XP-SP3 (v5.1.3102.5660) and jumper's above is even newer according to its version. So it should definitely work for you too.

Apparently the PatchAPI does work in 9x. My tool mentioned above is a simple GUI built in AutoHotkey that calls the API found in the _sfx_.dll (which is actually mspatcha.dll according to its VersionInfo) that comes bundled with the MS KB hotfixes or whatever they are. The KB SFX unpacking is done by the bundled 7-zip executable. Of course, for best testing one should use a vanilla 9x system, since mine is heavily upgraded, complete with AutoPatcher, uSP2, KernelEx and Revolutions Pack. But since AHK works even in Win95 and 7-zip probably does that too (I use 9.22 beta), the only possible liability would be the renamed mspatcha.dll (_sfx_.dll) found in every(?) MS hotfix package. So far in my tests I've tried with positive results: IE7-WindowsXP-KB2964358-x86-custom-ENU IE8-WindowsXP-KB2964358-x86-custom-ENU WindowsXP-KB2758857-x86-ENU WindowsXP-KB2964358-x86-custom-ENU WindowsXP-KB923293-v4-x86-ENU WindowsXP-KB934428-v2-x86-ENU WindowsXP-KB945436-x86-ENU Please bear in mind that I only unpacked and restored/deflated/whatever the files according to the built-in manifest, I did not replace the actual system files. That is all that the tool can do: provide the real files after applying the deltas. The actual replacement must be done afterwards through classic methods for libraries that are in use. If the PatchAPI usage proves itself to be usable and helpful on 9x machines, we could then build a delta creator. That's something I haven't tried yet.

Ha ha ha, nice try! Honestly, there's too many people out there (some call them developers ) that keep pouring NT-only software and whatnot. If I am to use my time for creation, I'd first help the 9x community because it's been left way out in the dark. Myself being a 98SE diehard fan, programming as a hobby on a 98SE machine, I'd have a hard time creating XP+ tools that could also work in Unicode environments. Last time I checked I was unable to install a virtual machine on this 667MHz Pentium III running 98SE to host a Vista/7/8/etc system for testing. While the other way around would always be possible. So paid developers wouldn't bother creating for 9x, while for me - unemployed since 1991 - would be technically impossible to create (or better said test the results) for Vista+. See: will not versus can not. Mainly.

Doable (at first sight) but to what avail in regard to the Win9x community? Upon a very brief reading here, MSDelta has a ridiculously high memory requirement on creation albeit source and target files would be relatively small. Considering the packing/unpacking might be done on low-specs machines (if we think about driver packs, to be on topic), usage of MSDelta technology could be a serious drawback. And frankly I have no drive to build tools that could only (or mostly) be used on NT-based systems. Or am I missing something obvious...?

We're on the same page regarding compatibility. However, the package creator cannot be responsible for the user selecting the wrong driver version in case there is no autodetection (implemented or possible). The advantage I see in such package is the ability to have more versions in a much smaller size due to the techniques mentioned above. So at least the user won't waste a lot of space (HDD/USB/CD/DVD/etc) for the various driver versions they would try in case they don't know exactly what to do and which one is the appropriate version for their specific hardware. That alone would be an improvement until - if ever - some hardware autodetection tool could provide the necessary feedback to the driver installer (if any). I've just read the topic you linked to above and as far as I understand the tool provided by wolstech requires that the KB (or whatever) SFX be unpacked prior to processing the actual delta files, while my tool does it all in one step through the integrated 7-zip unpacker, so one just feeds it with an original SFX package and out goes both the delta files and the processed ones, in separate subfolders. Please do try my tool to confirm it works. Funny to see wolstech and I use similar languages (since AHK is derived from AutoIt). Guess they do have a reason to exist. I suppose we could also build packer tools that would create the deltas from the basic files. I just never had the need for that but given enough details on the required behavior I could take a stab at it. EDIT: Apparently both wolstech and I use PatchAPI and not MSDelta. That shouldn't be an issue though since we would use our own compressed files with our own tools.

I'm pretty sure the OP mentioned "unpack, change, repack" as an operation they would perform in order to create the driver pack(s), not as something directed at the end users. There are numerous versions of certain drivers, some known to work on certain hardware, others known to work (or not) on other hardware, so it would indeed be difficult to provide a fail-proof package for absolutely all 9x machines in the world. But a shrinked-down package could still be created, where the SIS system (Single Instance Storage) would reduce the package size and if feasible, the delta patch-system I mentioned would additionally reduce that size so it could fit to a CD, which - since we came to that - I'd like to say that 900MB would be way too much for. I once had a 900MB blank CD burnt with a TEAC CD-Writer and I couldn't read its full contents afterwards although the overburn appeared to be succesful. A regular CD would only hold 740MB of data so the package would better fit that size or be split into more parts. Such endeavour would have to keep track of any and all known compatibility issues and - if possible - be able to read machine specs and lead the user towards installing the appropriate driver version. Which would indeed be a huge task. Otherwise generic driver packages built on single file versions would fail on specific machines. Last but not least we should take into account the various licenses that come with the drivers, especially in regard to redistribution which in many cases may be extremely limited or plain impossible officially. I shall refrain from providing my personal opinion on these licenses but for the sake of this community let's say it would be best to take all these things seriously.

Nice that you took on this job, jumper! I'm not sure I get things right so I'm gonna ask: is KernelEx supposed to implement stubs on a large scale or should it rather replicate original missing API behavior through our own code? Personally I'd like to see working code wherever possible rather than "not implemented" error codes being returned. Now, last time I checked I could build the whole KernelEx package, installer included. The original 4.5.2 has always built, installed and run correctly, while leyok's attempts always failed. Couldn't figure out why. So if you want, I could try to build an updated package for you, as soon as I remember how to use all these things, because my memory is failing me badly. Please feel free to contact me in private, via PM or e-mail (drugwash aol com).

Hi there and welcome! For smallest package size you may wanna check out the Delta Compression API. A third-party tool may need to be built in order to deploy such type of patched drivers on 9x machines since they're only supported by Windows Installer 3.0 and later. I have such (empirical) tool in my repository (see signature below): MSPatchGUI. A patch creation tool would also be required in order to create the deltas. Mr. Loew, what do you think of this - would it be feasible and useful?

Latest official redistributable cam be found here. Dunno if it's still compatible with 9x, haven't checked. You could also perform a search on your computer, especially in Program Files - chances are some other application already has one in their folder and you could just borrow it. There may be more versions, in which case you may want to check their version numbers and use the latest by placing it in C:\WINDOWS\System.

For audio I use Trout by skwire (Jody Holmes) - based on the BASS library and for video I use GOMPlayer 2.1.43.5119 (later versions don't suport 9x anymore).

Plenty of time, not enought focus. And oblivion getting in the way. Growing old too soon.

It wouldn't be (too) difficult if there wasn't another IC right next to the Dallas on the side that needs operated on. I don't have any precision tools, will have to find something appropriate. No problem with the replacement battery - a CR2032 (classic BIOS battery for newer PCs) would be fine and I do have a few dismantled boards where I can take the battery holder from. AA or AAA cells would be overkill - not even the two 286 boards I still have around use such large batteries. :-)

You said the on-board adapter is dual; maybe the driver is detecting a secondary adapter that actually belongs to the on-board LAN chip not to the disabled one in the PCI slot. Unfortunately I have no idea how to distinguish between the two, if at all possible with the DOS driver. Anyway this is easy to check after you physically pull the PCI adapter out.

@ georg: Thanks for the tip on the Dallas chips, I have three boards around that use such chips, one of them was put away long ago probably due to the failing Dallas. Unfortunately that one chip is soldered to the motherboard so I'm not sure I'll be able to revive it. We'll see. @ Hoko: Please bear in mind there is a slight possibility that certain version of Windows 3.x might not install or run (properly) on certain machines. I have my first computer, an IBM PS/ValuePoint (originally SX25MHz, modified by me to DX66MHz by replacing the quartz crystal) that used to operate Windows 3.1 without a hitch but would not accept 3.11 for some reason lost in the mist of time. Sure, this may be a rare situation but if possible, try to find out it the machine you purchase is/was able to run the specific version of Windows you want/have. Also try to find a machine that already has a decent amount of RAM installed because these old beasts would sometimes refuse one type of memory in favor of another (EDO/FPM) and buying extra RAM sticks may be tricky. Not to mention some sticks run at 5V while others at 3.3V and when mixed memory slots are available, RAM voltage may have to be manually adjusted through a jumper on the motherboard. Easy to miss, easy to fry a few RAM sticks... Oh and don't forget 486 BIOSes at that time would usually limit HDD capacity at 528MB unless there was issued some BIOS update in the mean time and hopefully was already applied to the motherboard. If you buy a HDD-less machine you may have a hard time finding a suitable HDD with no bad sectors and the right capacity. My IBM has a 528MB-limited BIOS, so one trick I used back in the time was installing an ISA sound card (ESS1868) that had a built-in IDE controller, to which I had attached a 1.2GB HDD that stored the data, however the main (bootable) HDD was still a small one. At that point I was already using Windows 95OSR2.1 but I guess it might work with 3.x too.

I had that page before my very eyes yesterday. It's impossible for it to simply vanish from one day to another! Maybe it was through Wayback Machine. Try this one through wayback machine: link , it worked a minute ago. Make sure you have temporarily disabled any redirect cleaner addon/extension in your browser. (small typo)

While looking for information on this issue I stumbled into an obscure mention on Intel's site regarding packet drivers. Could this be the missing link or am I far out...?

Well, you missed to specify that this was actually a reinstall over an old/incomplete installation. In that case yes, bad registry entries could cause such errors. Anyway, glad you sorted it out in the end.

There's a possibility that either your media (Windows 98 CD) or your optical drive (CD/DVD-ROM or RW) are faulty. if the errors are exactly the same on subsequent install attempts then most likely it's the media (the Windows disc); if the errors are randomly different it may either be the optical drive (defective, clogged lens, incompatible interface, incompatibility with another drive on the same cable), the RAM (bad locations, incorrectly seated, faulty connection pads) or the hard drive (bad sectors, incompatibility with another drive on the same cable). Due to so many possible reasons it's up to you to narrow down the issue by changing whatever possible in the configuration - Windows CD, optical drive, RAM stick(s), hard drive - after double-checking that everything is properly seated/connected. You may check the RAM using MemTest86 (a bootable disc). You may check the HDD for bad sectors using HDAT2.

Just a shot in the dark but have you actually tried to put all the driver files in a folder right in the root of the active partition (assumingly C:) and preferrably with a short name/path with no spaces (such as C:\NET or something)? Also not sure if it would work but try to send any output from the NET command to a file, i.e. using NET START > C:\netlog.txt or similar in autoexec.bat. That may offer a clue regarding the driver loading process.

Dunno if it helps but I found this discussion on a similar topic. Syntax error prevented the driver from loading: http://www.computerhope.com/forum/index.php?topic=121970.0 There may also be some useful links out there.

Which version of the driver did you get? In the very large one (83MB) v19.3 from Supermicro's site, the DOS inf lists 1096 among the recognized device IDs. Please check your oemsetuf.inf (its own version is 6.09) and see if there is a 1096 listed in the [PCI] -> DEVICE_ID section. If it's not, you're probaly using the wrong driver. The actual driver file e1000.dos is 64592 bytes dated July 28, 2014.