GreenMachine
Content Type
Profiles
Forums
Events
Posts posted by GreenMachine
-
-
Here is a start to find the machine's IP Address:
ipconfig /all | FINDSTR /C:"IP Address" > IP.TXT
That'll create a text file with the current IP addresses. The rest is fairly mundane Command Script coding: look at the file, see if it has "192.168.1." or "192.168.2", etc., and take action accordingly.
0 -
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 ...
0 -
@mdes:
Number Two is the correct answer
* Or should I not put the drivers in DRIVERDIR andDOPATH=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.
0 -
@VAD: I guess some people will do anything for a laugh!
I'll PM you in a day or two to answer your questions ... No time right now ...
0 -
Care to elaborate, Bilou_Gateux?
0 -
Thanks, Bitfrotter! A few more, and the success stories will outnumber the ... others!
0 -
@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.
0 -
Now, Jeremy, why in the world are you replying to a nearly two year old topic to add your two cents? Who is making whom look like what!?
Personally, I miss Numinous. There was a chap with brains, spunk, and loved to have fun!
Numinous! Come back!
0 -
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.
0 -
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.)
0 -
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.
0 -
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.
0 -
Wait: that is not the same post it was a minute ago ...
0 -
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!
0 -
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 ...
0 -
Well, changing to OEMPreinstall=NO definitly results in OEMPnPDriverPath NOT being set in DriversPath in the registry. Next test will be to inject it at the same time as I copy over the files.
0 -
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 ...
0 -
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.
0 -
Thanks, Alanoll, for the other shoe!
I'll play with it this weekend!
0 -
Cool. I guess that's another thing to add to the ToDo list ...
That also shows that nearly nobody uses the for DOS based installs.
Case closed!
0 -
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.
0 -
Isn't that just like Alanoll: comes back with a little tease, and then runs off!
Yea, I think something like that may be the best solution: have TXTSETUP.SIF copy a file over to the HDD, and call it from DetachedProgram.
OK, OK, I'll wait until the other shoe drops!
And another thing ... Thanks!
0 -
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:
If you need an ISO or CD, open a DOS Windows in your XPCREATE directory, and type: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
CDIMAGE -LXPCREATE -YD -N -H -X -OCI -M -D -BBOOT\XPCTBOOT.BIN CDROOT XPCREATE.ISOIf 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)
0 -
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
0
Kb834707 Don't Need (replaced With Kb867282)
in XPCREATE
Posted
That is what I thought I saw the first time. I guess I'll have to look into it. Don't be embarresed, Petya V4sechkin, lots of us don't speak English so well!