Jump to content











Photo
* * * * * 1 votes

[Package] PEFactory


  • Please log in to reply
46 replies to this topic

#26 sbaeder

sbaeder

    Gold Member

  • .script developer
  • 1338 posts
  • Location:usa - massachusettes
  •  
    United States

Posted 12 June 2010 - 06:53 PM

BTW2: e.g. the "Grub" issue is respected by adding a predefined / built menu.lst

I guess it all depends on if there are other "packages" added to a project...In other words, is the intention of a winbuilder "project" and the things that get added to it just a way to make a single PE environment - OR is it to also make a "multi-boot" image, where we can easily add in other things...

I hope it is eventually the latter - although I can see where some careful organization is needed...Look forward to seeing what comes out of this...

Scott

#27 Galapo

Galapo

    Platinum Member

  • .script developer
  • 3841 posts
  •  
    Australia

Posted 15 June 2010 - 11:21 AM

[quote name='psc' post='102088' date='Jun 11 2010, 07:16 AM']Thell the package some fundamental values:
(current "state of art":thumbup:
[codebox]Run,%BootManagerScript%,%ProjectTitle%[nativeEx_barebone]Set,%x8664%,%SourceArch%,PERMANENTSet,%ProjectType%,1,PERMANENT...[/codebox][/quote]Hi Peter,To me, there seems some redundancy here. Your new variable %x8664% seems to do the same thing as existing %TargetWOW64%. Currently, %TargetWOW64% is used by other projects except nativeEx, so no need to introduce another variable. Just change to:[code][nativeEx_barebone]Set,%TargetWOW64%,%SourceArch%,PERMANENT...[/code]Also, new variable %ProjectType% seems to do the same thing as existing %API_TYPE%. Currently, %API_TYPE% is either set by api itself or, better, if project sets it at script.project as is mostly the case. So no need again to introduce another variable, as %API_TYPE% has been existing on api for a long time now. Just change to:[code][nativeEx_barebone]Set,%API_TYPE%,1,PERMANENT...[/code]

Regards,
Galapo.

#28 Galapo

Galapo

    Platinum Member

  • .script developer
  • 3841 posts
  •  
    Australia

Posted 15 June 2010 - 11:27 AM

OR is it to also make a "multi-boot" image, where we can easily add in other things...


Currently, that's the easily the case with the DefineBootSector script of LiveXP and other similar scripts of a couple other projects. PEFactory hasn't implemented support as far as I can tell for the current existing dynamic generation of menu.lst of other projects. Peter might have that in the works.

Regards,
Galapo.

#29 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 15 June 2010 - 11:51 AM

To me, there seems some redundancy here. Your new variable %x8664% seems to do the same thing as existing %TargetWOW64%. Currently, %TargetWOW64% is used by other projects except nativeEx, so no need to introduce another variable.


Thanks for your hints!

You are nearly right! In several projects %x8664% is the same as %SourceArch%!
IMO there are also redundances between %SourceArch% and %TargetWOW64%. That is the reason for nativeEx NOT to use %TargetWOW64%.

I am not sure that ALL existing projects have %TargetWOW64% defined.
And because the PEFactory is intended to "make no assumptions about definitions in the parent project", I created the "redundant" variable.
Set,%x8664%,%SourceArch%,PERMANENT

Also, new variable %ProjectType% seems to do the same thing as existing %API_TYPE%. Currently, %API_TYPE% is either set by api itself or, better, if project sets it at script.project as is mostly the case. So no need again to introduce another variable, as %API_TYPE% has been existing on api for a long time now.

No, that's different! Inside PEFactory there is distinguished between:

XP > %ProjectType%=1
Vista > %ProjectType%=2
Win7 > %ProjectType%=4

Additionally: It is unbelievable, but there exist projects not using the API, e.g. nativeEX_BSOR.
Here %ProjectType%=8 is much better understandable than %API_Type%=<what?>

Peter

#30 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 15 June 2010 - 12:02 PM

Peter might have that in the works.

Correct! :thumbup:

Will come after "FromCD / FromRAM"

To be published (depending on until unknown issues) late this week or next week.

Peter

#31 Galapo

Galapo

    Platinum Member

  • .script developer
  • 3841 posts
  •  
    Australia

Posted 15 June 2010 - 09:23 PM

Hi Peter,

I made a mistake. It should have been:

&#91;nativeEx_barebone&#93;

If,Not,ExistVar,%TargetWOW64%,Set,%TargetWOW64%,%SourceArch%,PERMANENT

...

That's because %TargetWOW64% can be set by another script, ie when wow64 exists under a 64-bit PE.

%TargetWOW64% is used in VistaPEcapi, Leopard, Win7PE, Win7PESE, Win7Rescue, LiveXP. I know of one exception: nativeEx. I think it is better if you use an already existing used thoughout other projects, rather than forcing the use of a new nativeEx variable that is essentially duplicating function.

Regards,
Galapo.

#32 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 16 June 2010 - 12:06 PM

Hi Peter,

I made a mistake. It should have been:

&#91;nativeEx_barebone&#93;

If,Not,ExistVar,%TargetWOW64%,Set,%TargetWOW64%,%SourceArch%,PERMANENT

...

That's because %TargetWOW64% can be set by another script, ie when wow64 exists under a 64-bit PE.

%TargetWOW64% is used in VistaPEcapi, Leopard, Win7PE, Win7PESE, Win7Rescue, LiveXP. I know of one exception: nativeEx. I think it is better if you use an already existing used thoughout other projects, rather than forcing the use of a new nativeEx variable that is essentially duplicating function.

Regards,
Galapo.

Bold in the quote made by me.

Thanks, Galapo. This again proofs that nativeEX_??? projects are the only projects which claim and perform "Take everything from the source CD only".
No cross-links, no additional defines etc.

BTW: I'm rather familar with Win7RescuePE, and therefore I have to contradict.
The ONLY references to %TargetWOW64% seem to be a remainder of a copy of a copy of ...
History14a=Lancelot %SourceArch% %TargetWOW64% lines added to be compatible to new generation apps scripts that contain both x86 and x64 executables/dll etc. &#40;ps&#58; Win7RescuePE is a 32bit project, as a result both values are x86&#41;
and
%TargetWOW64%=x86
For me, currently it is not explainable, how a Lancelot's change came into a Joshua's project.
That reminds me on an old pasch's post "strange admin behaviour" ...

Excuse me as Dinosaur programmer:
When an app defines a variable and never uses the value of that variable (I call it WOM Write Only Memory):
Does the app really intend to WORK with that variable?
Maybe we here have the same programmer's different level like in the famous case "WinBuilder must be able to change the value of a constant (%ISOFile%)".

I understand that it seems to be difficult to propagate a "strict and clean package" here. The reactive lobby is too powerful.

Allow me to do further development of PEFactory on nativeEx_Win7 / Win7RescuePE only. That makes it much easier for me.
And that also closes my initial question for comments, suggestions, etc.

In my host I also let work nativeEX_barebone with PEFactory. But since I'm declared as idiot, nativeEx_barebone is my private enjoyment and not presented to the publish.
Therefore: Do not worry about VistaPEcapi, Leopard, Win7PE, Win7PESE, Win7Rescue, LiveXP. They all can work like before!

Peter

#33 paraglider

paraglider

    Gold Member

  • .script developer
  • 1739 posts
  • Location:NC,USA
  •  
    United States

Posted 16 June 2010 - 12:15 PM

I think Psc is correct. Targetwow64 does not seem to be used other than getting set. SourceArch is the one that seems to be used.

#34 Galapo

Galapo

    Platinum Member

  • .script developer
  • 3841 posts
  •  
    Australia

Posted 16 June 2010 - 12:17 PM

Thanks, Galapo. This again proofs that nativeEX_??? projects are the only projects which claim and perform "Take everything from the source CD only".
No cross-links, no additional defines etc.

Yes, that's exactly the point: wow64 can be taken from source CD and built into x64 PE. Hence the need for the variable to determine if wow64 exists so that CAPI require_file calls etc. for a 32-bit app will extract the wow64 files and not 64-bit files.

Regards,
Galapo.

#35 paraglider

paraglider

    Gold Member

  • .script developer
  • 1739 posts
  • Location:NC,USA
  •  
    United States

Posted 16 June 2010 - 12:27 PM

I don't see it. Only use of targetwow64 in commonapi is in Arch_Check:

win7pe version / livexp:

[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

vistape capi version:

[Arch_check]
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"

#36 Galapo

Galapo

    Platinum Member

  • .script developer
  • 3841 posts
  •  
    Australia

Posted 16 June 2010 - 12:38 PM

%TargetWOW64% is most needed for CAPI. It is used to determine if a program is compatible with PE architecture and/or existance of wow64.

Because %TargetWOW64% is a variable in current existance, no need to create %x8664% variable which does exactly the same thing.

Regards,
Galapo.

#37 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 16 June 2010 - 03:55 PM

%TargetWOW64% is most needed for CAPI. It is used to determine if a program is compatible with PE architecture and/or existance of wow64.

Because %TargetWOW64% is a variable in current existance, no need to create %x8664% variable which does exactly the same thing.

Regards,
Galapo.

?????
Search for "Set,%TargetWOW64%" in LiveXP, nativeEX_barebone, nativeEx_Win7, VistaPE, Win7RescuePE:
Suchen nach&#58; Set,%TargetWOW64%

LiveXP\Basic\Build&#92;&#48; - OnProjectRun.script&#40;95&#41;&#58; Set,%TargetWOW64%,%SourceArch%,PERMANENT

LiveXP\Basic\Build\5 - WOW64_Basic.Script&#40;45&#41;&#58; If,%Enable_WoW64_CheckBox%,Equal,False,Set,%TargetWOW64%,%SourceArch%,PERMANENT

LiveXP\Basic\Build\5 - WOW64_Basic.Script&#40;48&#41;&#58; Set,%TargetWOW64%,x86,PERMANENT

LiveXP\Basic\Build\Common_Api.script&#40;546&#41;&#58; If,Not,EXISTVAR,%TargetWOW64%,Set,%TargetWOW64%,%SourceArch%
And I have it in my projects by Common LiveXP API:
nativeEx_barebone\Basic\Build\Common_ApiEx.script&#40;547&#41;&#58; If,Not,EXISTVAR,%TargetWOW64%,Set,%TargetWOW64%,%SourceArch%

nativeEx_Win7\Common_ApiEx.script&#40;546&#41;&#58; If,Not,EXISTVAR,%TargetWOW64%,Set,%TargetWOW64%,%SourceArch%

VistaPE-CAPI\Base\Common_Api.script&#40;547&#41;&#58; If,Not,EXISTVAR,%TargetWOW64%,Set,%TargetWOW64%,%SourceArch%
EDIT: IMHO %TargetWOW64% is not really an "All Projects' property". It is a LiveXP property given as a "non-refusable-present" to other projects.
Sorry that I do not agree to use %TargetWOW64% in PEFactory.

Peter

#38 Lancelot

Lancelot

    Frequent Member

  • .script developer
  • 5013 posts
  • Location:Turkiye/Izmir
  • Interests:*Mechanical stuff and Physics,
    *LiveXP, BartPE, SherpyaXPE,
    *Basketball and Looong Walking,
    *Buying outwear for my girlf (Reason: Girls are stupid about buying bad stuff to make themselves uglier :))
    *Girls (Lyric: Girl,...., You will be a womann, Soon)
    *Answering questions for "Meaning of life",
    *Helping people,

    Kung with LiveXP, Fu with Peter :)
  •  
    Turkey

Posted 16 June 2010 - 06:01 PM

@paraglider

I 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

&#91;Process&#93;

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 PERMANENTLY
Set,%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 PERMANENTLY
hence following build is aware the condition.

First problem solved,
with this solution following works half
&#91;Process&#93;

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

&#91;Process&#93;

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

&#91;Process&#93;

unpack,,%setupFile%,True

require_file,msvbvm60.dll
===>
&#91;Process&#93;

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.


@psc
STOP 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.

#39 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 16 June 2010 - 06:04 PM

Pretend to be like a mature man.

A mature man surely does not cut an ICQ connection when he got a message he does not like!
And in my mind is something like "You did"

:thumbup:

#40 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 16 June 2010 - 06:16 PM

@Paraglider!

Post #38 is mainly adressed to you.

If you have read and understood it, can you please explain me in some sentences the sence of the some pages long post (if there is one)?

Thanks

Peter

#41 Galapo

Galapo

    Platinum Member

  • .script developer
  • 3841 posts
  •  
    Australia

Posted 16 June 2010 - 11:52 PM

If you have read and understood it, can you please explain me in some sentences the sence of the some pages long post (if there is one)?

Hi Peter,

The post is just explaining the history of how %TargetWOW64% variable came about, i.e., by mutual cooperation and development by the main project developers at the time, esp. those with multi-architecture projects or those wanting to include app scripts supporting multi-architecture.

The history outlined is that you were resistant to %TargetWOW64%, saying it was redundant, which is why the discussion of the variable then left you behind. But now with PEFactory since the aim of that is to support a range of projects, I guess including now multi-architecture, well you now need a variable which does the same thing as what %TargetWOW64% has done all along. My point is that %x8664% does not need to be used because we already have a variable which all main projects have agreed to use and have been using for a long time now, i.e. %TargetWOW64%.

Peter, why can't you agree to using a vaiable already common between other projects rather than reinventing the wheel? %TargetWOW64% is more explanatory than %x8664% -- maybe you should be naming it %x8664ia64% to be more logical under your naming convention?

I had thought this discussion was for suggestions about how PEFactory might be improved -- I really cannot understand why you ask for this and then cannot take on board a commonsense suggestion of using %TargetWOW64% instead of %x8664%.

Regards,
Galapo.

#42 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 17 June 2010 - 08:03 AM

My idea was to make the factory inpependent from projects and having it's own namespace, and define the variables project depending on entry.

But if you are sure that %TargetWOW64% is ALLWAYS defined, why not use it instead of %x8664%?

Peter :thumbup:

#43 paraglider

paraglider

    Gold Member

  • .script developer
  • 1739 posts
  • Location:NC,USA
  •  
    United States

Posted 17 June 2010 - 11:56 AM

%TargetWOW64% is a mechanism to indicate that if 64 bit source is used that x86 support has also been added to the build. So:

1) With x86 source %TargetWOW64%=x86
2) With x64 ( amd64 ) source %TargetWOW64%=x64 if no x86 support.
3) With x64 ( amd64 ) source %TargetWOW64%=x86 if x86 support has been added to the build with a WOW64 script
4) With IA64 source %TargetWOW64%=ia64 if no x86 support.
5) With IA64 source %TargetWOW64%=x86 if x86 support has been added to the build with a WOW64 script.

IA64 support can probably be ignored has not many people have Itanium computers and they don't have much future in the windows world. MS is dropping support with windows 8.

You can see that %TargetWOW64% is really just a boolean indicating if x86 support is available!

Its only effect is on the Common API Arch function. If the script indicates that it only supports x86 and the source is 64 bit and no x86 support has been enabled then a scripting error is thrown. It has no effect on Require_File that I could see.

#44 Galapo

Galapo

    Platinum Member

  • .script developer
  • 3841 posts
  •  
    Australia

Posted 17 June 2010 - 12:16 PM

It has no effect on Require_File that I could see.

The effect is derivative.

@psc
Thanks!

But let's see if you can also overcome issues with existing grub4dos script, WimPack, RunFromCD, and RunFromRAM. BootSDI and WimBoot will also need checking as PEFactory is likely not compatible there either.

Regards,
Galapo.

#45 Lancelot

Lancelot

    Frequent Member

  • .script developer
  • 5013 posts
  • Location:Turkiye/Izmir
  • Interests:*Mechanical stuff and Physics,
    *LiveXP, BartPE, SherpyaXPE,
    *Basketball and Looong Walking,
    *Buying outwear for my girlf (Reason: Girls are stupid about buying bad stuff to make themselves uglier :))
    *Girls (Lyric: Girl,...., You will be a womann, Soon)
    *Answering questions for "Meaning of life",
    *Helping people,

    Kung with LiveXP, Fu with Peter :)
  •  
    Turkey

Posted 17 June 2010 - 12:23 PM

It has no effect on Require_File that I could see.

Check again, either with
1- reading my previous post
2- testing with a project that has wow64 script from JFX
3- reading capi script carelfully

further:
to have scripts work between projects, capi is not enough, common variables (ex: %SourceArch% , %Target_Sys% etc... ) are also needed to be able to share scripts between projects.

truely, above %x8664% usage by psc is a result of mixed and careless mind as usual. It currently duplicates %SourceArch% and further used that way in scripts. If replaced to %SourceArch% with current design there is no problem. target pe behaviour to x86 applications has no importance for a cache mechanism.

The annoying (as usual) part is, package inserts a set of permanent variables inside projects that are either undeeded or redundant.
If one likes his namings, all can also be done by iniwrite/iniread to a package specific ini file. ALL Projects provides ALL required info with their existance permanet variables, no need to increase number of permanent variables by either populating or with subdefinations unless there is a goal to insert silently.

Besides all, as i wrote before, there is no need for such a package, a single script just before otheros (or end of apps) can do all these stuff (why not try your self on a pe2/3 build to practice how easy). True development would be shifting settings to near buildend hence caching before that point , which requires a set of heavy work, and all to avoid slowness of wb developement.

#46 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 17 June 2010 - 01:36 PM

truely, above %x8664% usage by psc is a result of mixed and careless mind as usual. It currently duplicates %SourceArch% and further used that way in scripts.

You did not understand, AS USUAL! :thumbup:

PEFactory has its own name space. So it (theoretically) can be used also in non LiveXP CAPI driven projects.

I already told it at a different place.
But for Those who do not understand AS USUAL:

The only thing to add a project to PEFactory, is to tell PEFactory, in which variables of the parent project necessary information is defined.
&#91;nativeEx_barebone&#93;

Set,%x8664%,%SourceArch%,PERMANENT

Set,%ProjectType%,1,PERMANENT

Set,%BootTMP%,NIL,PERMANENT

Set,%WimApp%,NIL,PERMANENT



&#91;nativeEx_Win7&#93;

Set,%x8664%,x86,PERMANENT

Set,%ProjectType%,4,PERMANENT

Set,%BootTMP%,%ProjectTemp%\boot.tmp,PERMANENT

Set,%WimApp%,NIL,PERMANENT



&#91;VistaPE_CAPI_v.12_&#40;RC1b_common_API&#41;&#93;

Set,%x8664%,x86,PERMANENT

Set,%ProjectType%,2,PERMANENT

Set,%BootTMP%,%ProjectTemp%\boot.tmp,PERMANENT

IniRead,%ProjectInfo%,VistaInfo,Imagex,%WimApp%

When I use %SourceArch% instead of %x8664%, I should have to include in PEFactory:
//Do the same like with %ISOFile%&#58; Just overwrite a predefined value with actual demanded values.

//As non-cooperative script do not care about consequences for ozther scripts

If,%ProjectTitle%=BlaBla,Set,%SourceArch%,I64
This is the Windmill Pansa way to increase the knowledge of an independent package about tenth of external specialities.
(Last tutorial. Who now again does not understand, may be proud about his stupidity. I do not expalin again).

Peter

#47 Lancelot

Lancelot

    Frequent Member

  • .script developer
  • 5013 posts
  • Location:Turkiye/Izmir
  • Interests:*Mechanical stuff and Physics,
    *LiveXP, BartPE, SherpyaXPE,
    *Basketball and Looong Walking,
    *Buying outwear for my girlf (Reason: Girls are stupid about buying bad stuff to make themselves uglier :))
    *Girls (Lyric: Girl,...., You will be a womann, Soon)
    *Answering questions for "Meaning of life",
    *Helping people,

    Kung with LiveXP, Fu with Peter :)
  •  
    Turkey

Posted 17 June 2010 - 02:30 PM

(Last tutorial. Who now again does not understand, may be proud about his stupidity. I do not expalin again).

again nice word from a mature man, ok this time stupid instead idiot since you prefer this way today to lower the level of matureness and distract attention from the truth of your package.

only a stupid script author would decide to populate or reinvent variables as permanent and use permanent variables to transfer value info from one script to another and call it a package for all project. A stupid redundancy for all to insert undeeded variables to other projects.

Stupid minds can not understand, but this simply violates variable handling of a project admin.

We have RegFactory (RF) by fxscrpt (fxscrpt is the only Peter i know who have excellent coding ability) which deserves a fancy name having a unique feature exists only in livexp since we know the value of good things, and this is you originally inspired when naming and method with your stupid package.

But fact is that, RF does not populate or reinvent variables like you did, it simply uses existing variables, and adds things that are specific to the package. (in order not to cause stupid minds mix the reality, adding things properly does not populate or reinvent wheels)

Unlike RF, your stupid package inserts a whole variable structure to the project variable list.

If your stupid mind could ever follow how fxscrpt nicely code things, you could see adding
Set,%PEfactoryini%,%projecttemp%\Pefactory\pscstupidvariables.ini,Permanent
is sufficient for your package,
instead of filling project variables with redundant variables, which would serve god knows which stupid future purposes you have in mind.


Well you truely di UNDERSTAND what i wrote,
above stupid post shows you are again (as usual) trying to change subject away from facts with a personal post attack by a stupid word "stupid"
facts: your package inserts redundant variables to projects silently, none of them needed.
facts: package does not give what people expect, what package does can be done with a single script which simply caches before otheros, which as a result not fancy at all.
with its stupid nature, it is only serves like a stupid troy horse.
facts:
IF you want to produce something valuable on this manner, a project that have an overall cache (which is possible) ability,
make your own win7 project (stop writing stupidly lieing excuses you write around trying to explain why your parasite project package made parasite way)
Truely
this idea (writing your own win7 project with above ability) opens alll freedeom to you,
since such a project would need a set of new variables as well as new organisations through all scripts including api arrangements, a whole set of all new organisations the way you like, without limitations of existing harmony between projects, would be at your hands.
just do not forget to add stupid (pefix, suffix) "nativeex" to the name of your new variables in order not to be mixed with current organisations. Hence everywhere full of variables having ex, native , nativeex etc. which would serve your selfsatisfcation without a comment around.

And IF you succeed on making such a project it would reach your goals:
1- a true (not parasite) win7 project by psc, having independent variables from all existing projects with a good (hence nobody will annoy) excuse, it can not be done with existing methods.
2- wb can get more slower by inserting new stupid things inside silently, since now wb author psc made a methodology to use cache widely in his projects.


IF such a project does not LIE (out of usual expectness because of known stupid behaviours of author) saying it is incompatible to all scripts (or organisations) for such a goal since such a goal can not be done with current organisation, Be sure
1- win7pe end users will love it
2- all other project admins would be happy to ignore anything inside knowing it is another (not common) regime of building.
3- you can have your new section on boot-land with "psc dictator projects", hence people who would follow your base projects to create others may give names (nativeexstupidnessA,nativeexstupidnessB, etc) and since you are the dictator you would have full control over all these admins.
4- you will not need to worry about any compatibilty between projects again, you have your dictatorship, you rule.
(ps: all dictators call their regime mostly kingdom, sometimes republic, which does not fool neither citizens nor historians, but you might prefer that way to welcome new users)


It is hard to expect you to act a man on this way, baahhhhh, trying to demolish other projects is more fun.
BUT maybe you can behave like a man on this goal, since it fullly serves your satisfaction.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users