Fabricated Incompatibility Win10XPE Discussion

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

Thanks for admitting, conversions because of Fabricated Incompatibility only cause wasted time
+ requires corrections etc. etc.

expected things with Fabricated Incompatibility or you should expect.

Fabricated Incompatibility only serves James and some Amigos. Rest is Wasted time.

*

That is Development - to improve and move forward without pointing fingers..

Yet another kind of bended logic,
 remind me a topic name "WinBuilder development should go!" where wrong decision made with a fake excuse like yours. Result, winbuilder died.
 (as Expected by me, also should be expected by winbuilder developers  )



Fabricated Incompatibility do not serve to improve and move forward,
It is natural path of any development PE or not.
eg. VersionTabXP http://theoven.org/index.php?topic=1720.msg31775#msg31775

Fabricated Incompatibility only Serves James so far to delete and write reconverted plugins Author names,
 which has nothing to do with improvement or move forward.

Recent Proof: Win10PESE improve and move forward without Fabricated Incompatibility.

 

I think it is all about Choice.
Some may like a full Size package and others may like a sub-compact package..
I'm aware that the sub-compact fits in the trunk of your full-size..
Yet I choose to drive the sub-compact model

Yes, Feedback Serves Everybody Well...

Fabricated Incompatibility only serves slower Feedbacks and slower development to improve and move forward (with your words)

Recent Proof.

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

Funny, you wrote "to improve and move forward" but you sabotage "to improve and move forward"  with Fabricated Incompatibility
Like Frauds do. 

***
At PE world,
These are things we had lived with BartPE, Reatogo, SherypaXPE, UBCD4Win, VistaPE, LiveXP ..... times
They all had motivation "Development to improve and move forward"
But they failed at one important point (like also winbuilder).
Development and improvement on one of them can not be used by other or not shared, or totally forgotten.
And other reasons.....


After current forum created and with projects Gena, Win7PESE, Win8PESE, Win8.1SE  Win10PESE
Such failure never happened since 8 years.

Flood lover Amigos not aware since everything work out of box all these years,
and that was the reason you could convert more than 100  plugins easily. (one day I will count  )


Today, with Fabricated Incompatibility for your Author name on it, revert back to 8 years . peh.

You are not aware yet with the self-satisfaction of your Author name on xpeplugins,
 Fabricated Incompatibility will not only cause bad times to regular users conversion troubles,
  Will also cause bad times to your selling "improve and move forward" development ideas,
    Time will show to you.  or with new posts at the current topic in passing time. 

You work too fast to bend logic with each post. 
I hardly catch you. 

I think it is all about Choice.
Some may like a full Size package and others may like a sub-compact package..
I'm aware that the sub-compact fits in the trunk of your full-size..
Yet I choose to drive the sub-compact model

Well, you again write things and do the opposite. + including 2 bended logics ...

**
In reality, there is no sub-compact model or full-size, I will only respond to your sub-compact model or full-size approach.

**
Initial Win10XPE motivation is:
"Win10XPE is new, simple, independent" and "stand-alone"
-->
with your words: sub-compact model

Today, It is not  sub-compact model anymore.
It is getting to your full-size. 

Previous Proof: Filling Project with lots of reconverted and created xpeplugins and other thigns.
Recent Proof: new macros ExtractWimFile and ExtractWimFileMui I am sure requested by you.

Shortly, you are pushing Win10XPE sub-compact model to be full-size !
No need to pretend on posts (post games) you like sub-compact .

Would have to say you are reading into things that are not true...
Yet, any attempt I make to support Full Size project has been met with a text book lesson and heavy resistance...

As a something do as an experiment (XPECodeChecker) was created to change the PESE project variables to XPE project variables
It was not a Converter and this fact was clearly noted within the interface..

After XPEPlugin testing Started > Oscar Created a XPECodeConverter - to convert XPE Varaibles to PESE (Not really sure of his process as have not seen)
Then Prz42 re-created Oscar's XPECodeConverter to PESECodeConverter (Thus The 360 Return back to where I first began - and the Joke to Prz42)

At that time there was No Intentional Compatibility between the Two Projects...
That Intentional Compatibility came much later by your efforts..

The XPEPlugin that are Posted, in this forum, which are in clear open sight for all to view
Those XPEPlugins where Created by the heavily modified and edited version of your PESE Plugin Creator(s)
with nothing to hide and all work and processes completely shared for all to see..
Yes, there are clearly duplicates of existing PESE Plugins in XPE - again not hiding anything...
But I can tell you as fact, just converting variables was not always enough..

James James....

Jumping from argument to argument, here is my respond:

*

Would have to say you are reading into things that are not true...

Well I am always open to public topic discussions instead of pm games
self-proof:  Even a lot years before you, I always discuss things open to the public. (Like current topic)
 So far Time always proves I am right. -->  You can reconfirm this argument with Chris or others who know me for years.

If not true, prove public. 

Yet, any attempt I make to support Full Size project has been met with a text book lesson and heavy resistance...

You again use 2 bent wrong logic.
1)
With your words :You provide a textbook lessons to others on xpe topics when they try to write xpeplugins or require feedback.
You follow 2 paths so far on topics:
a)
 In the end you rewrite them with Author=James with saying "taking liberty of reconverting plugin" fake excuse or mostly without writing anything to public topic.
 Proof: one of example like many others: you convert Prz42 Run MRU xpeplugin to Author=James xpeplugin only because Prz42 missed reading your text book to delete "Lancelot" name from xpeplugin.   
   There are too many that fits a)  Funny from one point of view. 
+
b)
You write and expect others to read and follow like all rest who feedback.
eg.
http://theoven.org/index.php?topic=2421.msg31047#msg31047
http://theoven.org/index.php?topic=2421.msg31673#msg31673
http://theoven.org/index.php?topic=2607.msg31368#msg31368

b2)
and when required you provide a long textbook to be read by end user, expected to be followed by end useres
eg.
http://theoven.org/index.php?topic=2631.msg31547#msg31547
to demonstrate "textbook" here is quoted:

If anything else is wrong, just let me know.

Ok I See A Few Things To Test

[Variables]
%ProgramTitle%=GImageX
%ProgramExe%=gimagex.exe
%ProgramExex64%=gimagex_x64.exe
%ProgramFolder%=GImageX
%SetupFile%=GImageX.zip
%SetupFilex64%=GImageX.zip
%FileContainer%=%ScriptDir%\GImageX_XPE_File.Script

[Process]
Echo,"Processing %ScriptTitle%..."
If,Not,ExistFile,%FileContainer%,Exit,"%FileContainer% Container File Not Found"
If,%RunFromWhere_ScrollBox%,Equal,"Run From RAM",RunFromRAM
If,%Architecture%,Equal,x64,Run,%ScriptFile%,PluginSetx64
//--
//--To Enable (TargetAppDataLocal-TargetAppDataRoaming-TargetProgramData) Variables
//AddVariables,%ProjectDir%\script.project,TargetBasePath
//--
Run,%ScriptFile%,Extract
//--
If,ExistDir,%Target_Prog%\%ProgramFolder%,DirDeleteQ,%Target_Prog%\%ProgramFolder%
If,Not,ExistDir,%Target_Prog%,DirMake,%Target_Prog%
If,Not,ExistDir,%Target_Prog%\%ProgramFolder%,DirMake,%Target_Prog%\%ProgramFolder%
DirCopy,%GTemp%\%ProgramFolder%\%ProgramFolder%,%Target_Prog%
FileCopy,%GTemp%\%ProgramFolder%\%ProgramFolder%\%ProgramExe%,%Target_Prog%\%ProgramFolder%
//--
Run,%ScriptFile%,Add_Shortcuts
//--
//ExtractSectionFiles,%ScriptFile%,AddFiles
//--
//Run,%ScriptFile%,Add_Registry
//--
//Run,%ScriptFile%,Add_Associations

[AddFilesInfo]
//- Extract files or folders from Install.wim image. Script Commands are not allowed
//- Each path must be specified as an absolute path starting from the root.
//- Wildcard char ’?’ and ’*’ are allowed. A comment begins with ;; (semicolon). ;;Example Comment

[AddFiles]
\Windows\System32\xxx.dll
\Windows\System32\??-??\xxx.dll.mui

[Add_Registry]
//- Add Registry Values <-- Use RegCPE

[Add_Associations]
//- Associate,Ext <-- Three Letter File Extension

[Add_Shortcuts]
If,%Desktop_CheckBox%,Equal,True,AddShortcut,Desktop
If,%StartMenu_CheckBox%,Equal,True,AddShortcut,StartMenu,%StartMenuFolder_TextBox%
If,%StartMpin_CheckBox%,Equal,True,AddPin,StartMenu
If,%TaskBpin_CheckBox%,Equal,True,AddPin,TaskBar

[Extract]
If,ExistDir,%GTemp%\%ProgramFolder%,DirDeleteQ,%GTemp%\%ProgramFolder%
DirMake,%GTemp%\%ProgramFolder%
ExtractFile,%FileContainer%,Folder,%SetupFile%,%GTemp%\%ProgramFolder%
//ShellExecute,Hide,%GTools%\7z.exe,"x #$q%GTemp%\%ProgramFolder%\%SetupFile%#$q -y -aou -o#$q%GTemp%\%ProgramFolder%\%ProgramFolder%#$q"
ShellExecute,Hide,%GTools%\7z.exe,"x #$q%GTemp%\%ProgramFolder%\%SetupFile%#$q -y -o#$q%GTemp%\%ProgramFolder%\%ProgramFolder%#$q"

[PluginSetx64]
Set,%SetupFile%,%SetupFilex64%
Set,%ProgramExe%,%ProgramExex64%
//Set,%ProgramFolder%,%ProgramFolder%_x64

Green will copy just the required program.exe (and just process as required)
Red is a Must To use proper arch exe with some possible error
Blue If Same Then use is Optional Use

2)
You support Full Size project never had any resistance.
 You and anybody are always free to create and share plugins around with mediafire etc. like you are doing today.
  You had trouble elsewhere which is not related at all.
Proof:
Win10PESE Full Size path continue with new plugins , recent examples:
Components\MBR2GPT - Bob.Omb
Components\EasyMBR2GPT - Bob.Omb
Components\MS Windows Media Player - Oscar
Components\Slide to Shutdown (Tablet PCs) - Bob.Omb
Components\Steps Recorder - Bob.Omb
....
And another Proof:
end users free to share their own version of plugins
eg.
Prz42 plugins http://theoven.org/index.php?topic=1983
----> eg Prz 42 version of "Run Tweak" plugin  http://theoven.org/index.php?topic=1544.msg21927#msg21927
available for a long while, like many other plugins around on topics.



*****
Maybe you are bad at reading textbooks like you are bad at history. 

Reminding: your writing "I am bad at history" is a fake excuse by you to delete names on plugins during re re convertions. 


**********
Like previous post,
You again write things and do the opposite with double bent logic.
-->
You complain about textbooks written to you but you write textbooks to others. 
with your words:
Again feels there are two conflicting points of view on Author..     

since textbook long quote, see you on next post.....

*

As a something do as an experiment (XPECodeChecker) was created to change the PESE project variables to XPE project variables
It was not a Converter and this fact was clearly noted within the interface..

After XPEPlugin testing Started > Oscar Created a XPECodeConverter - to convert XPE Varaibles to PESE (Not really sure of his process as have not seen)
Then Prz42 re-created Oscar's XPECodeConverter to PESECodeConverter (Thus The 360 Return back to where I first began - and the Joke to Prz42)

It was funny and at the same time sad reading that things around. It seems somebody did not study the textbook well. 

1 big drop of The half glass is full part was, such posts made me realize what you are doing.

*

At that time there was No Intentional Compatibility between the Two Projects...
That Intentional Compatibility came much later by your efforts..

Well you are looking from a very narrow point of view, or you are trying push discussion to a very wrong direction. (your future posts will show)
It is not about Two Projects.

Around 1 year ago, ~ 2018-03-11 , Intention of Win10XPE written to me by ChrisR "Win10XPE is new, simple, independent" and "stand-alone""

A core project by design do not have Incompatibility troubles at all which we face today.
 I asked ChrisR to inform me when time come to evolve to next step ~2018-03-11 and left forum for a long while.
  I was not informed.

All written Reply 9 of current topic. http://theoven.org/index.php?topic=2697.msg30492#msg30492

Well since I was not informed and I was not around,
 It seems this situation open gate to a Fabricated Incompatibility which only so far serves to James rewriting xpeplugins with own Author Name.
 
 It does not serve to ChrisR initial idea of "Win10XPE is new, simple, independent" and "stand-alone""

Well next step will be syntax design failures, which seem to be started now with ExtractWimFileMui andExtractWimFile ...
 keeping short, as written on my previous posts, I will respond to current topic with real life examples about failures when they start to happen.
  The natural result of Fabricated Incompatibility .....
    This also happened before elsewhere (not here), I am good with history and always took lessons. 

The XPEPlugin that are Posted, in this forum, which are in clear open sight for all to view
Those XPEPlugins where Created by the heavily modified and edited version of your PESE Plugin Creator(s)
with nothing to hide and all work and processes completely shared for all to see..
Yes, there are clearly duplicates of existing PESE Plugins in XPE - again not hiding anything...
But I can tell you as fact, just converting variables was not always enough..

With nothing to hide but delete any history or author info.
with your words:
Again feels there are two conflicting points of view on Author..   

See you on next post for final words... It takes long time to respond to double bended logics with proof.
ps:  There are more proof, I hope above enough.

As last words,

reminding current topic Lancelot Reply 6:

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.

Well ALL will not live troubles of Fabricated Incompatibility if we could get Type=Plugin working with Win10XPE one way (MacroLibrary) or other (Win10XPEMacro)

Naturally, I prove first way with MacroLibrary  ~ 4 Months ago. Only 7 days self proves MacroLibrary well written. 

One way or another, if that was made:
+ James would continue creating Add-On packages like he did for Win10PESE about 4 years or more using Type=Plugin without troubles to his Plugins.
ps: I am sure all James Type=Plugin still working, Macro Library has a good textbook idea behind to keep plugins continue work. 
+ And I would be away till Summer leaving rest to Bob.Omb
+ Oscar and Other users will not waste time to reconvert their plugins
+ All troubles and wasted time that happens because of Fabricated Incompatibility gone.

So far Fabricated Incompatibility only serves James having a fake excuse to do things,
 which James could do (or already did with Win10PESE for years) without such Fabricated Incompatibility excuse !


Today, Fabricated Incompatibility only cause wasted time to everybody that is all. So far no argument proves the opposite.


***
Reminding, I see half glass is full. I have no expectation or request to have Win10XPE work with Type=Plugin.


It is quite fun to prove what I wrote 1 year ago
 and 4 months ago
  (and things I write today later in future)
    about Fabricated Incompatibility is correct, that is all. 

I have and will never followed Prz42 - I do not like his coding method - Nor do I trust his uploads or testing..
Oscar Figured out Windows Media Player by following XPEPlugin..
MSTech does not even see the obvious, so went Text Book..

I have and will never followed Prz42 - I do not like his coding method - Nor do I trust his uploads or testing..

To me, It is good and success to see people like Prz42 can write complicated plugins today. 

Well, Run MRU plugin is a very simple example, nobody including Prz42 can fail when converting to xpe 
 Run MRU plugin does not need a convert anyway,
  It is only very funny proof Prz42 only failed to delete Lancelot name and you have the Fabricated Incompatibility excuse
    and now + "I do not like his coding method"
     and take the liberty of creating same plugins. 

Oscar Figured out Windows Media Player by following XPEPlugin..

Probably, but in addition, It seems Oscar already working on Windows Media Player plugins much before xpe (xpe starts with Win10XPE 18xx)
Oscar Reply 23 http://theoven.org/index.php?topic=1359.msg31846#msg31846

My old wmplayer win8.1SE x86  and old builds of win10 x86 plugin.
It works fine here.

Well, Oscar writes plugins with old school BartPE way, in future Oscar may ! need to write both plugin and xpeplugin, thanks to Fabricated Incompatibility.
and we will have a very circular re re re path of convertions 
Oscar BartPE style plugin - standard plugin - standard xpeplugin and continues ........
Oscar BartPE style xpeplugin - standard xpeplugin - standard plugin and continues ........

Thanks to Fabricated Incompatibility, only cause wasted time....

MSTech does not even see the obvious, so went Text Book..

See the obvious is sometimes hard,
We even have a Text Book topic now : "Fabricated Incompatibility Win10XPE Discussion"
 

Not familiar with Prz42  > MRU Plugin
If Referencing > Macrium Reflect Update
Then Prz42 Most likely Followed Others, Same As With ABU Process 

The main subject is not about Prz42 plugins or xpeplugins.

It is only one of the example for the bad consequences of Fabricated Incompatibility, that is all.
- Double wasted time
- using Fabricated Incompatibility excuse to delete Forgotten to Remove Lancelot name with naming "Taking Liberty of creating new plugin"

I missed that one:

But I can tell you as fact, just converting variables was not always enough..

Since Win10XPE did not need bad designed "ExtractWimFileMui and ExtractWimFile" for 8 months or more,
 give me a real life example other than that.
  I wonder what is missing with Win10PESE that cause the Fabricated Incompatibility. 

*
btw, only using %Tools% and %ProjectTemp% get all Launch buttons work with single architecture (%99 x86) plugins.  without Fabricated Incompatibility.

I am sure %GTools% and %GTemp% have a real life reason behind.    (sarcasm)

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

Since this topic created after dazza post with "Offline SFC Repair" plugin compatibility....
 Passing time, naturally Fabricated Incompatibility "wasted time" to create double plugin+xpeplugin (or hybrid) troubles continues.


revolver.mn - O&O DiskImage 12 x86 - x64 All WinPE Projects
http://theoven.org/index.php?topic=2741
->
revolver.mn - O&O DiskImage 12.0 & 14.0 (x86 - x64) Win10XPE
http://theoven.org/index.php?topic=2750

Well It is sad to see after 8 years All WinPE Projects changed with Fabricated Incompatibility.

Flood lovers never know the days different plugin for each project.....

*
Side by side with similarity dazza post with "Offline SFC Repair", time to underline another thing about Fabricated Incompatibility, on next post...

At Teik's request, I adapted the Previous Plugin to run with this new version of WinPE.

It seems revolver.mn get the pm, like many others. 

pm based development always have bad things behind,
 I remember from BartPE days on 911cd forum topics 10 or more years ago....
  Although not obvious at first look and looks normal,
   In time you understand real intentions and real goals behind with some sneaky people or hidden intentions,
    which you can catch they pm during topics. 

So far my experience show, using pm for none personal things is bad for all kind of development.
 When I get such pm, I ask the user to open a topic so others can see or benefit from the subject.
  (Proof: anybody who pm me about none personal things  )
  Pm also used to convince others (politics) with bent logics ( bent logics only works with unpublic discussions)
   which I believe is one of the main reason of this Fabricated Incompatibility. 

I also use pm, but with only personal things, not other things.
 Proof: none of the current topic member (or any other) has a pm from me about the current topic subject. There is nothing to hide.

Anyway, I believe open discussions since before this forum (proof, my posts on any other topics including none English)
It seems founders of USA thought the benefit of open discussion and public awareness too.
U.S. Constitution guarantees the freedom of the press in the United States
https://www.thoughtco.com/the-first-amendment-2073720

It seems even at ~1791 (230 years ago, not only 8 or 10 years with my life experience  )
 It was found things open to the public get the community to the better.

Well, I have nothing to hide, and always around for public discussions. 

Anyway, Life goes, as I wrote before, Half Glass to me full with Fabricated Incompatibility,
 I never had intentions to learn PE-nt6x-core since VistaPE,
  It was more fun to work on post-core related things,
    which was causing incompatibility and failures 8 years ago,
     and cause an exponential increase of wasted time in passing time.
     I had success on my side to fix such wasted time. 
      revolver.mn 2 topics is a simple example, there were more, there will be much more,
        unlike 8 years we never lived such a situation. Thanks to Fabricated Incompatibility.  (sarcasm)






Edit:
Next post continues about Launch button with James disrespectfully continue and use a manner to discredit Author .
Here is a copy of posts on other topic related to subject :

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

726

@James
In plugin Beyondcompare-4 section [Launch_Program] doesn't work because %HostOSArch% is empty, it has no value, neither x86 nor x64.

Code: [Select]

Set,%Tapp%,%GTemp%\%ProgramFolder%\%HostOSArch%
//OpenDir,%Tapp%
Start,,%ProgramEXE%,,%Tapp% ?????

728

In plugin Beyondcompare-4 section [Launch_Program] doesn't work because %HostOSArch% is empty, it has no value, neither x86 nor x64.

Hi Oscar,

It is by design, you must build once to get Launch buttons with multiarch xpeplugins work. 

729

I see. Thank you.

730

I was aware of that issue, and it was by design, but it also has unintended consequences (although first report)
So, I have proposed a move of that process to ChrisR..

731

but it also has unintended consequences (although first report)

It should be expected consequences...

As being the inventor of "Launch" button on all plugins since only x86 times :

Not first report, It was reported 9 or more years ago before the current forum ...
 Because of some idiots that always sabotage projects,
  and some forum amigos at those times, which simply cause wasted time,
   It took 3 years to solve that with step by step development

Technically, %SysType% (from Nightman times) and %OSArch% (after JFX or ChrisR) was variables of hostarch.
 Later I develop %HostOSArch% for the Launch button and other things.
  (not implemented to Win10XPE the way I designed, It was added like %SysType% or %OSArch%)
   No failure report around since 7 years or more, and now again. 

   As I wrote before these are Expected results and there will be more.... 

     Just another short note to history, that is all.

732

Thanks for the History Lesson...
History also shows XPE Processes being followed or duplicated...

733

So to Quote Myself for XPE History

I was aware of that issue, and it was by design, but it also has unintended consequences (although first report)
So, I have proposed a move of that process to ChrisR..

734

History also shows XPE Processes being followed or duplicated...

History also shows James follow and duplicate 100 or more plugins, delete others names with an excuse of Fabricated Incompatibility.
  James like follow Win10PESESE other SE and Gena processs.  but with failures, and as written before there will be more. 

So to Quote Myself for XPE History

very funny indeed. Knowing you for years I already know you like to hear yourself a lot.


Anyway, keeping short, what you all wrote after my Reply #731 is about other topics "Fabricated Incompatibility Win10XPE Discussion"
http://theoven.org/index.php?topic=2697.msg31993#new

Launch buttons James duplicated have expected failure and written as a historical post, that is all.

735

I love this conversation.

736

I think the conversation is disrespectfully and used in a manner to discredit Author.

737

XPE has been out almost a year - and we recently received the first report of a bug regarding Launch Button..
It was never considered a bug because you need to make a First Run to populate project and feature variables...
A fix has been proposed to the Author in regards to that Launch Button bug report...
That will fix the Launch Button bug - but it still would not populate the project and features variables...

738

That is how Feedback and troubleshooting 101 is used..
Verify the complaint...
Suggest a fix...
the rest in Authors Hands..

739

So the Fix for this non critical Launch Button issue has been addressed..

740

It is a simple fix - but yet then has been blown into what seems like a major problem.
Although not a concern to any other user for a year now..

just before reply 741, I post to current topic 56 57 58 :

741

I think the conversation is disrespectfully and used in a manner to discredit Author.

I believe you disrespectfully continue something already done with 3 + 2 total posts in a manner to discredit Author.

Enough to me following your disrespect on the current topic,
 I follow my advice to avoid your disrespectful posts in a manner to discredit Author, and respond to you on other topic,
  "Fabricated Incompatibility Win10XPE Discussion" Lancelot Reply 56 and 58 http://theoven.org/index.php?topic=2697.msg32027#msg32027

And a small reply to Bigbadmoshe reply 57 

Hi James,

I do not know what you are after, Fabricated Incompatibility naturally causes circular development, same things again and again.

Started here with Oscar Reply 726
http://theoven.org/index.php?topic=2488.msg31939#msg31939
continue nicely with Lancelot Reply 728
Maybe James Reply #730 required or not
but should end with Lancelot Reply 731 http://theoven.org/index.php?topic=2488.msg31999#msg31999

With your words,
you disrespectfully continue and used in a manner to discredit Author .

I do not have much expectation "respect" from someone who deletes all history and author names that discredits to ALL Authors
 by converting more than 100 plugins to xpeplugins with deleting all history and author info by hiding behind a Fabricated Incompatibility.

Still, with minimum expectation "respect" from you,
   we have current topic If you want to continue. 

I love this conversation.

Civilized public discussions are something I like too.   

Since James decide to disrespectfully continue something that is already finished on other topic, continue here:

I think the conversation is disrespectfully and used in a manner to discredit Author.

There is no discredit Author ! .    Another bended logic ... Further I will follow your fake "discredit" point of view :

Following your words: you disrespectfully continue something that ends with 3 posts.

In plugin Beyondcompare-4 section [Launch_Program] doesn't work because %HostOSArch% is empty, it has no value, neither x86 nor x64.

Hi Oscar,

It is by design, you must build once to get Launch buttons with multiarch xpeplugins work. 

I see. Thank you.

maybe + 2 posts and ends.

with your words:
That is how Feedback and troubleshooting 101 is used..
Verify the complaint...
Suggest a fix...
the rest in Authors Hands..

Points are taken and life goes.

**
I was expecting you continue with posts, and pointed you to use current topic if you want to continue

Anyway, keeping short, what you all wrote after my Reply #731 is about other topics "Fabricated Incompatibility Win10XPE Discussion"
http://theoven.org/index.php?topic=2697.msg31993#new

You disrespectfully continue and used in a manner to discredit Author .
I am only responding to your posts about "Launch button" subject which already ended.... 

Well, that is how life goes. 

@James
In plugin Beyondcompare-4 section [Launch_Program] doesn't work because %HostOSArch% is empty, it has no value, neither x86 nor x64.

I confirmed and verified This Report

Hi Oscar,
It is by design, you must build once to get Launch buttons with multiarch xpeplugins work. 

I confirmed and verified it was by design

I was aware of that issue, and it was by design, but it also has unintended consequences (although first report)
So, I have proposed a move of that process to ChrisR..

I Agreed there are consequences and I Suggested a [process] move as a Fix

That is how Feedback and troubleshooting 101 is used..
Verify the complaint...
Suggest a fix...
the rest in Authors Hands..

I do not agree with the selective quoting and interpretations of my posts...