Mindows Bootable CD and driver detection
#1
Posted 19 January 2007 - 09:10 PM
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
#2
Posted 22 January 2007 - 10:49 AM
Have you already tried to load the registry hives from NT systems into the local registry of a win9x based one?..
and just about anything except accessing the NT registry system.
...
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
#3
Posted 25 January 2007 - 01:55 AM
Hi roamer_1, welcome to the board!
Thanks for the welcome!
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..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.
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 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!Perhaps using some small compiler like AutoIt you'd also be able to edit these NT hives, what do you think?
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
#4
Posted 01 February 2007 - 11:20 PM
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
#5
Posted 02 September 2007 - 02:36 PM
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.
#6
Posted 19 November 2007 - 12:18 AM
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.
#7
Posted 19 November 2007 - 08:58 AM
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
#8
Posted 20 November 2007 - 06:11 PM
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...
#9
Posted 20 November 2007 - 06:40 PM
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
#10
Posted 21 November 2007 - 01:28 AM
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
#11
Posted 22 November 2007 - 05:31 PM
http://sourceforge.net/projects/shdl
http://rule-project.org/?q=node/4
http://www.holin.com/cindex.html
jaclaz
#12
Posted 25 November 2007 - 10:17 PM
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
#13
Posted 26 November 2007 - 09:12 AM
Nice!
Can you tell which the "DOS sys info" was?
For the record, by using the
makecab /D CompressionType=LZX /D CompressionMemory=21you 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
#14
Posted 28 November 2007 - 10:05 PM
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.@sheepdog
Nice!
Can you tell which the "DOS sys info" was?
For the record, by using themakecab /D CompressionType=LZX /D CompressionMemory=21you 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
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
#15
Posted 29 June 2008 - 11:43 AM
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
#16
Posted 29 June 2008 - 12:14 PM
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?There's also a good tool for reading hives from DOS here:
[url="http://www.boot-land.net/forums/Edit-registry-from-Dos-itand39s-possible-t176.html"]<a href="http://www.boot-land.net/forums/Edit-regis...sible-t176.html" target="_blank"><a href="http://www.boot-land.net/forums/Edit-regis...sible-t176.html" target="_blank">http://www.boot-land.net/forums/Edit-regis...sible-t176.html[/url]</a></a>
ABE: Ah, there it is, at [url="http://www.boot-land.net/forums/?showtopic=176"]http://www.boot-land.net/forums/?showtopic=176.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users