MOONLIGHT SONATA

Y'day i've to prepare an unattended XP SP3 Cd. After setup finished, to my disbelief i find that my integrated Optional Components add-ons failed to install. Even original portion of SP3 sysoc.inf failed. I looked into my add-on INFs and CABs - find no trace of any error there. In [DefaultInstall] all install perfectly. I then integrated the same set INFs and CABs into old XP SP2 disk and everything installed without fuss. I don't use neither RVM Integrator nor nLite. I always prefer to build by hand. Here comes the question - does Microsoft put any signing verification for SYSOC.INF in SP3? I don't modify SYSSETUP.INF, so never patched SYSSETUP.DLL. Only SFC_OS.DLL is patched in my source. Is there any DLL file needs to be patched so that additional sysoc.inf entries could be integrated? Any help would be appreciated, since installation right now is as good as hitting F3 to quit. Regards. MOONLIGHT SONATA

strel, found the problem, you missed that DISKPART actually finds an active partition as SYSTEM and a partition that's booted into as BOOT. so correct Partition NO. as well as the correct drive letter will be obtained by slightly modifying your code as noted below: :GETACTIVEPART FOR /F "TOKENS=2" %%A IN ('DISKPART /S GETPARTNUM.TXT^|FINDSTR /I "Primary Logical"') DO ( ECHO>PARTSTATE.TXT SELECT DISK %HDNUM% ECHO>>PARTSTATE.TXT SELECT PART %%A ECHO>>PARTSTATE.TXT DETAIL PART FOR /F "TOKENS=4" %%B IN ('DISKPART /S PARTSTATE.TXT^|FINDSTR /I "System"') DO SET PARTNUM=%%A&SET LETTER=%%B&GOTO :EOF ) What you think about the static HDNUM=0? thanks.

Well, strel, actpart.cmd gives following output: Disk 0 Partition 1 is active partition with letter C: Which actually is not. PARTSTATE.TXT contains: SELECT DISK 0 SELECT PART 1 SELECT PART 2 SELECT PART 3 SELECT PART 4 DETAIL PART The correct description would have to be: Disk 0 Partition 2 is active partition with letter D: Probing the script why it failed. inform you latter. REGARDS MOONLIGHT SONATA

Yzöwl, I checked both these scripts. As I said earlier, i've 4 partitions, of which Partition 1(the 2nd) is currently active, though i'm writting this fast reply from Partition 0. output for the earlier script is: Booted to Partition 1 on Disk 0 and assigned to Drive D: output for the last one you posted is: Booted to Partition 0 on Disk 0 and assigned to Drive C: What i understand with my limited knowledge is that the 1st output detects the active boot device and its assigned drive letter, while the 2nd one detects the currently booted partition. In case of a single partition system as we find in enterprises, both the output will be same. One problem that always pinned me is that while WMI returns partitions as 0,1,2,3,..., boot loader reads boot.ini and boots partitions on the basis of Partition(1),(2),(3),(4)... I thought about Get Antecedent and correlating with actual drive letters, but it was beyond my imagination that Get Antecedent^, Dependent could be used in a single query. I never found anything in net like that. You are genius. It's imagination of a genius; Google can search only what is recorded in fine print, it can't guess what genius holds in his imagination. Thanks. REGARDS MOONLIGHT SONATA

Well, Yzöwl, script don't fail if it's pasted into a .cmd file and executed as it is. It only fails if i change it to something like this: ('Wmic Path Win32_LogicalDiskToPartition Get Antecedent^, Dependent^^|Find %dp%') Output is : | is unexpected at this time. meanwhile i'm attaching a cmd script which i made and use for adding a /hal= switch depending upon a specific HAL type. That, though a rudimentary one, still throws light why knowing active partitions' drive letter is mandatory. fixbini.cmd.txt

yeah, that i know. it's useless detecting active partition during install as install probably is running in an active partition, unless it's forced in a non-active one. you perhaps thought my emphasize is on detection during UA install, rather my thought is when i sit pretty in Partition 1 and edit the boot.ini at the root of it, from where we all are getting 100% SURE that this is the boot.ini that will be read when machine restarts? If diskmgmt.msc can guide us then why not all these through Windows XP's native command-lines and probably WMIC? Someone VERY VERY SPECIAL and very close to my heart both in terms of esteem and effort that he generates in me for him read my topic starter when i 1st posted it. I keep my fingers crossed. Perhaps it's my inability that i couldn't drive home the point behind this whole thinking. Sorry, mate. thanks.

Thank you, strel, for your opinion. what you said is right, but still i request you to imagine the scenario again. 1. Pressed the power button 2. BIOS POST screen 3. Boot Choice Menu displayed, imagine it like below: First harddisk, first partition First harddisk, second partition First harddisk, third partition First harddisk, fourth partition We've two options at this stage - either push one choice from the menu and when desktop loads, start diskmgmt.msc from run box and know which partition is active, or, go back by pressing ctrl+alt+del and push a PE CD, then boot the PE and there again start any compatible application to learn which is active partition. You may agree with me, all these are workarounds to the problem, not the solution. I want to conclusively know which partition is active and what is its drive letter, before I push a script to modify boot.ini - be it to add a /kernel=somename.exe switch, or add a /hal=440volts.dll switch to bind the booting of one OS to a specific hardware abstraction layer. I hope I explained the necessity of my thinking in this regard. REGARDS MOONLIGHT SONATA

Well mates, my problem started because of installing Windows XP into different partitions. I've my home hard disk partitioned into 4 primary partitions. Drive letters are C,D,G and H with letters E and F occupied by my CD/DVD drives. XP is 1st installed on C: and then I made active the Partition D: and installed XP there also. Now, as you all know probably, boot.ini is read by boot loader depending upon which partition is active. Therefore, to boot partition C: I've to incorporate its ARC path into the boot.ini that resides in Partition D:, because D: is the active partition.Here comes my problem. how could i conclusively know which partition is active at any moment and what drive letter has system assigned to it so that the editing of boot.ini could be done through a BATCH/CMD solution and if possible, even during unattended installation. Any discussion in this regard is welcome. REGARDS MOONLIGHT SONATA

Well, resizing is not a problem at all; problem is EasyBoot only accepts 640x480 logos with 256 colors as background and the logo image must be saved as windows .BMP file, with no compression. So, just resizing larger wallpapers and then changing colors from 32-bit/24-bit to 256, invariably murders those images. This is the reason why i'm in search of link to some 640x480 size 256 color images. is there any website which can act as a supply-line? Thanks.

Hi MSFN Friends, I'm currently building a multi-boot CD based on EasyBoot foundation. Problems is i'm not finding websites that can provide a few XP-Style-XP-era 640x480 sized wallpapers. I wish to use those wallpapers as backgrounds for different pages in EasyBoot-based CD. Can someone point me to some websites that stores a handfull of 640x480 wallpapers? Thanks.

@soporific, yes it is! actually i'm not in need of an all-in-1 REG file, rather a set of tweaks from which i can select my desired ones according to specs. BTW, does your tweaks pack explain in detail the changes in registry or some .INI files it applies, or it just applies those tweaks upon selection? anyway, thanks, i'll look into your tweaks pack, for sure.

Well, i don't find any "Registry Tweaks" file/project (.REG Format) for Windows 98 SE after browsing this part of forum, like such available for Windows XP. I know mdgx.com has huge tweaks reported in various formats, yet you've to read and work for enormous amount of times in order to compile a REG file consisting only simple tweaks like those for explorer-shell-start menu etc. just. Can someone pls point out to a link in the forum where i can get Win 98 SE registry tweaks assorted for ready integration. or can someone post the reg file they use everyday? Thanks.

@jaclaz, Thanks. You may not believe, but when i asked i had you in my mind...i was expecting a response from you. Surely, your response settled all doubts. Now, i can really focus on successfull implementation of Plamdis' method and your knowledge. Since i joined MSFN and started browsing forum topics, jaclaz you remain in my memory with a term which whenever comes to my mind, it reminds me of you. "minigoogle" - you're synonymous with this term to whoever visits this site. Everytime we people are short in knowledge and knowledge base articles, jaclaz a.k.a "minigoogle" saves our day by posting those links and URLs. Web doesn't grow without leaving its footprint in your memory. Thanks for great service to learning.

Plamdi, excellent work! However, i've a few questions regarding the thing you achieve. 1. Can the whole thing be done during unattended installation depending on correct detection of File System type? To clarify more, if a hard disk is multi-partitioned and if the deployment media is used to install XP into different partitions, then can we use previously-built BOOTSECT.DAT to avoid running from floppy? 2. If that's possible then how to avoid use of bswrite.bat from floppy? Can we use already saved A:\BOOTSECT into the procedure? I know what i'm asking is mostly improbable, but my query is in line with how Microsoft makes and uses BOOTSECT.DAT when it does local installation of Recovery Console. Your opinion will be highly valuable in this regard. Thanks.

Well, if you attempt to open Device Manager, or Computer Management window, you receive an error similar to: "MMC cannot open the file C:\WINDOWS\system32\devmgmt.msc." This behavior may occur if one or more library files used by the Microsoft Management Console are missing or corrupted: 1. Msxml.dll 2. Msxml2.dll 3. Msxml3.dll 4. Msxml4.dll What you've to do is to use a batch file amendmmc.bat which contains: @echo Off setlocal enableextensions for %%v in (Msxml.dll Msxml2.dll Msxml3.dll Msxml4.dll) do call :reg_dlls %%v goto :eof :reg_dlls @echo Registering %~nx1 . . . regsvr32.exe %~nx1 /s if errorlevel 0 @echo %~nx1 Registered Successfully. if not errorlevel 0 @echo/DllRegisterServer in %~nx1 Failed. goto :eof endlocal & goto :eof Hope it helps your cause.