From: antispam@fricas.org   
      
   Lawrence D'Oliveiro  wrote:   
   > On Sun, 6 Jul 2025 00:36:51 -0000 (UTC), Waldek Hebisch wrote:   
   >   
   >> Lawrence D'Oliveiro  wrote:   
   >>>   
   >>> It was always tricky to emulate *nix on proprietary OSes. But   
   >>> emulating proprietary OSes on Linux does actually work a lot   
   >>> better. Look at WINE, which has progressed to the point where it   
   >>> can be the basis of a successful shipping product (the Steam Deck)   
   >>> that lets users run Windows games without Windows. That works so   
   >>> well, it puts true Windows-based handheld competitors in the shade.   
   >>   
   >> You mention Wine, but do you know what you are talking about?   
   >   
   > Just look at the success of the Steam Deck, and you’ll see.   
      
   Well, in Usenet discussion it is easy to snip/ignore inconvenient   
   facts that I gave.  In real life such approach does not work.   
      
   >> What went wrong?  Clearly VSI hit some difficulties.  Public information   
   >> indicates that work on compilers took more time than expected (and that   
   >> could slow down other work as it depends on working compilers).   
   >   
   > Weren’t they using existing code-generation tools like LLVM? That should   
   > have saved them a lot of work.   
      
   Should, yes.  Yet clearly compilers were late.  You should recalibrate   
   your estimates of effort.  In particular reusing independently   
   developed piece of code frequently involves a lot of work.   
      
   > No, the sheer job of reimplementing the entire kernel stack (including   
   > custom driver support) on a new architecture was what slowed them down.   
   > And the effort should have been avoided.   
      
   There are no indicatianos of substantial reimplementation.  Official   
   info says that new or substantially reworked code is in C.  But   
   w also have information that amount of Macro32 and Bliss did not   
   substantially decrease.  So, (almost all) old code is still in use.   
   It could be that small changes to old code took a lot of time.   
   It could be that some new pieces were particularly tricky.   
   However, you should understand that porting really means replicating   
   exisiting behaviour on new hardware.  Replicating behaviour gets   
   more tricky if you change more parts and especially if you want   
   to target a high level interface.   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)