@paragliderI don't see it. Only use of targetwow64 in commonapi is in Arch_Check:
the result of arch check triggers the behaviour of require_file
giving example:
before there were any multiarchitecture projects, following was sufficient for a 32bit application script
[Process]
unpack,,%setupFile%,True
require_file,msvbvm60.dll
but what will happen on x64 build (none wow64) with these codes,
64bit version of msvbvm60.dll will be extracted with also 32bit application.
1) 32bit application will not work because without wow64 it cannot
2) even if there is wow64, 32bit version of msvbvm60.dll does not exists since copied one by script is 64bit.
to solve 1st problem, it is obvious a variable needed to determine target pe behaviour to x86 applications, and psc also admits that fact today by reinventing a variable that is already used on all projects. (=> you logically can not agree with psc) (besides none of psc project have feature to support wow64, if package was for other projects, than follow other projects
common variable, if package for nativeex only, than does not need ===> nooo, better to implement a self made redundant variable silently inside other projects if they get the fish, this is the way he likes)
I asked this to Max_Real Qnx since at that time Leopard was the only project that supports multiarchitecture (well livexp was also building multiarch that times, but not public, according to gentleman rules I asked Max Real QNX), and he invent a new variable %x864% with a method of determining this variable which we use even today. It was you who said %x864% is confusing, hence variable name changed to %TargetWOW64% which is more meaningful. It seems you forgot old topics why this variable (and following api) needed where you take part. Well they are old topics because since things made there is
NO issue, only 1 man making annoyance.
Max model is simple,
at 1st steps of building, after finding sourcearch set TargetWOW64 equal to sourcearch
PERMANENTLYSet,%TargetWOW64%,%sourcearch%,Permanent
on x86 builds, value stable x86, hence for x86 projects value can be easly added to script project as a stable value.
on none x86 builds, if there is another script that adds wow64 ability to the target build, than this script will change %TargetWOW64% value x86
PERMANENTLYhence following build is aware the condition.
First problem solved,
with this solution following works half
[Process]
If,%TargetWOW64%,Equal,x86,Begin
unpack,,%setupFile%,True
require_file,msvbvm60.dll
End
above still gets msvbvm60.dll x64 version from source.
Since we have a variable now, there might be following solution by inventing require_filewow64 api
[Process]
If,%TargetWOW64%,Equal,x86,Begin
unpack,,%setupFile%,True
IF,%sourcearch%,Equal,x86,require_file,msvbvm60.dll
IF,Not,%sourcearch%,Equal,x86,require_filewow64,msvbvm60.dll
End
well, above does not look nice and simple.
Instead api call arch idea found and developed by Galapo which is much much much superior than above.
as a result to make a 32bit application script that supports multiarchitecture projects following change
[Process]
unpack,,%setupFile%,True
require_file,msvbvm60.dll
===>
[Process]
arch,x86
unpack,,%setupFile%,True
require_file,msvbvm60.dll
fits. I hope you know can see the direct relation between arch and %targetwow64%
One should be an idiot to object such a good solution. Truely it was that idiot who told me to practice a solution for the sitation by telling me he would follow if okey. Well it is working okey but after sometime this idiot decide to sabotage all projects by either wb coding or misinformed objections, usually lieing, and practicing games to insert his variables to other projects (ex: this topic package) . Since these actions are supported by also Nuno, Long while ago I decide no need to object anymore around. But after my absance this idiot intentionally writing WRONG and LIEING information around with naming me for a loooong while forced me to write this post. At least this topic proves that this idiot now accept (after all objections in past) there is a need of a new variable in his project, but instead of using %TargetWOW64% which is used by ALL projects, reinventing another one just to be cooparative (check a cooparative topic around that demonstrates how cooparative (sarcasm) and childish (hi JFX, I remember you) behaviour this idiot have. (well idiot is from above post of psc, not my personal choice, I prefer better descriptive words but decide to follow the one he prefers calling himself)
anyway,
I contact to all admins,
Administrators of multi-architecture projects agreed to the solution using %TargetWOW64% by understanding why needed, only 1 not agreed saying his project not need that saying it is redundant which shows he could not either a- understand b- did not like some other find a fundemantal variable name than him. (practically psc also right, nobody use that projects for x64 builds, and win7 parasite (not project) part naturally does not support x64, hence no problem for him that time)
Administrators of single architecture projects add %TargetWOW64% variable setting to x86 to support multiarchitecture scripts.
ps: I was the
only admin of win7rescue project that times, and made adjustments to win7rescue, someone should remember times of annoyance when people write they need a method to write app script to fit all projects. One should be idiot to take maintance responsibility of a project and keep it with its so far found missings and bugs reported to its topic.
This opened gates to developers making multiarchitecture scripts.
You can remember that above solutions created without existance of a wow64 script demanded by me having a farsight thinking, but we did not wait so long, a hero come from Germany called JFX who made wow64 scripts for LiveXP and later pe2/3 world, and scripts with arch lines worked with pex64wow64 builds nicely :>:>.
Till than, a set of improvments made on arch since we have a practice on pex64wow64 builds by the help of JFX script. Differences of arch section on capi's are due to capi versions (revisions). When project admins or end users update their capi (I do not mean capiex, instead of capiex nativeexapi should be more proper but lie is a habit hard to leave), they will have required improvments.
I hope not to see further LIEING comments about what I've done so far, but it is only a fake hope, I well know the beheviour of liers around. In the past I worked hard to solve issues of apps scripts to share between projects (which i guess i was the only one), starting work with JonF hence made a perfect syncronisation with VistaPE-Capi to share scripts and when Joshua around with Win7Rescue. Later with new multiarchitecture projects, I also worked hard on developing above perfect solution for the new generation multiarchitecture scripts with Galapo and Max and ctmag. (psc ignored that times saying he does not need that). With PaPeuser helping on testing on win7pese x64 builds also made required changes on a set of apps scripts to easly share between projects. I am happy to see scripts working nicely and so far made adjustments fits all conditions too. It is a good story of success with team work.
and reminding, what i wrote above is not about current topic's package.
This package, besides lieing goal, demonstrate how idiot brain work (for the ones who carelfully reads) on dictating other projects some permanent variables and incompatible methods to insert his scripts to other projects.
It is usual topic games by usual topic gamer regulars, changing subject to something else (like targetwow64 etc) instead of talking about topic (package), and to do this replying with misleading and lieing posts to point Lancelot, LiveXP or anyother in future.
ex: since galapo comment on saying %targetwow64% is redundant, check how topic goes, a good demonstration.
Because of misinforming topic that have goal to increase excitment, I get some communication from some users that does not check what is inside asking me how to use.
After checking i well explained them this is not what they expect, it is only fooling others with exciting title.
Shortly:
what package does can be simply made by: on vistape-capi, cache the build just before OtherOS, and make other builds with this caching continuing with changing scripts after OtherOS.
(well this is what i do easly more than a year on livexp , thanks to olegpov for pointing)
with using bad workaround, some further improvments maybe done by replaing registry on pe2/3 builds.
Main improvments with pe2/3 should be made to shift settings from mainconfiguration to somewhere near end (create iso) IF admins of pe2/3 projects interested in such a cache solution, which i believe would be nice. There are logical reasons for making these settings at begining with initial design of nightman. Better pe2/3 project admins comment on such needs on these changes. (!!)
Above package not needed at all if wb could process faster than slower. It simply caches build at some point, and do processing later. This is also what i do personally on livexp for my testings since olegpov pointed the issue a year ago, but practically not needed much. But since wb is slower and pe2/3 projects bigger with their files and registry, need of a workaround arise (like caching, or using ready reg files, or using smaller script adjustments, a set of scripting techniques etc. ) by end users since they can not fix wb. It is sad (well truely comic) to see wb development instead of fixing their builder, trying to workaround like normal end users.
As usual Well done (->sarcasm)
Additionally:
there were previous posts about another incompatibilty again lieing accusing livexp. Truely livexp took nightman model for adding grub4dos bootloader, hence supporting grub4dos scripts around. We did not put an OtherOS folder to project to demonstrate, we only followed footsteps of nightman to get a compatible solution to all pe2/3 projects , instead of reinventing and dictating them. Since than livexp is the only pe1 project that supports grub4dos scripts. If something compatible to pe2/3 on this manner, it is also compatible to livexp unless someone forces conditions to make something incompatibleç
Further, I may get some personal posts here which would as usual only serve to distracts facts written on this post and some others, by lieing, misinforming, misleading info to misinform (like previous post, facts are covered by pretending his usage of inserting a redundant variable by setting permanent, truely %targetwow64% used directly on build scripts (not apps) and this can not be covered by capi, a
redundant line to capi only added to fit 1 project admin unlogical objection ) or by personal comments which are being done so far. (=>post games) . Have fun on reading them.
@pscSTOP lieing using my name and STOP using my name with lieing to distract a subject.
I guarentee you, Wait sometime, be sure there MAY be some other project admins or users which you will be able to fool, lie, push out etc. like before me. For a loooong time I do not join anymore to wb developement topics or your shity project topics.
Pretend to be like a mature man.
