XPost: alt.comp.os.windows-10   
   From: newyana@invalid.nospam   
      
   On 7/30/2024 12:21 AM, Paul wrote:   
      
   >   
   > #Hello Newsgroups!#The time now is: G#The numbers are: -The even Numbers   
   are: +The Odd Numbers are: a** Hope you enjoyed this short exercise . . .   
   **/##### Bye for now #####   
   >   
      
   This is a shame. I could have used some extra numbers.   
      
   > Do you know whether WINE can run Metro.Apps ? Or Universal Windows Programs ?   
   > Even Windows can't always run the latter ones :-)   
   >   
       I worked with the WINE people very briefly, looking into adapting   
   Windows VB6 software to WINE. The redirect Windows calls (Shim?   
     Some kind of shepherding? I don't understand that part.) Over the   
   years the WINOs have adapted specific Win32 API calls to coorelate   
   WINE libraries. Unfortunately, it's not a 1-to-1 correlation. One user32   
   function might be in one library while the next one is in another   
   library. And of course, no docs to speak of. Real coders don't speak   
   English.   
      
      I didn't last long with the WINE people because they had no interest   
   in sharing information about how I could code to accommodate WINE.   
   They only wanted me to test my software and report bugs. Then I was   
   to be in charge of that bug until it was resolved by WINO lackeys --   
   temporary college student coders. (I had no idea that geeks were so   
   often paramilitary in their social structures.)   
      
      An example: I had used a quick hack in the ChooseColor function.   
   I'd never had any use for the color pallette that could be saved at   
   the bottom left of the colorpicker window. The lpCustomColors member   
   of the CHOOSECOLOR structure is supposed to take an array of long   
   integers to represent 24-bit colors for the grid. For whatever reason,   
   VBers were using an array of string pointers, which worked fine on   
   Windows if the custom colors were never used. In WINE those   
   details got lost in translation and the string array cause a crash.   
   The WINOs were adamant that I shouldn't code such things better.   
   They didn't want me to strain my little brain. They actually didn't want   
   me to unsderstand.They just wanted me to keep track of bugs until   
   a coder fixed them on the Linux side.   
      
      I don't claim to be able to program anywhetre near the level of   
   low-level detail that those people can, but they could have cooperated.   
      
      WINE is mostly geared toward running Photoshop and video games.   
   The WINOs wanted Microsoft games. Which is an important point. It   
   was never about bringing Windows software to Linux. The primary   
   motivation was to bring video games and maybe MSOffice to Linux geeks.   
      
       They'll take up the   
   challenge of whatever interests them. Then they have a chart showing   
   not how well the WinAPI is supported but rather the quality of support   
   for specific software. Put Cortana in a tight, transistor-festooned   
   bodysuit and hose her down, then put her in a Metro app,   
   and you can bet you'll get more WINE Metro support. Or at least   
   more WINE Cortana-all-wet-in-a-bodysuit support.   
      
      When I tried WINE maybe 15 years ago it was very spotty. For   
   example, Irfan View worked OK but had gaps in the GUI. Just   
   missing window areas. Odd glitches. Years later it seemed more polished,   
   though I tried my own software and WINE couldn't see subclassed windows   
   at all. I have an editor with a system richedit window and the richedit   
   just doesn't show up. On Windows there's also notable difference   
   between versions of richedit, with various little things. So you can   
   imagine how WINE would do it. They'd give you a Linux equivalent   
   and map some or most of the richedit messages to the Linux window,   
   with a shoehorn if necessary.   
      
      So the Windows version needs to be thoroughly orthodox, the   
   specific APIs used must be supported, and a Linux equivalent must   
   be adequate as a substitute for the Windows function. Thus, WINE might   
   support all sorts of things, such as .Net and Metro, but will likely   
   never support any of them fully.   
      
      I imagine you probably know all this, but it's an interesting topic   
   and probably most people haven't looked into how WINE works.   
   I ended up deciding that any idea of moving to Linux without leaving   
   behind favorite software was not realistic and never would be realistic.   
   (Lately I've had enough trouble just adapting richedit50 to what I   
   expect from richedit20. So how could I expect WINE to match the   
   expected behavior in the Linux equivalent?)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)