[Release] RyanVM Integrator v1.5.1 Final! (Feb. 28th 2008)

[Siginet]

RVM Integrator v1.5.1

http://professorcpu.net/IMAGES/RVM-Integrator_1.5.gif

v1.5 was in developement for almost a year. It was completely re-wrritten from the ground up multiple times due to major changes. It fixes the only major issue which was in v1.4.3 with Spaces and Symbols in the paths. It is also now compatable with Windows Vista. It has many new features! :D Some of my favorites are:
1. The new Driver.CAB Cacheing (Which can save about 10 minutes of your UpdatePack integration times!
2. The new Re-Compress Update/Addon Pack plugin (Which can also save tons of time from integrating UpdatePacks and AddonPacks.
3. The integrator can now directly integrate Switchless Installers that are not compressed into Addons!
4. It now keeps original file timestamps.
5. It has a bigger Graphical User Interface With a brand new Logo, Thanks to HJW and Wolfx2 for the graphics!
6. It has a bunch of new cmdline parameters which will allow users to control just about every aspect of the integrator from within their own scripts!
New CMDLine Parameters (http://siginetsoftware.com/forum/showthread.php?t=283)

And many other great additions!

The integrator is much more powerful with the addition of new Entries sections and Plugin features which will allow Addon creators to make addons that are much more sophisticated!

I hope everyone appreciates all of the work the Beta Team and I have put into this release. I personnally would like to thank all of the beta testers for their help!!!

Changes:



Fixed: (v1.5.1) Recompress UpdatePack/Addons plugin was giving an error during compression of certain addons.
Improvement: ASMS files are automatically compressed. Now ASMS compression takes place after txtsetup.sif is updated.
Addition: New File Menu which links to the "Unattended Parameters" thread. So that users can learn how to use the integrators switches to automate processes.
Improvement: [FileCopy] and [FileMove] will now detect if a file is compressed and extract the file as needed.
Fixed: When no Lable is given for the iso name the integrator was giving it a name of "%3" but now it will use "RVMi" by default.
Addition: New File Menu "Optimize System Files Now" which will perform "Optimize System Files" only.
Addition: If files are compressed on the original source then the integrator will compress the new files automatically.
Addition: Added many new Unattended Parameters! You can read about them here: http://siginetsoftware.com/forum/showthread.php?t=283
Improvement: WPI Plugin files are only copied if needed or newer version exists.
Fixed: The gui now supports Large (120 DPI) Fonts.
Change: When a settings file is loaded it is now copied to integrator.ini instead of pointing the integrator to a different settings file.
Addition: The integrator will now save your original timestamps on edited files.
Improvement: Bigger Graphical User Interface, with a new Logo, Thanks to HJW and Wolfx2!
Improvement: Updated English_1.5.lng file.
Improvement: Changed the way certain files are executed to give better compatability with system settings.
Addition: Added a new advanced option to cache driver.cab. This comes in handy for those of us who integrate multiple copies of our disks. It dramatically speeds up multiple integrations by about 10 minutes (Depending on your computer's speed). It detects if it is xp home, pro. 2003 and it also verifies the md5hash of each file that was added to driver.cab. If the cached files match all the above then it copies the cached driver.cab instead of recompressing driver.cab... which is the longest portion of integration. If it doesn't match all the above then it will perform a recompression of driver.cab and cache the finished files for later.
Addition: Added the ability to add switchless .exe files as addons. They are automatically added to svcpack and svcpack.inf.
Addition: Added a new plugin... "ReCompress Update/AddonPacks". This new plugin will utalize the integrator to allow a user to optimize any UpdatePacks/AddonPacks so that when used for integration they will not need to compress most files found in I386_Compress. It also will ask for a txtsetup.sif file you can specify for the integrator to parse to find files that are compressable. (Specifying a txtsetup.sif file is reccommended... but is completely optional.)
Addition: Added the option to SlipStream a ServicePack file without performing an integration.
Addition: Added a new Inputbox to the "MakeISO Tab" (This also means there is a new addition to the English_1.5.lng file as well: 1135 = Browse To the Location Which Contains the Finished I386 Directory.)
Addition: The integrator now checks the I386 Directory for existing compressed or uncompressed files which are being moved from rvmtemp\extracted. If they exist they are deleted before the transfer.
Addition: Added usable Fourth pole in ExtraFileEdits which forces the integrator to use Case Sensativity when editing files. - Requested by: enu_user.
Addition: Added code to prevent users from integrating RyanVM's 2.2x Updatepacks over 2.1.x UpdatePacks. - Requested by RyanVM for future UpdatePacks.
Addition: Added new @PLUGINS variable for use with [FileCopy], [FileMove], [DirCopy], [DirMove], [RunFile] and the new [CreateCab] and [ExpandCab] sections. This new variable will allow a UpdatePack/Addon creator to specify the RVM Integrators PLUGINS directory as a place of source/Destination of files.
Addition: You can now use parameters in the [RunFile] section.
Addition: Added 2 new Sections that can be used in any entries file for expanding and creating complete cab archives. [ExpandCab] and [CreateCab]. They were mainly created so that people can make Media Center UpdatePacks/Addons.
Addition: Added code to automatically parse txtsetup.sif to see which files can be compressed in the i386 directory. It also automatically compresses cat files too. (I386_compress is still available as well.)
Addition: Added support to automatically parse drvindex.inf to see if files need to be copied or moved to driver.cab. (drivercab_copy and drivercab_move are still available as well.)
Addition: mmsetup.cab recompression is automatically performed if msmsgs.exe is found in the updatepack or if the section mmssetupcab_move is found in entries.ini. It does not recompress mmsetup.cab if neither of those areas are found.
Addition: Completly removed modifype.exe due to Vista incompatabilities and replaced it with n7Epsilon's PEChecksum.exe. Thanks n7Epsilon! (This file is used in the patch addons to make sure the correct PEHeaders are placed in HexEdited files.)
Addition: When you click on the Config: integrator.ini located on the main gui tab it will open the ini in notepad.
Improvement: [HexEdit] sections were expanding and recompressing files for every single edit made to the file. Now it only expands the file once and then recompresses when it finishes all edits.
Improvement: [ExtraFileEdits] sections were expanding and recompressing files for every single edit made to the file. Now it only expands the file once and then recompresses when it finishes all edits.
Improvement: Changed the way the integrator detects Upgrade disks. Hopefully this will be more universal. Only tested on windows XP.
Improvement: Files are now moved instead of copied during the "Shifting Files Around" stage of integration which will drastically improve on the integration time.
Improvement: The integrator will now add a .ini to the end of any filename given in Save Settings (if .ini doesn't allready exist at the end of the name).
Improvement: Forced [EditFile] to create any directory structure and the file it is editing if it does not allready exist.
Improvement: Posted new English_1.5.lng file which contains more areas to translate. (Like the menu items at the top)
Improvement: Re-Wrote the entire Translation portion of the integrator so that it does not need to know the exact amount of lines used for translation.
Improvement: Added more advanced debugging. When you select the advanced debug features it will show a lot more paths in the log.
Improvement: The Advanced Option "Convert Unicode to ANSI" feature should be obsolete now so it has been removed.
Improvement: Made the integrator check if at least 1.5 GB of space is available to perform integration.
Improvement: Got rid of the need for xcopy.exe.
Fixed: The integrator is now fully compatable with Windows Vista x86 and x64 versions.
Fixed: Path issues with 7zdn.exe which should get rid of a lot of bugs with spaces and symbols in the paths.
Fixed: Slipstreaming during integration when selecting "<NO>" didn't always run.
Fixed: "French Windows XP retail and OEM CD are correctly recognized, but not the corporate one."
Fixed: Detection of Corporate and Upgrade disks. Please check each os you have to see if it is detected correctly. If it is not please post your Pidgen.dll file So I can figure out why.


It would be awsome if you could all check out my http://Support.SiginetSoftware.com page and join as a refferal on my http://www.yourps34free.com/index.php?ref=4517441 It is very easy. Just sign up with an email address then order 1 offer. Once your order is verified then I have you as a refferal. I have even found a YouTube video of an official NBC G4TV broadcast (http://www.youtube.com/watch?v=DFKYVE__Mug ) to make you feel more comfortable. ;)

I only need 11 more refferals to get a Playstation3. Thanks VCC for being my first refferal!!!
I am getting some people signing up... but most of them are not filling out an offer. I don't get credit unless 1 offer is complete.

Download RVM Integrator v1.5 (http://integrator.siginetsoftware.com/index.php?download)
MD5Hash: DDD4429DD980D17D5386AF0DC2CCCE15

[bhishmar]

Hi Siginet
Congragulations for bringing out this looong awaited final-1.5.
Salute the long hours of hardwork gone into it.
regards

[mf3imp]

It's a great satisfaction to reach a result after so much work and so many tests. I attach the Italian language file, so it can be placed in the download pages.

Edit: attachment removed by me because it's already in the download page.

[Stimpy]

Well done Siginet, you did it, and did it good!

[dolivas27]

Hi Siginet Thanks for all the hard work. One question was there a reason this was not fixed for the final? http://siginetsoftware.com/forum/showpost.php?p=3099&postcount=18

[Kelsenellenelvian]

I just got that error with the last rc also haven't had a chance to test the final.

[ENU_user]

press cancel when ever it asks for txtsetup.sif (folder)
here it works fine :)

[biatche]

What's changed from the last rc to final?

[mr_smartepants]

Well Done!
Whew, I didn't think it would take us this long to get here.
Great job!

[bugmenot]

Good job on the new version Siginet. I can't wait to give it a spin :D

[biatche]

sigi, mind leaking to me, since your final is out, should we be expecting 2.2.1 Final out sometime REALLLLLY soon. (Judging from pattern of rvmi releases). I plan on formatting some pcs, thinking of whether to use RC or wait for final.

[biatche]

sigi, while it don't really matter, I think it's good to name the exe like rvmi.exe rather than rvm_integrator_1.5.exe it's so long.

[wimb]

Hi Siginet

Congragulations with your Release of RyanVM Integrator v1.5 Final !

Great job :D

wimb

[Siginet]

Hi Siginet Thanks for all the hard work. One question was there a reason this was not fixed for the final? http://siginetsoftware.com/forum/showpost.php?p=3099&postcount=18

Oh man... :( I completely forgot to look into this. :( I guess I'll fix it soon but fo now it will have to do. :(

[Siginet]

Released v1.5.1. Fixed ReCompress Plugin. It no longer gives an error when recompressing certain addons.

[Oron123]

And once again - I thank you very much, Siginet, and all the other excellent testers.
Finally is it here. :-D

[MrNxDmX]

Congratulations on the final RVMi ;)
Lets start translating :mrgreen:

[ChiefZeke]

:) After all your hard work I really hate to ask but, will UpdatePack 2.2.1 be final pretty soon? I am just itching to finally bring both of my systems up-to-date and a few friends/neighbors that I assist are pesering me - in a good way.

[cme4pc]

Thank You for all your hard work.

Just thought you should be aware....

There are two versions?.... 1.5.1 is the latest @ RVM?

Date: 2/28/2008 11:43:52 PM

From Siginet's RVM Integrator Home Page and Major Geeks D/L's Today>
MD5 Hash
RVM Integrator 1.5 Final.exe DDD4429DD980D17D5386AF0DC2CCCE15

From the DL link on Ryan's forum
RVM_Integrator_1.5.1.exe 42AC4B700F1EAB537ECA71C6719BB19B

BTW - Ryan posts indicate that the RC of the new update pack will be the exactly the same as the final release.... he is only going to change the filename by dropping the "RC1"... therefore if you already have downloaded the RC then you already have the final release. He indicates that he will probably make changes and release to mirrors on Sunday... but again, (and check the update pack site/forum for last minute changes), if you already have the RC, you already have the final. Try to save traffic on mirrors.

Thanks again Sig.

[Siginet]

Yes 1.5.1 is the latest. The only difference between 1.5 and 1.5.1 is the Recompress Updates/Addons Plugin is fixed. So for normal integrations there is no difference. ;) I'm sure Major Geeks and other sites will update soon.

[ENU_user]

couldn't help wondering , and to ask , if someone can consider making an explorer shell extension for the integrator and so it can register/unregister as a plugin in the path ..
the idea offcourse is having this option to integrate from any location selecting addons or dirs to integrate ... using the switches
http://siginetsoftware.com/forum/showthread.php?t=283
with an option to run integrator hidden

so far im able to use this through sendto shortcut with a small batch in the path :)

[cme4pc]

Thanks for the clarification and hopefully your reply will prevent confusion w/the masses. With the AP project, RyanVM, OEMScan, the driver pack updates and your integrator projects all back in current status, there may actually be hoper for screwdriver turners like me. Much obliged because all of this is slicker than snot (that's a compliment we say in the south.)

I came across some interesting reading on MS Tchnet, concerning SP3 RC update script and have seen "post SP3 update" packs circulating around on other sites.... Something that people should be aware of.... SP3 RC's break MS Update. MS intends for them only to be for early adopters and testing performance / compatibility issues. MS SPECIFICALLY STATES ALL RCs' of SP3 ARE FOR TESTING-EVALUATION AND SHOULD NOT BE APPLIED TO MISSION CRITICAL SYSTEMS.

Therefore, techs like myself need invaluable tools such as RVM-Integrator and the others aforementioned, to update systems in a stable and consistent manner. All of you deserve a HUGE ROUND OF APPLAUSE!

Thanks again!

[compstuff]

Just a simple but sincere THANK YOU!!!!! :-D

[ENU_user]

in the WPI plugins menu you can maybe have a link pointing to WPI.hta and call it "configure WPI" if exists then it launches ...

enable\disable should be "dynamic" btw ;)

thanks again!

[n7Epsilon]

Hello, I found a bug in the recompression plugin, in the txtsetup.sif that you select so that it compresses directly overwriting files, it does not read [SourceDisksFiles.x86], so any files in any pack that overwrites files referenced in that section are not compressed.

Steps to reproduce this bug:
Recompress RyanVM Update Pack 2.2.1 RC1, notice that wmvcore.dll inside the pack is not compressed in the final ZIP file, open txtsetup.sif of a generic sp2 source, notice that wmvcore.dll (and many other files) are referenced in [SourceDisksFiles.x86] and not compressed.

However when integrating normally with this recompressed pack, it is correctly read and recompressed.

Impact: Unnecessary increase in integration time.

- Another bug:
[drivercab_copy] does not work if the file listed in the section has been precompressed (which is done by the recompression plugin).

Steps to reproduce the problem:
1. Use Integrator 1.5.1 to recompress RyanVM Update Pack 2.2.1,
2. Notice in entries ini, the file sffp_mmc.sys is listed in [drivercab_copy], and sffp_mmc.sy_ is present in the recompressed output.
3. Integrate with recompressed pack, notice that sffp_mmc.sy_ is present only in I386 and not in driver.cab

Impact: Will cause problems for more involved drivers, should be solved for future update packs.

Solution: When processing [drivercab_copy], check to see if compressed version is in I386 first and uncompress it to drivercab expanded, otherwise just copy.

Workaround: Modify recompression plugin so that any files that need to be compressed, if they are listed in drivercab_copy, to be skipped and left uncompressed.

[ENU_user]

siginet i just want to bring to you're attention that files containing "bad CRC" will make it in. like switchless installers ..

as to archived addons 7z usually gives a message "bad CRC" if a file is found bad wile extracting OR if an extraction failed for any reasons ..

I thought id point this out if you wanted to offer a workaround for bad files ...extractions ... maybe quarantine them ;)

btw, n7Epsilon, did you checkout the first post on this page ;)

thanks again for you're good work guys...

[Siginet]

Hello, I found a bug in the recompression plugin, in the txtsetup.sif that you select so that it compresses directly overwriting files, it does not read [SourceDisksFiles.x86], so any files in any pack that overwrites files referenced in that section are not compressed.

Steps to reproduce this bug:
Recompress RyanVM Update Pack 2.2.1 RC1, notice that wmvcore.dll inside the pack is not compressed in the final ZIP file, open txtsetup.sif of a generic sp2 source, notice that wmvcore.dll (and many other files) are referenced in [SourceDisksFiles.x86] and not compressed.

However when integrating normally with this recompressed pack, it is correctly read and recompressed.

Impact: Unnecessary increase in integration time.

- Another bug:
[drivercab_copy] does not work if the file listed in the section has been precompressed (which is done by the recompression plugin).

Steps to reproduce the problem:
1. Use Integrator 1.5.1 to recompress RyanVM Update Pack 2.2.1,
2. Notice in entries ini, the file sffp_mmc.sys is listed in [drivercab_copy], and sffp_mmc.sy_ is present in the recompressed output.
3. Integrate with recompressed pack, notice that sffp_mmc.sy_ is present only in I386 and not in driver.cab

Impact: Will cause problems for more involved drivers, should be solved for future update packs.

Solution: When processing [drivercab_copy], check to see if compressed version is in I386 first and uncompress it to drivercab expanded, otherwise just copy.

Workaround: Modify recompression plugin so that any files that need to be compressed, if they are listed in drivercab_copy, to be skipped and left uncompressed.

I admit I did realize the problem with it not compressing files in [SourceDisksFiles.x86] but I did not have a chance to change it before final. I will change it in a later release.

As for drivecab_copy not expanding compressed files... that was supposed to be fixed a long time ago. :( I will have to look into this and make sure that it will copy or expand the files listed as needed. Thanks for reporting your findings. :)

Edit: Hmmm... looking at the code it does look like it is supposed to check for a compressed file of any file listed in drivercab_copy and uncompress the file to the .\drivers directory if it is found there. I am gonna run a test now to verify if it is failing for me.

Edit2: After testing an integration with RVM Integrator v1.5.1 and RVMUpdatePack2.2.1RC1-ReCabbed.zip the file sffp_mmc.sys was expanded to driver.cab.
Could you please try to test again and see if you still have an issue?

[ENU_user]

* sig i know you where about to fix that winntsif bug concerning variables in edits ... with the last RC
which is now broken function.
--------------------------------------------
* can you check if copy isn't copying all the basic files needed on the root ... like WIN51IP, setup .. otherwise im not sure what caused them exactly to get absent
---------------------------------------------------
* can you make cat compressing conditional to if exist, it seems the whole process of it is running all the time needlessly ..

[n7Epsilon]

I tested a few more times and discovered that it was going there indeed, I will continue to investigate and iron this issue down, it seems to happen in some cases only.

[Siginet]

* sig i know you where about to fix that winntsif bug concerning variables in edits ... with the last RC
which is now broken function.
--------------------------------------------
* can you check if copy isn't copying all the basic files needed on the root ... like WIN51IP, setup .. otherwise im not sure what caused them exactly to get absent
---------------------------------------------------
* can you make cat compressing conditional to if exist, it seems the whole process of it is running all the time needlessly ..

I think the winntsif function is fixed in the final.

I have seen on very rare occasions that the files on the root are not copied. I'm not sure exactly what causes it. I think I'll add a final check for IDENT files at the end of integration and have the integrator add them just in case. I have only seen this happen in Vista. I think it is not really a bug of the integrator but a bug in how Vista Deletes/Copys/Moves files. All I can think is vista sometimes acts like it is finished deleteing a directory before it is actually done deleteing. Then the files start copying before the directory is deleted 100% causing the missing files. That is my only explination as to what is happening. But like I said... it is on rare occasions. Basically all I can think... is VISTA sucks! ;)

As for cat compression being conditional... I don't think so... because now the integrator processes all of the cats found in svcpack. At the same time it makes sure that the info is placed in svcpack.inf. I suppose I can stop the integrator from extracting the cat files and just recognize that it is a compressed .ca_ file and process it. Which would make this process much faster. What slows it down is the fact that it extracts every compressed cat file to make sure it really is a cat file and not some other ca? file. But I agree... something different needs to be done here. I think it is a pain when I go to add more addons and I have to wait an extra few seconds for it to process all of the cats. ;)

[GreatJobGuys]

Many thanks for a fine product you've refined over the years, it's looking its best yet.

May I ask what exactly the Recompress Plugin is used for? I apologise for my ignorance, would I be right in presuming it does something to the effect of recompressing addons/files contained within to .7z, hence reducing the size of the integration?

What would be recommended here, to use the plugin or to just leave it be as there still seems to be a few teething problems as its a new feature.
Finally, if I was to download the plugin and use it, would I be able to just copy the plugin folder, Zip to the plugins folder of another running version of the Integrator on a PC without an internet connection?

Thanks.

[ENU_user]

I think the winntsif function is fixed in the final. can you give it a spin ..? here i get a bold error every time i use it ..



I have seen on very rare occasions that the files on the root are not copied. I'm not sure exactly what causes it. I think I'll add a final check for IDENT files at the end of integration and have the integrator add them just in case.
good enough! you can cache them ..



What slows it down is the fact that it extracts every compressed cat file to make sure it really is a cat file and not some other ca? file. But I agree... something different needs to be done here. I think it is a pain when I go to add more addons and I have to wait an extra few seconds for it to process all of the cats. ;)

i suppose CAT files integrity can be cached with some advanced switch or something that doesn't need to run @ all time

if the code is cluttered for some ode routine ...you would basically be patching a mistake in the code ... and then thats where usually hell likes to break loose ...

[ENU_user]

with "switchless.exe" we can definitely put it in to use "7z t ." for checking integrity before adding or editing svcpack.inf as they are not getting extracted simply added ... so you it can be measured with

"test integrity of files before integrating in advance"

as for regular integrations using "addons" you can maybe measure something with the summery quote "everything is ok" 7z leaves with every extract and offer a workaround for the badly extracted ...

[Siginet]

Many thanks for a fine product you've refined over the years, it's looking its best yet.

May I ask what exactly the Recompress Plugin is used for? I apologise for my ignorance, would I be right in presuming it does something to the effect of recompressing addons/files contained within to .7z, hence reducing the size of the integration?

What would be recommended here, to use the plugin or to just leave it be as there still seems to be a few teething problems as its a new feature.
Finally, if I was to download the plugin and use it, would I be able to just copy the plugin folder, Zip to the plugins folder of another running version of the Integrator on a PC without an internet connection?

Thanks.

The Recompression Plugin will compress certain files within the updatepack so that your integrations will be performed much faster. ;) It is common practice among addon creators to leave files uncompressed within the addons so that the Addon size is compressed in full much smaller for distribution. Which makes distribution easy... but then integrations take so long due to having to compress all of these files.

Yes you can just copy the plugins\Zip folder to another computer in the integrators Plugins folder and the integrator will recognize it just fine. ;)

[ENU_user]

@siginet a faster switch for 7z t ..

7z l -slt *.ext >stdout.always faster then the console
then look for the statement "Error:" >stdout.always faster then the console..
and ignore any "is not supported archive" <--statements ..
the rest are probably all bad CRC files.
will take a second to prob the needed results ..

[n7Epsilon]

Hello again, after some tests I found this bug, try to integrate the attached entries ini to your source and look at winntdirectories.

In 1.4.3 there was a mechanism that searched for the greatest dirid, incremented it by one and replaced it in the txtsetup entries in the entries file before integrating, thus avoiding any conflicts.

This is causing problems with some of ricktendo64's packs as they try to add the same dirid as ryan's new pack (with regards to the wlan update).

Integrator should check to see if the dirid key and value were listed before and then not add them again.

If not then search first by value to see if it was added in a previous run then adjust [txtsetup_files] in the pack to point to them and not add it twice.

If not then it should check if the dirid key (the number) was listed before and then find the greatest number and increment it by one and adjust [txtsetup_files] accordingly.

This bug will break packs that add new dirids as ms/ryan release new updates

[Siginet]

Hello again, after some tests I found this bug, try to integrate the attached entries ini to your source and look at winntdirectories.

In 1.4.3 there was a mechanism that searched for the greatest dirid, incremented it by one and replaced it in the txtsetup entries in the entries file before integrating, thus avoiding any conflicts.

This is causing problems with some of ricktendo64's packs as they try to add the same dirid as ryan's new pack (with regards to the wlan update).

Integrator should check to see if the dirid key and value were listed before and then not add them again.

If not then search first by value to see if it was added in a previous run then adjust [txtsetup_files] in the pack to point to them and not add it twice.

If not then it should check if the dirid key (the number) was listed before and then find the greatest number and increment it by one and adjust [txtsetup_files] accordingly.

This bug will break packs that add new dirids as ms/ryan release new updates

I have confirmed the issue. Actually it is the same as it has allways been. It is written to check any WinntDirectories greater than 299. Paul was the one who coded this a long time ago. I suppose everyone was supposed to know to make sure they use WinntDirectories higher then 299. I began messing around with coding it a different way but it is proving to be more difficult than I expected. So I will need to spend some more time on it.

Basically my idea on the way to code it will be that the integrtor will grab a list of all txtsetup_files and check the directory code by spliting the code at each comma ",". The 8th portion of the split is the directory code. Then it will check for a refference to that WinntDirectory code in the txtsetup_dirs portion of that entries file. If it does not exist then it will copy that txtsetup_files key and value to the z_datastore.ini. If it does exist in txtsetup_dirs then it will look to see if it is used in the txtsetup.sif file. If it is not used then it will copy the txtsetup_dirs key and value to z_datastore.ini. If it does exist then it will check if the value of txtsetup.sif and txtsetup_dirs matches. If it matches then it will copy it to z_datastore.ini. If it doesn't match then it scan the entire txtsetup.sif WinntDirectories section for a matching path. If it finds a match it will use that WinntDirectories code. If it doesn't then it will increment the code by one until it finds an empty one and then it will update the txtsetup_files code with the useable code and add the txtsetup_Dirs and txtsetup_Files infor to z_datastore.ini.

That is how it's coded in my head. ;) Now I just need to put it into real code! lol! I think the code is even more confusing when written in words! Haha!

[Siginet]

@n7Epsilon Looks like I fixed the txtsetup_dirs/txtsetup_files issue for v1.5.2. ;) I also took it a step further and I've added some code that sorts that section as well. So now the integrated WinntDirectories section of txtsetup.sif will be in order.

@Enu_user I have tested winntsif many times in v1.5.1 and it is working flawlessly. Make sure you are using the correct syntax.

[WINNTsif]
Shell\DefaultStartPanelOff=No

Specifically the backslash. ;) I found out that in the RC release I had the incorrect syntax in the integrators source code which was using a forwardslash. That is part of the reason the RC was failing.

I've been actually testing with an entries file that writes a complete winnt.sif file.

[ENU_user]

oohhh well i just checked, it doesnt like the commented stuff , woops
i should have checked Z_.ini to look what and how it collects [winntsif]

i had some commented stuff mainly so i can remember some settings so i can toggle the comments and switch between the settings ...

i can only confirm it works ;)

[Siginet]

I'll look into the commented stuff. The integrator should ignore any commented areas.

[DizzyDen]

.... Something that people should be aware of.... SP3 RC's break MS Update....
I have been testing and developing update packs for SP3 before it actually went RC and I have never experienced it breaking MS Update.

The rest of your post it absolutely correct, it IS NOT RECOMMENDED for production systems, and I would not install it on a system that I could not afford to lose data on since it will not produce a smooth upgrade to an official SP3 when it is released. The options would be to spend time saving all data that cannot be lost to another storage media, or lose it.

[bhishmar]

I think all of those files are files dealing with drivercab_move. Basically those files are supposed to end up in driver.cab. I'm pretty sure in the first run they do make it into driver.cab. So your disk should work fine in the first and second run. But since driver.cab is never extracted in the second run those files never get moved into the driver.cab... which is fine cause they allready exist there. But they must be left behind for some reason.

I think it is because the drivercab_move sections are completely skipped if a cache exists. So what I'll have to do is make a list of the moved files in the cache and make sure that the integrator deletes the allready cached files.

I will also look into the issues with the Advanced Options not saving to the settings files correctly.

Thanks for the reports. :)

Hi Siginet
This is from 1.5beta23 post. This may not be an issue at all, but just bringing to your notice, so that for future 1.6 it can be fixed, if it turns out to be an issue.

Two identical integrator runs WITHOUT & WITH driver-cab caching enabled, results in output files differences.
The run in which caching is enabled results in additional #19 files. Since these #19 files are already inside driver.cab in both cases, no functional problem, as noted earlier.

Only thing reminding you of what u indicated earlier. Pls ignore if not relevant.

I think it is because the drivercab_move sections are completely skipped if a cache exists. So what I'll have to do is make a list of the moved files in the cache and make sure that the integrator deletes the allready cached files.
Thanks & Regards

[Siginet]

So are you saying that files are being left behind in 1.5.1? I haven't noticed this.

[ENU_user]

editing....

[Siginet]

OK... I am lost. When I test I don't have an issue. I'll run another test when I get home. Drivercab_copy/Move sections are not skipped when a cache exists. Basically they are processed and if driver_cab move is processed then the files that would be moved to driver.cab are deleted instead of moved. At least that is how I remember coding it.

[ENU_user]

moved to the next page

[bhishmar]

So are you saying that files are being left behind in 1.5.1? I haven't noticed this.
Just do two successive integrations with RVMUpdatepack only. First one with driver.cab caching disabled, & second with caching enabled.

The second integrator run has more files (#19) left in the output. Other than this the two outputs are exactly identical.
But all these 19 files are anyway already included within the driver.cab, in both run outputs. So i think there is no functional problem.

Only see why this happened, to ensure no other side effects.
regards.
Note: The extra files in i386 are: aec.sy_, battc.sy_, kmixer.sy_, kswdmcap.ax_, msdv.sy_, ndisuio.sy_, ntkrnlpa.sy_, portcls.sy_, powerfil.sy_, ..........
allmost all files seems to be from sp2.cab

[newsposter]

are you saying that you run the integrator multiple times on the same 'source'?

[bhishmar]

are you saying that you run the integrator multiple times on the same 'source'?
No I do not. Why does anyone with a sane mind need to do that.:p

But you can invoke multiple integrator runs, always starting with the same XP-SP2 source, each time generating output in different folder. Now why do I need to do that? Simply to test the output-result file-set of the integrator. They are expected to be exactly the same.

In this case it is not! The difference is not functionally relevant as indicated in my earlier post. I do not think correcting this discrepancy is a priority, unless otherwise siginet thinks so.

I am pointing out this issue only from the sake of good software engineering.
regards

[biatche]

there were a couple of odd times i had to reintegrate the same stuff over.. i couldnt pass certain install stages of the rvm-integrated source at times.

[ENU_user]

I am pointing out this issue only from the sake of good software engineering.
regards

thats more like it


are you saying that you run the integrator multiple times on the same 'source'?

if i had to take it from how\where bhishmar got or understood that question ...

well thats a built in feature already ,if you, me or any one else is having to use it ,might as well have it work like it should ... nothing to do about if its necessary or not ... if you are using the integrator you expect it to run with no bugs ..

[bhishmar]

Thanks ENU_user for stating the obvious. My appreciation.

Btw ENU_user. Let me take this opportunity to mention another offtopic issue, which I had always wanted to say.

I have been following (at least attempting to read) many of your posts in these forums with great interest.
I do know or have a feel that, many of your posts are excellent in technical content.
But alas, most of the time I could not follow your post because of the special strain of English! language you are using!!

I mean No offence here, only venting my frustration, at the energy spent in deciphering your posts.

I have seen many posters here, whos first language is not english, but I have not felt a sense of loss, when I do not understand them. But in your case it is different, it is a real loss for our community. I have always sincerely prayed that somehow you improve your english writing skills, for the benefit of others in this community.

Having said this I am also curious to know how Siginet is able to follow your discussion & update his integrator code for the benefit of us all. I strongly suspect that Sigi is having a special language translator up his sleeve, to decode ENU's posts.

Otherwise, May god help Siginet to understand ENU_user's suggestions better, so we all benefits.
And ENU_user, dont get me wrong (I hope your reading skills are better than writing). This is really a letter of appreciation.
Regards

[ENU_user]

well I should take this opportunity to praise siginet
siginet is a real guy, he makes an effort in everything he does!.

as to my English i can try to teach myself to better it so one feels more comfortable or contended when reading ...

actually till before the spell checker in firefox was out I would hardly post anything ...
so first we should thank god for making the guys code in a great spell checker
it really helped a lot and i do have a feeling my writing is improving in some confident way ..

advise taken: i cant promise "strain free reading" at all times.. but I agree I must try, so god helps me ..and everyone

thanks again

[ENU_user]

removed

[biatche]

LOL @ bhishmar.

I too once had awful time trying to comprehend what ENU_User tries to say. Mostly to do with one of his addons, which at some point I just gave up. Thankfully, he's so skillful with addons, he fixed them and I didn't have to post anything.

But seriously, Thanks ENU_user, you've contributed a lot to the development of rvmi. You seem to spot out a lot of issues.

If sigi would share his code with you, you could maybe help him develop 'test code' for new features and bug fixes. Of course only sigi would release them officially

Where you from though ENU_User?.. maybe you could try watching some movies

[ENU_user]

thanks biatche... maybe later we can go on chatting some more right now we are dealing with some problems concerning a few bugs so lets all hang on for now till siginet gets around them

@sig I think i found something weird when using a command stream to append addons

to replicate this use the command without the \intgrate switch
then look into integrator.ini
under [AddonPacks] listing

here im seeing the addon names show on both sides where its shouldn't
the parameter on the right side should only show the path to the addon
without the addon itself pended...


thank

[Siginet]

thanks biatche... maybe later we can go on chatting some more right now we are dealing with some problems concerning a few bugs so lets all hang on for now till siginet gets around them

@sig I think i found something weird when using a command stream to append addons

to replicate this use the command without the \intgrate switch
then look into integrator.ini
under [AddonPacks] listing

here im seeing the addon names show on both sides where its shouldn't
the parameter on the right side should only show the path to the addon
without the addon itself pended...


thank

what is the cmdline you are using?

[ENU_user]

RVM_Integrator_1.5.1.exe /Addons:"d:\addon\1_AddOn_.cab,2_AddOn.rar,3_AddOn.7z"

just try that then look in integrator.ini

[ENU_user]

driver.cab caching: my last attempt to refine my previous post on the subject ;)

assume we are using an updatepack in both integrations with driver.cab caching ...Enabled (for the demo)

integration 1.

A) on to a fresh source after the files are copied to the destination directory
the integrator will calculate a hash file for driver.cab before expanding it!! , & store it in the caching directory.

B) files [drivercab_move] from the updatepack are copied to the cache directory (in hash form), for future comparison needs

* back to the integration process

C) driver.cab expands & files mentioned in B) are compressed into driver.cab


D) the newly repacked driver.cab is then copied to the caching directory

integration 2.

now we are not actually using the same source ,but a complete fresh one!

A) files are copied to a fresh destination directory

B) a hash is generated for driver.cab and compared with the hash generated
in ( integration 1. "A)" )

this will be the first passing point to check if driver.cab caching can accrue
a miss match at this point will cause driver caching to be discarded

lets assume the hash's match so we can continue to illustrate the Demo\\

with passing the first check we just validated that driver.cab is the same in both integrations in its pre-modified, untouched state.

C) files from the updatepack are next to be processed:
the files previously saved in integration 1 B) now need to be compared with the ones arriving from the updatepack in integration 2. (the current)

except this time the file in (updatepack integration 2.) may differ from the ones in integration 1. by hash or count of files.
in this pass the comparison job fails ...if there is a mismatching condition ..driver caching feature is discarded

if the files are identical in "hash" and "count" then the cached driver.cab from the cached directory mentioned in integration 1. D)

overwrites the one on the source, skipping the need to repack the driver.cab needlessly ....

[Siginet]

@Enu I allready save the hash of files in the drivercab.ini file. ;) Your idea is basically the same as what I am doing allready. Except the adding of the hash of the original driver.cab. I will be adding this feature.

[Siginet]

RVM_Integrator_1.5.1.exe /Addons:"d:\addon\1_AddOn_.cab,2_AddOn.rar,3_AddOn.7z"

just try that then look in integrator.ini

The first comma should be place before the file name. ;)


/Addons:"d:\addon,1_AddOn_.cab,2_AddOn.rar,3_AddOn.7z"

[ENU_user]

edit complete ...

[ENU_user]

it seems to me that the COMMA added to the and of the path. is bad
it doesn't seem to adjust with other sets of commands.

having it placed like that in the command at the end of the path isn't clean when built-in variables in "SET" "CALL" "FOR" use "\" at the end of a path always.

"working on some sendto extension to be able to integrate from explorer ..."

for multiple addons when setting the order of the var & "comma" in some placement order to run the command it all works

when its for single standalone addons the output is "d:\DIR\\some_addon.7z which wont work (note the "\\")

I can change the order but then one SET will break the other....

the problem is when selecting a few addons. or when selecting stand alone ones.

[Siginet]

This is by design of autoit. When more than one file is selected the string is split that way. If you use the FileOpenDialog() command in autoit you will notice what I am talking about. Actually it makes since and should make it easier to code a sendto type of extenson. You should easily be able to tell what is the dir and what are the files.

[ENU_user]

well suddenly the script will accept this:
d:\DIR\,some_addon.7z
and process it really as the way it looks in integrator & without special limitations
d:\DIR\\some_addon.7z & like this -> d:\DIR\|some_addon.7z

now suddenly it works !! before it didn't!

but wait: this means that something else is still in the way of all this :(
I mentioned something about integrator.ini under [AddonPacks] listing
which wouldn't write the path correctly ..

now I'm seeing its OK to accept DIR\, even if it translates DIR\\ or DIR\|

integrator accepts it but in some condition it makes "sorry no entries.ini found" even if the paths seem to be looking right in integrator.ini

i think the best way to override any issue's for "entries.ini not found"
is by making sure all paths are set correctly inside integrator.ini & only then read everything from integrator.ini to the command line and only then -> integrate

if something isn't right the script can force the script to say "wrong path specified" .. or something else if that message is already taken/used ..

if there is a bug anywhere that is related to paths you will be able to find it quickly after setting some new conditions or anything similar to this

besides with that you will eliminate all the time wait till "no entries.in found" appears and you can isolate this with a new message
"wrong path specified" so when there is a real condition where "no entries.in found" it will serve its purpose exactly not for anything else.

[ENU_user]

maybe its better to have all cat files processed at the beging
right after all files are extracted & entries are collected
the cat files if exists will first get cabbed & only then moved to svcpack

then the process can continue ...as usual getting all the cat file placements at the beginning & out of the way

[elrico]

Yeah really good, i love the new integrator :D

I ran a some tests since the release of 1.5.1 and all is good.

About driver.cab this is what i see :
If i took SP2 already integrated MS CD of home / pro / MCE this is the same file, but i've two version of SP2 (SP2 original, and SP2a/b?) and here the driver.cab is not the same (even SP2.cab is different).

I don't have tested "driver.cab caching" on the two version of SP2, but you save some good minutes of my life with this option. The only thing i notified (but i think you're aware of this) : the files that must be only in driver.cab (aec.sys ... ntkrpamp.exe ...) are added to i386 directory when i ran a second integration (driver cab caching sucessful!).
Ok not a problem when i install XP (only space consumming on CD).


Thank very much !

[Siginet]

Yeah I plan on changing the drivercab cacheing to use md5 hashing of the original driver.cab file as well. Which would fix this problem.

[showtime33]

avira antivir decided to flag RyanVM Integrator Current version: 1.5.1

http://img366.imageshack.us/img366/180/flaggeddl3.png

[Siginet]

avira antivir decided to flag RyanVM Integrator Current version: 1.5.1

http://img366.imageshack.us/img366/180/flaggeddl3.png

Please notify AntiVir of the false positive. Thanks for reporting!

[nonno fabio]

suggestion:
we have noticed that Integrator is able to write no more than 640 lines in dosnet.inf and about 750 in txtsetup.sif: we have tested that this could cause problems with some big addons.

It's possible to increase those limits?

Thanks

[Siginet]

Hmmm... this is the first I have heard about this. :( Do you have an addon that causes this problem? I'd like to do some testing and see what I can do.

[nonno fabio]

here are some entries.ini files:
OnePiece_Vista_Style_Per_WinXP_AIO_AddOn.rar 11.4 KB
http://pyhsvq.bay.livefilestore.com/y1pFG_qqWrz4Q1QeRyq5tRl4UWTrhHBVqoPnZWbjZFJIF7xAVz ybGizYXAv8UDI6jXDzZjbtEKgCqeoTMCWWEq2Zw/OnePiece_Vista_Style_Per_WinXP_AIO_AddOn.rar?downl oad
Hash MD5 3D6B81021C2578728231B42694B67BF6

or

OnePiece_Windows_Sidebar_Addon.rar 7.57 Kb
http://pyhsvq.bay.livefilestore.com/y1pFG_qqWrz4Q0k7tGVcMBE9iClGPaEzoMahrmqhS9XpN78Z_C 1QwpGfxQ-gwIXmBhYyqo4ZCEjpn_mAO-sl_ZPCw/OnePiece_Windows_Sidebar_Addon.rar?download
Hash MD5 CA07844E9896189D3609E62A8C0DC651

edit: vista AIO addon has 1200 lines, Sidebar one 650

[ianymaty]

Here are Romanian translation for RyanVM Integrator v1.5.1
I made two versions, one with romanian specific diacritics and the other without.

[koy]

Just tried downloading RVM Integrator and received this message from Eset Smart Security:

"Name">h**p://integrator.siginetsoftware.com/data/download.php?id=1

"Threat">Win32/Packed.Autoit.Gen application

"Action">connection terminated - quarantined

"Information">Threat was detected upon access to web by the application: C:\Program Files\Internet Explorer\iexplore.exe.

Is this anything to bother about?

koy.

[Siginet]

Eset/Nod32 have been giving a lot of false positives about the integrator. I think I am changing my mind about what my favorite AV program is.

[nonno fabio]

small bugfix request for Integrator:
When an addon needs to put the same file from txtsetup.sif in two different locations, Integrator chooses only one of them and discards the first one.

For example:
file.dll =1,,,,,,,2,0,0

file.dll =1,,,,,,,1,0,0

Integrator, unlike Nlite, won't consider the first line and will write only the last one.

This could create some problems.

Thanks.

[ENU_user]

[obsolete_entries]
util.dll

;these get mixed up
wmiutils.dll = 100,,,,,,,,3,3
wmm2ae.dll = 100,,,,,,,,3,3

the outcome is a hybrid of the two previous one mentioned, looking like this
wmiutwmm2ae.dll = 100,,,,,,,,3,3

[Siginet]

small bugfix request for Integrator:
When an addon needs to put the same file from txtsetup.sif in two different locations, Integrator chooses only one of them and discards the first one.

For example:
file.dll =1,,,,,,,2,0,0

file.dll =1,,,,,,,1,0,0

Integrator, unlike Nlite, won't consider the first line and will write only the last one.

This could create some problems.

Thanks.

I actually heard that Ryan requested nLite to be changed so that it does not allow this. It is much easier... and reccommended to just place a duplicate of the file on the disk and list them in txtsetup like:

file.dll = 1,,,,,,,1,0,0
file1.dll = 1,,,,,,,2,0,0,file.dll

Since the ISO is Optimized in the end anyways the files do not take up any extra space on the disk.


[obsolete_entries]
util.dll

;these get mixed up
wmiutils.dll = 100,,,,,,,,3,3
wmm2ae.dll = 100,,,,,,,,3,3

the outcome is a hybrid of the two previous one mentioned, looking like this
wmiutwmm2ae.dll = 100,,,,,,,,3,3

Hmmm... that seems like an odd bug. Because neither one of them match. But maybe you meant

[obsolete_entries]
utils.dll

wmiutils.dll = 100,,,,,,,,3,3
wmm2ae.dll = 100,,,,,,,,3,3

Becomes:
wmiwmm2ae.dll = 100,,,,,,,,3,3

??

I can see this happening. It's a limitation in my code. I remember running into it a long time ago. But it never became an issue. I have an idea on how I can change it in the future. It may cause it to peform this section slower though.

[ENU_user]

i think the WPI compiling part doesn't work run on 64-bit xp ..