19 replies to this topic

[pscEx]

To do some tests about the necessarity of RegAddBoot, I downloaded the actual Go2PDF.Script and inserted into nativeEx_barebone.
I used common_API version 19

Two questions:
On my x86 system with x86 source cd (xp_SP3_DE), the API command 'Arch' exited the script with the message:

%ProgramTitle% requires WOW64 for PE x64/IA64

The x64 suggestion is truelly wrong!
BTW: The API required %ProgramTitle% is not defined in the script. But defining it does not remove the x64 hint.

Are the lines

RegAddBoot,HKLM,0x1,SYSTEM\ControlControlSet\Control\Printers,DefaultSpoolDirectory,#$ptemp#$p\PrintSpool
RegAddBoot,HKLM,0x1,SYSTEM\ControlControlSet\Control\Print\Printers,DefaultSpoolDirectory,#$ptemp#$p\PrintSpool

correct?

BTW: On my local registry a corresponding entry to the first line does not exist.

Peter

[was_jaclaz]

BTW: On my local registry a corresponding entry to the first line does not exist.

Rest assured, you are not the only one that miss that key.

Under HKEY_LOCAL_MACHINE\SYSTEM there is:

• ControlSet001
• ControlSet002
• ...
• ControlSet00n

and

• CurrentControlSet

which is a redirection (only in a "live" Registry) to whatever ControlSet00n is set in HKEY_LOCAL_MACHINE\SYSTEM\Select

jaclaz

[MedEvil]

jaclaz are you sure about the ControlSet00n?
The way i unstood it, there are always only 3 controlsets in rotation.

[pscEx]

Rest assured, you are not the only one that miss that key.

Under HKEY_LOCAL_MACHINE\SYSTEM there is:

• ControlSet001
• ControlSet002
• ...
• ControlSet00n

and

• CurrentControlSet

which is a redirection (only in a "live" Registry) to whatever ControlSet00n is set in HKEY_LOCAL_MACHINE\SYSTEM\Select

jaclaz

You misunderstood.
I do not have the key

RegAddBoot,HKLM,0x1,SYSTEM\CurrentControlSet\Control\Printers,DefaultSpoolDirectory,#$ptemp#$p\PrintSpool

The ControlSet00n are nor relevant in that issue.

Peter

[cdob]

The way i unstood it, there are always only 3 controlsets in rotation.

Addional controlsets maybe archived, this are old, not used anymore.
Exampe ControlSet221: http://www.extermina...keys/msqpdxserv

I do not have the key

Yes, I don't have a Control\Printers\DefaultSpoolDirectory too.
There is a ControlSet001\Control\Print\Printers\DefaultSpoolDirectory.

[pscEx]

There is a ControlSet001\Control\Print\Printers\DefaultSpoolDirectory.

Peter

[was_jaclaz]

jaclaz are you sure about the ControlSet00n?
The way i unstood it, there are always only 3 controlsets in rotation.

You understood it wrong.


I never experienced personally anything further than Controlset005, but there are people who do :
http://www.forensicf...m...opic&t=4952


@psc

And the bad news is that I still do not understand, you posted about "ControlControlSet" and you also made it RED is it a variable of some kind?

jaclaz

[pscEx]

And the bad news is that I still do not understand, you posted about "ControlControlSet" and you also made it RED is it a variable of some

Correctly it should be
CurrentControlSet

Peter

[MedEvil]

Addional controlsets maybe archived, this are old, not used anymore.
Exampe ControlSet221:

If i ever happen to see 200+ controlsets in my registry, i do not try to fix, i buy a new computer!

[was_jaclaz]

@psc
So, you apparently failed to explain yourself , a bit different from a misunderstanding on my side.

@Medevil
Yep, I would also smash the old one, burn it and scatter it's ashes, you never know it could be contagious even when swithed off for good.



jaclaz

[pscEx]

@psc
So, you apparently failed to explain yourself , a bit different from a misunderstanding on my side.

I beg your pardon, Sir, that I always continue to write technical descriptions understandable for maintaining persons (In this case the post was mainly adressed to Lancelot / Pedrole15).
Doing that I often forget the readability for the end users.

[Lancelot]

Hi Peter,

some short answers:
* use latest capi
* Arch warning (suggestion) is right, to get arch lines work properly you need to update nativeex_barabone, add this line (probably to fundemantals script)

Set,%TargetWOW64%,%SourceArch%,PERMANENT

* go2pdf:
well I just try to install go2pdf to my hostos and found go2pdf is not compatible for x64 builds. So I just updated the script with minor modification about checking source.

I do not know go2pdf script well, I leave further changes and comments to galapo or others.

[Galapo]

Yes, I don't have a Control\Printers\DefaultSpoolDirectory too.
There is a ControlSet001\Control\Print\Printers\DefaultSpoolDirectory.

Maybe there's a bug in the script? I only have that key as well.

* Arch warning (suggestion) is right, to get arch lines work properly you need to update nativeex_barabone, add this line (probably to fundemantals script)

Set,%TargetWOW64%,%SourceArch%,PERMANENT

Or maybe nativeEx could now include the OnProjectRun script: http://livexp.boot-l...ojectRun.script.

Regards,
Galapo.

[pscEx]

Set,%TargetWOW64%,%SourceArch%,PERMANENT

OK, in nativeEx_barebone this is only necessary for including LiveXP apps having the Arch command.
For tests I'll include and after that I'll remove again.

But currently I do not understand the whole construction:

• For me %TargetWOW64% means a definition whether the target OS has a WOW64.
  Therefore I would assume a True / False or Yes / No, but there is a x86 / x64
• Why there is the redundancy that two variables have the same value?
  Or is it possible that %TargetWOW64% is changed inside the build, while %SourceArch% is constant?

* use latest capi

Look into the first lines of post #1

Peter

[Lancelot]

Hi Peter,

[*]For me %TargetWOW64% means a definition whether the target OS has a WOW64.
Therefore I would assume a True / False or Yes / No, but there is a x86 / x64

I opened a topic to ask your opinion long time ago. But on the topic you seem not to understand and responded not well. It seems now you understand so maybe better if you check the topic here to see where a miscomunication appears.
So I followed Max_Real QNX method (Set,%TargetWOW64%,%SourceArch%,PERMANENT) only Max was using %X864% instead of %TargetWOW64% . Since %X864% name was not clear I asked Galapo for a better name and we have %TargetWOW64%.

If x86 projects wants to have multiarchitecture scripts work in their projects, all they need to do is adding "Set,%TargetWOW64%,%SourceArch%,PERMANENT" to an appropriate script.

No need to change the method, most alive projects (vistapecapi, multi7os, livexp, vistaleopard) already uses it. Method works well and also forces admins to use common variable names instead of reinventing them.

[Lancelot]

[*]Why there is the redundancy that two variables have the same value?
Or is it possible that %TargetWOW64% is changed inside the build, while %SourceArch% is constant?

no redundancy, %TargetWOW64% is planned to be changed by a future possible wow64 script/option.
Well, recent posts indicates that there will be such an option soon which would change this value to x86 (if not x86 already ) if selected.

[pscEx]

If the %TargetWOW64% will be changed during the build, there is of course no redundancy.

And do I understand correct:
If the target's %SourceArch% is x64, and there will be a WOW for x86, then the target supplies processing of x86.
Therefore %TargetWOW64% = x86?

But %TargetWOW64% is primarily set to %SourceArch%, in this case to x64.
What is triggered, when the value changes from x64 to x86?

Or does that simply mean: Add WOW64 support to the target PE?
And if the WOW64.script is not selected, there is something wrong with the ??? script. It cannot run in the PE.

That can much more easier be checked by Verify.
(Verify checks all scripts, the changed %TargetWOW64% is unknown for scripts 'before' the WOW64Support script).

Peter

[Lancelot]

And do I understand correct:
If the target's %SourceArch% is x64, and there will be a WOW for x86, then the target supplies processing of x86.
Therefore %TargetWOW64% = x86?

no,
there do not have to be WOW64

you can make a PEx64 build without having wow64 (%TargetWOW64% = x64)
you can make a PEx64 build with having wow64 (%TargetWOW64% = x86)

But %TargetWOW64% is primarily set to %SourceArch%, in this case to x64.
What is triggered, when the value changes from x64 to x86?

As written many times before, it is triggered by an enabled wow64 script/option.

[pscEx]

Sorry, I edited during you replied.

I think I do not understand the underlying ideas.

So treate these last posts just as my brainstorming.

Peter

[Lancelot]

That can much more easier be checked by Verify.
(Verify checks all scripts, the changed %TargetWOW64% is unknown for scripts 'before' the WOW64Support script).

a small reply to the edit:
For some probably "vital" scripts, verify would be used. Besides it is obviously difficult (and boring) to re-set all apps scripts to make a build with different architecture. As a result (after a brainstorm) current mechanism used.