Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Stephen Hoffman <seaohveh@hoffmanlabs.invalid>
Newsgroups: comp.os.vms
Subject: Re: Bootcamp
Date: Fri, 11 Jul 2025 17:13:11 -0400
Organization: HoffmanLabs LLC
Lines: 52
Message-ID: <104rup7$1mu3j$1@dont-email.me>
References: <mchom4F15kcU1@mid.individual.net> <mckld9Fg08sU1@mid.individual.net> <10465mq$62th$1@dont-email.me> <104cgf1$vk0k$1@paganini.bofh.team>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 11 Jul 2025 23:13:12 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="c51077b6fab71e0182e283603f5040cc";
	logging-data="1800307"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+rCBuu7LQ9TH/hU0anJB/8Wh2IahlmqxU="
User-Agent: Unison/2.2
Cancel-Lock: sha1:Ee2d6gWaq9RFNZpxiN6QPuMKylg=

On 2025-07-06 00:36:51 +0000, Waldek Hebisch said:

> 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...

Some folks are seemingly unfamiliar with OpenVMS and OpenVMS apps, and 
apparently also seemingly unfamiliar with Linux, and with a fondness 
for unworkable suggestions.  Not that I too don't have a fondness for 
unworkable suggestions.

What you've posted has been highlighted before. As has porting VAX/VMS 
to the Mach kernel, which actually happened. (Hi, Chris!) It also 
doesn't appreciably move the operating system work forward. Ports 
~never do.

And there is a vendor that already provides custom solutions based on 
porting parts of the APIs to another platform, with Sector7. What 
Sector7 offers very much parallels Proton and Wine, too. But unlike VSI 
and Sector7, there are a whole lot more users of each of those 
candidate apps than the often-one-off apps found on OpenVMS.  That 
disparity increases the effort involved for each app, and for the users 
of that app.

And at the end of all that work, what's left? Outsourcing third-party 
OpenVMS app support to VSI, on a compatibility API? They can offer that 
now, and without creating Proton  and Wine.

> Given 40+ developement team (this seem to correspond to publicaly 
> available information about VSI) and considering 10kloc/year developer 
> productivity...
> ...What went wrong?  Clearly VSI hit some difficulties...

40 or 50 engineers is far too small for a project of the scale and 
scope of a feature-competitive operating system.  For a competitive 
platform, I'd be looking to build (slowly) to 2000, andquite possibly 
more. But that takes revenues and reinvestments.

As an example of scale and scope that ties back to Valve and their 
efforts with Wine and Proton and Steam Deck and other functions, Valve 
may well presently have as many job openings as VSI has engineers:
https://www.glassdoor.com/Jobs/Valve-Corporation-Jobs-E24849.htm
https://www.valvesoftware.com/en/


-- 
Pure Personal Opinion | HoffmanLabs LLC