Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


  • Content count

  • Donations

  • Joined

  • Last visited

Community Reputation

0 Neutral

About msoltyspl

  • Birthday 02/25/1977

Contact Methods

  • Website URL
  1. Greetings This short guide presents a reasonably trivial way to change /any/ HAL (that means - following official nomenclature - incompatible ones as well), while doing sysprep on W2K and WXP. It's probably well known by anyone syspreping often, although these days it's far less useful than a few years ago, when there were far more non-apic PCs. From personal exeprience I still have to deal with plenty PIII based machines (cheap, used laptops in particular) - and having just 1 image simplifies life a lot. And ... I still meet people thinking it's impossible. Anyway, here's the tiny guide: 1) Before you do your usual sysprep drill, you will need: hals: hal.dll, halacpi.dll, halaacpi.dll, halmacpi.dll kernels: ntoskrnl.exe, ntkrnlmp.exe These can be found in \windows\Driver Cache\i386 (or \winnt in W2K, in usual cases). Either loose ones, or in one of the spN.cab - of course, loose ones take precedence over the ones in spN.cab files. 2) Rename: hal.dll -> halpic.dll ntoskrnl.exe -> ntosU.exe ntkrnlmp.exe -> ntosM.exe 3) Copy "your" hal and kernel files to c:\windows\system32 (don't worry, they won't conflict with anything). 4) Prepare cutom boot.ini, the one I use looks in following way: [boot loader] timeout=3 default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="XP default (2)" /noexecute=optin /fastdetect /sos multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="XP default (3)" /noexecute=optin /fastdetect /sos multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="XP pic (2)" /noexecute=optin /fastdetect /sos /hal=halpic.dll /kernel=ntosU.exe multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="XP acpi/pic (2)" /noexecute=optin /fastdetect /sos /hal=halacpi.dll /kernel=ntosU.exe multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="XP acpi/apic/u (2)" /noexecute=optin /fastdetect /sos /hal=halaacpi.dll /kernel=ntosU.exe multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="XP acpi/apic/m (2)" /noexecute=optin /fastdetect /sos /hal=halmacpi.dll /kernel=ntosM.exe multi(0)disk(0)rdisk(0)partition(3)\WINDOWS="XP pic (3)" /noexecute=optin /fastdetect /sos /hal=halpic.dll /kernel=ntosU.exe multi(0)disk(0)rdisk(0)partition(3)\WINDOWS="XP acpi/pic (3)" /noexecute=optin /fastdetect /sos /hal=halacpi.dll /kernel=ntosU.exe multi(0)disk(0)rdisk(0)partition(3)\WINDOWS="XP acpi/apic/u (3)" /noexecute=optin /fastdetect /sos /hal=halaacpi.dll /kernel=ntosU.exe multi(0)disk(0)rdisk(0)partition(3)\WINDOWS="XP acpi/apic/m (3)" /noexecute=optin /fastdetect /sos /hal=halmacpi.dll /kernel=ntosM.exe This way, I have an image that can boot in all the HAL scenarios I deal with, either from partition 2 or 3 (my first partition is always reserver for syslinux bootmanager). Of course, adjust for you environment. 5) Do sysprep, but remember about one important thing, if you're preparing Windows XP - sysprep resets boot.ini's timeout to 0 (it doesn't happen on W2K's sysprep) - so make sure to select "quit" instead of "reboot", and fix the boot.ini afterwards accordingly, before rebooting. If you forgot about that step, then just fix it by any other means (boot some livecd, mount image under unix and fix, w/e). 6) Go through usual windows setup drill after cloning, choosing whatever HAL combination you might be needing. After all is done, update Manage->Device Manager->Computer (this is prooly not needed, postclone setup stage handles it iirc - I'm not sure if W2K did that though) and clean up boot.ini to not confuse regular users I've been following this procedure happily, since W2K have been released. A good few years ago I posted similar guide on nforcershq's forums, so some folks might recognize the approach. Hope it's still useful, despite Vista/Win7 times
  2. nlite 1.3.5 and sysprep problems

    When I use nLite 1.3.5 on Windows 2000 (pl version) with sp4, in a very minimal way: 1) no hotfix integration 2) just a few text and pnp drivers added 3) no removed components (and all compatibility checkboxes set) 4) some visual tweaks then after running sysprep 1.1, mini-setup complains about a bunch of files (c_852.nls, some install fonts, some stuff from i386 like certain agt dlls). It actually looks like if language version was at fault here. At home I use english versions only, and I don't remember nLite ever giving sysprep any problems. Does nlite remove any additional stuff, assuming 3) is true ? My exact nlite config - in attachment config.txt
  3. nLite 1.2.1 breaks Office 2003 administrative install

    Hello ! It was mentioned some time ago, regarding IE7, in this thread: http://www.msfn.org/board/index.php?showtopic=86346 along with simple fix (it was about bad registry access rights after slipstreaming). It saved me a lot of wasted time today (with office xp pro vlk) Btw, the problem still exists in 1.3 rc.
  4. Intel INF update

    IDs are the same. This is just a separate directory with a few inf/cat files. From what I understand, they are chosen by intel's installer, depending on the situation (what already is installed). Manually, it seems to be up to me. The only differences in all the files are: -CatalogFile=ich6ide.cat +CatalogFile=ich6id2.cat (depends on inf) -IfInstalledDriverFile=pciide.sys +IfInstalledDriverFile=intelide.sys -Needs=pciide_Inst +Needs=intelide_Inst -Needs=pciide_Inst.Services +Needs=intelide_Inst.Services Either way, I'll try with both and see how it goes.
  5. Intel INF update

    Hello I've noticed that INF update for intel chipset contains subdirectory SP (with small remark in readme.txt - "The sub directories (e.g. SP) contains special INFs."). When I ran diff over, for example, esb2ide.inf and esb2id2.inf, the files turn out to be almost identical (referencing different cats and intelide.sys in case of SP). How, if at all, should this directory be approached from perspective of sysprep or cd integration ? Is it safe to ignore SP subdir, and just supply the path to main directory (xp for instance) in OemPnPDriversPath ? Or maybe should I move "special" cats and infs for the main directory ?