Fabricated Incompatibility Win10XPE Discussion

Reply 16
http://theoven.org/index.php?topic=2722.msg31416#msg31416

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

Design -> Intentional

And your further post only hides your real goal,
 you like to put your name on plugins that is all. 

As ChrisR had no desire to continue to support the PESE project with a History of supporting every version of windows.

NO: PESE have no such "primary goal" to support every version of windows !
only it is quite easy to do such a thing with Win10PESE.

Thus we now have Extend Support for the PESE Project and

Win10PESE Extended support will continue to no extent.
From Atari800xl point of view, Flood gates are open. 

a Reduced (Windows 10) Project in XPE

No
%GTools% -> %Tools%   
etc.
have nothing to do with such a fake reason.
Anyone can create a "Reduced" (Windows 10) project without breaking compatibility of plugins.
Well the only idea is writing James name on plugins,
 fine to me,
  but have a self-respect and post correct arguments on topics,
   no need to hide behind a fake reason.


next project with %FTools% is enough to "fabricate" fake reason write another name on plugins. 
 
In reality, one do not need a fake reason for that, this only cause incompatibility that is all.

Come on

Reply 17
http://theoven.org/index.php?topic=2722.msg31417#msg31417

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

If You Want PESE Features - Then Use PESE Project

I agree, only from another point of view.
 

Reply 18
http://theoven.org/index.php?topic=2722.msg31424#msg31424

My Goal is to Support ChrisR's XPE Project..
And appear to be the only one do so by Creating 3rd Party Member Optional Program Plugins..
I have no need to follow other plugins, as I have long history of plugin creation in this forum..
But, yet then we ALL seem to follow the same process that works..

Lance,
Over the years I have learned a lot from you, from your posts and this forum.
You have helped me figure many things out along the way.
And for that I offer my sincere sense of gratitude..

Reply 20
http://theoven.org/index.php?topic=2722.msg31426#msg31426

Hi James,

No need to jump posts with words "Fabricated Incompatibility"
It is to me "Fabricated" and I always stand behind my words unless It is proven wrong. Eg. Respod to your post
So far on various posts and topics not proven.
.............
Shortly I call this "Fabricated Incompatibility" you call it "Incompatibility"
In the end plugins developed so far not compatible to Win10XPE direclty.
( well I use them with Win10XPE here anyway )


You miss a point ( a lot but I decide to not mention on this post )
An end user  Bigbadmoshe ask for help to get some Win10PESE plugins work with Win10XPE
Reply 8
http://theoven.org/index.php?topic=2722.msg31404#msg31404

Your post acts like an Amigo Leader that only serves to give reason to have fun to some posters but  not Bigbadmoshe.
I am sure It will be very easy to help Bigbadmoshe when he feedbacks.

Your post : I mean things you write, not personally you.

@Bigbadmoshe

It is an now old thing that comes and goes, It will slowly settle down in future,
 your post do not cause an issue, after your feedback things will continue 

Reply 22
http://theoven.org/index.php?topic=2722.msg31433#msg31433

I wanted to answer on the off-topic, but you were faster
(
It seems that we are on a loop about the incompatibility or fabricated situation. Not very cheerful

Again, if useful!
It is clear that it was initially designed to be independent of WB, SE. It was intentional
I was focused on the new design, free and independent, without really wanting to go further.
No plugin, so no incompatibility with them, no competition ... 

Then some requests to add Apps arrived
I tried to explain myself here
Also, the reading of "Win10XPE Project" topic speaks for itself on the creation of the first plugins and macros
example to integrate firefox 55.0.3 64-bits manually Reply #34
how to integrate an application Reply #59 and following post
No simple way to use the existing plugins and more than 80 plugins developed before you came back to bring back the lost sheep
I like the simplicity and the building speed of Win10XPE so no really desire to change on my side

It results on 2 branches, not really great but most users can live with that and so do we.
I'm going to stop justifying myself of the choices made, I Kown I can't convince you.
But I hope I'm not going to see a new fabricated situation from this state.

Closed parenthesis on my side.   

It's probably because I didn't close it  Closed parenthesis onmy side too
)
I wouldn't want to have to move, sorry for the inconvenience,

Hi Chris,

here is
{
*

It seems that we are on a loop about the incompatibility or fabricated situation. Not very cheerful

after 8 years it is the first time such thing happening and have expected results.
( or you should expect ! )

Again, if useful!
It is clear that it was initially designed to be independent of WB, SE. It was intentional
I was focused on the new design, free and independent, without really wanting to go further.
No plugin, so no incompatibility with them, no competition ... 

Again, if useful, I replied this many times before:
Last time Lancelot Reply 14 http://theoven.org/index.php?topic=2697.msg30546#msg30546

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 !)

*

Then some requests to add Apps arrived
I tried to explain myself here
Also, the reading of "Win10XPE Project" topic speaks for itself on the creation of the first plugins and macros
example to integrate firefox 55.0.3 64-bits manually Reply #34
how to integrate an application Reply #59 and following post
No simple way to use the existing plugins and more than 80 plugins developed before you came back to bring back the lost sheep

Naturally such requests arrive, it is the same story of all projects, and things continue as expected,

That is the reason I ask you to inform me when such thing start to happen with my reply 2018-03-11 when you start the project without any public topic.

but you did not inform !

Again, if useful, I wrote this many time before
Last time Lancelot Reply 14 http://theoven.org/index.php?topic=2697.msg30546#msg30546

+
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 like the simplicity and the building speed of Win10XPE so no really desire to change on my side

Me again writing same things :

Simplicity and Speed:
+
Simplicity fine to me.
Fabricating incompatibility is not related to Simplicity or Speed..
As I wrote before %Tools% %GTools% , come on....

You did not need to change such things for simplicity.
 Please do not hide behind such changes with such reason "Simplicity"
   Microsoft can make all .cmd files on the internet fail by only changing cmd variables and some commands:
     eg.
     %Temp% -> %GTemp%
     %SystemRoot% -> %GSystemRoot%
     copy ---> gcopy
     cd ---> gcd
     etc...
     And if Microsoft does such thing and says they did that for simplicity, I am sure all will laugh including you.

+
Speed is not related to simplicity,
 Speed is wimlib-imagex.exe (I have not compare with 7z yet)
   Big Thanks to you  and wimlib  for introducing a faster way to build PE using wimlib-imagex.exe. 
     You will see Win10PESE (and probably other SE after some time ) will have a similar or faster speed in passing time.

*

It results on 2 branches, not really great but most users can live with that and so do we.
I'm going to stop justifying myself of the choices made, I Kown I can't convince you.
But I hope I'm not going to see a new fabricated situation from this state.

There is no reason to justify yourself of the choices you made.
 But to me no need to give wrong arguments which make me reply current and previous posts.
eg.
You like %GTools% only because you like G , fine. 
-> It fabricates incompatibility, again fine. 
--> You do not want any compatibility with any way, again fine. 
---> reason, unknown, again fine. 


It is what it is, to me you fabricate incompatibility which only serves James and some Amigos.

It is to me still "fabricated incompatibility".

So far I respond all your related posts and arguments with also providing proof of concept .....
eg. 3 months ago compatible Win10XPE was building faster and simple.

There are 4 or 5 ways to get plugins work directly with Win10XPE, I had provided 2 of them, you do not want to, end of discussion. On my side I like to work on 5th way when I find some time....

On other topic (reason we are here), James jump to words "fabricated incompatibility" !
 James aware of this situation is fabricated since he benefits most, I do not know why he reacts that way.

On the other hand:
Regular Users around also already aware of "fabricated incompatibility", it is fun watching their response. (smile of the day  )
James - use  "fabricated incompatibility" to remove names and put his name to xpeplugins hiding behind
"Support ChrisR's XPE Project.."

My Goal is to Support ChrisR's XPE Project..
And appear to be the only one do so by Creating 3rd Party Member Optional Program Plugins..

Atari800xl - likes the flood with things what James do
dazza - likes to smile with things what James do
etc.
Like All other Amigo on forum world
https://cbssanfran.files.wordpress.com/2013/01/159554099_8.jpg?w=594&h=1&crop=1
 


Others, like Bigbadmoshe etc. will always fail with available plugins because of "fabricated incompatibility".

It's probably because I didn't close it  Closed parenthesis onmy side too

Closed parenthesis on my side.   

You should know, I already closed parenthesis and move on, life goes,
I have no intention to convince you to do something about this since 3 or more months,
 or no intention to create discussion.

Unlike amigos, you know I am quite busy updating plugins on my side recently.









********
And reminding, as I wrote on other topic:

It is an now old thing that comes and goes, It will slowly settle down in future,
 your post do not cause an issue, after your feedback things will continue 

I hope with all these posts, it is settling down now on your and James side.








*********
Better write last words to underline things:

* It is to me (and as you can see as well as others)  "fabricated incompatibility" -> when you give Microsoft example above to anyone they will react same. 

I will call this "fabricated incompatibility" with reasons given including current post,
 I am fine and very clear it is intentional since 3 or more months


With other words:
* I am fine with "fabricated incompatibility" 

As I wrote before and shortly here: I see half full glass with "fabricated incompatibility"  ..... 


ReClose parenthesis on my side.   

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

Hi Bigbadmoshe,

do not change Type=
change Author name
eg.
Author=Bigbadmoshe
-->
Author=Bigbadmoshe converted with CodeCheckerXPEPlugin

or whatever.
Type= value reserved for Type, such Type values you write will fail in some future....

On the other hand:
Regular Users around also already aware of "fabricated incompatibility", it is fun watching their response. (smile of the day  )
James - use  "fabricated incompatibility" to remove names and put his name to xpeplugins hiding behind
"Support ChrisR's XPE Project.."

Again feels there are two conflicting points of view on Author..
And there is no personal benefit from sharing XPEPlugins created - Except for the Benefit of Others..

Well use things provided with the project and available xpeplugins by mostly James. Life will be easier for you.
And so far it is a complete project and can be used for PE stuff, with a great set of xpeplugins.

Thank You
Those Are Kind Words About The XPE Project

Again feels there are two conflicting points of view on Author..
And there is no personal benefit from sharing XPEPlugins created - Except for the Benefit of Others..

The author never has conflicting points of view. 

1st quote on your post is to use correct "Type" and preserve "Author" name of the original plugin.
eg:
Type=Plugin
Author=KYHI
-----------------Converter or whatever ---- >
Type=XPEPlugin
Author=KYHI converted with CodeCheckerXPEPlugin

Like slore do with WimBuilder.


2nd quote  on your post:
Only about James fake excuse to delete author names using fabricated incompatibility.
not related to the first quote
also mentioned on other topics
eg.
reply 9 10
http://theoven.org/index.php?topic=2695.msg30510#msg30510

an update:

James - use  "fabricated incompatibility" to remove names and put his name to xpeplugins hiding behind
"Support ChrisR's XPE Project.." + with another fake excuse "I am not good with history"

As I wrote before:

It is what it is, to me you fabricate incompatibility which only serves James and some Amigos.

3rd quote  on your post:
A new user like Bigbadmoshe would have no idea what is going on.
proof: Bigbadmoshe posts on other topic around http://theoven.org/index.php?topic=2488.msg31474#msg31474

Advice to Bigbadmoshe is same as to cretino
reply 629 http://theoven.org/index.php?topic=2488.msg31384#msg31384
--> give a basic path to avoid fabricated incompatibility



======>
If such incompatibility was not fabricated, we would not have troubles like cases with
cretino, Bigbadmoshe, dazza ... and current topic ....

It is fabricated incompatibility, these are expected results (at least by me) and life goes....

+
Also better change Title of other topic to give the impression to new users with search engines,
 "Plugins not compatible with XPEPlugins "

http://theoven.org/index.php?topic=2607
Win10XPE Optional Member Plugins
eg.
-->
Win10XPE Optional Member XPEPlugins
-->
....

Time passes, no parenthesis,
Fabricated Incompatibility continues expected results , just writing here 2 posts for history:

1)
Windows Media Player Plugin:
Started with Oscar Reply 19
http://theoven.org/index.php?topic=1359.msg31568#msg31568
I guess Oscar convert this to Plugin, feedback for Win10PESE saying no need .net framework
James need to verify with Win10XPE
and continues etc. etc. etc.
At one point Lancelot will upload to Win10PESE ....
James-Win10XPE + Oscar-Win10PESE + Oscar update info + James update + Lancelot add to server.

expected results of re re re circle, like Oscar wrote in the past:
http://theoven.org/index.php?topic=2421.msg28158#msg28158


See you next post.

2)
It is funny indeed.
*

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).

That was the reason not to get compatibility back ~3 or 4 months ago.
Today:

Teik some of the existing Features Now Use the New Macro(s) included in the Newest XPE Macro Library
Because of this, the older Projects folder should be completely over-written with New Project Release

Same could be made 4 months ago to get compatibility back with the same excuse by James..

**
anyway, life goes. only writing above for history...

Having a quick look to latest package Win10XPE_2019-02-18
2 more expected results of Fabricated Incompatibility I notice :

1)
As expected,
not sure but I see you set get %FallBackLanguage% without last |
It was that way with all SE anyway, fix already made Win10XPE Plugin compatible package ~ 4 months ago...

wasted time....

see you next post...

2)

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.

Although replied to that, It seems you miss Require_FileQ 
you have new syntax ExtractWimFile and ExtractWimFileMui,

XPEMacro:
ExtractWimFileMui,\Windows\System32\ntdll.dll
=
MacroLibrary:
Require_FileQ,ntdll.dll

rest of ExtractWimFile and ExtractWimFileMui duplicate ExtractSectionFiles ....

ps: Require,FileList already have index, sourcewim etc. options since Date:2018.11.07 , ~3.5 months ago....
etc. etc....

well I leave design troubles to your side......
But reminding, such bad design mostly give trouble to converters like Oscar.


*******
Anyway,
The funny part is a reinvention of Require_FileQ, macro which you used a lot on your arguments for Fabricated Incompatibility ....

So far all your arguments fail or double fail from my point of view.
Still, I have no expectation,
Life goes. only writing above for history...

Not really surprising, I expected it
Just few points to avoid that some quotations taken out of context are confusing in this Fab.Funny thread

Set %FallBackLanguage% without last |
Has indeed been modified to get the right number of Mui Language, as in SE, with:
StrFormat,Split,%FallBackLanguage%,|,0,%nblang%

The 2 new macros have been created for more flexibility in the code behind Build Core.
They are only to be used Occasionally. For a list of files, it is better and faster to use the ExtractSectionFiles macro
I maintain my argument: will always be less efficient... mainly if overused

I didn't miss either Require_FileQ but as you probably saw, it's not really the same.
I tried to make it flexible enough to do All in one
They accept Wildcards (* ?), a Target Folder (or preserves the dirs structure) and the Image Index

Example of Current use:

Code: [Select]

// comctl32.dll.mui Exist in All Language Folders if done with \Windows\System32\??-??\comctl32.dll.mui
ExtractWimFileMui,\Windows\System32\comctl32.dll
// tipresx.dll.mui Exist in All Language Folders (for SnippingTool)
ExtractWimFileMui,\Program Files\Common Files\microsoft shared\ink\tipresx.dll
// Wildcards, Target Folder and Index for smb 1.0 driver
ExtractWimFile,\Windows\WinSxS\*_microsoft-windows-smb10-minirdr_*\mrxsmb10.sys,%GTarget_Sys%\Drivers,1
// Wildcards and Variable
ExtractWimFile,\Windows\WinSxS\x86_microsoft.windows.c..-controls.resources_*_%Language%_*

Although replied to that, It seems you miss Require_FileQ 

Busy the next few days so see you soon, Life goes 

Hi Chris,

It is great you, at last, understand I am having fun with Fabricated Incompatibility after I could hardly understand It is intentional. 

Well not only fun, You know I always stand behind my words,
after understanding lately there are pm games behind things... which probably use a bended logic,
 It is better to write what I am writing about with real life examples.

eg.
Reply 26 http://theoven.org/index.php?topic=2697.msg31484#msg31484

Again feels there are two conflicting points of view on Author..

responded
Reply 27 http://theoven.org/index.php?topic=2697.msg31504#msg31504

The author never has conflicting points of view. 

replying your post with 2 posts, 1-technical and 2-main point.

1)-technical
*
I see you explain ExtractWimFileMui, features...... Yes I see them before your post.
I already respond to these features :

well I leave design troubles to your side......
But reminding, such bad design mostly give trouble to converters like Oscar.

There will also be other troubles (I do not mean speed) on your side with ExtractWimFileMui, features.

I will try to post here as proof of my words when they come up around and I notice.

*

I maintain my argument: will always be less efficient... mainly if overused

We already share same with this argument.
Require,FileList already used with "CMD Adds" and new Win10PESE\Components\"MS Windows Media Player" plugins .

what we do not share is, we do not need Fabricated Incompatibility for such speed gain. Proof: "CMD Adds" + "MS Windows Media Player" ..... plugins. (and others in passing time...)

*
In fact Require_FileQ support things ..., that made Oscar conversion work ....
see codes
http://theoven.org/index.php?topic=1359.msg31568#msg31568

When Win10PESE use BuildClass 3 default (like Win10XPE),
 It will be easier for me to see what is required on that area.
  For now, in theory, I do not see any reason for the expansion of this syntax or things like ExtractWimFile and ExtractWimFileMui, ... Time will show....

*
%FallBackLanguage% without last | is only result of wasted time with Fabricated Compatibility....
I am sure there are more,
I just remember that since I had fixed that 3.5 months ago at times I was not aware Fabricated Incompatibility is intentional.

See You on next post.....

2) Main point:

I didn't miss either Require_FileQ but as you probably saw, it's not really the same.

Come on, you miss Require_FileQ but you can not admit it now. 

Anyway, without Fabricated Incompatibility, Life would be easier without wasted time

*
 %FallBackLanguage% without last | is an example for core development wasted time

*

The time and effort

One of the Expected results of Fabricated Incompatibility, or you should also expect when you were having fun to send The time and effort for plugins to trash.... 

==>
More "The time and effort" lost with circular development :
Reply 44 http://theoven.org/index.php?topic=1359.msg31764#msg31764
Reply 43 http://theoven.org/index.php?topic=1359.msg31766#msg31766

*
Similar to "Media Player" topic case:
I guess following steps:
- James XPEPlugin
- Oscar Plugin
- James XPEPlugin
- Oscar Plugin
- James XPEPlugin
- Lancelot Update Oscar Plugin to server
- next expected steps
- Oscar feedback
- Lancelot Update Oscar latest feedback to server
- James follow Oscar latest feedback

Re re re re , circle circle circle circle , It is funny from one point

First there was James
XPE code checker (aka PESE2XPE converter)
then oscar wrote
XPE2PESE converter (an 180º turn of XPE code checker)
now there is Prz42
PESE2XPE converter (an 180º turn of XPE2PESE converter, and de facto a 360º turn of XPE code checker)

 

well not funny for wasted development time ...

only some amigos do not have trouble with wasted time anyway, they like to cheer with flood...
 

+
After initial "My Computer - Name" topic http://theoven.org/index.php?topic=778.0
Plugin served well and served for all projects for years.

Today with Fabricated Incompatibility :
some Computer Name improvements started somewhere here (not sure)
http://theoven.org/index.php?topic=2621.msg28908#msg28908
improved at Win10XPE
feedback by sandy reply 707 http://theoven.org/index.php?topic=2488.msg31769#msg31769
update ChrisR for Win10XPE
feedback by Lancelot and update for Gena Win7PESE Win8PESE Win8.1SE Win10PESE
--> probably next step update ChrisR for Win10XPE with feedback by Lancelot or keep it simple decision.
--> maybe other next steps...

*
there will be other expected stories, at different levels of project development..... above are easy examples not easy to write all....



And final words on next post ....

*
and as expected, your XPEMacro will bet bigger and bigger in time,

Few macros used to simplify the use and for a faster build.

==>
You main motivations
"Win10XPE is new, simple, independent" and "stand-alone"

will be lost in time (passing time proves, and more time will pass that will serve to prove my words)
only left thing behind will be "Fabricated Incompatibility" , that is all.

It is what it is, to me you fabricate incompatibility which only serves James and some Amigos.

with floods and smiles. 

sad part is, wasted time....

***
Anyway,

Not really surprising, I expected it

Progress 
I am happy you now more understand where I stand for,
I am at fun part of Fabricated Incompatibility related things. 

The half glass is full 

It appears "XPE Feedback and Tested" serves everybody well...

In Regards to 3rd Party Programs (ie Media Player and ABU)
All I've seen is Failed Attempts To Follow or Convert working XPEPlugins
And most conversions require correction, But that is left in the hands of others..

So Yes, Testing and Feedback should and does Help everybody - if they choose to follow it..
That is Development - to improve and move forward without pointing fingers..

Out of current topic but you trying to bend logic is quite funny indeed.

It appears "XPE Feedback and Tested" serves everybody well...

From your point of bended logic, I can also say:

It appears "Win10PESE Feedback and Tested" servers everybody well...

Recent Proof:
Reply 30 http://theoven.org/index.php?topic=1359.msg31579#msg31579

As I Have Not Received Any Feedback Regarding Windows Media Player Since My Conception 7 Months Ago..

Good you have tested feedback from Win10PESE 

and even more Recent proof.

15 char Limitation only valid for
ComputerName\ComputerName,ComputerName
ComputerName\ActiveComputerName,ComputerName
( I did not test separately )

which is "Win10PESE Feedback and Tested"


More Proof:
All your "reconverted" plugins come from tested Plugins from projects Gena Win7PESE Win8PESE Win8.1SE Win10PESE and from plugin server Yomi.
I did not count number of plugins you reconvert, 100 and more I guess..

As I wrote before:

It is what it is, to me you fabricate incompatibility which only serves James and some Amigos.

What you wrote have nothing to do with Fabricated incompatibility.

From your "serve well" point, related part to "Fabricated incompatibility" is :

+
Gena served well to Win7PESE, without a Fabricated incompatibility, plugins directly work out of box.
+
Gena and Win7PESE served well to Win8PESE, without a Fabricated incompatibility, plugins directly work out of box.
+
Gena and Win7PESE and Win8PESE served well to Win8.1SE, without a Fabricated incompatibility, plugins directly work out of box.
+
Gena and Win7PESE and Win8PESE and Win8.1SE served well to Win10PESE, without a Fabricated incompatibility, plugins directly work out of box.
+
Today,
Gena and Win7PESE and Win8PESE and Win8.1SE served well to Win10PESE, without a Fabricated incompatibility, plugins directly work out of box.
and naturally Win10XPE serve well to Win10PESE (and opposite), with Fabricated Incompatibility, causing wasted time for both projects.

Well, as I wrote before,
Fabricated Incompatibility only serves James and some Amigos. Rest is Wasted time.


bended logics, peh...

Yes, Feedback Serves Everybody Well...