15 replies to this topic

[roamer_1]

Hi everyone,

I have been using a bootable Mindows CD as a platform for repairing computers for some time, as it is quicker than BART disks, and the win98 NTFS drivers are "stupid" enough that often one can access damaged NTFS systems that an NT based solution cannot handle. It is also quite nice for virus detection, partitioning, and just about anything except accessing the NT registry system.

In order to use it well (and quickly) I keep hardware detection turned off, but this can be troublesome, as one is stuck without nic drivers, chipset drivers (think USB), and one is stuck with 256 color graphics on standard vga.

I have had good success detecting hardware from DOS (on boot) and "injecting" drivers into the Mindows system directory/registry before it starts using simple batch scripts which seems to be the way to do it- But, it is rather awkward in practice, since one has to prepare "driver packages" in advance for everything.

I would like to discuss methods and practices with like-minded folks, and would be particularly interested in work by others (already existing and supported) which offer "driver packs" for Win98 similar in kind to the driver packs available for WINNT systems.

If such cabpacks exist, I would like to attempt to read the accompanying INFs and inject the drivers necessary during the bootup process (from DOS). I am mainly interested in chipset and NIC which would have to be carried on the CD, whereupon USB and NIC would be available on startup for WIN, making it quite simple to redirect WIN to look for further drivers from a USB thumb or network location.

I would welcome any discussion regarding this issue.

-Bruce

[Brito]

Hi roamer_1, welcome to the board!

..
and just about anything except accessing the NT registry system.
...

Have you already tried to load the registry hives from NT systems into the local registry of a win9x based one?

Not sure of available tools inside win9x (perhaps regedit?) to load system hives, but I'm quite sure that windows API itself can be of our help here (unless the format is not compatible) since we can load win9x registry hives on regular NT systems.

Perhaps using some small compiler like AutoIt you'd also be able to edit these NT hives, what do you think?


There's also a good tool for reading hives from DOS here:
http://www.boot-land...sible-t176.html

[roamer_1]

Hi Nuno Brito,

Hi roamer_1, welcome to the board!

Thanks for the welcome!

Have you already tried to load the registry hives from NT systems into the local registry of a win9x based one?

Yes, but it can be confusing, as it becomes interspersed among the reg entries for Mindows itself- it also requires hex-editing the original 9x regedit to accept NT registries- A method I cannot recall, having long ago abandoned this as a method. Win9x registry tools do not support unicode either. Might be worth another try using TiyHi's regedit..

Not sure of available tools inside win9x (perhaps regedit?) to load system hives, but I'm quite sure that windows API itself can be of our help here (unless the format is not compatible) since we can load win9x registry hives on regular NT systems.

The format is not compatible 9x => NT. though NT can read 9x... Like I said above, someone had hexed up a fix but it was not useful to me, especially for using cleanup tools and for chasing hard-to-kill virii on a dead NT system, or disabling drivers and the like, which is the primary reason to invade the reg on a dead box anyway... I have had some success with CIA Commander, as a separate entity from Mindows, but it is rather clunky to use.

If one knows what the problem is, one can stuff a .reg file into startup on the dead box, but it must be able to boot to the user level for that to be effective, and as I said, supposes one has already diagnosed the error. A neat trick, if removing a virus previously detected, just to clean regkeys, but primitive to say the least.

Perhaps using some small compiler like AutoIt you'd also be able to edit these NT hives, what do you think?

Perhaps so, but I am nothing more than a batch writer... One helluva batch writer, but batch writer none the less.I keep threatening to get into a language, but I always make do with DOS... find a tool that does what I need and slap on a WBAT wrapper to make it easy... And there ya go. . And there another reason I like 9x better than BART, too... real DOS!

AFAIR, AutoIt "inherits" it's abilities from the OS, so I doubt it would do what you want here...

What would be lovely is if someone would port one of the available off-line reg editors that work so nicely on a B.A.R.T- But, alas, more folks need to get involved with mini9x to get that to happen, not to mention authors of some of the available portable apps which will not work from Mindows... Like Jellybean keyfinder, which worked for a while under 9x for reading remote registries, but now fails to do so... Most folks just assume BART, and don't figure mini98.

I did recently find this http://registrytool.com/ which looks exciting to me, but whether it will run as a portable app from Mindows, I don't know. It is capable of sand-boxing any Windows reg and then saving changes to a reg file which can be imported on boot... pretty close to what I want.

There's also a good tool for reading hives from DOS here:
http://www.boot-land...sible-t176.html

Thanks for the link! I will be trying this guy out, for sure!

-Bruce

[roamer_1]

There's also a good tool for reading hives from DOS here:
http://www.boot-land...sible-t176.html

Hi again Nuno Brito,

Just wanted to say thanx again for this little tool- it works perfectly for reading offline registries (either 9x or NT) from DOS or from a DOSBOX in the mini98... It may not be pretty, but it works a charm!

-Bruce

[hai_ok]

bootable Mindows CD

In order to use it well (and quickly) I keep hardware detection turned off, but this can be troublesome, as one is stuck without nic drivers, chipset drivers (think USB), and one is stuck with 256 color graphics on standard vga.

I have had good success detecting hardware from DOS (on boot) and "injecting" drivers into the Mindows system directory/registry before it starts using simple batch scripts which seems to be the way to do it- But, it is rather awkward in practice, since one has to prepare "driver packages" in advance for everything.
I would welcome any discussion regarding this issue.

-Bruce

This is exactly what I am looking for.
Please share with me how you are building the driver packages and then injecting them at boot time. I have a 12 MB Mindows and I only want to add video, sound and direct x. If it works like BartPE, then I am sure we can load DX just like a driver. Thanks for your help.

[roamer_1]

This is exactly what I am looking for.
Please share with me how you are building the driver packages and then injecting them at boot time. I have a 12 MB Mindows and I only want to add video, sound and direct x. If it works like BartPE, then I am sure we can load DX just like a driver. Thanks for your help.

Hi hai_ok,

My method of building a driver package (or any other package for that matter) is to start with a clean image of Mindows on a spare harddrive. I have a dedicated drive that Mindows is installed to using SUBST commands from the autoexec to spoof Mindows on a Ramdrive (though really in a folder on a back partition), and spoof my CDROM in another folder. Once installed basic and clean, I zip the Mindows installation and store it in order to keep a clean installation.

I also wrote a DOS batch that will store a full directory listing, full backup of system files, and a full export of the reg for different jobs. there is also a job called "org" (for original), which is the "picture" taken when the installation was first made.

The SAME thing is done for a full version of Win98SE installed on the C: drive.

I wrote yet another batch that changes boot files so I can boot to either the full or the mini version... The same "picture taking" and "Restoring" capabilities work for the full version too.

So the general idea is to use the full original clean version, With a "picture" taken while it is clean. Then one would install the driver or app in question, reboot, and take another "picture" of the system. It is then a simple matter to compare the various components (before vs. after) gathering the differences in the two reg exports into a .reg file, collecting the changed or added files into a zip with a batch to copy them to the folders they were taken from, and then write a batch to add any entries to system files as needed. This is then written into an installation batch and the whole works is zipped to make a package.

I then restore the full Windows back to original and test the installation package. If it works, I then edit the pertinent paths in the installation (including reg entries and system file entries) from C:\WINDOWS to R:\MINDOWS, and try to install it into the Mini98. After a bit of cussing and fiddling around with Dep Walker and Systernals reg and file tools, I can generally figure out all the dependencies that are not in my "stock" mini98, and add the required deps to a folder on my CD so they will be available for the installation, writing the necessary extra info for copying these deps onto the end of the installation package installer batch.

Then the trick is to detect the proper card during the boot process. I do this after the choice to boot the Mini rather than DOS, after the basic MINI has been blown to the ramdrive, but before firing WIN.COM. My prototype sniffer uses pci.exe to spit the detected cards to a file that I can parse to detect particular things. Unlike you, I am interested in a bit more- I would like the board detected so that I know which USB to install, I would also like the NIC, and would be happy to get vid too, if only so it was better to look at Since the "installer" is all batch, and with regedit onboard, it is a simple thing to blow in all the reg entries and files needed to install the thing. Since it is effectively blown in before WIN knows what is going on, there is no restart needed to initialize the driver.

While I have made enough driver installations to prove the concept, it is not as easy as one would believe... After painstakingly creating setups for all of my own boxes, I found it unbearable to continually make drivers thereafter to increase my compatibility. All to soon my CD was over full, and mostly just supplying the raft of drivers I might need.

My next attempt will only detect the USB on boot, and I will carry the drivers on a thumb drive... writing the installation to a registry on that thumb... the thumb registry would then be imported to the main registry on a reboot, and would basically be saved back to the thumb on shutdown getting those drivers off my CD and adding the ability to save the registry settings (something I have always looked for...

Even so, it is a thankless task by myself. If there was a lot of interest and we could get together on conventions, then many people could write the things and we could develop a full database. Perhaps there is a better way- I am certainly open to ideas.

[was_jaclaz]

Even so, it is a thankless task by myself. If there was a lot of interest and we could get together on conventions, then many people could write the things and we could develop a full database. Perhaps there is a better way- I am certainly open to ideas.

Rest assured that there are a number of people still "fiddling" with Win9x and Mindows.

(though of course the leechers/contributors ratio is of course rather high)

Why don't you make a new specific thread proposing the "conventions" you have been using and publishing your batches, we can discuss them and start a specific project.

jaclaz

[roamer_1]

Rest assured that there are a number of people still "fiddling" with Win9x and Mindows. [...] Why don't you make a new specific thread proposing the "conventions" you have been using and publishing your batches, we can discuss them and start a specific project. -jaclaz

Hiya jaclaz! Thx for the reply.

Unfortunately, my stuff is rather dependent upon my particular flavor of DOS, which ran into some distribution problems . It is my intention to publish again, but cannot until I reformulate my installer/gather tool to a wget disk builder kind of thing.

I do have some parts readily available as proof of concept- The early versions of my HOSTINFO, which proves the detection-on-boot method, are probably available as distributables, as I remember Mike (Winimizer) and myself going around with it for a while... It collects information from the host machine (PCI card ID for NIC, VID, USB, CHIP, and Partition info, etc, and stores in an inifile in %temp%). My SYSBACK, the gizmo that does the "picture taking" is probably pretty close to distributable too... Let me see what I can offer in proofs right now, and I will work on getting the rest of it in a presentable condition.

But more to the point, I am not happy with my method, as it requires creating these packages from scratch. I would like to talk about other methods that may not require as much... For instance, I am fairly certain that I can parse and process .infs from DOS... Perhaps one could take advantage of the prepackaged routines already available using 9x and 2k cabs... I know that Win98SE detection ability increases if one adds the driver cabs from ME... Perhaps one could build on the existing- adding to the stock cabs to improve detection across the board- not only helping ourselves but the greater 9x community at the same time...

While my method works, perhaps there is a better way...

[was_jaclaz]

One of my semi-random ideas :
what if we use a Win95 based setup with the /p f switch:
http://members.bella...cary/switch.htm

is there a way to log what happens in "miniwin" ?

jaclaz

[roamer_1]

One of my semi-random ideas :
what if we use a Win95 based setup with the /p f switch:
http://members.bella...cary/switch.htm

is there a way to log what happens in "miniwin" ?

jaclaz

I guess I don't follow ... /pf does not work in '98... a disability that is easily remedied using a .reg file to kill the enum while still in DOS (blown in w/ regedit before handing off to WIN.com). I know this to work, as my Mini98 does this as a boot-up option.

I don't know if a bootlogger would work, as they tend to be of little use once WIN.COM is fully initialized, and any winlogger is not going to work until explorer is on the job... perhaps between the two...

One can also capture wininit and RunOnce values on the fly if you run into a particular stinker, as those are the only places the setup can play dirty pool... but it is generally pretty easy to see what has occurred using the "before and after" method.

???

The necessity of rebooting IS the problem with 98 detection, Though in the mini, one can just exit to DOS and "exit" again to restart win... That is enough in most cases, and one doesn't lose the ramdrive. But if detect is turned on, one must of a necessity detect every_stinking_thing... One cannot just detect VID, NIC, and CHIP/USB without stumbling through the whole 9 yards, and that happens for everything that is not detected on each boot. A serious PIA for a tech disk...

That is why I propose to detect from DOS, and hope to mimic the detection of Windows... but have the option of ONLY detecting a limited set of devices. I believe this to be a plausible working model, except the wininit would not process the new drivers, they would be fed directly into the reg, and the drivers blown to the required directories. The only problem I see in this model is if the installation requires changes in vmm32, but that could be done too- Just extracting the needed vxd as a headered file to the vmm32 directory (or IOSUBSYS)

In my last attempt, HOSTINFO detection added only 3 secs to the boot process, with an additional overhead of 5-9 (est, avg) secs added to copy and process the detected drivers from the cd into the Win installation. That is absolutely stellar compared to a full-detect 98, or any WinPE! Now, will that be as quick digging through cabs and extracting all the etc? I dunno... But I would like to try it .

In reality, one really only need to detect the chipset, drive, and usb in the initial run, those being, therefore, the only drivers needed onboard the CD... With MaximDecim's mass stor driver and 2k USB stack built into the mini one can then carry the bulk of the drivers on a thumb, and have access once the thumb is detectable in the win boot-up. See?

The real issue for me, the thing that would make it worthwhile, is to use the pre-existing driver databases for win2k, winme, and win98se to get a broad enough base of drivers to begin with. If we could then add another cab containing whatever newer stuff is needed, then we would clearly have less work to do than starting a brand new system and writing installers for everything.

The same could be done, btw, for some program installers too. If one can get to the inf in the installer package, parse and process it from DOS, then the program could effectively be "injected" on the fly too, in exactly the same method, though probably a nice autoit installer for Mindows to mimic the Windows Installer would be a more attractive project .

The problem is that I don't know enough about the installation process to speak with authority- I would much prefer a collaboration before I go killing another month of Sundays finding out my wild hair is nothing more than that- a wild hair... Somebody out there has serious knowledge of the structure of the driver cabs, how to add extra cabs to the system, and what pitfalls I might hit on my merry way.

Again, if correct, the work done here would work even better in a full 98 installation as well, adding and updating win98's ability to auto-detect and install newer equipment. A worthy project for the 98 community to take on.

-Bruce

[was_jaclaz]

Another few semi-random ones, maybe something that could work as a base?

http://sourceforge.net/projects/shdl
http://rule-project.org/?q=node/4
http://www.holin.com/cindex.html

jaclaz

[sheepdog]

If of any use
This very simple script take each file in the current directory and compress it using makecab command.
Each cab file is put into a subdirectory ".\Cab".
The filename of the cab file is the same but has the last character replaced by an underscore (_).
Do makecab /? for more switches and explaination.

CODE
@echo Off
title MakeCab all file in current directory

FOR %%L IN (*.*) DO makecab %%L /L ".\Cab"

exit

Then search/extract the required files into windows\system\inf

extract /d c:\windows\options\cabs\win95_02 - Utilizing the /d switch will list the contents of the win95_02 cabinet.

extract /a /d c:\windows\options\cabs\win95_02.cab mmsystem.dll - Utilizing the /a and /d switch will locate the mmsystem.dll by searching win95_02.cab and beyond.

extract c:\windows\options\cabs\win95_10.cab mmsystem.dll /l c:\windows\system - Knowing which cabinet contains a particular file, you can use this command to extract file(s). The /l switch is used to specify the location to where you want the file to be placed once extracted.

extract /a c:\windows\options\cabs\win95_02.cab mmsystem.dll /l c:\windows\system - Using the /a switch searches cabinets 02 and beyond for mmsystem.dll. Once located, the file would be extracted from the appropriate cabinet and then placed into the c:\window\system directory. The location of the cabinet may vary on your computer.
It was info I posted to a chap interested in creating win9x driver packs, detected devices parsed to a batch file via a dos sys info utility
All the best

[was_jaclaz]

@sheepdog

Nice!

Can you tell which the "DOS sys info" was?

For the record, by using the

makecab /D CompressionType=LZX /D CompressionMemory=21

you should get maximum compression level

Do check these, some interesting info on 98 setup and compression:
http://www.msfn.org/...-9x-t81068.html
http://www.msfn.org/...ion-t50671.html
http://www.msfn.org/...sue-t25374.html

Also, cabpack should be the GUI equivalent:
http://www.larsheder....de/cabpack.htm

jaclaz

[sheepdog]

@sheepdog

Nice!

Can you tell which the "DOS sys info" was?

For the record, by using the

makecab /D CompressionType=LZX /D CompressionMemory=21

you should get maximum compression level

Do check these, some interesting info on 98 setup and compression:
http://www.msfn.org/...-9x-t81068.html
http://www.msfn.org/...ion-t50671.html
http://www.msfn.org/...sue-t25374.html

Also, cabpack should be the GUI equivalent:
http://www.larsheder....de/cabpack.htm

jaclaz

Hi jaclaz sorry for the delay, it was configus with the two hardware screens dumped to file, a program I see you have listed earlier.
The infs could quite easily be incorperated into the cabs and cds full of all the drivers made, with prompts for driver1 cd to be inserted etc

[sheepdog]

In moving onto other things, (microchips to make some money) I wish to pass on to this forum (not to be published onto the msfn forums please, i hate their draconian moderators) what I have gleemed. Along time ago I created a 9x mp3 playing setup that fitted completely onto a single 1.6 meg formated floppy disc. The steps involved creating a further stripped down mindows install (many thanks for all your work mike) i.e disabling setupx.dll and reenabling it to install only the hardware associated with sound playback,substituting system.dat with the 121kb file you will find floating about on the internet, striping shell32 of needless padding 520kb and extracting all the files from the thus smaller vmm32.vxd and compressing the whole thing using a brilliant dos compression utility called paq(large ram needed). Paq requires a dos memory management utility for it to work. On start up the floppy would initally via dosamp play files from the cd using dos soundblaster drivers, at which time paq would be called to decompress the files into a ram drive created at boot up, all the directories/files would be directly decompressed into this ram drive apart from the vmm32 files which would need combining into the vmm32.vxd file using the vxdlib tool. This process took sometime but as the music was playing via dosamp anyway it didnt matter, once completed win9x would boot up and then takeover. I cannot for the life of me remember the dos utilities files name but in dos it mimicked multitasking and helped expediate startup. The idea was to later incorperate networking capabilities and bluetooth in the 9x setup to transfer mp3s to the car etc.
Sorry if things are a bit vague but this was sometime ago and my old brain is not what it was.
To get back on topic you may find the dos susu i.e susucdhd.exe utiliites useful for storing files in the win9x setup process, I used one out of the family to store the installed drivers and it survived a soft reboot better than anything else I had tried, just include the drive in the path.
Anyways like I say, time to move on just wanted to record the info somewhere as it might be helpful.
See you around sometime
nostromo signing off

[JonF]

There's also a good tool for reading hives from DOS here:

&#91;url=&#34;http&#58;//www.boot-land.net/forums/Edit-registry-from-Dos-itand39s-possible-t176.html&#34;&#93;<a href=&#34;http&#58;//www.boot-land.net/forums/Edit-regis...sible-t176.html&#34; target=&#34;_blank&#34;><a href=&#34;http&#58;//www.boot-land.net/forums/Edit-regis...sible-t176.html&#34; target=&#34;_blank&#34;>http&#58;//www.boot-land.net/forums/Edit-regis...sible-t176.html&#91;/url&#93;</a></a>

Link's broken for me, even if I quote your message and cut-and-paste the URL from the tag. And how did that link get so weird?

ABE: Ah, there it is, at [url="http://www.boot-land.net/forums/?showtopic=176"]http://www.boot-land.net/forums/?showtopic=176.