Converting script between PESE and XPE

Is there a quick way to convert scripts that written for PESE to XPE?

Re-Create Them....
As there are many variable and syntax changes...

I successfully run my own  ~ 100 pe se addons with xpe. I wrote a second API to map PE SE syntax to XPE syntax. Its by no means complete as it only maps the macros that I use.

Hi sandy,

I successfully run my own  ~ 100 pe se addons with xpe. I wrote a second API to map PE SE syntax to XPE syntax. Its by no means complete as it only maps the macros that I use.

I had done that last year, Everything work fine with a month work ... 

some useful tips on your way :
You can have 2 xpe plugins at the begining and at the end
eg.
\Apps_S\0_First.Script
\Apps_S\zzzz_Last.Script

inside first xpe plugin, you can use Set,....,Permanent
eg.
Set,%Tools%,%GTools%,Permanent
Set,%api%.........,Permanent
Set,%ProjectTemp%,.....,Permanent
.....
on last plugin, revert back to first condition
Set,%api%.........,Permanent
.....


during build, All  Plugins (SE/Gena plugins)  run between "First" XPE plugin and "Last" plugin will work without changing anything with them. 


Another tip:
Macro Library also can also be used that way, you will need some variables, just for a head start you can use something like that inside first xpe plugin:
Set,%BuildClass%,3,Permanent
Set,%_ML_Shortcut_TYPE%,NO,Permanent
Set,%_ML_RF_TYPE%,NO,Permanent
Set,%_ML_RegAddBootMethod%,NOT_IMPLEMENTED_WARN,Permanent
Set,%PluginArch%,,Permanent
Set,%OSFamily%,NT6,Permanent
Set,%TargetWOW64%,x86,Permanent
Set,%SourceArch%,x64
Set,%Tools%,%GTools%,Permanent
Set,%api%.........,Permanent
Set,%ProjectTemp%,.....,Permanent


.....
Probably some more ..... this will give you an idea.

ps:
Since you are familiar with api now by writing a 2nd api, info: Shortcut creation can be done out of Macro Library via any 3rd party plugin.



****
It was more fun to me to get Plugins (SE/Gena) also work with LiveSystemPro and WimBuilder, so I do not work in that area after 1 month last year,
 Maybe you are interested to above tips maybe not, I did not test anything related to above, but practiced the idea with %100 success last year,
    so only sharing tips from old experience using memory that is all.

nice approach Lancelot and Sandy.
I would like to see more.

@Sharp, doing a search and replace for the following will usually get it up and going.

// ***  From PE    ------>    XPE  ***
//  %TargetDir% -->       %GTarget%
//  %Target_Sys%  -->   %GTarget_Sys%
//  Add_Shortcut -->        AddShortcut
//  %SourceArch% -->    %Architecture%
//  %ProjectTemp% -->   %GTemp%
//  %target_win%  -->    %GTarget_Win%
//  %GlobalTemplates% --> %ProgCache%
//  RegAddBoot, Call, %BuildModel%  <-- Unrecognized Commands in XPE
//  //If,%pCheckBox_DesktopShortcut%,Equal,True,AddShortcut,Desktop,,%LinkDir%\%ProgramEXE%,%ProgramTitle%,%LinkDir% <-- DOESN'T WORK
//  If,%pCheckBox_DesktopShortcut%,Equal,True,AddShortcut,Desktop,,%LinkDir%\%ProgramEXE%,%ProgramTitle%,
//  If,%pCheckBox2%,Equal,True,AddShortcut,StartMenu,%pTextBox_StartMenuLocation%,%LinkDir%\%ProgramEXE%,%ProgramTitle%, <-- USED THIS IN DAEMON TOOLS.,

// E:\10PE3\Workbench\Common\ ==   E:\10XPE1\ProgCache\
// Replace Workbench\Common\    with %ProgCache%
// E:\10XPE1\Temp                <-- This might be download folder.
// SET,%DestDir%,%Target_Prog%
// SET,%DestDir%,%GISO%\Programs\%ProgramFolder%
// %Target_Prog%  == TargetDir%\ISO\Programs


I know I don't have them all, with Sandy's info perhaps we could nail 'em all down.
Regards
RoyM

Hi

most were advised right at the start of the XPE project by James/ChrisR

http://theoven.org/index.php?topic=2488.msg26779#msg26779

Is there a quick way to convert scripts that written for PESE to XPE?

But here we go around again 2 years later..

I think the key take away here is - with some experience comes success..

nice approach Lancelot and Sandy.
I would like to see more.

It is there since the beginning .... I thought everybody already aware !

Another path other than I wrote is, (maybe sandy path) create a single (or a set of) xpe-plugin (eg. "Compatibility to Plugin" ) to get all plugins work with WinXPE out of box.

This way people like sharp will not open such topics anymore.

Such plugin would start with a set of variables eg.
Set,%SourceArch%,%Architecture%,Permanent
....
(whatever written about variables from whom on relevant topics, but I advise be careful, sometimes provided info I read around is not correct)
and continue with adding some macros
eg.
Set,Add_Shortcut,"Run,%ScriptFile%,BlaBla",Permanent

Tip:
using such a plugin :

Code: [Select]

[Process]
Set,Add_Shortcut,"Run,%ScriptFile%,Shortcut_not_implemented",Permanent

[Shortcut_not_implemented]
Echo,"Add_Shortcut under construction",Warn

will prevent Add_Shortcut lines fail. 
And you can continue improvements later.
(this tip can also be used to improve other macros slowly in time)

ps: sandy 2nd api should be getting operational with using this way.

one can use a 2nd api or Marco Library (or both 2nd api and 3rd Macro Library ) for such macros.

This should take only a ~ week .


ps:
Only reason It had taken a month to me was,
 To improve Macro Library (instead of writing a 2nd api like sandy),
  I had to first learn how to extract files from wim ( Set,%BuildClass%,3,Permanent -> RequiresFileQ, Require,FileList works with extracting from wim ) and figure out xpe-pecmd shortcut creation (which was already written inside xpe macro)

Tip:
after Set,%BuildClass%,3,Permanent , just follow log with Require_FileQ,msimg32.dll , all codes ready and working 

--> Win10PESE\Images Configuration --> Enable_Type3_CheckBox --> enable to test such things (Advanced users only)

Tip:
Last year I used Macro Library instead of writing another api, since it was much easier for me,
 most macros work out of box no need to rewrite again by only working on %BuildClass% 3 )

***
Anyway, it is quite easy to have a head start with these tips just in a day,
 Also, It is much tidy instead of writing a conversion table post on a topic which always have missing things,
  Write all conversion info to a  "Compatibility to Plugin" so all users like sharp can benefit from that,
    converting plugin to xpeplugin will naturally fail since xpe do not have all plugin macros
      getting plugins work out of box is much more easier.
         Only requires some time to follow a correct path, like sandy, maybe you can spend some time too RoyM, I am sure everybody benefits from such a thing.

Just spend 1 day with the above tips, you will get surprised how easy to get plugins start to work out of box without conversion etc.
You can spend some little time on such success, I have no interest in such idea, I can only feedback.

On my side what you refer "more" is to get plugins work out of box with all projects like LiveSystemPro and WimBuilder and WinPE by ms,
 which already works at home but requires a lot work to get public ready (not easy like writing a "Compatibility to Plugin" xpe-plugin) .

So all in your hands.

 
Re: Win10XPE Project General Discussions  « Reply #3 on: May 15, 2018,
My first experience with XPE, August, 2019.

Sorry, I was a latecomer and didn't catch that.
It just so happens I am on vacation this week.
And I have another week next month.

"How hard could it be"...  <-- 'Just pokin' fun at 'ya.)
Thanks for the tips, I will certainly use them.

"I do like Sandy's approach".
If Sandy could share some API stuff, that would be fantastic.
Otherwise, If I can break away from Vaca Stuff,
I will invest some time to a PESE to XPE converter.

Regards
RoyM

I will invest some time to a PESE to XPE converter.

There have been at least 3 posted - all with the same results...
It is safe to say the initial XPE Release has moved way beyond that point..

Yet, one could use PESE with all it's Supported API's, Macro's & Plugins to Build WinPE, Thus no need to Rewrite or Convert anything...
XPE works so very well because it's concept was to keep it very small & simple...

Yet, one could use PESE with all it's Supported API's, Macro's & Plugins to Build WinPE, Thus no need to Rewrite or Convert anything...
XPE works so very well because it's concept was to keep it very small & simple...

The topic after sandy post is not about that.
 About what you wrote, I had already build Win10XPE with Macro Library last year (3rd way) , Macro Library (self proves) is beyond that point, It is designed is to keep simple to get compatibility easier since day 1.

Like PEBakery compatibility options, idea is to get plugins to work out of the box with Win10XPE without any converter etc,
 which is in reality already there waiting someone to notice. (eg. sandy)
   And with this way, there will be no failure like 3 converter trials which will naturally fail as explained in previous post, Win10XPE do not cover all syntax.
    I am sure since you like to see end-user such a success that will make Win10XPE look better, you should be happy. 

Since I had already practiced 2 (later +1 = 3) methods with %100 success last year that gets plugins work %100 out of box, I shared my experience.



@ RoyM,

Have fun on vacation, it will be easy. 

Well after you practice with RoyM-api for such goal,
 you will have a better idea about Macro Library, and figure out "black propaganda" hiding behind things like "small" simple" etc. 

Most important, after such a plugin, like PEBekary missing compatibility options (and design etc.), we will not have such topics as sharp or converters anymore.


Tip:
You will need such a thing during your tests to see parameters on log.

Code: [Select]

[Process]
Set,Add_Shortcut,"Run,%ScriptFile%,Shortcut_not_implemented",Permanent

[Shortcut_not_implemented]
Echo,"Add_Shortcut under construction - Par: -#1- -#2- -#3- -#4- #5- -#6- -#7- -#8- -#9-",Warn

during macro design, log is your best friend. 


RoyM, sandy, Have fun and good luck. I hope you quickly figure out how easy such a task and have fun during development.
 

Is there a quick way to convert scripts that written for PESE to XPE?

But here we go around again 2 years later..

I agree, just a new relaunch.

I had already build Win10XPE with Macro Library last year (3rd way) , Macro Library (self proves) is beyond that point, It is designed is to keep simple to get compatibility easier since day 1.
.....

What can I say! Bravo 
But, I still don't get it at All
It only complicates things and it will be a BIG source of confusion for users.
It works fine as it is, with its 36 variables and 17 macros. Adding PESE variables and ML macros is not the best for loading time, building time, simplicity,...

And The Win10XPE Optional Member XPE App Plugins collection, 100% compatible and nicely written, is impressive
We need nothing more to keep it small and simple for users

We need nothing more to keep it small and simple for users

Plugins working out of box is top simple, like good old days before fabricated incompatibility. ( http://theoven.org/index.php?topic=2697.0 )

I hope RoyM and sandy have good times when creating such xpe-plugin.

+
If you read all, only reminding, I am not working on such thing, I had already done that a year ago and It was quite easy.
 I only share my old experience saying all possible with both methods and works fine out of box.

Was not suggesting my way is the only or best way. That was why its not been published. its a 200 line plugin that allows all my pe se plugins to run both with xpe and 10 pe se. It just redirects the few variables that are not standard in xpe and adds a small number of macro library macros that I ported to xpe that are not included with xpe or have different names. I totally agree there was no reason to rename variables / macros that have been in use with se projects for years. However we are where we are and have to live with what is.

Hi sandy,

Was not suggesting my way is the only or best way. That was why its not been published.

Sure it is not the only or best way, there are I guess ~ 5 or 6 ways ... , As I wrote I prefer 5 th way 
But it is sad you do not publish for that reason.

Alternatives available good for everybody,
like WimBuilder, LiveSystemPro, PEBakery, Win10XPE, Win10PESE, all rest SE, Gena ...


Please reconsider sharing your work maybe on a topic at Plugin section ( to avoid things ... )
http://theoven.org/index.php?board=9.0

I am sure RoyM and others will be happy ...

RoyM reply 9 :

"I do like Sandy's approach".
If Sandy could share some API stuff, that would be fantastic.

As you wrote (I had written similar last year)

we are where we are and have to live with what is.

Life goes, since we have to live with what it is, better move on by sharing your work 

I totally agree there was no reason to rename variables / macros that have been in use with se projects for years.

OK, I can agree with that statement - But XPE was just a concept by the Author - that was willingly posted to this forum...
The initial Feedback was positive - yet everybody waited for Author to further develop - so they could test improvements...
No one stood up to help with any development except myself - I followed the existing code and variables and concept...
Over the course of a few months - some users (very few) provide feedback and testing results and offered little input...
See that is one of the Biggest problems in this forum, we have a lot of couch quarterbacks, that contribute nothing to the game...
I can go back and read users posts, I see no shared Apps, processes, or development suggestions..
Yet I see lots of posts about other Members not supporting this or that for what ever reason....

We know the proof of integration has been tested and was found to be valid by a (stated) month long re-write of existing PESE Core Project & Plugin's ...
Adding More Code To An Existing Project  - Was never the intended concept for XPE to follow - actually it was just the opposite...

Now if anyone would care to share an Optional 200 line App - they are free to do so..
Yet, if that App was to create Issues or error complaints from users in regards to the XPE Project..
That App would be removed because those issues would be effecting the perception of the XPE Project..

Some members are posting Optional Apps or Fixes - yet all the while reporting Project Error Reports - that where Self-Inflected..
Some Members are posting Optional Apps - without testing or seeking feedback or they contain missing or unwanted processes..
Those Apps (are/have been/will be) removed via a MOP Cleanup because those issues are effecting the perception of the XPE Project..

However we are where we are and have to live with what is.

Hi James,

What you wrote is mostly not about the current topic subject, and some are quite funny indeed.
 If you are serious, I can respond to them on another topic.

Anyway, to avoid the fabricated policy you wrote, I had already written :

Please reconsider sharing your work maybe on a topic at Plugin section ( to avoid things ... )
http://theoven.org/index.php?board=9.0

So you do not need to consider the things you wrote ....

As written, and as you had written similarly in the past : We are where we are and have to live with what is.

I hope sandy share the work on a topic like TheOven supporting everybody share their work freely (remember even you), and we continue to live with what it is.

But to get back to the Original Post

Is there a quick way to convert scripts that written for PESE to XPE?

It is just easier to re-create the app following XPE structure
It would be more widely acceptable to a general user and easily integrated into project..