Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account



Photo

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

- - - - -

  • Please log in to reply
10 replies to this topic

#1
lloyd munga

lloyd munga
  • Member
  • 1 posts
  • Joined Yesterday, 06:18 PM
  • OS:XP Pro x86
  • Country: Country Flag

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




How to remove advertisement from MSFN

#2
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,121 posts
  • Joined 30-May 05
  • OS:98SE
  • Country: Country Flag

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.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#3
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,281 posts
  • Joined 21-June 06
  • OS:98SE
  • Country: Country Flag

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?



#4
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,852 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

May I ask a question? :unsure:

 

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). :w00t: :ph34r:

 

jaclaz



#5
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,281 posts
  • Joined 21-June 06
  • OS:98SE
  • Country: Country Flag

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.



#6
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,852 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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 :yes: 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... :unsure:

Before I forget, we have some news here (possibly useful):
http://www.msfn.org/...mpression-tool/
http://www.msfn.org/...tool/?p=1091462

jaclaz

#7
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,281 posts
  • Joined 21-June 06
  • OS:98SE
  • Country: Country Flag

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 by Drugwash, Today, 10:30 AM.


#8
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,852 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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 :yes: 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/...dll-usage-help/

jaclaz

#9
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,281 posts
  • Joined 21-June 06
  • OS:98SE
  • Country: Country Flag

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. :no:

Or am I missing something obvious...? :huh:



#10
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,852 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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. :no:
Or am I missing something obvious...? :huh:

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"? :w00t: :ph34r:

 

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:rolleyes:

 

jaclaz

 

 


  • Tommy likes this

#11
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,281 posts
  • Joined 21-June 06
  • OS:98SE
  • Country: Country Flag

Ha ha ha, nice try! :lol:

Honestly, there's too many people out there (some call them developers :rolleyes: ) 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. :whistle:  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. :angel


  • Tommy likes this




3 user(s) are reading this topic

3 members, 0 guests, 0 anonymous users


    Tommy, loblo, rloew