72 replies to this topic

[MedEvil]

Most interesting!!!
The nativeEx developer has a problem with an inofficial version of the CAPI(V22) and blames the LiveXP developers for that, though those use CAPI(V15)!

[sbaeder]

Coooome on peeps , is there really need for the exchange of such niceties?

I mean, fights from time to time are a good thing because soon after they are over (quickly) you are able to better appreciate peace. \V/

A M E N ! ! !

[Galapo]

Hi Peter,

%SourceArch% and %TargetWOW64% can be different depending upon source and script selection.

%SourceArch% can be 64-bit, but 32-bit programs will run if WOW64 is present. Hence the need for a distinction.

Currently, it's up to each project to define %TargetWOW64% -- LiveXP does this with the OnProjectRun and then with '5 - WOW64_Basic.Script'. Maybe CAPI could set %TargetWOW64% to %SourceArch% if %TargetWOW64% is undefined?

Regards,
Galapo.

[Lancelot]

common variables for common apps:

History:
about targetwow64:

First it was used by Max_Real QNX on Leopard (at that times LiveXP did not support multi_arc but followed Max since it was the first I guess)

Max_Real QNX was using %Os_Type% and %x864% (not %SourceArch% %TargetWOW64%)
ex:
%Os_Type%=x86
%x864%=x86

Before it was too late, and since it was the early times of x64, in order projects not use uncommon variables with their "common apps scripts" a set of topics created - discussed.
Long story to short; In the end of topics there becomes an agreement saying:

%SourceArch% (from nativeex world by Peter's request)
%TargetWOW64%

will be used on projects.

Max_Real QNX followed the agreement making required changes on Leopard. As well as Jonf (on vistape-capi), yahoouk (multi7), LiveXP. (+Live98 beta)....

Edit:
setting value method of %TargetWOW64% (old name %x864%) introduced by Max_Real Qnx on Leopard and followed that way.

[pscEx]

Maybe CAPI could set %TargetWOW64% to %SourceArch% if %TargetWOW64% is undefined?

That would be a good solution!

Peter

[pscEx]

I changed my CAPI (added first code line)

[Arch_check]

If,Not,EXISTVAR,%TargetWOW64%,Set,%TargetWOW64%,%SourceArch%

If,#1,Equal,x86,If,Not,%TargetWOW64%,Equal,x86,Exit,"%ProgramTitle% requires WOW64 for PE x64/IA64"

If,#1,Equal,x64,If,%SourceArch%,Equal,x86,Exit,"%ProgramTitle% can only run on PE x64/IA64"

Peter

[Galapo]

Hi Peter,

[Arch_check] should be like this:

[Arch_check]

Set,%arch%,#1

If,#1,Equal,off,Set,%arch%,%SourceArch%

StrFormat,POS,%arch%,|,%multiarch%

If,%multiarch%,Equal,0,Begin

If,Not,EXISTVAR,%TargetWOW64%,Set,%TargetWOW64%,%SourceArch%

If,%arch%,Equal,x86,If,Not,%TargetWOW64%,Equal,x86,Exit,"%ProgramTitle% requires WOW64 for PE %SourceArch%"

If,%arch%,Equal,x64,If,Not,%SourceArch%,Equal,x64,Exit,"%ProgramTitle% can only run on PE x64"

If,%arch%,Equal,IA64,If,Not,%SourceArch%,Equal,IA64,Exit,"%ProgramTitle% can only run on PE IA64"

End

Else,Begin

StrFormat,POS,%arch%,%SourceArch%,%multiarch_test%

If,%multiarch_test%,Equal,0,Exit,"%ProgramTitle% requires different source architecture than current %SourceArch%"

End

Regards,
Galapo.

[pscEx]

Thanks!

For nativeEx projects that can wait until Pedro does it.

For me currently is importent that it does not prohibit standard nativeEx barebone project from successful build.

Peter

[sbaeder]

SO, I get lost on all this sometimes, but is Pedro still interested in being the "owner" of the CAPI, and if so, does he need "help" to keep it moving forward (at least for bug fixes like this) so that we really have a single "fork" (or a "common" Common API)

Seems like there has been a couple of things like this that could easily be added to the "master" copy if there was some sort of a thing...

Wouldn't that be better than each project having its own revision? (and all of them saying they are version 22 ?)

[Lancelot]

Hi sbaeder,

pedrole15 is away for a loooong while.
After this topic
http://www.boot-land...?...t&pid=78602
and after final release at post 605
he is away.

capi's main goal is providing a common method for application scripts to be used between projects. as a result all projects making its revision is bad. (in fact it was that way before untill pedrole15 united ).

Further, I agree with you, if there are api's specific to a project it should be outsite capi .

[sbaeder]

Thanks...I think what it does is FANTASTIC, and would really like to see some sort of a "repository" and version control system for things like this that are used a LOT across projects. I have seen the issues with Virtual Box, Avira, and others.

The Download area is a "start", but it's not really a revision management system...I'll noodle on that in the background and think about what we might be able to do.

ThANKS
Scott

[paraglider]

A revision management system would be a great idea for common scripts.

Also the ability in a link file to link to another web server would be useful so scripts can easily be shared amongst projects without each project having its own copy. Something like:

[main]
website=http://rescue.w07.net/Projects/Win7RescuePE/locale.script
link=%BaseDir%\Projects\common\locale.script
selected=True

[MedEvil]

Link files already exist. Check nativeEx_barebone.

[paraglider]

They only support links to files that already exist locally. You have no support for downloading the linked file automatically via winbuilder other than by downloading the containing project.

So for example if I just download nativex_win7 my link files point to files that do not exist locally unless I download the win7rescuepe project!

What I am asking for is that when I download nativex_win7 it also downloads automatically the win7rescuepe files if they don't already exist locally. Currently it cannot do that because the link files contain no reference to the originating web site.

Also online docs provide no description for link files.

[Lancelot]

Hi paraglider,
**

Also online docs provide no description for link files.

better to make a request topic.
**
here is an old request for link files to support downloading which I guess matches your idea.
http://www.boot-land...amp;showbug=229

[paraglider]

Yes. That matches my idea.

[MedEvil]

They only support links to files that already exist locally. You have no support for downloading the linked file automatically via winbuilder other than by downloading the containing project.

You should talk to Peter. As far as i know, nativeEx_barebone will download the nativeEx_core files upon run, if they do not already exist localy.

[pedrole15]

Hi sbaeder,

pedrole15 is away for a loooong while.
After this topic
http://www.boot-land...?...t&pid=78602
and after final release at post 605
he is away.

capi's main goal is providing a common method for application scripts to be used between projects. as a result all projects making its revision is bad. (in fact it was that way before untill pedrole15 united ).

Further, I agree with you, if there are api's specific to a project it should be outsite capi .

Hello all
I have been busy in my work last month
My last WB was WB78SP4 , there is probably a lot change since
I must re-learn WB before making something,
I'm not sure to have so much time as before for WB developpement

Pedro

[Lancelot]

Welcome back pedrole,

we are truely missing you , It is nice you have some time now.

[pscEx]

New issue with CAPI 25:

nativeEx_barebone fails when processing VirtualBoxNIC_AMD_PCNET.script.

Reason %arch%

Peter

[Lancelot]

nativeEx_barebone sucess when processing VirtualBoxNIC_AMD_PCNET.script when winbuilder080rev3 (Official wb080) used.

Issue highly probably with "winbuilder home" of psc, shortly psc (Peter).

[pscEx]

@Pedro!

Maybe that my environments reacts more sensible.

But here in [Expand_file1] %arch% is still undefined. I suggest that you set it to x86 if undefined.

Peter

[pedrole15]

Hi, Peter
I just download nativeEx_barebone and run with WB080 I don't get any error
No error with %arch% when processing VirtualBoxNIC_AMD_PCNET.script.

Pedro