35 replies to this topic

[pscEx]

Lancelot currently is working to smooth several outstanding x64 issues.

One logical issue is:
Depending on the source CD (x86 or x64) different files have to be copied to the %target%

One of these 'copied' is the WB command 'ExtractFile'.

To help here, I made the following changes to nativeEx:

• !Fundamentals.Script detects the type of the source CD and writes it into the variable %ProjectArchitecture% (already used by Lancelot in individual scripts)
• !Fundamentals.Script got an additional section:
  

  [XExtract]
  
  //ScriptFile,folder,file,target
  
  StrFormat,REPLACE,#3,.,_%projectarchitecture%.,%nFile%
  
  ExtractFile,#1,#2,%nFile%,#4
  
  If,EXISTFILE,#4\#3,FileDelete,#4\#3
  
  FileRename,#4\%nFile%,#4\#3

What the developer has to do (sample Gavotte's RAM disk in CMD.Script)

• Attach the two versions of RRamDisk.sys as RRamDisk_x86.sys and RRamDisk_x64.sys
• To extract, do a call to !Fundamentals.Script:
  

  Run,%FundamentalsScript%,XExtract,%ScriptFile%,Folder,RRamDisk.sys,%target_sys%\drivers

@Pedrole15:
What about to include in API:

XExtract=Run,%FundamentalsScript%,XExtract,%ScriptFile%

Peter

[Lancelot]

Hi Peter,

For now I use %projectarchitecture% on individual scripts to make scripts not dependent on other scripts.

For a long while VistaPE Leopard uses %Os_Type% permanent variable for its scripts which supports both x86 and x64,
In order not to cause redundancy, I Followed Mex_Real_Qnx and now LiveXP supports VistaPE Leopard's apps scripts by adding 2 permanent variables to script.project :

%Os_Type%=x86

%x864%=x86

and both values are already used on some apps script on LiveXP (some examples: Recuva.script, dependency_walker.script , jedi_dependencyviewer.script)


For my x64 tests I have another individual script:

[Process]

....

If,ExistFile,%SourceDir%\AMD64\TXTSETUP.SIF,Run,%scriptfile%,SetAMD64

If,ExistFile,%SourceDir%\I386\TXTSETUP.SIF,Run,%scriptfile%,SetI386



[SetI386]

set,%target_win%,%TargetDir%\I386,Permanent

set,%target_sys%,%TargetDir%\I386\System32,Permanent

set,%source_win%,%SourceDir%\I386,Permanent

set,%source_sys%,%SourceDir%\I386,Permanent

set,%Os_Type%,x86,Permanent

set,%x864%,x86,Permanent



[SetAMD64]

set,%target_win%,%TargetDir%\AMD64,Permanent

set,%target_sys%,%TargetDir%\AMD64\System32,Permanent

set,%source_win%,%SourceDir%\AMD64,Permanent

set,%source_sys%,%SourceDir%\AMD64,Permanent

set,%Os_Type%,x64,Permanent

Set,%x864%,amd64,Permanent

having %OS_Type% permanent variable makes things smooth,
It is easier to ask any project admin to add 2 values to script.project to support multi architecture scripts

Giving example:
on dependency walker script of LiveXP we have this line:
Unpack,Folder,depends22_%Os_Type%.zip,True

And for RRamDisk.sys this should work
Extract,%ScriptFile%,Folder,RRamDisk_%Os_Type%.sys,%target_sys%\drivers


maybe !fundemantals.script can use somethings similar to above code ?

[pscEx]

With the above post I wanted to simplify extracting attachements and put the %ProjectArchitecture% query into the core, inspite it creates some redundancy.

One of these 'copied' is the WB command 'ExtractFile'.

To help here, I made the following changes to nativeEx:

But maybe we should consider things from the very beginning.

I understand

• %Os_Type% is the architecture of the host
• %x864% is the architecture of the PE which currently is built (architecture of the source CD)

In nativeEx the following host values are defined:

• %HostOS% (currently XP / W2003): LiveXP %Os_Type%
• %Host64Bits% (True / False)

And these PE / source CD values

• %OS% (currently W2000 / XP / W2003)
• %Source64Bits% (True / False)
• %SourceArch% (currently x86 / x64 / i64): LiveXP %x864% (w/o i64)

EDIT: changed wrong variable names to correct ones
are queried from the flag files of the source CD (Win5????)

In my opinion for a clean and structured build no more variables are necessary.

For me easy, for you may it complicate some things:

In nativeEx there are no architecture depending scripts like Recuva.script, dependency_walker.script , jedi_dependencyviewer.script

When I understood everything correct, my suggestion:

I rebuild the changes from post #1 to the above mentioned variables.
You try to use them in your scripts.
If there are any issues, we find a way to solve.

Else: Tell me what I see wrong

Peter

[Lancelot]

For me easy, for you may it complicate some things:

using this complicate things !!
Extract,%ScriptFile%,Folder,RRamDisk_%Os_Type%.sys,%target_sys%\drivers

Else: Tell me what I see wrong

Lets start with these 2 values:

[*]%Os_Type% is the architecture of the host

NO, %Os_Type% is the architecture of the source CD

[*]%x864% is the architecture of the PE which currently is built (architecture of the source CD)

NO, it shows if an application can work on the build.
when source CD is x86:
%x864% value is x86
when source CD is x64:
%x864% initial value is amd64
If project have wow64 script, than its value changed to x86 by this script.


I hope you understand ?

[Lancelot]

Adding:

when source CD is x64:
%x864% initial value is amd64

I feel having initial value of %x864% be x64 better when source CD is x64, I just checked and it doesnt effect leopard too which as a result I feel Mex_Real_Qnx agree with such a change. what you think ?

[pscEx]

NO, %Os_Type% is the architecture of the source CD

Now I'm completelly feeling to be a fool:
In my current LiveXP project (actualized some minutes ago), %OS_Type% is set in:

script.project(86): %Os_Type%=x86
Apps\File Tasks\doublecmd.script(31): If,Not,ExistVar,%Os_Type%,Set,%Os_Type%,x86
Apps\HD Tasks\File Undelete\Recuva.script(28): If,Not,ExistVar,%Os_Type%,Set,%Os_Type%,x86
Apps\System\Debug\dependency_walker.script(34): If,Not,ExistVar,%Os_Type%,Set,%Os_Type%,x86

How does the source CD set %Os_Type%
Similar with %x864%

script.project(87): %x864%=x86
Apps\System\Debug\jedi_dependencyviewer.script(30): If,Not,ExistVar,%x864%,Set,%x864%,x86
Apps\System\Debug\jedi_toolhelpviewer.script(30): If,Not,ExistVar,%x864%,Set,%x864%,x86

How does the source CD set %x864%

Peter

[pscEx]

Adding:
I feel having initial value of %x864% be x64 better when source CD is x64, I just checked and it doesnt effect leopard too which as a result I feel Mex_Real_Qnx agree with such a change. what you think ?

Cross posting.

Let's first resolve the issue of my latest post.

Peter

[Lancelot]

Peter,

**
currently LiveXP project only supports x86 source.

so i only add %Os_Type%=x86 and %x864%=x86 to script.project.


When LiveXP supports x64 source, as i wrote before this (or similar) would be added:

For my x64 tests I have another individual script:

[Process]

....

If,ExistFile,%SourceDir%\AMD64\TXTSETUP.SIF,Run,%scriptfile%,SetAMD64

If,ExistFile,%SourceDir%\I386\TXTSETUP.SIF,Run,%scriptfile%,SetI386



[SetI386]

set,%target_win%,%TargetDir%\I386,Permanent

set,%target_sys%,%TargetDir%\I386\System32,Permanent

set,%source_win%,%SourceDir%\I386,Permanent

set,%source_sys%,%SourceDir%\I386,Permanent

set,%Os_Type%,x86,Permanent

set,%x864%,x86,Permanent



[SetAMD64]

set,%target_win%,%TargetDir%\AMD64,Permanent

set,%target_sys%,%TargetDir%\AMD64\System32,Permanent

set,%source_win%,%SourceDir%\AMD64,Permanent

set,%source_sys%,%SourceDir%\AMD64,Permanent

set,%Os_Type%,x64,Permanent

Set,%x864%,amd64,Permanent

**

These lines added to make scripts support other x86 projects that do not have %Os_Type% and %x864% variable (vistapecapi, nativeex_barabone, naughty etc.)

Apps\File Tasks\doublecmd.script(31): If,Not,ExistVar,%Os_Type%,Set,%Os_Type%,x86
Apps\HD Tasks\File Undelete\Recuva.script(28): If,Not,ExistVar,%Os_Type%,Set,%Os_Type%,x86
Apps\System\Debug\dependency_walker.script(34): If,Not,ExistVar,%Os_Type%,Set,%Os_Type%,x86
Apps\System\Debug\jedi_dependencyviewer.script(30): If,Not,ExistVar,%x864%,Set,%x864%,x86
Apps\System\Debug\jedi_toolhelpviewer.script(30): If,Not,ExistVar,%x864%,Set,%x864%,x86

In future when all projects have %Os_Type% and %x864%, these lines wont be necessary.

[pscEx]

So, logically we are back here:

In nativeEx the following host values are defined:

• %HostOS% (currently XP / W2003): LiveXP %Os_Type%
• %Host64Bits% (True / False)

And these PE / source CD values

• %OSType% (currently W2000 / XP / W2003)
• %S64Bits% (True / False)
• %SArch% (currently x86 / x64 / i64): LiveXP %x864% (w/o i64)

are queried from the flag files of the source CD (Win5????)

In my opinion for a clean and structured build no more variables are necessary.

When I understood everything correct, my suggestion:

I rebuild the changes from post #1 to the above mentioned variables.
You try to use them in your scripts.
If there are any issues, we find a way to solve.

Please think about the suggestion!

Peter

[Lancelot]

So, logically we are back here:

Not fullly, if it was me only who makes a pex64 project, I would be glad to follow your named variables. I dont care what the variable name is or who gave the name.

But Mex_Real_Qnx 's leopard project (which is to only alive project that builds PEx64) actively uses %Os_Type% instead of your %SArch% in many scripts, and %SArch% is not a permanent variable on nativeex.

Please think about the suggestion!

Thinking again, why not add
Set,%OS_Type%,%SArch%,Permanent
to !Fundemantals.script ????

[pscEx]

Thinking again, why not add
Set,%OS_Type%,%SArch%,Permanent
to !Fundemantals.script ????

Black and White (w/o any gray)
If a script needs it's own (changed) value of %SArch% stored in %OS_Type%: Yes
If %OS_Type% is only a redundant copy of %SArch%: No

Peter

[Lancelot]

If %OS_Type% is only a redundant copy of %SArch%: No

%OS_Type% is not a redundant copy, because %OS_Type% is permanent, %Sarch% is not.

If a script needs it's own (changed) value of %SArch% stored in %OS_Type%: Yes

Than yes

as an example,
I use same dependency walker script on both my livexp builds and my pex64 tests, %Os_Type% value changes .
Unpack,Folder,depends22_%Os_Type%.zip,True

[pscEx]

%OS_Type% is not a redundant copy, because %OS_Type% is permanent, %Sarch% is not.
Unpack,Folder,depends22_%Os_Type%.zip,True

OOPS! I made a mistake when explaining:
%OSType%, %S64Bits%, %SArch% are local values.
When they are assigned, different PERMANENT values are defined:

If,ExistVar,%OSType%,Set,%OS%,%OSType%,PERMANENT

If,ExistVar,%S64Bits%,Set,%Source64Bits%,%S64Bits%,PERMANENT

If,ExistVar,%SArch%,Set,%SourceArch%,%SArch%,PERMANENT

(I'll edit the above post)
Maybe %OS% should be replaced by %SourceOS%

Peter

[Lancelot]

If,ExistVar,%SArch%,Set,%SourceArch%,%SArch%,PERMANENT[/code]

Yes i lately noticed that too,

Than i would ask to change this lines

If,ExistVar,%SArch%,Set,%SourceArch%,%SArch%,PERMANENT

Else,Set,%SourceArch%,nil,PERMANENT

=====to this======>

If,ExistVar,%SArch%,Set,%OS_Type%,%SArch%,PERMANENT

Else,Set,%OS_Type%,nil,PERMANENT

Reason:
nativeex use SourceArch only with !fundemantals.script, leopard use %OS_Type% on many scripts. It is easier to make the change with nativeex not to cause redundancy, is it too hard to change ??? or do we need api because we cant agree with a single script change

[pscEx]

nativeex use SourceArch only with !fundemantals.script, leopard use %OS_Type% on many scripts. It is easier to make the change with nativeex not to cause redundancy, is it too hard to change ??? or do we need api because we cant agree with a single script change

First: API not necessary!
Second: For me, it is a question of 10 seconds to change, and some other 1 minute to upload.
But inspite of that I want to ask Max, whether he spends maybe one hour to change.
Reason: %OS_Type% does not tell the user about 'Source' (Remember my post where I misunderstood as host OS).

If Max disagrees, no problem for me to use his %OS_Type%

Peter

[Lancelot]

@psc

I fully agree with you, I like %SourceArch% more than %OS_Type%

if Mex_Real_Qnx agrees but dont have time, I can spend 1 hour to change his project
I need to check Mex_Real_Qnx's project and things ludovici have done, need time.
ps: outoftopic: I believe At some point vistaleopard and vistacapi will unite in future....

Further:

Have you understand %x864% ?

Edit: capi->vistacapi, leopard-->vistaleopard

[pscEx]

Have you understand %x864% ?

Not really
Maybe it is logically the same as nativeEx's %Host64Bits% (Or %Source64Bits% ?)
Peter

[Lancelot]

Let me explain step by step not to cause misunderstandings.

First:
x86 applications works on PEx86

x64 applications works on PEx64
x86 applications CAN work on PEx64 if wow64 exists on PEx64

Example:
jedi_dependencyviewer is a x86 application (no x64 version exists), and can work on PEx64 if wow64 exists on PEx64
how to understand if wow64 exists ??

To keep post short, I hope so far you understand ? If it is okey next post is for solution.

[pscEx]

x86 applications CAN work on PEx64 if wow64 exists on PEx64

Also to prevent misunderstandings: This question is seriously meant: I'm novice in x64, but in my opinion:
If you are working on x64 OS, you automagically have Wow64
If not, under what conditions you get or not get it?

EDIT: Maybe I got it! Is the question to have Wow64 on the PE?

Peter

[Lancelot]

If you are working on x64 OS, you automagically have Wow64 ???????

No, it is not true for PEx64.

There are some trials to make wow64 work on PEx64, for now no success. But in future.......

Even after success, some may prefer not to have wow64 on PEx64 (optionality :>)


I hope example on my previous post is more clear now ?

[pscEx]

There are some trials to make wow64 work on PEx64, for now no success. But in future.......

Cross posting again.

This issue seems to be interesting to be handled in nativeEx
(Last Wednesday I got a 64 bit XP CD ...)

Give me some Latin weeks days time to check.

My dream now is that 'nativeEx gets everything from source CD only' can also include x64 or i64 ...

I hope that the dream does not become a nightmare ...

Peter

[Lancelot]

It wont be a nightmare at least for PE1x64, It is fun for me to make some tests with PE1x64, so far thanks to you and olegpov and paraglider, Now things works better :>. (Also Thanks to saydin77 a loooooooooooot)

ps: no comment about i64

for now lets focus on need for %x864% not to cause a redundant variable, I guess you now understand wow64 is only an option for PEx64 builds.

To solve the issue for scripts, we need another permanent variable, %x864% is created by Mex_Real_Qnx, besides it is not widely used so it will be easy to change its name. Better to decide as early as possible.

current usage for nativeex would probably sth like this (from Mex's design):
at !Fundamentals.script
set,%x864%,%SourceArch%,Permanent

and if project dont have a wow64 script or an option, than %x864% value stays the same with %SourceArch%.

lets say we have !wow64.script that makes PEx64 build have wow64, than the script would contain
set,%x864%,x86,Permanent


As a result:
on an x86 app script this line would nicely work for builds with
a)PEx86
b)PEx64
c)PEx64 with wow64

If,Not,%x864%,Equal,x86,Exit,"%ProgramTitle% requires WOW64 for PEx64"

Question is:
I hope you understand the need of %x864% ?
if yes, than I guess we need a better name for %x864% , what you suggest ?

[pscEx]

I hope you understand the need of %x864% ?

Sorry Lancelot: Currently No!

But it has been a long day including C++ resShort etc. Maybe I'm too tired now.
Tomorrow I'm going to try to understand again.

I'm sure that finally we'll find a logically correct solution w/o redundancies which does not require any (or only some small) changes in the current projects.

Peter

[Lancelot]

I'm sure that finally we'll find a logically correct solution w/o redundancies which does not require any (or only some small) changes in the current projects.

Okey, tomorrow .
Good night.

[yahoouk]

Dear all,

I'm working with 32+64 bits Vista,2k8,Windows7 at the moment.
Almost finish and clearing the scripts now.
Can you wait a few days and check with mine to progress again?

Thanks,

YahooUK