I wonder if a linux "live" environment would be able to be faster and support more hardware? Even something command line that has the ability to check HAL, read controller hardware and provide read/write on ntfs drives, edit windows registry/boot.ini to inject driver/HAL information.

Something like TinyLinux or DSL from a PXE boot, cd boot, usb boot or drive boot. You'd have a pre-setup like Sysprep does to prepare the system to restart using linux and other processes, ie. generalizing the hardware (might not even need to do that).

I find that a pre-imaging setup to be best, something run from windows beforehand that will run on next boot. Not needing additional media to boot from. Similar in function to Sysprep without the hardware dependency to run.

However, this would involve the ability to script in Linux, of which I have no experience. Though, I'm willing to learn. Maybe a perl scripter to help?

http://www.pixelbeat.org/cmdline.html

Command to check CPU information -
grep "model name" /proc/cpuinfo

Small *nix distro's
http://bengross.com/smallunix.html

Yeah I'd also rather not have to boot into a PE type environment. It's not as fast as sysprep either.

Some interesting information HAL changing issues

http://communities.vmware.com/thread/15 … p;tstart=0
http://communities.vmware.com/thread/29202

and an MS kb

http://support.microsoft.com/kb/237556

So a couple things noted...

Multiprocessors use -
i386\driver.cab\ntkrnlmp.exe extracted to %windows%\\System32\ntoskrnl.exe
i386\driver.cab\ntkrpamp.exe extracted to %windows%\System32\ntkrnlpa.exe

Uniprocessors use -
i386\driver.cab\ntoskrnl.exe extracted to %windows%\System32\ntoskrnl.exe
i386\driver.cab\ntkrnlpa.exe extracted to %windows%\System32\ntkrnlpa.exe

HALs -
i386 source file: i386\driver.cab\halmacpi.dll
Computer type: ACPI Multiprocessor PC
Copy to this folder: winnt\System32
Rename to this file name: hal.dll

i386 source file: i386\driver.cab\halaacpi.dll
Computer type: ACPI Uniprocessor PC
Copy to this folder: winnt\System32
Rename to this file name: hal.dll

i386 source file: i386\driver.cab\halacpi.dll
Computer type: Advanced Configuration and Power Interface (ACPI) PC
Copy to this folder: winnt\System32
Rename to this file name: hal.dll

i386 source file: *i386\driver.cab\halsp.dll
Computer type: Compaq SystemPro Multiprocessor or 100% Compatible
Copy to this folder: winnt\System32
Rename to this file name: hal.dll

i386 source file: *i386\driver.cab\halapic.dll
Computer type: MPS Uniprocessor PC
Copy to this folder: winnt\System32
Rename to this file name: hal.dll

i386 source file: *i386\driver.cab\halmps.dll
Computer type: MPS Multiprocessor PC
Copy to this folder: winnt\System32
Rename to this file name: hal.dll

i386 source file: *i386\driver.cab\hal.dll
Computer type: Standard PC
Copy to this folder: winnt\System32
Rename to this file name: hal.dll

i386 source file: *i386\driver.cab\halborg.dll
Computer type: SGI mp
Copy to this folder: winnt\System32
Rename to this file name: hal.dll

The only HAL above that seems to work on both normal/standard/most Uni and Multi Processors is this one -
i386 source file: i386\driver.cab\halacpi.dll
Computer type: Advanced Configuration and Power Interface (ACPI) PC
Copy to this folder: winnt\System32
Rename to this file name: hal.dll

We should be able to edit our own INF file to change the HAL appropriately with the HAL.inf. Perhaps we can install the HAL like we do the mass storage? Only reason I say that is because Sysprep -bmsd injects System classes into mass storage section of the sysprep.inf file from the windows driver directory.

But we also have the issue of an incorrect mass storage driver.

Perhaps we should move the posts on Replacing Sysprep with our own process to another thread?

ed. I just found this helpful little tidbit that we might be able to edit to our testing...
http://windowsitpro.com/article/article … ssing.html

What's devpath suppose to do anyways, set the path in the registry?

It's most likely because the earlier version proved to be more reliable. But you'll have to read the change log to find out.

In Windows 98 we used to enum the system drivers in the registry. I don't know if we can do it in a similar way.

Oh and in your test the HAL would be the same, it's only the chipset that's different. And it'd most likely work without any extra intervention except for booting into safe mode.

llewxam wrote:

I do use it, but Ghost doesn't touch the SID, you need GhostWalker to do that part if you want a 3rd party tool to do SID.  Ghost just clones.  SysPrep directly handles SID, when SysPrep setup manager is run it gives an option to not reset the SID, which means if you don't check it, the SID is reset.  That is why your (OverFlow) suggestion earlier about just copying the hard drive's files over to another drive works instead of needing cloning software - my Restore disc simply marks a partition as active and un7zips an archive of a SysPrepped setup.

Actually the latest version of Ghost, if I'm not mistaken, has the ability to change SID (albeit I think it uses NewSid or Sysprep too lol).

I could be wrong. As I hate the latest version of Ghost.

Exactly... this is basically what acronis and ghost do.

I used to do that by selecting Advanced Configuration and Power Interface (ACPI) PC and Standard IDE before running Sysprep. The HAL is basically the one that just works with just about everything, fortunately.

Yeah MySysprep still uses sysprep lol. But we could do something with editing the boot.ini. I mean it would be a manual process of editing selecting the HAL.

Or you can select a basic HAL that works with both multi and uni processors (which you do anyways before sysprepping).

What is your thought on making it so the system boots properly with the correct HAL and mass storage drivers?

Newsid can regenerate new SID and you can command line the workstation name you want.

And basically then we'd need a join domain script, easy enough.

But then find a way to get it so the imaged Windows install will boot with the new hardware without frakin.

Here's a deal with sysprep, it can use both OemDriverPath in the INI and Registry import location. But if you can import the driver locations into the registry you can also install drivers using the windows driver installation DLL too. But its something way different for the mass storage drivers.

The way I used to do it is only install driver with sysprep that I needed in order to boot and function, network, mass storage and chipset. Everything else was done with an post sysprep mini setup (with either my installer or something else).

Sorry Jeff, I'm not able to really test Sysprep all too often anymore as my job has changed companies and my responsibilities have evolved. But when, and if, I get a free moment (from the wife, child, house and life) I'll test it wink

Yes he does hate sysprep. I agree that a fresh install is much cleaner but sometimes you have to use sysprep or something similar.

I put a request in to fix it in the main 3rd party drivers download thread.

An offline sysprep to inject the drivers you only need really is the way to go with this. As annoying as it is.

Also,

DP_Modem_wnt5_x86-32_90128

\D\3\M\S\1\mdmhamrw.inf

There's a possible issue with having brackets in commented out sections. Quick and easy fix.

I saw that too. Its with DP_Modem_wnt5_x86-32_90128.

From what I can tell it's doing it from this file \D\3\M\S\1\mdmhamrw.inf for a Smart Link SmartModem...

There are brackets in a commented out section that's making it freak. I don't know if I'll be able to edit the function to steer away from that as the Regular Expression checks for the next start bracket to end it's scanning of lines.

But it's a simple fix to the inf file. And you don't break any signing or anything crucial.

Virtual download to http://3rdpartydriverpacks.thesneaky.co … 2_80925.7z  should be changed to
http://3rdpartydriverpacks.thesneaky.co … 2_90225.7z

Also the first post should be updated to reflect the fact that http://3rdpartydriverpacks.thesneaky.co … -32_810.7z is no longer around and merged with, what TV?

llewxam wrote:

I just ran your latest version (3.2e), couple things.  First, when I specified which folder contained the INFs it kept the default C:\D int he search.  Not a big deal since I saw it was piped, but maybe give an option to search additional folders after the user specifies which folder they want to scan, the app hung when I ran it the first time because I didn't catch the C:\D in there, and since that folder didn't exist it chocked.  Maybe I was just not patient enough to wait for it to move on, I get like that!!  big_smile

It's always done that. If you select the text and then drop in your locations it will write over whats there. But it's designed to add to the list you currently have in the input box. This way you can add different locations to scan, not having to rewrite the locations.

The application doesn't care if the folder is there or not. It won't hang if it can't find the location it'll just proceed to the next location(s). I think you weren't patient enough.

llewxam wrote:

Another nice thing would be to be able to specify where the CSV file (or Excel if that's your thing) is saved, when it started running I didn't know where it would go.  I found it in the root of where the tool was run, but would prefer to specify it goes in the root of where it is scanning.

For now I'll add a mention of it in the read me and the help tool tip and more information dialogs. Eventually, as shown in the "to do" list it's a future hopeful feature "set with ini". I don't know if I'll add a graphical option for location. I might.  I figured most people would know to look at the same folder as the program for exporting.

llewxam wrote:

After it scanned for a bit I got a message box "AutoIt Error" "Line -1:   Error: Array variable has incorrect number of subscripts or subscript dimension range exceeded."

The folder I had it scanning was C:\DP\D (so no silly path Jeff  hahaha) which contained all main and 3rd party packs.  I ran the tool again only on the chipset pack and it finished fine.

It's possible that one of the 3rd party packs has a malformed section of an inf file(s). Probably a HWID with a equals sign in the line. The main packs scan perfectly fine. I'll try out the third party ones at some point.

Can you pinpoint which of the 3rd party this is happening to? Thanks for the sleuthing!

v3.2e out!
-- Fixes tip help from "comma" to "Pipe symbol"
-- Fixes some internals issues with deleting old export hardware profile
-- Changed visuals to all display internally on main window, exporting hardware profile will not show tooltip
-- More visual changes - clear button for locations, filters
-- Fixes main window on top issue when browsing for folder/file locations

v3.2e will be out Monday, hopefully. If anyone has experience with Regular Expression (not my strong suit) please let me know.

Also, another point on weight of INF drivers. We need to take into consideration the OS architecture specific drivers. Some may be generic from 9x and up and some are specific for XP and up. So there's also that.

Thanks for the insight Jaak! I didn't even know there was a "prize" lol.

The only other thing my tool is lacking from the core scan is the ability for the section scanner to pick up the hwids list with backslashes which tell the windows driver installation to go to the next line for another(more) hwid(s).

But we, at Driverpacks, seem to fix these so that they are on separate lines anyways. So I'm unsure as to how important of a fix that is.

What we need is more testing of the tool to make sure there are no blind spots. I can do only so much in my testing. I need people are who are more familiar with the daily grind of what the drivers should be, what's left out and what shouldn't be there.

I'm just happy my tool has speed up development for some of the developers, like Mr_SmartePants with sound and graphics. And the code has helped Jeff with his coding.

This is my testing process...

I use Windows Search to find every INF file in a specific driver folder (I don't include any INF files that are packed within ZIP files in the driver folders), noting the INF file total. I then proceed to manually copy from every INF in the said folder the set of HWIDS that are good into a spreadsheet.

Then I use my tool and set it to the same folder and scan. I then proceed to match my manual list to my automated list to make sure that I have the exact same end result.

Man getting to this point has been an adventure!