You are not logged in. Please login or register.
DriverPacks.net Forum » Posts by bphlpt
Oops. :embarassed: Sorry, That's what I get for not reading close enough. I'm used to ARCH being set to x86/x64 in my code instead of 32/64. I haven't looked totally through your script to see where else ARCH is used, but you might be able to use the same or similar definitions. Worst case just change my last line to:
IF %ARCH%="32" SET "DPLoc=%cur%\%OSbuild%\x86" ELSE SET "DPLoc=%cur%\%OSbuild%\x64"
But I still believe my logic is more efficient. 
Cheers and Regards
I think your processor bit-ness test:
:PROCESSOR
:: Detect OS bit-ness on running system. Assumes 32-bit unless 64-bit components exist.
SET "ARCH=32" & SET "DPLoc=%cur%\%OSbuild%\x86"
IF EXIST "%SystemRoot%\SysWOW64" (SET "ARCH=64" & SET "DPLoc=%cur%\%OSbuild%\x64") ELSE (
IF DEFINED PROCESSOR_ARCHITEW6432 (SET "ARCH=64" & SET "DPLoc=%cur%\%OSbuild%\x64")
)could be slightly simplified with:
:PROCESSOR
:: Detect OS bit-ness on running system. Assumes 32-bit if 64-bit components do not exist.
SET "ARCH=64"
IF NOT EXIST "%SystemRoot%\SysWOW64\cmd.exe" IF NOT DEFINED PROCESSOR_ARCHITEW6432 SET "ARCH=32"
SET "DPLoc=%cur%\%OSbuild%\x%ARCH%"I also incorporated checking for the existence of "SysWOW64\cmd.exe" instead of just "SysWOW64" as suggested by both vmanda and dumpydooby.
Cheers and Regards
Sorry, there was a typo in the previous post. Rather than edit, I'll repost here:
Looking forward to testing the fix.
Cheers and Regards
Ok, I fixed my typo's in my last mediocre post about the use of the 2 cmd's the use of the IF EXIST etc...
I seen that I could fix the cmd myself, but I thought no I need to find out why the issue was happenin in the first place, hope he understands it and can do a fix that will not have the issue with bit space, then I think he will have a universal cmd for the SAD2 tool
----------------------
The 'DP_Install_Tool.cmd' is not the problem, just the extra ')' in the cmd was a legit issue tho please make sure to pass that on, as I found out the nature of the error and it was a mind bogglin one too
Well that is wat you would think, but no ..
here is the layout I just ran into last night.
1 Dual arch AutoUnattend.xml with both amd64 and x86 architectures, ok now we are goin to get a little confusin maybe, just follow along
you have this 1 XML file dual arch, and you have in it to RunAsynchronous or RunSynchronous commands ..
having the exact same run for a cmd or .exe ( or ANYTHING at this point ) in each amd64 and x86 and install a x64 OS will run BOTH the amd64 and x86 components in the pass
So wat I was gettin was that, the amd64 section of the XML file was gettin ran first ( and was fine on the x64 OS ) then the x86 section was gettin ran right after the amd64, witch would throw the windows error up, witch is legit, but to the fact that I didnt even know that BOTH comopnents ( amd64 & x86 ) would get ran if install a x64 OS .. if this has made since, that is the gist of that, lets go on ..
Now for the x86 OS install, this is just plain simple, it ignores the amd64 sections of the XML file .. thats all there is too the x86 side, it runs just the x86 components listed in the XML file ..
So using a dual arch XML file ( you have to beeee very careful to wat ya have in BOTH amd64 and x86 sections of the components pass or you may end up flubbin a x64 install, the critical areas I see that are visible to this is the RunAsynchronous or RunSynchronous commands listed in amd64 and the x86 parts
Ok, 1 final notation is that: When usin the above setup of a XML file and RunAsynchronous or RunSynchronous commands, they will run in 1 of 2 bit spaces = if amd64 the execution is from the 64 bit space, IF it runs the x86 it is ran from 32 bit space, and thus in the DP install tool.cmd this is wat was ACTUALLY happenin, is that the amd64 RunAsynchronous was the correct run cause the line was executed on a x64 OS, witch the DP Install tool.cmd finished as intended. Now the x86 RunAsynchronous command runs right after the amd64 and it would be in task manager as running in 'DP_Install_Tool.cmd *' ( witch means 32 bit run on x64 OS ) ok, fine, BUT it would pull the %PROCESSOR_ARCHITECTURE% == x86 ... and that is were I get the cross error in the DP_Install_Tool.cmd being ran.
SO to correct the bit space run on a x64 OS install, I created 2 cmd's - 1 for the x86 pass and 1 for the amd64 pass in the XML file, the x86 has in it, this is the very first thing that gets lookd at - 'IF EXIST "%HOMEDRIVE%\Program Files (x86)" GOTO EXIT' - the exit is at the bootom of the cmd so it doesnt hurt it to just simply exit out so this way it is truly ran on the correct OS Arch x86 , now the amd64 pass runs the cmd runs but does not have the check if "%HOMEDRIVE%\Program Files (x86)" exists, so that will run in 64 bit space and the %PROCESSOR_ARCHITECTURE% == amd64 when ran, so now I have this fixed more or less the correct way cause of the bit space run time for both arch's .. nifty I know LOL.
now that must sound a little better
OK Thanks.
As soon as you can post an update we'll give it a test.
Cheers and Regards
Close but no.
The 'DP_Install_Tool.cmd' is not the problem, just the extra ')' in the cmd was a legit issue tho please make sure to pass that on, as I found out the nature of the error and it was a mind bogglin one too
Well that is wat you would think, but no ..
here is the layout I just ran into last night.
1 Dual arch AutoUnattend.xml with both amd64 and x64 architechtures, ok now we are goin to get a little confusin maybe, just follow along
you have this 1 XML file dual arch, and you have in it to RunAsynchronous or RunSynchronous commands ..
having the exact same run for a cmd or .exe ( or ANYTHING at this point ) in each amd64 and x86 and install a x64 OS will run BOTH the amd64 and x86 components in the pass
So wat I was gettin was that, the amd64 section of the XML file was gettin ran first ( and was fine on the x64 OS ) then the x86 section was gettin ran right after the amd64, witch would throw the windows error up, witch is legit, but to the fact that I didnt even know that BOTH comopnents ( amd64 & x86 ) would get ran if install a x64 OS .. if this has made since, that is the gist of that, lets go on ..
Now for the x86 OS install, this is just plain simple, it ignores the amd64 sections of the XML file .. thats all there is too the x86 side, it runs just the x86 components listed in the XML file ..
So using a dual arch XML file ( you have to beeee very careful to wat ya have in BOTH amd64 and x86 sections of the components pass or you may end up flubbin a x64 install, the critical areas I see that are visible to this is the RunAsynchronous or RunSynchronous commands listed in amd64 and the x86 parts
Ok, 1 final notation is that: When usin the above setup of a XML file and RunAsynchronous or RunSynchronous commands, they will run in 1 of 2 bit spaces = if amd64 the execution is from the 64 bit space, IF it runs the x86 it is ran from 32 bit space, and thus in the DP install tool.cmd this is wat was ACTUALLY happenin, is that the amd64 RunAsynchronous was the correct run cause the line was executed on a x64 OS, witch the DP Install tool.cmd finished as intended. Now the x86 RunAsynchronous command runs right after the amd64 and it would be in task manager as running in 'DP_Install_Tool.cmd *' ( witch means 32 bit run on x64 OS ) ok, fine, BUT it would pull the %PROCESSOR_ARCHITECTURE% == x86 ... and that is were I get the cross error in the DP_Install_Tool.cmd being ran.
SO to correct the bit space run on a x64 OS install, I created 2 cmd's - 1 for the x86 pass and 1 for the amd64 pass in the XML file, the x86 has in it, this is the very first thing that gets lookd at - 'IF EXISTS %PROGRAMFILES(x86)% THEN EXIT' - so this way it is truly ran on the correct OS Arch x86 , now the amd64 pass runs the cmd runs but does not have the check if %PROGRAMFILES(x86) exists, so that will run in 64 bit space and the %PROCESSOR_ARCHITECTURE% == amd64 when ran, so now I have this fixed more or less the correct way cause of the bit space run time for both arch's .. nifty I know LOL.
now that must sound a little better
Still experimenting. Now getting occasional more random type errors.
Ok, using Win 7 x64 Pro I get this in the cmd now
http://img689.imageshack.us/img689/3682 … 181613.png
It did fine on Win 7 x86 Pro
------
Ok, I remade the ISO ( only editin the xml file ) and it werkd, BUT this time I got a eeror ( it was a windows error box ) that it could not find C:\D\SAD2\xxxxx.cmd .. plaease make sure you typed yada yada
Not discounting the possibility / probability of operator error, but wanted to throw these out there in case anyone recognizes a symptom. Suggestions anyone?
EDIT: UPDATE
Well my last error was a double entry in the xml file to run the Test.cmd hehe, crazy ass x64 runs the x86 and x64 xml entries
SO really it was a error ----- [operator]
I am cleanin all this up right now to make sure there isnt no issues with the xml file from x64 user
------------
Ok, here is the issue I am running into, I use a dual arch xml file to cover everything I do with installin win 7, now usin the x86 or amd64 components sections causes the Install_Tool to run 2 times thus givin me that windows error with 'windows could not find C:\D\SAD\xxxx.cmd' Please make sure you typed the name correctly ... '
Ok, now I removed the x64 RunSynchronous so it doesnt get ran 2 times on x64 installs, now the only 1 that gets ran is the x86 components section with causes it to run in 32 bit space .. yea sum will understand this sum wont ..
SO, I am not sure wat to do to the cmd to get the viable info for win 7 only runnin it from a xml like I am, but this would be the area to do it in if it could be modified for win 7 and xml use, maybe I can do it, I'll try ..
Cheers and Regards
Hey Erik,
A friend of mine, monkie53, aka emplosion69, is trying to implement SAD2 in a build and since some of the drivers installed in this way need a reboot before taking effect, rather than running SAD2 at either FirstLogon.cmd or SetupComplete.cmd he's figured out a way to pause the build just before the last reboot, (henceforth referred to as the "install" stage), so he can run SAD2 at that point so that after the reboot, all the drivers should be in effect at first desktop. SAD2 works fine for him in an installed OS, his real OS - Win7 x64 - and the VM's OS. But when he runs it at the "install" stage he has a problem. The drivers seem to install, but the script seems to get "lost". After the 30 second countdown the script hangs with an error - "The system can not find the path specified." I'm wondering if this is a variant on the error that used to be there where the script did a CD and forgot to go back and ended up lost? Any suggestions? Thanks in advance.
Cheers and Regards
did a fresh VMstall and got the screen shot to make it clear on wat I see
http://img26.imageshack.us/img26/3927/w … 221334.png
EDIT: I use this in my AutoUnattend.xml file
<RunSynchronousCommand wcm:action="add"> <Description>Test</Description> <Order>6</Order> <Path>cmd /c %WINDIR%\Setup\Scripts\Test.cmd</Path> </RunSynchronousCommand>in the Test.cmd I have
cmd /c START /wait %systemdrive%\D\SAD2\DP_Install_Tool.cmdI tested this cmd line with a cmd with this in it from the $OEM$\$1\D\SAD2 folder
cmd /c START /wait DP_Install_Tool.cmdand all the cmd's close out in a installed OS, my real OS and the VM's OS, but at the install stage ( image ) the cmd has that error line witch causes it to drop down to the C:\> and it will not close out auto as it should
EDIT2: LOL n/m we found the problem:
Ok, figured out the issue LMFAO it was right there the whole damn time ..
ok, original block from the ( SAD2-120326 ) DP_Install_Tool.cmd..
:Timer ECHO. & ECHO This window will close itself in 30 seconds... & ECHO. For /l %%A in (1,1,30) do (<nul (SET/p z=#) & >nul ping 127.0.0.1 -n 2 ) ) ECHO *********************************************************************and delete the ")" and ya have this below..
:Timer ECHO. & ECHO This window will close itself in 30 seconds... & ECHO. For /l %%A in (1,1,30) do (<nul (SET/p z=#) & >nul ping 127.0.0.1 -n 2 ) ECHO *********************************************************************I started lookin at the cmd more and seen the
(code
)
so ok, no biggie, we seen this before, then I looked and seen there really wasnt a '(' for that last ')' that I deleted and viola!
Now we are in business YaY
Another reason I found today while reading through the help file, 7-zip.chm, for using LZMA2 vs LZMA for compressing the Driver Packs, is that LZMA2 is more multithread frinedly. LZMA compression uses at most 2 threads, whereas LZMA2 compression uses as many threads as there are cores available. Yes I know that compression time is not the issue that decompression is, but it will save you time. Just saying...
Cheers and Regards
7zip does have a history of things being in beta stage for YEARS. LOL Remember how long that 4.65 was final before v9 was finally released? I wonder why they do that? I was going by the listing here - http://sourceforge.net/projects/sevenzip/files/7-Zip/
Cheers and Regards
EDIT: With current downloads of v9.20 ALONE numbering 114,841,923, not counting the rest of the v9 series, or counting the other archiving programs that are also able to handle LZMA2 files such as HaoZip - http://www.haozip.com/Eng/index_en.htm, it sure seems that you should be able to consider being able to handle LZMA2 type files as a reasonable requirement. And if you include a version of 7-Zip that's able to handle them with your release, then even that concern goes away.
Yeah, I saw that. I grabbed both x64/x86 installers from the main site and extracted each 7z.exe & 7z.dll.
I thought the 9.22 was beta.
I knew you saw it - That remark was meant for OverFlow. I didn't know if he saw it. Since he mentioned using LZMA2 for x64 DP's and updating BASE I thought it might be useful for him. Sorry for the misunderstanding.
9.22 is NOT marked as Beta anywhere I saw.
Cheers and Regards
I don't know if you saw this over in the SAD2 thread, but for your convenience I'll repeat it here:
Erik, while the standalone version you referenced, the 9.20 "7za" version, seems to be the latest available, you could also use the 7z console version, the "7z" version. The 9.22 version is available here - http://sourceforge.net/projects/sevenzi … -Zip/9.22/. To get them, you can install the version you want and copy the files out, either the x86 or x64, or just extract the files you need, using 7-zip of course. The only files you need are "7z.exe" and "7z.dll", you just need to have them both from the x86 and/or x64 version. They do not have to be installed or registered. Put the .exe and the .dll in the same folder and you're good to go. The 7z.exe is command line driven, which you can see the main command options by opening a command box in that folder and simply typing "7z" without the quotes.
The "7z.exe" plus "7z.dll" are larger than the 7za.exe standalone, but they are available in both x86 and x64 versions and they fully support LZMA2.
EDIT: Also, to be clear, the "7z.exe" plus "7z.dll" combination is fully capable of handling both compression and decompression chores.
Cheers and Regards
I have so far had to babysit 7-zip to note time of archiving. Does anyone know of a way to automate this? If i had the slightest clue of the command-line settings, i would set up a batch of files to be compressed, & echo a text line & redirect to a file, so that i could calculate from file modifications times. I'm not complaining; it's just difficult to get anything else done at the same time.
Here's a timing routine you're welcome to use. I save it as TestTime.cmd, but you can use whatever name you want.
@ECHO OFF & SETLOCAL ENABLEEXTENSIONS ENABLEDELAYEDEXPANSION
(CALL :f_GetTime _StartTime)
::
:: Call the Routine here that you want to time
::
:: ping is an extraordinarily inaccurate, but simple delay for testing
:: the "3" will delay for ~2 seconds - this is just an example
:: REMOVE THIS "ping" LINE AND REPLACE IT WITH A CALL TO THE ROUTINE YOU WANT TO TIME!!
::
ping 127.0.0.1 -n 3 >nul 2>&1
(CALL :f_GetTime _EndTime)
(CALL :f_TimeDiff %_StartTime% %_EndTime% _TimeDiff)
::
:: At this point , the variable _TimeDiff will have the time that the Command
:: Routine took -- %_TimeDiff% will be set to the string HH:MM:SS.MSC
:: You can echo to the screen or redirect to a log file or use it however you like.
:: THIS IS ECHO'D TO THE SCREEN JUST AS AN EXAMPLE
::
echo %_TimeDiff%
ENDLOCAL&GOTO :EOF
:: #############################################################################
:: :f_GetTime _Time
::
:: Load time in a variable, zero padded using ONLY "standard" delimiters (:.)
::
:: Usage: CALL :f_GetTime _Time
::
:: %_Time% will be set to HH:MM:SS.MSC - NOTE: that MS is now THREE digits
::
:: Although the default time delimiter, in Windows XP and above is either . or :
:: users can change the delimiter to just about any character they like. And you
:: know theres always that one guy, the one who writes everything in green ink,
:: who will do this! This script always returns HH:MM:SS.MSC, note that MS
:: is now 3 digits, no matter which time delimiter has been set in the control
:: panel. Based on a discussion at ss64.com, with input from avery_larry and
:: bluesxman, and tweaks by bphlpt using examples by Frank Westlake.
::
:: Dependencies: None
::
:: Upon exit, ERRORLEVEL is set to 0.
:: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
::
:f_GetTime _Time
SETLOCAL ENABLEEXTENSIONS
FOR /F "tokens=1-3 delims=1234567890 " %%G IN ("%TIME%") DO (SET "_Delims=%%G%%H%%I")
FOR /F "tokens=1-4 delims=%_Delims% " %%G IN ("%TIME%") DO (SET "_hh=00%%G"&SET "_min=00%%H"&SET "_ss=00%%I"&SET "_ms=00%%J0")
ENDLOCAL&(SET %1=%_hh:~-2%:%_min:~-2%:%_ss:~-2%.%_ms:~-3%)&EXIT /B 0
::
:: #############################################################################
:: #############################################################################
:: :f_TimeDiff %_StartTime% %_EndTime% _TimeDiff
::
:: Subtract %_StartTime% from %_EndTime% and assign difference to _TimeDiff.
::
:: Usage: CALL :f_TimeDiff %_StartTime% %_EndTime% _TimeDiff
::
:: %_TimeDiff% will be set to HH:MM:SS.MSC - NOTE: that MS is now THREE digits.
::
:: Dependencies: None
::
:: Upon exit, ERRORLEVEL is set to 0.
:: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
::
:f_TimeDiff %_StartTime% %_EndTime% _TimeDiff
SETLOCAL ENABLEEXTENSIONS
(CALL :f_ConvertTimeToMs %1 _StartTime)
(CALL :f_ConvertTimeToMs %2 _EndTime)
(SET /a "_DiffMs=%_EndTime%-%_StartTime%")
IF 0 GTR %_DiffMs% (SET /a "_DiffMs=%_DiffMs%+24*3600000")
(SET /a "_hh=(%_DiffMs%/3600000)")
(SET /a "_min=(%_DiffMs%/60000)-60*%_hh%")
(SET /a "_ss=(%_DiffMs%/1000)-3600*%_hh%-60*%_min%")
(SET /a "_ms=%_DiffMs%-1000*(%_DiffMs%/1000)")
(SET "_hh=00%_hh%"&SET "_min=00%_min%"&SET "_ss=00%_ss%"&SET "_ms=000%_ms%")
ENDLOCAL&(SET %3=%_hh:~-2%:%_min:~-2%:%_ss:~-2%.%_ms:~-3%)&EXIT /B 0
::
:: #############################################################################
:: #############################################################################
:: :f_ConvertTimeToMs %_Time% _TimeInMs
::
:: Convert a time to Ms.
::
:: Usage: CALL :f_ConvertTimeToMs %_Time% _TimeInMs
::
:: %_TimeInMs% will be set to the number of Ms in %_Time%.
::
:: Dependencies: None
::
:: Upon exit, ERRORLEVEL is set to 0.
:: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
::
:f_ConvertTimeToMs %_Time% _TimeInMs
SETLOCAL ENABLEEXTENSIONS
(SET "_Ms=%1")
ENDLOCAL&(SET /a "%2=3600000*(1%_Ms:~0,2%-100)+60000*(1%_Ms:~3,2%-100)+1000*(1%_Ms:~6,2%-100)+(1%_Ms:~9,3%-1000)")&EXIT /B 0
::
:: #############################################################################Cheers and Regards
I am working on implementing these changes into my SAD2 script (easy since it's stand-alone).
That's exactly why I posted in that thread. The more controlled environment of stand-alone apps are definitely easier to deal with.
Cheers and Regards
Thanks for doing this. I hope it is helpful to mr_smartepants. If I could trouble you to do yet some further tests, while you're set up I wonder how much further improvement in speed would happen if the x64 bit version of 7-zip could be used? (I wouldn't think there would be much difference in size, if any.) Your timing tests might require an external script calling the 7-zip routines, but it should be able to be done. Thanks again.
Cheers and Regards
To continue the comparison, it would be interesting to compare size and decompression speeds of the same DP's compressed with LZMA vs LZMA2. I understand that DP's compressed with LZMA2 would no longer be compatible with older versions of SAD2, but if all DP's were LZMA2'd that could knock off several MB's for some of the DP's so anyone downloading a lot of them would see the difference in the compressed sizes, the time required to download them, and the time required to decompress them. I know size doesn't matter as much now since drives are large, but when it comes to download and hosting files, this could save bandwidth (even in torrents) which would be noticeable and appreciated. There are many other instances on the web that require a recent version of 7-zip for this very reason so this would not be unique.
Cheers and Regards
I would think the important aspects are a balance of size and speed of DEcompression, since that will be done FAR more often that the compression.
Cheers and Regards
I will be glad to have this post copied to where it was suggested, but would also prefer to leave a copy here since I feel it is a direct continuation of the conversation I began in post #44 - http://forum.driverpacks.net/viewtopic. … 516#p47516 - therefore directly associated with the latest update, unlike most of the posts from #52 - #70 which I agree are mostly OT - FOG etc.
Erik, while the standalone version you referenced, the 9.20 "7za" version, seems to be the latest available, you could also use the 7z console version, the "7z" version. The 9.22 version is available here - http://sourceforge.net/projects/sevenzi … -Zip/9.22/. To get them, you can install the version you want and copy the files out, either the x86 or x64, or just extract the files you need, using 7-zip of course. The only files you need are "7z.exe" and "7z.dll", you just need to have them both from the x86 and/or x64 version. They do not have to be installed or registered. Put the .exe and the .dll in the same folder and you're good to go. The 7z.exe is command line driven, which you can see the main command options by opening a command box in that folder and simply typing "7z" without the quotes.
The "7z.exe" plus "7z.dll" are larger than the 7za.exe standalone, but they are available in both x86 and x64 versions and they fully support LZMA2.
EDIT: Also, to be clear, the "7z.exe" plus "7z.dll" combination is fully capable of handling both compression and decompression chores.
Cheers and Regards
OK So from what you are saying, apparently at least some of the Brothersoft downloads of 7-Zip might include toolbars or other things that violate the 7-zip license, and it makes sense that someone should be sure that I.P. knows so he can do something about it if he so chooses. Fair enough. By all means you should pass that on to I.P.
But you seem to be implying that "a 'special' command-line unzipper for DP's (incl. SAD2 & BASE)" would be useful, and that I don't understand. The DP's are just compressed files, and 7-zip already has a command line utility that can handle them. So what am I missing?
Cheers and Regards
And how did we get off on THIS tangent?
Cheers and Regards
Sorry Erik, please feel free to relocate any and all of my distracting posts to the appropriate thread. I agree it would be better.
Cheers and Regards
If that's the case, what makes FOG - http://sourceforge.net/projects/freeghost/ - require the use of SFX? And why would I want to use something that has those kinds of special requirements? Not trying to be argumentative, just curious. If FOG has so much to offer, please explain the benefits you derive from using it.
Cheers and Regards
I'm with mr_smartepants that I don't understand why you feel using an SFX is required. If I understand what you said about the size of the SFX being 1GB, then it has the DP's inside it. So if there's an update to any of the DP's, you have to make a new SFX, right? No one is saying put the DP's in the image, keep them separate. That's the whole idea behind SAD2. But that doesn't mean you have to put them in something else like an SFX. Why do you think you need to do that? What's the difference between remaking the SFX and manually distributing it versus manually distributing the DP's which you say you don't want to do? Just updating the DP's that changed has got to be a smaller thing to distribute than a whole new SFX. I'm very confused.
But I would be interested in the guide you're putting together. I'm sure I'd learn something new. So please share.
Cheers and Regards
I still have not tested LZMA2-compressed DriverPacks yet but we still need to maintain backwards compatibility with older versions of SAD2.
I know you want to be backward compatible with previous versions of SAD2, but if all DP's were LZMA2'd that could knock off several MB's for some of the DP's so anyone downloading a lot of them would see the difference in the compressed sizes and the time required to download them. I know size doesn't matter as much now since drives are large, but when it comes to download and hosting files, this could save bandwidth (even in torrents too) which would be noticeable and appreciated. There are many other instances on the web that require a recent version of 7-zip for this very reason so you would not be unique. But it's up to you of course.
Glad it's working out. I'll look forward to testing it out.
Cheers and Regards
As you see I've been a lurker for a while. Good thing since new registrations were closed. I was actually an non-member lurker for a good while before that. Sorry I haven't said anything up til now, not even "Thanks for all your hard work and thanks for keeping this maintained for all our benefit!" Which is way overdue.
I thought your script just used "stock" pieces of the 7-zip package to do the unzipping. If not, I would think it could. The 7-zip Console app pieces 7z.exe and 7z.dll if necessary which are available in both x86 and x64 forms. Your script already does the checks necessary to be able to determine the current architecture, so you can take advantage of it. In the bin folder you could make two sub folders based on the system arch and put the arch dependent versions in the respective folder.
bin
..._86
......dpinst.7z [instead of dpinst32.7z
......the necessary 7-zip x86 files and any other x86 dependent files
..._64
......dpinst.7z [instead of dpinst64.7z
......the necessary 7-zip x64 files and any other x64 dependent files
When you make your architecture checks, set a variable ,%Arch%, to either _86 or _64 as appropriate. Then instead of code like:
IF Exist "%%i:\OEM\bin\un7zip.exe" SET "M=2"
you could use things like:
IF Exist "%%i:\OEM\bin\%Arch%\un7zip.exe" SET "M=2"
This could even end up making the code simpler. Instead of having separate code sections for x86 and x64 use, with the right variables set up you could end up with one code section which might be easier to maintain and troubleshoot, while becoming more flexible at the same time.
This suggestion is from an extremely brief glance through the code, so I might very well have underestimated the impact of trying to make the changes, and if so I appologize. Anyway, it was just a thought.
Cheers and Regards
DriverPacks.net Forum » Posts by bphlpt
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 3 official extensions. Copyright © 2003–2009 PunBB.
[ Generated in 0.201 seconds, 6 queries executed ]