From: bill.gunshannon@gmail.com   
      
   On 7/6/2025 8:52 AM, Waldek Hebisch wrote:   
   > 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.   
      
   See what I mean!!! He wants VMS gone.  I don't know why he hangs   
   out here other than to annoy real VMS users.   
      
   >   
   > 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.   
   >   
      
   Damn it, stop feeding the troll.   
      
   bill   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)