Jump to content

GreenMachine

Developer
  • Content Count

    3,070
  • Joined

  • Last visited

  • Donations

    $0.00 

Posts posted by GreenMachine

  1. As many of you have noticed, there have been problems both loging onto xpcreate.com, and sending mail to xpcreate.com. All those that previously recieved a username/password shuld be able to logon, Those that have recently sent a request will be answered in the next 48 hours (if all goes well). Please let me know (support(a)xpcreate.com) if your username/password still does not work.

    Thanks for your consideration ...

  2. @mdes:

    Number Two is the correct answer

    * Or should I not put the drivers in DRIVERDIR and

    DOPATH=NO

    DOSATA=YES

    DRIVERDIR=$OEM$\$1\DRIVERS

    XPCREATE does not supply the drivers, just the information needed to integrate the drivers, based on the drivers found in DRIVERSDIR.

  3. @Weed: The difference between the commercial and the freeware versions is listed here: http://xpcreate.com/versions.htm

    The freeware version slipstreams just as the commercial version. The commercial version inludes code to connect to my server, get the latest list of hotfixes, and download them. If you want the commercial options, you have to pay the price. Part of the reasoning behind this is that I have helped the community, and continue to help the community, doing that which is difficult: slipstreaming the hotfixes. Downloading the hotfixes is something that even the least experienced amongst us can do. If you want me to do it for you, it is simply that you want me to save you time. If you consider your time that valuable ... as above: you will have to pay the price.

    The short answer is:

    I will consider a low priced subscription for freeware users to access the download code, and download lists. I will not be offering this service for free.

    No, I will not allow you, as a freeware user, to download the commercial versions.

  4. Well ... actually my first test on a real machine did not seem to work ... the drivers were there, DriversPath in the registry was OK, the directories had been parsed and INFCACHE.1 created, but the drivers did not install.

    I'm going to play around with it a little more tonight or tomorrow.

    @RyanVM: I guess Bilou_Gateux got you going. If not, I'll go over it for you later. XPCREATE has updated TXTSETUP.SIF since I included SATA integration about a year ago. Two things of importance:

    1) You do not need to add to an existing [sourceFiles]: there is no drawbacks in creating a new one. In fact, there are already a few.

    2) You need to include the EOF marker.

    The rest is actually quite simple. I will look at Bilou_Gateux's stuff later: it is always enlightning!

    Oh well, that's today's update.

  5. My experience shows that you cannot install Office 2003 at that point in Windows XP or Windows 2003. I've not tried it in Windows 2000. The error you see is not the real error, rather Doctor Watson attemping to log the error.

    To test, you could stop the installation at that point (perhaps a command script with a pause in it from CMDLINES.TXT), and try to manually install Office 2003. (Shift-F10 will pop up a DOS box, and you can run Office 2003 setup - d:\setup.exe perhaps - and see any errors.)

  6. The Web Site is undergoing some maintenance, and you may experience problems over the weekend, either sending mail to the xpcreate.com address, or logging into the Freeware or Commercial Sections of the site. Please be patient, and try again later. I expect all problems to be cleared up over the weekend.

  7. Well, I think I've got it.

    I have a script that:

    - Takes a sub-directory and compresses all the files with paths using CABARC

    - Parses the directory for INF files and makes a concatenated path list (as in OEMPnPDriversPath)

    - Creates a Command Script to expand the CAB file to the correct directories

    - Creates a Command Script to inject the paths into the registry

    - Packs it all into an IEXPRESS executable

    What I have not automated yet is the updating of TXTSETUP.SIF, and the addition of the file to I386. But I suspect that will happen soon.

    Looks good on VPC, now I'll test it on a real box, and get back to y'all in the 'morrow.

    Thanks, Alanoll, for getting me on the right track.

  8. OK, OK, I should have listened more carefully! Anyway, I knew that YOU knew.

    I am not sure that you need to take the files in the sub-directory and CAB then into the I386 directory - but you probably know better than I - I thought they were the same version as was already there, or in any event that they were the correct version. It does seem like the last few lines of DOSNET.INF, with the files from the sub-directories, is certainly not needed.

    Thanks, Bilou!

  9. True, RyanVM, last time I checked, too! To copy the files there anyway, as CMDLINES.TXT, if placed in $OEM$ is run regardless of the OEMPreinstall setting. I was hoping that OEMPnPDriversPath would act similarly, but, alas, no.

    No matter, I've about finished my script.

    @j4ever, there are plenty of threads in the Device Drivers Section that achieve exactly what you want. I am looking for the same results, simply avoiding using non-Microsoft programs. My method will certainly be more complicated than what has already been posted, and if you are having trouble with that, this will undoubtably give you more headaches. Remember ... keep it simple ...

  10. I could do that ... but you know me! I use CABARC and IEXPRESS to create the SFX package, all from a Command Script that automatically scans a given directory. Easy enough to have it crate the DriversPath, and inject it with a REG command.

    As for the INFCACHE.1 file, it seems that is created when you start the Add Hardware Wizard for all the directories in the DevicePath registry setting.

    So, I'm close ...

    Thanks again, Alanoll.

    To be continued ...

  11. Well, I got that part to work, however it seems that the DevicePath in the registry, which should be %systemroot%\inf;, followed by whatever it picks up from OEMPnPDriversPath only contains %systemroot%\inf, leading me to suspect that OEMPnPDriversPath does not work once OEMPreinstall is set to no (though I was/am under the impression that it should). Injecting the values into the registry would be easy enough, if, in fact, the OEMPnPDriversPath thingy won't work in this case. From what I see, the DevicePath setting is needed so that setup parses the directories, and creates the prefetch information stored in INFCACHE.1. Without that file, I think that the INF files inside will not be used when searching for drivers. Of course, all this is speculation, as I have only tried on a virtual machine.

    Just a status update. If you have anything to add, Alanoll, I'm all ears. Otherwise, I'll keep you posted.

  12. I think ...

    - As you are just updating an existing file, there should be no problem having it copied correctly.

    - If the PCI Venor ID is not already in TXTSETUP.SIF, you WILL need to add it.

    - The DetachedProgram entry above is to add more drivers. (Only PART of the process.) You should not need it. If you have a Dell Server, I would only add that which you know you need.

    I believe the real key is in ForceCopyDriverCabFiles. That is all you were missing from your initial attempt.

  13. OK, I seem to remember a similar problem noted by Bilou_Gateux. Could you please try this solution?

    If you still have the CDROOT directory, we will use that. If not, change DELROOT to NO in XPCREATE.INI, and re-run XPCREATE.

    Remove the last 6 lines from DOSNET.INF in the CDROOT\I386 directory. Specifically, these lines:

    d1,UNIPROC\kernel32.dl_

    d1,UNIPROC\ntdll.dll

    d1,UNIPROC\win32k.sy_

    d1,UNIPROC\winsrv.dl_

    d1,XPCLNT_QFE_BINARYDROP\shlwapi.dll

    d1,XPSP2_BINARYDROP\shlwapi.dll

    If you need an ISO or CD, open a DOS Windows in your XPCREATE directory, and type:
    CDIMAGE -LXPCREATE -YD -N -H -X -OCI -M -D -BBOOT\XPCTBOOT.BIN CDROOT XPCREATE.ISO

    If you do not use the ISO/CD, CDROOT with the modified DOSNET.INF should work fine.

    I think I do not need to add the names of files in the subdirectories to DOSNET.INF, and that is what is causing your woes. On a CD based installation, DOSNET.INF is not used this way, so the problem does not manifest itself.

    Please post your findings!

    (And again, I got the attachment, so you can delete it now)

  14. I know that many people install their Driver Packs by extracting them with a DetachedProgram entry. All examples that I have seen require using OEMPreinstall=YES. Has anyone managed to do this with OEMPreinstall=NO?

    I also know that there is a modified setup.exe, which runs a preinstall command script. That is not what I am looking for, either ...

    I am certainly not trying to belittle anyone's solution, but I am looking for a way to do this without modifying any Microsoft files, other than possibly DOSNET.INF or TXTSETUP.SIF. A good solution would be similar to:

    DetachedProgram=%CDROM%\MySetup.exe

    However, there is no CDROM variable pointing to the CDROM, and this seems to be the biggest obstacle.

    Any success stories out there? Any suggestions? And please ... I know what I want, so do not suggest that I use OEMPreinstall=YES, or that I hex edit, or replace, some Microsoft files.

    Thanks

×
×
  • Create New...