[Doc] RVMi @Destination parmeter

Windows XP Professional x64 Edition Update Pack discussion.
Post Reply
User avatar
ENU_user
Posts: 1253
Joined: Wed Jan 25, 2006 1:42 pm

[Doc] RVMi @Destination parmeter

Post by ENU_user » Thu Nov 13, 2008 4:35 pm

a new parameter was added to rvmi beta namely to serve addons that can support both 64 bit window & 32 bit ... without this parameter some wrong edits would get applied especially around the "I386\" path reaching from entries.ini Edits.

on 64 bit this path represents a different folder.

[EditFile] for instance would create useless files on that directory if you had to use I386\ edits that where meant for a 32 bit source ..

* if your addon was strictly made for the 64 bit version the normal syntax is for example :

[EditFile]
AMD64\WINNT.SIF,GuiUnattended,DetachedProgram

* Now if you wanted to aim this edit to work for a 32 bit source as well with AMD64 one.. you would normally only had to add all I386\ paths for the same edits (same Entries.ini)

but finally once integrated this will cause a regressions on the 64 bit source as it happens to have also the I386\ available on the Root.. ^^

conclusion: you could use the new uni parameter: @Destination it should take care of any issues involving path edits in entries.ini for all sections needing the path destination specifically specified to support the addon making for both 32bit destination source files & AMD64 destination source files using all in all one Entries.ini.

[EditFile]
@Destination \WINNT.SIF,GuiUnattended,DetachedProgram

32bit destination=I386\
AMD64 destination = AMD64\

remember: this parameter is new Under a beta and needs more tests to prove itself out ..
Last edited by ENU_user on Fri Nov 14, 2008 4:34 pm, edited 1 time in total.

User avatar
mr_smartepants
Posts: 824
Joined: Thu May 18, 2006 5:56 am
Location: Cambridgeshire, UK

Post by mr_smartepants » Fri Nov 14, 2008 5:20 am

So if I wanted to make edits to only 32-bit source I would use the syntax

Code: Select all

[EditFile] 
I386\WINNT.SIF,GuiUnattended,DetachedProgram 
This syntax has NOT changed since previous versions for 32-bit.

But, if I wanted to make an addon universal for both 32- and 64-bit OS then I would use

Code: Select all

[EditFile] 
@Destination \WINNT.SIF,GuiUnattended,DetachedProgram 
So the variable @Destination doesn't need to be declared anywhere in the entries.ini? :?
Would there be any drawbacks to using the @Destination variable on a 32-bit only source? (apart from breaking compatibility with previous RVMI).

The problem I'm having with the latest beta (posted over on Siginet's site) is that when integrating an addon with [EditFile] entries WITH an updatepack, the [EditFile] section is NOT working. The addon alone works fine with no updatepack.
I believe this is a PATH problem that may be caused by the new [EditFile] code for the new variable.

I just want to make sure the addons I use are compatible with both the release/beta RVMI (nlite compatibility would be a bonus, but I'm not counting on that).
Image
Some heroes don't wear capes, they wear Kevlar and dog-tags!

User avatar
5eraph
Site Admin
Posts: 4618
Joined: Tue Jul 05, 2005 9:38 pm
Location: Riverview, MI USA

Post by 5eraph » Fri Nov 14, 2008 1:49 pm

[EditFile] was not working in my beta 2008-05_0.01 update pack with RVMi 1.5.3. I don't believe new code is causing the problem, mr_smartepants.

I have not tried betas 7 or 8 of RVMi yet.

Code: Select all

[EditFile]
AMD64\txtsetup.sif,WinntDirectories,AddLines.dirs
AMD64\txtsetup.sif,SourceDisksFiles.amd64,AddLines.amd64

[AddLines.dirs]
270 = SoftwareDistribution\DataStore
271 = SysWOW64\Macromed\Flash
272 = system32\en-US
273 = SysWOW64\en-US

[AddLines.amd64]
waaclient.dll = 155,,,,,,,82,0,0,aaclient.dll
waaclient.mui = 155,,,,,,,273,0,0,aaclient.dll.mui
wFlsh9.ocx = 155,,,,,,,271,0,0,Flash9f.ocx
wFlshUtl9.exe = 155,,,,,,,271,0,0,FlashUtil9f.exe
wimapi2.dll = 155,,,,,,,82,0,0,imapi2.dll
wimapi2fs.dll = 155,,,,,,,82,0,0,imapi2fs.dll
wmstsc.exe = 155,,,,,,,82,0,0,mstsc.exe
wmstsc.mui = 155,,,,,,,273,0,0,mstsc.exe.mui
wmstscax.mui = 155,,,,,,,273,0,0,mstscax.dll.mui
wmuweb.dll = 155,,,,,,,82,0,0,muweb.dll
wtsgqec.dll = 155,,,,,,,82,0,0,tsgqec.dll
wtzchange.exe = 155,,,,,,,82,0,0,tzchange.exe
ww03a3409.dll = 155,,,,,,,82,0,0,w03a3409.dll
wwuapi.mui = 155,,,,,,,82,0,0,wuapi.dll.mui
wwuaucpl.mui = 155,,,,,,,82,0,0,wuaucpl.cpl.mui
wwuaueng.mui = 155,,,,,,,82,0,0,wuaueng.dll.mui

User avatar
mr_smartepants
Posts: 824
Joined: Thu May 18, 2006 5:56 am
Location: Cambridgeshire, UK

Post by mr_smartepants » Fri Nov 14, 2008 2:16 pm

Well, I just tried my addon with both [editfile] with @Destination variable and [winntsif] functions and beta 8 works perfectly using those. I guess the explicit path use with [editfile] is intermittent.

In fact 5eraph, you might want to try your update pack with the following lines:

Code: Select all

[EditFile]
@Destination\txtsetup.sif,WinntDirectories,AddLines.dirs
@Destination\txtsetup.sif,SourceDisksFiles.amd64,AddLines.amd64 
Image
Some heroes don't wear capes, they wear Kevlar and dog-tags!

User avatar
ENU_user
Posts: 1253
Joined: Wed Jan 25, 2006 1:42 pm

Post by ENU_user » Fri Nov 14, 2008 4:16 pm

@Destination parameter will be good for having the ability to make an addon that can work both for 32- and 64-bit OS, a bit pointless if the addon is for a specific OS

this parameter was also introduced for getting the integration's true source path when using the [runfile] as a side dish parameter (consult the integrator's manual document about [runfile] over @siginet's Integrator page)

siginet hardly had a chance to start or better yes finish what he started implementing with this ,but as you already know this release was piloted to feedback code65536's implementations .. (siginet's work is a foot back from being complete)

my side of this release was to allow it being released as is.

to be more accurate with the above statement : if this helped you get a better integrator, you won't have to wait very long for siginets updated one that will include some + new features + change logs ..etc ;)

if you stumble upon something regarding code65536's implementations or anything else for this release please check the topic update @ http://siginetsoftware.com/forum/showthread.php?t=493

cheers ...

User avatar
Siginet
Site Admin
Posts: 2894
Joined: Fri May 27, 2005 1:07 pm
Location: Planet Earth
Contact:

Post by Siginet » Sun Nov 16, 2008 3:19 pm

That is a great reply enu_user. That is exactly my plan. I wanted to get a stable beta out there which could do the main things that it has allways done with the improvment of cablite.dll. I need people to test it like crazy. On top of that I would really like people to test out all of the new [RunFile] parameters I have implemented and give me feedback on what works and what does not work. Or if they have other parameter suggestions.

The new parameter features bring the integrator to a whole new level of functionality and will allow an addon maker full control of what is happening during an integration.

As for why I changed many sections of the integrator to look in the root first... then in i386 for files is because many of the sections did different things... which made it confusing for addon makers. They had to remember to use i386\eula.txt when they were using [EditFile] but they would only have to specify eula.txt when using [ExtraFileEdits] because [EditFile] looks by default in the root of the disk and [ExtraFileEdit] looks in I386 by default. So now that is changed. These sections now will look in the root first... then in i386 next.

Or if you use @Destination it will automatically look in I386 or AMD64 depending on the OSType. ;) Which allows for universal addons.
Image
--Siginet--

Techware
Your Virtual Technician
Computer Management Software

MichaelPeerm
Posts: 9
Joined: Thu Jun 07, 2018 11:30 am
Location: Virgin Islands
Contact:

Doc RVMi Destination parmeter

Post by MichaelPeerm » Tue Jul 24, 2018 7:37 pm

hope this isnt a dumb question, but . . . was this doc crowd-funded?? cant remember.

User avatar
bphlpt
Posts: 1346
Joined: Sat Apr 19, 2008 1:11 am

Re: [Doc] RVMi @Destination parmeter

Post by bphlpt » Tue Jul 24, 2018 9:27 pm

I really can't figure this guy out. More and more it seems that he's just a spammer and that all of his posts should be deleted and he should be banned. I could be wrong, and if so I apologize, but looking at all of his posts in total, they just don't make any sense. [And many of them, such as this one, individually don't make any sense either.

If his posts are deleted, then any posts responding to him, including mine, could be deleted as well in order to keep the forum "cleaner". Just my opinion.

Cheers and Regards

Post Reply