Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!newsfeed.bofh.team!paganini.bofh.team!not-for-mail From: antispam@fricas.org (Waldek Hebisch) Newsgroups: comp.os.vms Subject: Re: Bootcamp Date: Sun, 6 Jul 2025 00:36:51 -0000 (UTC) Organization: To protect and to server Message-ID: <104cgf1$vk0k$1@paganini.bofh.team> References: <100jfjh$2l94e$1@dont-email.me> <1020odr$2t5n5$1@dont-email.me> <1041t4b$349i3$4@dont-email.me> <1044fhf$3p5ha$5@dont-email.me> <10465mq$62th$1@dont-email.me> <10470qi$d897$2@dont-email.me> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Sun, 6 Jul 2025 00:36:51 -0000 (UTC) Injection-Info: paganini.bofh.team; logging-data="1036308"; posting-host="WwiNTD3IIceGeoS5hCc4+A.user.paganini.bofh.team"; mail-complaints-to="usenet@bofh.team"; posting-account="9dIQLXBM7WM9KzA+yjdR4A"; User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64)) X-Notice: Filtered by postfilter v. 0.9.3 Lawrence D'Oliveiro wrote: > On Thu, 3 Jul 2025 10:56:26 -0400, Arne Vajhøj wrote: > >> 5) The idea of emulating one OS on another OS is questionable >> in itself. It is not that difficult to achieve 90-95% >> compatibility. But 100% compatibility is very hard. Because >> the core OS design tend to spill over into >> userland semantics. It is always tricky to emulate *nix >> on VMS and it would be be tricky to emulate VMS on *nix. > > 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? At the start Wine project had idea similar to yours: write loader for Windows binaries, redirect system library calls to equivalent Linux system/library calls and call it done. The loader part went smoothly, but they relatively quickly (in around 2 years) discoverd that devil is in emulating Windows libraries. Initial idea of redirecting calls to "equivalent" Linux calls turned out to be no go. Instead, they decided to effectively create Windows clone. That is Wine provides several libraries which are supposed to behave identically as corresponding Windows libraries and use the same interfaces. Only at lowest level they have calls to Linux libraries. In light of Wine experience, approach taken by VSI is quite natural. Why part has taken so much time? We do not know. One could expect that only small part of kernel is architecture dependent. Given that this is third port architecture dependent parts should be well-know to developers and clearly speparated from machine independent parts. There are probably some performance critical libraries written in native assembly (not Macro32!). Of course compilers (or rather their backends) are architecure dependent. There is also question of device drivers, while they can be architecture independent the set of devices available on x86-64 seem to differ from Itanium or Alpha. Given 40+ developement team (this seem to correspond to publicaly available information about VSI) and considering 10kloc/year developer productivity (I think this is reasonable estimate for system type work) in 4 years VSI could create about 1.6 Mloc of new code. We do not know size of VMS kernel, but at first glance this 1.6 Mloc is enough to cover architecure dependent parts of VMS. So one could expect port in 4-5 years or faster if architecure dependent parts are smaller. IIUC initial VSI estimate was similar. 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). Note that compilers are neccessary for success of VMS and in compier work VSI actually worked close to your suggestion: they reuse open source backend and just add VMS-specific extentions and frontends. But without knowing what took time we do not know if some alternative approach would work better. -- Waldek Hebisch