Fabricated Incompatibility Win10XPE Discussion

Hi dazza

Tried using this one but get error:
Unable to create directory:  [DirMake,%ProjectTemp%\TempExtractFolder\%containerfolder%]

you shouldn't expect a plugin designed for one project Win10PE SE, in this case, to work with another, since they use different project variables

Any chance of a plugin for Win10XPE as well?

I'm sure there is, but you need to ask in the appropriate place

http://theoven.org/index.php?topic=2488.msg30464#msg30464
or
http://theoven.org/index.php?board=39.0

you shouldn't expect a plugin designed for one project Win10PE SE, in this case, to work with another

Didn't notice anywhere in this post that it actually stated which PE it was for - hence asking

you shouldn't expect a plugin designed for one project Win10PE SE, in this case, to work with another, since they use different project variables

missing info:
Plugins designed for Win10PESE, Win81SE, Win8PESE, Win7PESE, Gena

App plugins designed to be used by all projects, projects designed to use or not up to project.

I'm sure there is, but you need to ask in the appropriate place

http://theoven.org/index.php?topic=2488.msg30464#msg30464
or
http://theoven.org/index.php?board=39.0

Wrong:
the current topic is the very right place to ask.


Edit:
original topic before split attached

you shouldn't expect a plugin designed for one project Win10PE SE, in this case, to work with another

Didn't notice anywhere in this post that it actually stated which PE it was for - hence asking

Hi dazza,

you can check plugins by looking inside [Main]

*
Type=Plugin
+
HistoryXXX=...
HistoryNotesXX=....

If you see Type=Plugin, check history notes if the author creates compatibility for Win10XPE or not.

eg.
Bob.Omb's "SFX Constructor" plugin works both as Type=Plugin with all projects that supports Type=Plugin (Win10PESE, Win81SE, Win8PESE, Win7PESE, Gena) and also with Win10XPE

Code: [Select]

Title=SFX Constructor
Type=Plugin
History001=Bob.Omb Plugin Created Date: 2018/05/23
History002=Bob.Omb Fixed Compatibility, Continuity, and Self Repair (Green Play Button) - Date: 2018/05/26
History003=Bob.Omb Further updated with full XPE compatibility - Date: 2018/05/26
History004=Lancelot update to get Plugin better XPE compatible - Reply 17 18 19 http://TheOven.org/index.php?topic=2494.msg28402#msg28402 // Add Default_Button - Date:2018.10.20 // Removed Empty HomePage - Date:2018.11.28

*
Type=XPEPlugin

such plugins only work on Win10XPE

**
I am sure Bob.Omb will get plugin compatible to Win10XPE after your request.


***
This incompatibility situation is only a fabricated thing created by some bad ideas behind.
In 2019 all Type=Plugin will work with Win10XPE out of box.
For now only very rare Type=Plugin works with Win10XPE.

Hi
Well, I stand corrected, I thought I could see you working towards that end with changes in the Macro Library, but not being an SFX Constructor plugin user, I wasn't aware there were any available, my bad as they say

Thanks you both for your responses - I will keep eye out for updated plugin, and look forward to the future where all will be compatible with all projects, which is definitely a good thing

I thought I could see you working towards that end with changes in the Macro Library

Macro Library already updated,
After only 7 days work  (Start 2018-10-01 - End 2018-10-08 ) Win10XPE was working with Macro Library and all Type=Plugin working.

But it seems James like to delete author history etc. names and other things with a fabricated excuse "incompatibility".

I decide to work on another method which requires much more time (side by side with Bob.Omb support, other interesting things with other projects, and Life ...)

Happy new year to All 

This incompatibility situation is only a fabricated thing created by some bad ideas behind.
In 2019 all Type=Plugin will work with Win10XPE out of box.
For now only very rare Type=Plugin works with Win10XPE.

I do not really agree. A little history to explain:

The XPE project was really small initially and without any plugins.
The variables were named with the prefix G (Global) in order to be independent of internal WB variables %SourceDir%, %TargetDir%, %ISOfile%
Being independent from other projects, It does not use subfolders such as \Tools\Win10XPE or \Target\Win10XPE, more easier to browse in explorer.
Wimlib extract ListFiles is the engine. It is very fast and it avoids having to mount or extract boot.wim and install.wim files.
Few macros used to simplify the use and for a faster build.

When the first plugins were created,
It seemed too complicated to use the existing plugins related to the XPE concept:
- Require_FileQ vs ExtractSectionFiles (Wimlib extract ListFiles)
- Add_Shortcut in Win10PE.cfg vs shortcuts witten in pecmd.ini. Same for Add_Pin.
... and all others used macros
%API_TYPE%=3 didn't exist at that time and the work to make them compatible was too important.

It was much easier to write some additional macros
And now, It seems enough with only the 17 existing macros and it helps to maintain a good speed of construction.
And the simple concept allows me to stay in touch even if it is only from time to time

Win10XPE has grown up now, it is stable, simple, fast and complete (Not only to sell it but what I really think).
It has now a small success, Also. And it should be able to live without me and without too much change, I believe.

The counterpart is the compatibility with existing projects and existing plugins.
I can understand but I do not really see any pathways other than current one with 2 separate branches.
With XPE plugins in their own topics. With _XPE written in plugin's name and with Type=XPEPlugin. To avoid at best any confusion.

Writing compatible scripts is of course achievable
But it really complicates writing, you need knowledge of both projects with the variables names, macros...
And who is able to test a plugin with a build for both projects + possibly both architectures, not me
It does not seem to me the right way.

I believe that it is possible to live with 2 and independent projects.
with respect for each other for a good emulation, and leaving free users to choose their paths.
My way, it would be good to read other points of view
 

Open the floodgates :-)

But seriously: I agree with you, ChrisR, thank you for your clear explanation.

Happy new year to All 

This incompatibility situation is only a fabricated thing created by some bad ideas behind.
In 2019 all Type=Plugin will work with Win10XPE out of box.
For now only very rare Type=Plugin works with Win10XPE.

I do not really agree. A little history to explain:

I do not agree, Since it was already proven:
Getting Win10XPE was easy only one week task to get all Type=Plugin working.
Since this was proven, It is a fabricated situation.

When you start a new project (~ 2018-03-11 ) I already wrote:

Following experience with Gena having Saydin77-Core It would be easy to get Plugins continue work.
  (ps: The Idea to create Plugins and TheOven.org Forum was not get forced to rewrite plugins again and again)

*
Following your history:

The XPE project was really small initially and without any plugins.

Sure, I deeply know how a project starts at core level.

The variables were named with the prefix G (Global) in order to be independent of internal WB variables %SourceDir%, %TargetDir%, %ISOfile%
Being independent from other projects, It does not use subfolders such as \Tools\Win10XPE or \Target\Win10XPE, more easier to browse in explorer.
Wimlib extract ListFiles is the engine. It is very fast and it avoids having to mount or extract boot.wim and install.wim files.
Few macros used to simplify the use and for a faster build.

you mix "being independent " with "not able to run on same base folder".
wb wrong designed "internal" variables is not a trouble, on other way around all projects can also be updated with %ISourceDir% %ITargetDir%, %IISOfile%
and all plugins would continue work even "not able to run on same base folder".

*

When the first plugins were created,
It seemed too complicated to use the existing plugins related to the XPE concept:
- Require_FileQ vs ExtractSectionFiles (Wimlib extract ListFiles)
- Add_Shortcut in Win10PE.cfg vs shortcuts witten in pecmd.ini. Same for Add_Pin.
... and all others used macros
%API_TYPE%=3 didn't exist at that time and the work to make them compatible was too important.

You did not inform core project development finished and ask for such thing.
I accidentally saw conversion posts on topic and understand what is going on.
(such posts remind and annoyed me winbuilder wrong designed bartpe script conversion.
 Probably wrong design is intentional but I am sure there is a fabricated excuse ~9 10 years ago, I was not around)

*

It was much easier to write some additional macros
And now, It seems enough with only the 17 existing macros and it helps to maintain a good speed of construction.
And the simple concept allows me to stay in touch even if it is only from time to time

As written earlier, writing additional macros with "different names" cause another compatibility trouble,
well this is not related to wb wrong designed internal variables at all....

Win10XPE has grown up now, it is stable, simple, fast and complete (Not only to sell it but what I really think).
It has now a small success, Also. And it should be able to live without me and without too much change, I believe.

We all know, things evolve. Never stay as it is.... 

The counterpart is the compatibility with existing projects and existing plugins.
I can understand but I do not really see any pathways other than current one with 2 separate branches.
With XPE plugins in their own topics. With _XPE written in plugin's name and with Type=XPEPlugin. To avoid at best any confusion.

well since incompatibility fabricated, this is the only way left behind to write xpe special plugins.

Writing compatible scripts is of course achievable
But it really complicates writing, you need knowledge of both projects with the variables names, macros...
And who is able to test a plugin with a build for both projects + possibly both architectures, not me
It does not seem to me the right way.

Good, there is no trouble to write compatible plugins, in the end simple plugin mostly have simple features
shortcut
extract
runfrom
since only syntax things need to be replaced %Tools% %GTools% Add_Shortcut AddShortcut (similarities goes....)

+
Well you could also add plugin support to your project without changing %Gtools% etc....

I believe that it is possible to live with 2 and independent projects.
with respect for each other for a good emulation, and leaving free users to choose their paths.
My way, it would be good to read other points of view
 

respect sure required 
there is only 1 member that likes to play in the border of respect around.

****
Well Chris,

It is ok new project thanks to wimlib and your hard work.
But your decisions only open gate to a great set of conversions which we do not need for years....
And recently "spam advertisement" post game we do not see for years....

Getting Win10XPE was easy only one week task to get all Type=Plugin working self proves it is a fabricated situation.

To me all fine,
You open me new gate to develop new projects which I did not for years feeling it would be disrespectful to SE and you. My mistake. 

Plugins will work with XPE one way or another, as you also wrote it is quite complex to write a single plugin for different types,
and only solution to me getting plugins work on xpe...
 Thanks for opening that gate to me. 

@Chris,

good side:

Open the floodgates :-)

But seriously: I agree with you, ChrisR, thank you for your clear explanation.

you make Atari800xl write a post (instead of delete)

thanks. 

@ChrisR,

****
Well Chris,

It is ok new project thanks to wimlib and your hard work.
But your decisions only open gate to a great set of conversions which we do not need for years....
And recently "spam advertisement" post game we do not see for years....

Getting Win10XPE was easy only one week task to get all Type=Plugin working self proves it is a fabricated situation.

With Atari800xl words:

You really create flood
http://www.wikizeroo.net/index.php?q=aHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvRmxvb2Q
nice pictures.

Reminding, same people do not join winbuilder-java to create flood. 
Think about it.

To me all fine,
You open me new gate to develop new projects which I did not for years feeling it would be disrespectful to SE and you. My mistake. 

Plugins will work with XPE one way or another, as you also wrote it is quite complex to write a single plugin for different types,
and only solution to me getting plugins work on xpe...
 Thanks for opening that gate to me. 

Just to clear,
I do not try to change your ideas, I am all fine with this fabricated situation,
 which only serves to create flood for some people.
  But also open gates to me for better plugins (I mean Type=Plugin).

Happy New Year. 

And recently "spam advertisement" post game we do not see for years....

Sorry, I do not really see and I fail to understand, I answer there

Just a small parenthesis for some additional info

I do not agree, Since it was already proven:
Getting Win10XPE was easy only one week task to get all Type=Plugin working.
Since this was proven, It is a fabricated situation.

Fabricated situation, Yes it can be seen like that but it was mostly a Timing story
You haven't been on the forum for a while When the first plugins were created.
Without you, I wouldn't have been able to implement Macro Library with a new %API_TYPE%=3
And it seemed really too complicated to me to rewrite all essential macros.
With at first wimlib extract vs Require_FileQ. Add_Shortcut in Win10PE.cfg vs pecmd.ini,...
And so I didn't see how to enjoy the existing plugin.
>>
Resulting in plugins to be recreated with new macros
and as it was different, so independent, I adapted to my tasts the names of Macros
Without going through Call,xxx because I didn't need much of them.
Probably here my main mistake

It was, at that moment, the easiest way for me without taking too much time.
When you came back, there were too many new XPE plugins already written here or elsewhere (I think of our Korean friends).
Also, use Require_FileQ using wimlib to extract a file+mui will always be less efficient than ExtractSectionFiles
Opening, pointer, extraction and closing of Install.wim is done only once with ExtractSectionFiles and not for each file
That' s why it's difficult to turn back.

I didn't think to go much further with XPE at the begining,
And I didn't want to restart completely, Just come by from time to time. Here, right now, it's not too bad.


Otherwise, for information and better to say it publicly, as I turned the page on PESE.
I prefer not to interfere more with the extended development
It would not be good for me, for the development done and for bob, Lancelot or others
In order to let them free, really free, whatever the path chosen.
 

Hi ChrisR,

Just a little respond to parenthesis:

Around 2018-03-11, when you start project and informed, you wrote it is designed to be basic project.
with your words "it should be more a stand-alone program" (is it now !)
A basic project is like "Saydin77 Core" (a stand-alone program)
You did not post around time came to next step with shorcut & runfrom etc. or ask or do Macro Library update. (+1 point to Fabricated situation)

ps: unlike SE , Gena is build on "Saydin77 Core" (Gena is the successor to Saydin77 Builder) and Type=Plugin designed to be independent from core.

+
I was not informed, but I accidentally saw this post
http://TheOven.org/index.php?topic=2421.msg28158#msg28158
and follow the relevant posts.
After that It is not hard to figure out what James start to do and have fun with this fabricated situation.
You should have seen or predict even when late dazza like situation start which serves James recreate or rerecreate plugins only.
Well I should be away till summer, but now I am here. Thanks for the fabricated situation.

+
I see you frequently compare Require_FileQ with "ExtractSectionFiles "
It is not fair to compare banana with apple. (math rules ;))
You already know Macro Library now have
Require,FileList
which is same with "ExtractSectionFiles "
and same speed.

I can also tell you, comparing Require_FileQ vs Require,FileList -> Require,FileList will be faster with increasing number of files.
I can also tell you, comparing "ExtractSectionFiles " vs Require,FileList -> speed same
only maybe with 1 or 2 files Require_FileQ faster. (not tested)

Well both Require_FileQ vs Require,FileList work with Type=Plugin anyway.

+
Even things were too late from your point of view,
Win10XPE could support both XPEPlugin and Plugin same time (various ways...), but you prefer not to. (+1 point to Fabricated situation)

+
Macro Library created in a way not to convert same plugins again and again... Very independent from project or core.
So same syntax can be used following Macro Library with another macro plugin (like Win10XPE Macro) but you prefer not to. (+1 point to Fabricated situation)

==> so Bob.Omb Offline SFC Scans plugin would work without need a conversion and dazza situation not happend.
-------> you prefer not to, fine to me.

Even from looking from far with a technical prespective
http://theoven.org/index.php?topic=2695.msg30510#msg30510
It is a Fabricated situation . (+1 point to Fabricated situation)


*
I think of our Korean friends already create relevant XPE plugins.

The only one around we all know who have fun with this fabricated situation seems to be James. Self prove is passing time and relevant posts....



****
Just to remind,
I am fine with this fabricated situation, even James deleting my names on converted or reconverted or rereconverted plugins.
It opens me new gates of development.
also good new syntax for Macro Library. (thanks to new tools you create and your Macro)
There were things I felt missing with Macro Library expecting you fix with SE in passing years which I see not fixed with also Macro, good opportunity to improve to better. 

I am fine with the fabricated situation,
 But Further I can not let things Peter Schang & Nuno Brito did with post games which you also had suffered in the past,
  when they first intentionally fabricate a situation (incompatibility or another project or whatever)
   and than jump to other topics to spam advertise or play other kind of public post games following a fabricated situation.
    Such activities kills ALL projects and ALL development in passing time, we know from past. (self prove: Peter Schang & Nuno Brito projects)
     As Atari800xl wrote, http://theoven.org/index.php?topic=2688.msg30491#msg30491 I will not open floodgates for such thing,
      with basic reason behind the first day, I do not like projects and plugins die in passing time without a valid technical reason but because of fabricated situations.
        This only serves lost information.

Closed parenthesis on my side.   

I hope you read carefully and understand where I stand for.

Discussion continues on other topic, after Reply 8
http://theoven.org/index.php?topic=2722.msg31404#msg31404

related posts quoted and posted here in an order:

Reply 11
http://theoven.org/index.php?topic=2722.msg31408#msg31408

I used the XPE Code checker with full convert. No luck. ill try without full conversion.

I do not know XPE code checker.
As I wrote try without conversion.

as far as I remember,
CMD Settings_Color
CMD Settings_Console
CMD Settings_Options Layout
should work

ContextMenu
probably work

Exp ContextMenu_ShellNew
Exp IconSize
IconPositions
probably work

should: let me know
probably: let me know

Tweak UserPreferencesMask.Script
Tweak Visual Effects.Script
will not work (with or without conversion) but you can work around that

Keep in mind, all these conversions stuff happening only because of a fabricated incompatibility,
eg. http://theoven.org/index.php?topic=2488.msg31384#msg31384
....
In some close future, there will not be a conversion requirement.
I do not need conversion at home since 3 months I guess 

Reply 12
http://theoven.org/index.php?topic=2722.msg31410#msg31410

If You Want PESE Features - Then Use PESE Project
The Goal of XPE was not to be PESE

Win10XPE a rather simple in its design and at the same time fairly complete project .
With a simplified user interface and fewer options.

Reply 13
http://theoven.org/index.php?topic=2722.msg31411#msg31411

And YES, this "Fabricated Incompatibility" was by Design.
As ChrisR had no desire to continue to support the PESE project with a History of supporting every version of windows.
Thus we now have Extend Support for the PESE Project and a Reduced (Windows 10) Project in XPE

Reply 14
http://theoven.org/index.php?topic=2722.msg31412#msg31412

And YES, this "Fabricated Incompatibility" was by Design.

Reply 15
http://theoven.org/index.php?topic=2722.msg31414#msg31414

(...something about the floodgates opening...)