new to forum like to say hi like to help if i can for 9xme projects

[lloyd munga]

if i did start a topic in the wrong place i'm sorry let me know and i'll go where i'm told  by the powers that be to do pennance .... i figured i would get to the meat of the matter ....... 9xme driver pack solution ........

 

i have access to probably 10 -20 gig of old drivers with new being found all the time, so i'm going to start building up a database of drivers for 9xme ....... now, if i was to do this, would this be helpful? it should easy enough to unpack withh any number of available unpackers, change the inf and repack but i do have a few questions:

 

if the driver is based on the wdm (windows driver model) theoretically you should be able to use  the newest driver for that hardware on  a 9xme box (as long as its 32 bit?), but not be able to use the drivers enhanced features for the newer os for the most part .... would this be the correct assumption?

 

with the newest drivers being digitally signed, is there a way to bypass or rewrite or hack the signature ( it's gotta be sha'd or some type of hash) or just install drivers offline first

 

i'm still new to this driver pack thing, i was searching out of necessity for ways to cut down install sizes and deleting multi instances of duplicate files ..... it's called SIS or single instance storage ...... if the driver packs are packed efficiently this way, hopefully  the ultimate DP solution could be brought to heel in a 900mb cd which can be read by most older cd roms ..... I wanted to make a win3.x9xme install cd with os install and programs for all os on one cd (like a linux multi-distro full package)

 

i would assume that there is a lot of duplicate code that isn't hardware specific that can be concatenated to build the driver executable on the fly (or is that a flight of fancy?) i guess what im saying is making the drivers universally modular.

 

i know its an old subject, but it's like a bad rash, it just won't go away

[rloew]

if the driver is based on the wdm (windows driver model) theoretically you should be able to use the newest driver for that hardware on a 9xme box (as long as its 32 bit?), but not be able to use the drivers enhanced features for the newer os for the most part .... would this be the correct assumption?

Unfortunately, not even close.

There are significant differences between the Windows 9x implementation and Window NT implementation that make a lot of Drivers unuseable. There are differences even within the 9x family as I found out trying to port Windows 98 Drivers to Windows 95.

In addition, if a newer OS feature is used, the unsatisifed API Imports cause the Loader to reject the Driver. Stubbing may be possible but there is no guarantee that a given Function does not play an essential role in the execution of the Drivers Code.

with the newest drivers being digitally signed, is there a way to bypass or rewrite or hack the signature ( it's gotta be sha'd or some type of hash) or just install drivers offline first

Windows 9x would ignore the Signature. The Checksum can easily be erased.

[Drugwash]

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?

[jaclaz]

May I ask a question?

 

WHY it is *needed* to "to unpack with any number of available unpackers, change the inf and repack"?

 

I mean would it not make more sense to make the actual drivers be available "as they are" and provide a tool or a set of detailed  instructions (or, better, both) to allow the "final user" to modify the drivers (when/where possible) himself/herself (asking nicely to provide back the modified and TESTED driver)?

 

I doubt that a "one-size-fits-all" approach on a huge mass of drivers may lead to anything more than a handful (maybe) of working ones and a large majority of useless crap (additionally modified).

 

jaclaz

[Drugwash]

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.

[jaclaz]

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.

I understand and exactly because of this:

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.

I asked, because if a driver is *somehow* modified/repacked/compressed/whatever BUT the result is not tested and verified working on the specific hardware it represents IMHO more "wishful thinking" than an useful solution, and you can compress it as much as you want/can, still it will take some space without being of any practical use...

Before I forget, we have some news here (possibly useful):

http://www.msfn.org/board/topic/171184-microsoft-ipd-intra-package-delta-compression-tool/

http://www.msfn.org/board/topic/171184-microsoft-ipd-intra-package-delta-compression-tool/?p=1091462

jaclaz

[Drugwash]

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.

Edited December 26, 2014 by Drugwash

[jaclaz]

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.

Yep and it seems like NOONE actually made a compression/decompression tool using MSDelta.dll , so if by any chance you have nothing better to do, a nice project would be using MSDelta AVOIDING the stupid .Net bloat:

http://www.msfn.org/board/topic/173071-msdeltadll-usage-help/

jaclaz

[Drugwash]

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...?

[jaclaz]

Doable (at first sight) but to what avail in regard to the Win9x community? ...

...

... 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...?

Maybe it is just about time to bring down the wall between the "we" and the "they" and consider everyone as being  "ordinary" slaves under the MS "plaaned obsolence evil plan"?

 

I mean, now that also 2K and XP are out of support, we could maybe manage to rebuild the wall only to keep the NT 6.x people outside?

And yes, if we cannot get to it, remember how  Win2K is waaaay better than WinMe and how Godzilla can make mincemeat out of King Kong ANYTIME! 

 

jaclaz

 

 

[Drugwash]

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.

[rloew]

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?

Does that Delta Compression API even work on 9x?

The one I got from a W2K Hotfix would need Patching to work if at all.

I have my own difference tool that I used to use to distribute updates.

A Program and/or Script would be needed to locate, patch and place the files according to the system being updated.

[Drugwash]

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.

[rloew]

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.

I checked the mspatcha.dll 5.2.9354.0 from a W2K Hotfix. It appears to load properly even under Windows 95. The header says Minimum OS = 6.0 so I didn't think it would work.

Newer Versions may or may not work. If not, the Delta Files may have to be rebuilt with a working Version.

[Drugwash]

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.