syrynxx

This is the SP2 RC2 version of the OPK and PE dated May 13th. Been in training so I still haven't gotten any farther than building a hard-drive version of PE, but one of the bit things I was looking for is WMI support. Here's from the MKIMG.CMD file: /WMI : Include Windows Management Infrastructure (WMI) support for WinPE. /NOWF : Disable Windows Firewall (which is usually loaded by default in WinPE). Use this only if you run server apps in WinPE, as client networking is unrestricted. Note that disabling the firewall does not reduce the WinPE image size. So WMI support is optional in the base, as opposed to being part of BuildOptionalComponents.vbs as I would have predicted. And I like the Windows Firewall - now I won't get paranoid about my hard-drive-based PE getting infected.

I attended Microsoft's OEM roadshow for SP2, and their tech presenter said that the SP2 version of WinPE can now boot off of a USB device (assuming BIOS and USB device both support booting as well). I just finished building my first XP SP2 RC2 version of PE, so I haven't gotten that far yet. -syrynxx

The %SystemRoot%\System32\SETUPREG.HIV in the WinPE build is what gets turned into the SYSTEM registry hive. The tricky part is that the "PagingFiles" registry entry for the paging file has hardcoded drive letters (e.g. C:\PAGEFILE.SYS 100 400), which might make CD-based PE builds misbehave if they %systemdrive% isn't the same as this drive letter. Or perhaps you could try to cover multiple bases by stuffing in a pagefile entry for many drive letters. The risk with this strategy is that if one of those drive letters matches a hard drive partition, you won't be able to nuke that partition from space since it has an open active system file on it. -syrynxx

I looked into this myself. The intelligence has to be in the version of the MS PE build kit, not with the source OS. Just like the BuildOptionalComponents.vbs file is needed to create the OC/OC2.BAT files needed to register the support files for WSH/HTA/ADO, there must be a file (or a new version of B..O..C.vbs) that creates batch files to register WMI support. The closest I came was the WBEMOC.INF file. WBEM is the old name for what MS now calls WMI. ; WBEMOC.INF ; ; This is the Setup information file to install WBEM ; as an Optional Component. This file lists the support files needed, but not the registry stuff that would go along with it, since it says : [WBEM.AddReg] ; all registry additions are being handled within hivecls.inx, hivesft.inx, and hivesys.inx And I hadn't gone through the CLASS/SOFTWARE/SYSTEM hive source files to isolate the WBEM-related entries. -syrynxx

That limit was inherent to the FAT16 file system, which had a 16-bit limit for addresses in the file allocation table. 2^16 sectors of 2^16 bytes each = 4G. 65536 sectors of 65536 bytes each. But DOS, which could only address one 64k segment at a time, couldn't handle a 65536 byte data frame, because it wouldn't have any memory left in that page frame for OS instructions. That's why formatting a 4G FAT16 with NT4 gave you a warning that it might be incompatible with DOS. So DOS' formatting ability was capped at 2^16 sectors of 2^15 bytes = 2048M. NT4 could handle a 64k data frame, but the FAT16 file system couldn't go any higher than 2^16*2^16. The ExtendOEMPartition does a conversion of the 4G FAT16 partition to NTFS, then extends it - FAT16 is capped at 4G regardless of your OS. Prior to the ATAPI.SYS driver in NT4SP3, the next limit for an NT4 boot partition was the 2^10 cylinder addressing limit, which was in BIOS. 2^10 cylinders * 255 heads * 63 sectors/cylinder * 512 bytes/sector = 8.4G limit. Some BIOSes like IBMs cropped this at 7.8G. Then INT13h extensions came around, and there was much rejoicing. That's just from memory - only slightly peripheral to the topic. -syrynxx

No dice with the transplanted E1000325.INF and SYS files from 2003 in XP PE. I am baffled. Ich bin baff. Je nege. And so on. -syrynxx

'Twould seem the Intel 100/1000 driver is stubborn to installation using the normal "put files here" method. I even created an installation capture on "regular" XP SP1 using WinInstall LE 2003 to note file locations, and I had all the files in the same locations (except the INF files which got renamed to OEM1.INF and OEM2.INF). One thing I saw was that in regular XP SP1, which recognized the card, it was originally using the E1000NT5.SYS driver. I switched to a build of MS PE created from Server 2003 instead of WinXP SP1, and the Pro/1000 XT in my test system was recognized right away. That eliminates the problem, but doesn't answer the question of why XPSP1-PE didn't load the E1000325.INF file. The native 2003 file that loads support is NETE1000.INF. The only file listed in the [e1000.CopyFiles] section is e1000325.sys,,,2 - don't know if that "2" refers to the [WinntDirectories] value of "2" = system32, but the driver is only in the DRIVERS folder. I'm going to try using the Win2003 INF/SYS in a WinXP SP1 PE and see what happens. Ve let you know. -syrynxx

The linux distro I used a while ago which had a Tetris game during the install was... Caldera OpenLinux 2.0. Caldera, of course, d/b/a SCO nowadays (hawk-ptooey). and now back to your regularly scheduled thread. -syrynxx

It seems it's not just WinPE that won't boot from a USB device - no version of Windows will. http://blogs.msdn.com/oldnewthing/archive/.../15/113811.aspx From the MS White paper "Recommendations for Booting Windows from USB Storage Devices" at http://www.microsoft.com/whdc/device/storage/usb-boot.mspx "Current versions of Windows should not be installed to USB hard disk drives because Windows does not support USB hard disk drives as the primary boot device. " So it looks like a lost cause. Alors. -syrynxx

When you say "port", are you referring to "recompile in 32-bit mode" or "run 16-bit program on WinPE"? The former would require 16-bit source code or a decompiled version of the program, while the latter would require someone to develop a PEBuilder plugin for the WOW subsystem. -syrynxx

Update - I just verified SQL query ability from MS PE 1.2 built from WS03 source, but I had a strange problem before I got it working. First step - run "BuildOptionalComponents.vbs" from the PE build directory. If you run off a WS03 source as I did, you'll need to comment out the version checking in this VBS file, since it claims it's only designed to run from Windows XP. This creates the OC.BAT and OC2.BAT files in the Win PE i386 folder. If you run this VBS without any parameters, it will copy all support files necessary for WSH/VBS, HTA, and ADO support to the PE target directory, as well as some sample files to prove the subsystems work. Second step - from a booted copy of WinPE, run OC.BAT, which in turn calls OC2.BAT. This does a bunch of REGSVR32 calls. Third step - verify subsystem functionality by running \SAMPLES\testWSH.vbs, testHTA.hta, and testADO.vbs. The test ADO will ask for a SQL server name, user, and password, then attempt to query the Northwind database (one of the defaults). This worked for me, only after I performed "step 2.5: Replace all files in 'C:\Program Files\Common Files\System\Ole db' with the ones from a fully-installed copy of WS03." My testADO.vbs wasn't working at first, and I had to create a test subset of OC2.BAT with the REGSVR32 silent switch removed (/S). Then I saw I was getting the following error : "C:\Program Files\Common Files\System\Ole db\MSDAORA.DLL is not an executable file and no registration helper is registered for this file type." which I got for about 10 files in that folder. Copied over the ...\Ole db folder from a normal WS03 installation, and then the DLLs registered jes fine. I believe Wes Miller, who did the WinPE webcast for Microsoft a few weeks back, also had a problem with his testADO.vbs script during the demo, so perhaps there's something fishy in the MS PE build script. Hope this helps. -syrynxx

My two cents... The default PnP behaviour for loading drivers prefers signed drivers over unsigned, regardless of your signing policy (which looks to be "ignore"). That said, if XP recognizes your PnP Vendor/Device combo in its own INF file (I see lots of Intel cards in NET557.INF), it'll load the native XP driver even if it's older than your unsigned driver. If you copied over the XP driver with a vendor file of the same name, the "signing" won't match, and bad things result. But this looks like XP just doesn't recognize that device, so you just need to copy the INF file for your adapter into the \i386\INF folder (or somewhere in your OEMPnPDriversPath). Don't know where that CertClas.inf error is coming from. I looked in my own XP INF folder, and didn't see "pci\ven_8086&dev_103d" (which is the PnP signature of your adapter) in any files, so it's not a natively-recognized NIC. Look in the vendor's INF file for this string to verify it's the right INF. Hope this helps. Intel is PnP vendor 8086. Some geek got a chuckle over that assignment. -syrynxx

This is from \i386\LAYOUT.INF of my XP Volume License CD with slipstreamed SP1: (around line 15800) spcdname = "Windows XP Professional Service Pack 1 CD" spcdtagfilei = "\win51ip.sp1" My CD has that WIN51IP.SP1 file off the root. Don't know why your PE build is looking for it, but that's what it's looking for. The file is 2 bytes of nothingness. -syrynxx

If you're just looking to get files to a printer without any formatting, you could try the old COPY /B method. I did this to print a plain text file: NET USE \\laptop\IPC$ /u:username password just to establish an authenticated InterProcess Communication link from PE to my laptop. Then I typed COPY /B filename \\laptop\prtshare which copied the file in binary mode (no formatting) to the printer share. This would probably work for a parallel-attached printer (just use LPT1: as the destination instead of the UNC). Can't help you for a USB-attached printer. -syrynxx

Version 1.2 of WinPE was available to volume licensing customers as of June 2003. Could've been available sooner, but I believe the versioning is: WinXP RTM --> WinPE 1.0 release WinXP SP1 --> WinPE 1.1 release Win2003 --> WinPE 1.2 release and there will be a new version coming out whenever WinXP SP2 goes gold. That aside, MS WinPE should be launching STARTNET.CMD as the default shell, which echoes some "obey the EULA" text at you and stops at an open CMD prompt. This is controlled by the registry value HKLM\System\Setup\CmdLine REG_SZ "Whatever you want to launch" If your default shell is a CMD file, closing that file will shutdown/reboot MS WinPE. So check your value for this reg entry, and if it's STARTNET.CMD, verify that STARTNET.CMD exists. This should be a step in the right direction. -syrynxx