XPost: alt.comp.os.windows-10   
   From: robin_listas@es.invalid   
      
   On 2024-07-30 14:43, Newyana2 wrote:   
   > 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?)   
      
   I think I knew about this, but probably because you mentioned it before   
   on another post :-)   
      
   --   
   Cheers, Carlos.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)