Jump to content

Zacam

Member
  • Posts

    19
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    United States

Posts posted by Zacam

  1. VLite and nLite make "educated" guesses about the installation media presented to them. They do not reverse or decouple anything information wise.

    That however is NOT the illegal conversation Kel is referring to.

    "So yes occasionally i do go out on the internet and try to find the windows OEM source files for a dell or whatever the brand. I am sure you all know that anytime you take this route you really have no idea what you are getting, whether it is OEM, REtail, Dell, Toshiba, 64bit x86 ect... "

    That is. Such discussion CANNOT be carried anywhere here. And based on the statement of the request, even if what you wanted was possible, nobody here would provide it.

  2. Well, I do feel sheepish for not having considered that solution.

    I was attempting to make it easier to (if necessary) perform manual re-installs of components, without having to extract an entire motherboard set, but I will see how well this idea tests out.

    Thanks for the feedback and the suggestion, I'll let you know how it goes.

    **Edit

    So, it has gone well. Though, setting some sort of an instruction delay, (if you have it set to delete copied drivers) before it actually restarts the system would be nice, or did I miss something in the documentation?

  3. So, in an effort to decrease file copy times during pre-setup, I alpahbetized the [Files] section in DOSNET.INF according to a DOS level dir command.

    It worked beautifully.

    I'm curious though if I need to retain the [FloppyFiles.#] sections or if they can be deleted as their entries also exist in [Files] section, or if they can be merged into a single [FloppyFiles] section if the windows setup is still utilizing them, even though the install is not occuring from floppy. (What are those things, anyway? j/k :-D )

  4. Well, fortunatly I've kept all my SP2 patched files even after I converted the addons to use the Integrators [HexEdit] function. But since nLite does not have this feature, (and for informational completness) I'm sharing the various versions of the files that have been listed here.

    Every file was personally modified by hand using mirkes.de Tiny Hexer with offset verification done using HeavenTools PE Explorer and tested on live installs. They have been cab compressed with PECheckSum correction for inclusion into the \I386 dir.

    Multiple versions exist, so be sure to pick the appropriate version number. I'll be updating this frequently and will continue to maintain it concurrently with my RVM Addons (which can be found [url="http://www.ryanvm.net/forum/viewtopic.php?t=2274"]HERE[/url].).

    [b]SFC_OS.dll[/b]:
    5.1.2600.2180: [url="http://zacam.ueuo.com/rvmprojects/dlls/SFC_OS_5-1-2600-2180.cab"](Right-Click, "Save As")[/url]

    [b]Syssetup.dll 5.1.2600.2180[/b]:
    Disable Syssetup.INF Signature Checking: [url="http://zacam.ueuo.com/rvmprojects/dlls/SYSSETUP_5-1-2600-2180_INF.cab"](Right-Click, "Save As")[/url]
    Disable INF Checking & OOBE: [url="http://zacam.ueuo.com/rvmprojects/dlls/SYSSETUP_5-1-2600-2180_INF_OOBE.cab"]: (Right-Click, "Save As")[/url]
    Disable OOBE[url="http://zacam.ueuo.com/rvmprojects/dlls/SYSSETUP_5-1-2600-2180_OOBE.cab"](Right-Click, "Save As")[/url]

    [b]Syssetup.dll 5.1.2600.2689[/b]: **For those with [url="http://support.microsoft.com/kb/894871"]KB894871[/url] installed.
    Disable Syssetup.INF Signature Checking: [url="http://zacam.ueuo.com/rvmprojects/dlls/SYSSETUP_5-1-2600-2689_INF.cab"](Right-Click, "Save As")[/url]
    Disable INF Checking & OOBE: [url="http://zacam.ueuo.com/rvmprojects/dlls/SYSSETUP_5-1-2600-2689_INF_OOBE.cab"](Right-Click, "Save As")[/url]
    Disable OOBE: [url="http://zacam.ueuo.com/rvmprojects/dlls/SYSSETUP_5-1-2600-2689_OOBE.cab"](Right-Click, "Save As")[/url]

    [b]TCPIP.sys for 100 concurrent connections[/b]: **I need to add more versions and more options per ver.
    5.1.2600.2827[url="http://zacam.ueuo.com/rvmprojects/dlls/TCP_5-1-2600-2827.cab"](Right-Click, "Save As")[/url]

    [b]USBPort.sys for 500mhz Port Polling[/b]: [color="red"]**Not for Use with Wireless Mice!![/color]
    5.1.2600.2180: [url="http://zacam.ueuo.com/rvmprojects/dlls/USB_5-1-2600-2180.cab"](Right-Click, "Save As")[/url]
    5.1.2600.2730: [url="http://zacam.ueuo.com/rvmprojects/dlls/USB_5-1-2600-2730.cab"](Right-Click, "Save As")[/url]
    5.1.2600.2783: [url="http://zacam.ueuo.com/rvmprojects/dlls/USB_5-1-2600-2783.cab"](Right-Click, "Save As")[/url]
    5.1.2600.2846: [url="http://zacam.ueuo.com/rvmprojects/dlls/USB_5-1-2600-2846.cab"](Right-Click, "Save As")[/url]
    5.1.2600.2891: [url="http://zacam.ueuo.com/rvmprojects/dlls/USB_5-1-2600-2891.cab"](Right-Click, "Save As")[/url]

    [b]UXTheme.dll for Unsigned Theme Usage[/b]:
    6.0.2900.2180: [url="http://zacam.ueuo.com/rvmprojects/dlls/UXTHEME_6-0-2900-2180.cab"](Right-Click, "Save As")[/url]
    6.0.2900.2523: [url="http://zacam.ueuo.com/rvmprojects/dlls/UXTHEME_6-0-2900-2523.cab"](Right-Click, "Save As")[/url]
    6.0.2900.2845: [url="http://zacam.ueuo.com/rvmprojects/dlls/UXTHEME_6-0-2900-2845.cab"](Right-Click, "Save As")[/url]

    Hope people find this useful.
  5. albie_3177: check the message I posted here, that may help you.

    Also, I noticed that if you have a SATA and an IDE HDD in place when installing, even if your installing to the SATA, my motherbard atleast ends up installing to the SATA as D: and the boot files go to C: (the IDE drive). The only workaround I have for this at the moment is to disconnect the IDE HDD's before I install so that the SATA is set to C:. (And yes, my BIOS is set to SCSI first, CD-ROM second and nothing for third and fourth boot devices, boot other is disabled.)

  6. You may need to change the HardwareIdsDatabase to reflect the actual PCI\VEN\SUBSYS of your particular SATA controller, but I use these setting in my TXTSETUP.SIF for my ECS KT-600a:

    [SourceDisksFiles]
    viamraid.sys = 1,,,,,,4_,4,1,,,1,4

    [HardwareIdsDatabase]
    PCI\VEN_1106&DEV_3149 = "viamraid"

    [SCSI.load]
    viamraid = viamraid.sys,4

    [SCSI]
    viamraid = "VIA SATA RAID Controller"

    Naturally, don't forget to compress a copy of viamraid.sys and place it in your \I386 directory.

    The viamraid.sys file I use is actually the one from Bashrat's Mass Storage pack, not the one from the ECS download page for my motherboard.

    HTH.

  7. What about just changing the conditional jumps at 21106 and 21121?

    What about them? The purpose that I can divine that the hack was aiming for was to have WINNT take SERVERNT's place. Simply changing the conditional jumps still means (even if the exe is changed) that WINNT is still doing WINNT's processes, not SERVERNT's.

    And if we change the conditional's, why not the actuals as well?

    DMBOOT.SYS
    00021111 EB39 jmp L0002114C
    0002112C EB1E jmp L0002114C

    DMCONFIG.DLL
    6CAE417C EB39 jmp L6CAE41B7
    6CAE4197 EB1E jmp L6CAE41B7

    Besides, the conditional at 21106 points us to load 21113. Reversing that means instead of skipping what WAS winnt means we'll now load right to it next, possibly breaking the intention of bypassing it altogether.

    In case anyone misses the edit I made, I realized that I accidentally posted the same information in the section for the DLL from the SYS instead of the actual DLL information. That's been corrected, and I've also linked to a cabbed collection of the newly modified files. No nLite or RVM Integrator INI just yet, as I need proof other than my machines that this works. And since I don't have enough HDD's to pull off testing here, I need someone else to.

  8. Firstly, my apologies, this is going to be a long one. Grab a sandwich and some coffee before reading this one through.

    So, in looking at the toms hardware guide on how this (the XPRAID5 Hack)was done, I examined the results.

    Frankly, I was confused. Sure, it works, but it does mangle a few things. I have to wonder if the person who brought this to THG's attention (and why nobody in THG bothered) actually looked at these files with a disassembler. The fix should have and could have been a little cleaner.

    Allow me to illustrate using excerpts from the dmboot.sys and dmconfig.dll files.

    I'll try and make this make sense. For reference, I use tiny hexer and PE Explorer.

    Here's a code snippet of DMBOOT.SYS (the original) at the location to be changed:

    0002107A						   SSZ0002107A_WINNT:
    0002107A 57494E4E5400 db 'WINNT',0
    00021080 0000 Align 2

    00021082 SSZ00021082_SERVERNT:
    00021082 5345525645524E5400 db 'SERVERNT',0
    0002108B 000000 Align 2

    Let's see what PE Explorer Disassembler says about the recommended HEX edit chage (Hacked DMBOOT.SYS, same location):

    0002107A						   L0002107A:
    0002107A 53 db 53h; 'S'
    0002107B 45 db 45h; 'E'
    0002107C 52 db 52h; 'R'
    0002107D 56 db 56h; 'V'
    0002107E 45 db 45h; 'E'
    0002107F 52 db 52h; 'R'
    00021080 4E db 4Eh; 'N'
    00021081 54 db 54h; 'T'

    00021082 SSZ00021082_WINNT:
    6CAC5D4C 57494E4E5400 db 'WINNT',0
    00021088 00 db 00h;
    00021089 00 db 00h;
    0002108A 00 db 00h;
    0002108B 00 db 00h;
    0002108C 00 db 00h;
    0002108D 00 db 00h;

    Guh. Granted, it works. Switching their position changes the relocations that are called, which I'll list here (these relocations are the same between the original and the hacked, with two slight differences):

    000210F2						   L000210F2:
    000210F2 FF75FC push [ebp-04h]
    000210F5 8B353C5D0400 mov esi,[ntoskrnl.exe!_stricmp]
    000210FB 687A100200 push SSZ0002107A_WINNT
    *******This is how the above line looks in the hacked file*************
    000210FB 687A100200 push L0002107A
    *******End Difference One**************************************
    00021100 FFD6 call esi
    00021102 85C0 test eax,eax
    00021104 59 pop ecx
    00021105 59 pop ecx
    00021106 750B jnz L00021113
    00021108 8B4508 mov eax,[ebp+08h]
    0002110B C70001000000 mov dword ptr [eax],00000001h
    00021111 EB39 jmp L0002114C

    00021113 L00021113:
    00021113 FF75FC push [ebp-04h]
    00021116 6882100200 push SSZ00021082_SERVERNT
    *******This is how the above line looks in the hacked file*************
    00021116 6882100200 push SSZ00021082_WINNT
    *******End Difference Two**************************************
    0002111B FFD6 call esi
    0002111D 85C0 test eax,eax
    0002111F 59 pop ecx
    00021120 59 pop ecx
    00021121 750B jnz L0002112E
    00021123 8B4508 mov eax,[ebp+08h]
    00021126 C70002000000 mov dword ptr [eax],00000002h
    0002112C EB1E jmp L0002114C

    So, it's essentially faking it out. Swapping the relocation pointers for WINNT to assume the abilities of SERVERNT and leaving SERVERNT to do god knows what (what WINNT would do in the original, pressumably).

    But what if we take a closer look at 2 lines in particular and then swap their hex code:

    000210FB  687A100200					push	SSZ0002107A_WINNT
    ....
    00021116 6882100200 push SSZ00021082_SERVERNT
    *****swap-o-matic******
    000210FB 6882100200 push SSZ00021082_SERVERNT
    ....
    00021116 687A100200 push SSZ0002107A_WINNT

    Without HEX swapping WINNT and SERVERNT at the begining of the file.

    Just in case you don't want to do the mental gymnastics, here's the complete patched sequence:

    0002107A						   SSZ0002107A_WINNT:
    0002107A 57494E4E5400 db 'WINNT',0
    00021080 0000 Align 2

    00021082 SSZ00021082_SERVERNT:
    00021082 5345525645524E5400 db 'SERVERNT',0
    0002108B 000000 Align 2
    ------------
    000210F2 L000210F2:
    000210F2 FF75FC push [ebp-04h]
    000210F5 8B353C5D0400 mov esi,[ntoskrnl.exe!_stricmp]
    000210FB 6882100200 push SSZ00021082_SERVERNT
    00021100 FFD6 call esi
    00021102 85C0 test eax,eax
    00021104 59 pop ecx
    00021105 59 pop ecx
    00021106 750B jnz L00021113
    00021108 8B4508 mov eax,[ebp+08h]
    0002110B C70001000000 mov dword ptr [eax],00000001h
    00021111 EB39 jmp L0002114C

    00021113 L00021113:
    00021113 FF75FC push [ebp-04h]
    00021116 687A100200 push SSZ0002107A_WINNT
    0002111B FFD6 call esi
    0002111D 85C0 test eax,eax
    0002111F 59 pop ecx
    00021120 59 pop ecx
    00021121 750B jnz L0002112E
    00021123 8B4508 mov eax,[ebp+08h]
    00021126 C70002000000 mov dword ptr [eax],00000002h
    0002112C EB1E jmp L0002114C

    WINNT is now pointing to (pushing, being pushed by, whatever) the section that was once labled for SERVERNT, which means it now goes through all it's subsequent routines as the spirit of the hack intended.

    The same holds true of the DLL.

    Original:

    6CAC5D40						   SSZ6CAC5D40_LANMANNT:
    6CAC5D40 4C414E4D414E4E5400 db 'LANMANNT',0
    6CAC5D49 000000 Align 4

    6CAC5D4C SSZ6CAC5D4C_SERVERNT:
    6CAC5D4C 5345525645524E5400 db 'SERVERNT',0
    6CAC5D55 000000 Align 4

    Hacked:

    6CAC5D4C						   SSZ6CAC5D4C_WINNT:
    6CAC5D4C 57494E4E5400 db 'WINNT',0
    6CAC5D52 00 db 00h;
    6CAC5D53 00 db 00h;
    6CAC5D54 00 db 00h;
    6CAC5D55 00 db 00h;
    6CAC5D56 00 db 00h;
    6CAC5D57 00 db 00h;

    6CAC5D58 L6CAC5D58:
    6CAC5D58 53 db 53h; 'S'
    6CAC5D59 45 db 45h; 'E'
    6CAC5D5A 52 db 52h; 'R'
    6CAC5D5B 56 db 56h; 'V'
    6CAC5D5C 45 db 45h; 'E'
    6CAC5D5D 52 db 52h; 'R'
    6CAC5D5E 4E db 4Eh; 'N'
    6CAC5D5F 54 db 54h; 'T'

    Sure enough, same relocation swapping occuring:

    6CAE415D						   L6CAE415D:
    6CAE415D FF75FC push [ebp-04h]
    6CAE4160 8B35B811AC6C mov esi,[msvcrt.dll!_stricmp]
    6CAE4166 68585DAC6C push SSZ6CAC5D58_WINNT
    *******This is how the above line looks in the hacked file*************
    6CAE4166 68585DAC6C push L6CAC5D58
    *******End Difference One**************************************
    6CAE416B FFD6 call esi
    6CAE416D 85C0 test eax,eax
    6CAE416F 59 pop ecx
    6CAE4170 59 pop ecx
    6CAE4171 750B jnz L6CAE417E
    6CAE4173 8B4508 mov eax,[ebp+08h]
    6CAE4176 C70001000000 mov dword ptr [eax],00000001h
    6CAE417C EB39 jmp L6CAE41B7

    6CAE417E L6CAE417E:
    6CAE417E FF75FC push [ebp-04h]
    6CAE4181 684C5DAC6C push SSZ6CAC5D4C_SERVERNT
    *******This is how the above line looks in the hacked file*************
    6CAE4181 684C5DAC6C push SSZ6CAC5D4C_WINNT
    *******End Difference Two**************************************
    6CAE4186 FFD6 call esi
    6CAE4188 85C0 test eax,eax
    6CAE418A 59 pop ecx
    6CAE418B 59 pop ecx
    6CAE418C 750B jnz L6CAE4199
    6CAE418E 8B4508 mov eax,[ebp+08h]
    6CAE4191 C70002000000 mov dword ptr [eax],00000002h
    6CAE4197 EB1E jmp L6CAE41B7

    We do the same swap-o-matic:

    6CAE4166  68585DAC6C			push	SSZ6CAC5D58_WINNT
    ....
    6CAE4181 684C5DAC6C push SSZ6CAC5D4C_SERVERNT
    *****swap-o-matic******
    6CAE4166 684C5DAC6C push SSZ6CAC5D4C_SERVERNT
    ....
    6CAE4181 68585DAC6C push SSZ6CAC5D58_WINNT

    and we get this:

    6CAC5D4C						   SSZ6CAC5D4C_SERVERNT:
    6CAC5D4C 5345525645524E5400 db 'SERVERNT',0
    6CAC5D55 000000 Align 4

    6CAC5D58 SSZ6CAC5D58_WINNT:
    6CAC5D58 57494E4E5400 db 'WINNT',0
    6CAC5D5E 0000 Align 4
    ...............
    6CAE415D L6CAE415D:
    6CAE415D FF75FC push [ebp-04h]
    6CAE4160 8B35B811AC6C mov esi,[msvcrt.dll!_stricmp]
    6CAE4166 684C5DAC6C push SSZ6CAC5D4C_SERVERNT
    6CAE416B FFD6 call esi
    6CAE416D 85C0 test eax,eax
    6CAE416F 59 pop ecx
    6CAE4170 59 pop ecx
    6CAE4171 750B jnz L6CAE417E
    6CAE4173 8B4508 mov eax,[ebp+08h]
    6CAE4176 C70001000000 mov dword ptr [eax],00000001h
    6CAE417C EB39 jmp L6CAE41B7

    6CAE417E L6CAE417E:
    6CAE417E FF75FC push [ebp-04h]
    6CAE4181 68585DAC6C push SSZ6CAC5D58_WINNT
    6CAE4186 FFD6 call esi
    6CAE4188 85C0 test eax,eax
    6CAE418A 59 pop ecx
    6CAE418B 59 pop ecx
    6CAE418C 750B jnz L6CAE4199
    6CAE418E 8B4508 mov eax,[ebp+08h]
    6CAE4191 C70002000000 mov dword ptr [eax],00000002h
    6CAE4197 EB1E jmp L6CAE41B7

    Sadly, not much can be done about the EXE. No matter what, it's going to do this:

    01002830							   SSZ01002830_winnt:
    01002830 77696E6E7400 db 'winnt',0
    01002836 00 db 00h;
    01002837 00 db 00h;
    01002838 00 db 00h;
    01002839 00 db 00h;
    0100283A 00 db 00h;
    0100283B 00 db 00h;

    So, the question is this: Is it the order that they're referenced to or listed in? DMADMIN.EXE has (prior to editing it) nothing related to WINNT, only SERVERNT and LANMANNT. Obviously, just changing the EXE alone wouldn't work, pressumably because of what the relocation pointers in the SYS and DLL do when calling WINNT, they don't accomplish the desired result. (and obviously, as WINNT isn't being called by the EXE, the WINNT sections won't work right leaving the EXE to call to them under the guise of SERVERNT).

    Can switching the PUSH's so that calls to WINNT now execute what SERVERNT was responsible for be enough? (for the astute observers: the DLL and SYS list each of the three initially in reverse order of each other. SYS lists WINNT, SERVERNT, LANMANNT; DLL lists LANMANNT, SERVERNT, WINNT. For whatever that's worth.)

    If anyone has the capability and willingness to test differently modified files, PM me or respond here, as I'd really like to find out if these changes to the SYS and DLL (with the original change to the EXE of course) are enough, but lack the resources/equipment to do so. (I can verify that the modified files DO work as normal under a regular XP Pro install and do not introduce any problems). Even better if you can tell me if it won't work and can explain (prove-ably) why the method currently in use is the only operable one.

    (A note: The original "Hack" doesn't modify the PE Checksum of either the SYS or DLL, only the EXE. The method used here changes the PE Checksum of all three, so if you use this information to change your own files, don't forget to update those.)

    *edit: realized I confused the examples and posted code from the SYS into the sections for the DLL. Corrected.*

    Cab'd files for I386 Use. No nLite or Integrator INI yet.

    https://www.sharemation.com/Aeenzawthi/NEW_...CAB?uniq=40a2tk

  9. ... and after its done it reverts to scanning the default directory...

    That's the part that is likely to kill you. Or at the least, make you loose a lot of hair.

    It is possible to add drivers to the cd for installation during GUI Mode Setup, either by copying to the hard disk first or directly from the CD. Controlling how windows does it's handling for driver locations though to modify it's behavior is another matter entirely. You _could_ combine a method for inserting a disk swap phase during GUI Mode and build a second cd specifically for drivers, but there is no telling how well that would work.

  10. Try placing the following directly into your TXTSETUP.SIF file:

    [SourceDisksFiles]
    iaStor.sys = 1,,,,,,4_,4,1,,,1,4

    [HardwareIdsDatabase]
    PCI\VEN_8086&DEV_27C3&CC_0104 = iaStor_ICH7DH
    PCI\VEN_8086&DEV_27C1&CC_0106 = iaAHCI_ICH7R

    [scsi]
    iaStor_ICH7DH = "Intel® 82801GR/GH SATA RAID Controller (Desktop ICH7R/DH)"
    iaAHCI_ICH7R = "Intel® 82801GR/GH SATA AHCI Controller (Desktop ICH7R/DH)"

    [SCSI.load]
    iaStor_ICH7DH = iaStor.sys,4

    Compress iaStor.sys into iaStor.sy_ and place in the \I386 folder.

    Then do the Drivers from CD method and copy into a SATA folder the following:

    iaStor.sys, iaStor.inf, iaStor.cat, iaAHCI.inf, iaAHCI.cat.

    If you preffer not installing drivers from cd, the above could be added to TXTSETUP.SIF as well, but it's more complicated in deconstrucing the INF's for the relevant information to force the installation.

    For further help on problems like these, a url link to where your drivers are obtainable from would be helpful.

  11. Reading the Slipstreaming SATA/RAID Drivers Guide was no help , because I dont understand step 1 with my drivers :S

    Naturally, extract your downloaded drivers, but delete the txtsetup.oem file.

    Then, place the following code into TXTSETUP.SIF for step 1:

    [SourceDisksFiles] <--Already Exists, so just append or sort in.
    nvatabus.sys = 1,,,,,,4_,4,1,,,1,4
    nvraid.sys = 1,,,,,,4_,4,1,,,1,4

    [HardwareIdsDatabase] <-This already exists, so just append or sort in.
    GenNvRaidDisk = "NVRAID"
    *_NVRAIDBUS = "NVRAIDBUS"
    PCI\VEN_10DE&DEV_00EE = "CK8SSS"
    PCI\VEN_10DE&DEV_00E3 = "CK8SSS"

    [SCSI.Load] <--Already Exists, so just append or sort in.
    CK8SSS = nvatabus.sys,4
    NVRAIDBUS = nvraid.sys,4

    [SCSI] <--Already Exists, so just append or sort in.
    CK8SSS = "NVIDIA nForce3 250 Serial ATA Controller"
    NVRAID = "NVIDIA nForce(tm) RAID Class Device"
    NVRAIDBUS = "NVIDIA nForce(tm) RAID Class Controller"

    (NOTE: These are strings only for nForce3 items. All other references to other nForce material as available from INF's not included as 1: Far too confusing with item_name re-usage and 2: I don't have a either a whole lot of time right now OR an nForce motherboard.)

    I'd then suggest doing the drivers from cd method. Don't forget to skip to Step 4 and compress nvraid.sys -> nvraid.sy_ and nvatabus.sys -> nvatabus.sy_ and place them in "%CDSOURCE%\I386".

    And if all else fails, go to the DriverPacks thread where you can gather more assistance, even if you are not using a driver pack per se, you are doing something involving slipstreaming a vendor driver into your install media.

    Though, if you do decide to do a driver pack, I updated my ECS KT600-A drivers by extracting the ones from Bashrats MassStoragePack 6.03.1. More current for the VIA, though I'm reading there now that there are some nForce issues, you might be able to get away with using the files from the MassStoragePack (copy them from the extracted source "D\M\N\123\" instead of using the downloaded MSI zip file contents).

  12. FYI in the Audioshell Addon, the AudioShe.inf is MISSING a ; at the begining of the first line. If you place a " ; " there, framedyn.dll and srclient.dll errors should disappear on systems where you are installing Audioshell Addon.

    I just did a test where I ran Integrator 1.2.2, RVM 2.03, 2.04 and 2.05 and ONLY added Audioshell. That was it, nothing else. I didn't even make it unattended to simplify things. Received framedyn.dll and srclient.dll errors. I then corrected the INF after discovering the issue and burned a new ISO with the corrected file, and obtained a perfect install.

  13. I totally dig XPize and what it does. 'Nuf said on that, many others have already said more than I can.

    I do have _one_ slight issue though, but I'm not entirely sure about to how to go about it.

    Icon backgrounds look sweet, regardless of theme. Dialogs rock, also regardless of theme.

    Not all of the animated work looks so great though, in particular one that I end up staring at a lot.

    Alpha%20White.png

    The white bordering around the icons in the transfer window in this theme (a personally made one, but other dark themes also have this problem) is mildly annoying. Is there a way you might be able to "tighten" the edges around the borders, or failing that, can I manually edit that resource file and have XPize Settings apply the "corrected" without re-installing it?

  14. A wonderful and workable idea. In the end I've just scrapped the idea of a multi-boot cd. Mainly because in explicitly following the directions or even in adjusting them according with what I need, it still doesn't work. *shrug*

    Glad that someone thought to reply with anything though.

  15. I am familiar with how to make slipstreamed and slipstream unattended cd's. Familiar with NLite and RyanVM packs and Gosh's method of reducing source on the above and having it work fine.

    Now I'm making a disc with CDShell where I have 2 copies of XP SP2. One for Desktop - Unattended (PROD) and Laptop - Unattended (PROM) with seperate cd-keys and other winnt.sif settings.

    Making a directory structure that matches the Multi-Boot DVD's guide (even though this is going on cd-rw) or even using my own directory structure (listed below) I still get the same issue/error. I've tried regular slipstream with "winnt32.exe /dudisable /noreboot" obtained BOOT and I've even set (in PROD and PROM) full copies of a full reduced source installer and even the documented full original SP2 I386 dir copied.

    $OEM$\
    BOOT\
    I386\
    MISC\
    PROD\
    PROM\
    SYSTEM\
    cd.txt
    PROD.DAT
    PROM.DAT
    readme.htm
    setupxp.htm
    win51
    win51ip
    win51ip.sp2

    The error is this. CDShell operates fine. Does the splash screen, I press enter to boot, choose one of 2 menu options (as there are only two, and they chain to the appropriate .DAT file. setupldr.bin and txtsetup.sif modified appropriately, winnt.sif in existance or not doesn't seem to matter) and it launches the windows setup where it copies and initializes the driver base prior to drive selection.

    I then choose the drive where I can do (have tried to do) any of the following:

    Installing to the existing partition, with a format,

    Deleting existing partition and installing with a format.

    It deletes partitions fine. But in the format stage, doing either full NTFS or a Quick NTFS I get the same error:

    "Setup cannot format the partition.

    Your computer may not have enough memory to perform this operation, or your Windows XP CD-ROM may contain some corrupted files.

    Setup cannot continue. To quit Setup, press F3"

    Now, if I told it to erase the partition and try booting of the disc again and try assigning the now empty partition to install on, it say's it needs to verify my systems ability due to the lack of an exisitng OS and wants me to put in an NT3.51, 4.0, Win 98, ME or 2K cd before it will proceed.

    This only happens with the cd that I created under the multi-boot instructions, even following them to the letter (to the extent that I'm only putting 2 XP installers on it and nothing else). Again, a regular slipstreamed cd, NLite'd cd with RyanVM, Reduced Source SP2 w/RyanVM all install fine in Attended or Unattended.

    Any ideas how to get this working? :(

    System Specs:

    ECS KT600-A

    AMD Sempron 2400 @ 1.66 Mhz @ 333 FSB

    Kingston matched 256x2 (Total 512) mb DDR400 @ 333, BIOS detected default's by SPD.

    ATI Radeon 9200

    WD 7200rpm 40gb HDA

    Sony 52x24x52 cd-rw

    **EDIT: Verbatim error message added.

  16. I've been lurking for awhile and now that I'm doing alot of testing (most of which revolves around doing an OS re-install frequently) I decided to go unattended slipstream.

    While it's worked perfectly (even combining MSFN Unattended Guide and Gosh reductions and jdeboeck's Removal cmd's) I've noticed two things.

    The first happens even on a plain unattended slipstream. Task Manager no longer shows me the name of who is running what. While I have yet to notice any system problems arising from this (and my own testing has not gotten me to run something that wasn't supposed to be runable) I haven't really been worried about it, but very curious.

    Secondly, I've noticed that MBSA lists items that are not on the main list. If MBSA lists items as a critical security update, why doesn't WU?

    In conjunction with the second (though it may be counted as a third) I've noticed after updating my svcpack.inf that IE will now no longer display graphics on certain webpages and I cannot seem to determine (without a lot more extensive testing) which is doing it. Other browsers display the pages fine, and the images (once saved to local copies) load into IE and Preview just fine. Below is svcpack.inf for my XPSP1a cd. (yes, I know the Q's and KB's are missing in the file names. I did that on purpose)

    [SetupHotfixesToRun]  
    814078.exe /Q:A /R:N  
    817787.exe /Q:A /R:N  (recommended by MBSA)
    823182.exe /Q /O /N /Z  
    823353.exe /Q:A /R:N  
    824105.exe /Q /O /N /Z  
    825119.exe /Q /O /N /Z  
    826939.exe /passive /norestart /quiet  
    828035.exe /Q /O /N /Z  
    828741.exe /Q /O /N /Z  
    "832483.exe /C:""dahotfix.exe /q /n"" /q:a"  
    833987.exe /passive /norestart /quiet  
    835732.exe /Q /O /N /Z  
    837001.exe /Q /O /N /Z  
    839645.exe /passive /norestart /quiet  (recommended by MBSA)
    840315.exe /Q /O /N /Z  
    840374.exe /Q /O /N /Z  
    840987.exe /passive /norestart /quiet  
    841356.exe /passive /norestart /quiet  
    841533.exe /passive /norestart /quiet  
    841873.exe /Q /O /N /Z  
    867282.exe /passive /norestart /quiet  (recommended by MBSA)
    871250.exe /passive /norestart /quiet  
    873333.exe /passive /norestart /quiet  
    873376.exe /passive /norestart /quiet  
    873377.exe /passive /norestart /quiet  (recommended by MBSA)
    885250.exe /passive /norestart /quiet  (recommended by MBSA)
    885835.exe /passive /norestart /quiet  
    885836.exe /passive /norestart /quiet  
    888113.exe /passive /norestart /quiet  (recommended by MBSA)
    888302.exe /passive /norestart /quiet  (recommended by MBSA)
    889669.exe /passive /norestart /quiet  
    890047.exe /passive /norestart /quiet  (recommended by MBSA)  
    890175.exe /passive /norestart /quiet  
    891711.exe /passive /norestart /quiet  (recommended by MBSA)
    891781.exe /passive /norestart /quiet  
    qchain.exe  
    msxml3.exe /qn  (recommended by MBSA)(MSXML 3.0 SP5)
    dxsetup.exe /silent

    The MBSA recommended ones were added after a base install with the non-recommended ones flagged them. DX9.0c integrated, WMP still at default XP Gold version w/SP1a, no other updates than listed. The base install displays problem sites fine, so I'm pressuming it's one of the MBSA ones.

×
×
  • Create New...