Sujet : Re: Bootcamp
De : antispam (at) *nospam* fricas.org (Waldek Hebisch)
Groupes : comp.os.vmsDate : 06. Jul 2025, 13:52:22
Autres entêtes
Organisation : To protect and to server
Message-ID : <104dri4$11oku$1@paganini.bofh.team>
References : 1 2 3 4 5 6 7 8 9 10
User-Agent : tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64))
Lawrence D'Oliveiro <
ldo@nz.invalid> wrote:
On Sun, 6 Jul 2025 00:36:51 -0000 (UTC), Waldek Hebisch wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> 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