From Newsgroup: comp.os.vms

In article <10g7m7j$nkcb$1@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 11/26/2025 3:48 AM, Volker Halle wrote:

Am 26.11.2025 um 09:25 schrieb gcalliet:

Another question. How VMS/XDE is implemented? It seems being a
brilliant effort, and being very interesting to understand. Will they
publish about that?

maybe have a look at the Introduction to VMS/XDE Webinar:

https://www.youtube.com/watch?v=cBJa_zOOkSo

It may answer some of your questions.

Especially around 8-10 minutes in.

I also asked some pretty specific questions at the VSI forum
about implementation and got answers.

Neither that video nor the VSI forum posts gave a lot of detail
about the actual implementation. I suspect they did something
closer to gVisor/Dune than just having a loadable kernel module
that builds in a bunch of VMS code, for instance.

But we have insufficient detail to know.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms


On 12/2/25 9:48 AM, Dan Cross wrote:

In article <10g7m7j$nkcb$1@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 11/26/2025 3:48 AM, Volker Halle wrote:

Am 26.11.2025 um 09:25 schrieb gcalliet:

Another question. How VMS/XDE is implemented? It seems being a
brilliant effort, and being very interesting to understand. Will they
publish about that?

maybe have a look at the Introduction to VMS/XDE Webinar:

https://www.youtube.com/watch?v=cBJa_zOOkSo

It may answer some of your questions.

Especially around 8-10 minutes in.

I also asked some pretty specific questions at the VSI forum
about implementation and got answers.

Neither that video nor the VSI forum posts gave a lot of detail
about the actual implementation. I suspect they did something
closer to gVisor/Dune than just having a loadable kernel module
that builds in a bunch of VMS code, for instance.

But we have insufficient detail to know.

Near the end there was a mention of a code name for the technology upon
which XDE is based (but I don't remember what that was). It would indeed
be nice to know more about the emulation, including how it works, how it
came about, and what other plans there are for it, if any. It seems
unlikely to me that it was made expressly for use in a development
environment that doesn't really provide any new capabilities.

Much was made of the fact that with VMS/XDE you can use Linux tools to
operate on your code files directly and then not have to move them to a
VMS system to compile them. But the same would be true if the files
lived on decently-working NFS or SMB shares on a real VMS system. And
moving the files really isn't that hard, and would be even easier if an
rsync implementation were available.

Much was also made of the fact that you can, for example, run a VSCode
task that starts up a new instance of VMS/XDE and runs a build procedure
within it using native VMS tools. But you can do the same thing with an
SSH command to a real VMS system.

There was a list of DECset tools that were state-of-the art decades ago alongside modern Linux equivalents in order to make the point that
people have different expectations now for how to do development. But
other than code editing and version control integrated into the IDE,
VMS/XDE doesn't meet any of those expectations.

There are no Linux tools that can analyze and profile your object code
or images, and you can't use Linux make utilities to build your code,
nor Linux test frameworks to test your code unless those tools have been
ported to VMS. Or unless each command generated by the make utility or
test framework starts a new instance of VMS/XDE and runs a native VMS
command, which would be extraordinarily cumbersome. You can't run the
VMS debugger unless your Linux IDE has an extension to run a remote
debugger (and a suitable debugging agent exists on VMS). Again, no
advantages here for VMS/XDE over a real VMS system.

The emulation of the system services and RTLs sounds like some pretty
neat engineering, but surely they didn't do all that for an IDE that
doesn't really offer anything new?

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10gobsg$2uher$1@dont-email.me>,
Craig A. Berry <craigberry@nospam.mac.com> wrote:

On 12/2/25 9:48 AM, Dan Cross wrote:

In article <10g7m7j$nkcb$1@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 11/26/2025 3:48 AM, Volker Halle wrote:

Am 26.11.2025 um 09:25 schrieb gcalliet:

Another question. How VMS/XDE is implemented? It seems being a
brilliant effort, and being very interesting to understand. Will they >>>>> publish about that?

maybe have a look at the Introduction to VMS/XDE Webinar:

https://www.youtube.com/watch?v=cBJa_zOOkSo

It may answer some of your questions.

Especially around 8-10 minutes in.

I also asked some pretty specific questions at the VSI forum
about implementation and got answers.

Neither that video nor the VSI forum posts gave a lot of detail
about the actual implementation. I suspect they did something
closer to gVisor/Dune than just having a loadable kernel module
that builds in a bunch of VMS code, for instance.

But we have insufficient detail to know.

Near the end there was a mention of a code name for the technology upon
which XDE is based (but I don't remember what that was). It would indeed
be nice to know more about the emulation, including how it works, how it
came about, and what other plans there are for it, if any. It seems
unlikely to me that it was made expressly for use in a development >environment that doesn't really provide any new capabilities.

I've been rewatching the video trying to catch it; so far I
haven't. Granted, I've been letting it run in the background
while I do other work, but I'll peel off some time to sit down
and watch it properly.

gVisor is an interesting model to examine and compare against.
Google built that as a way to efficiently sandbox untrusted
code; the idea is that, when you run a program under gVisor, you
actually spin up a very small virtual machine with a userspace
hypervisor written in Go. When the program makes a system call
or otherwise invokes the system, this causes a trap into the
kernel, which then arranges for the Go program to run and handle
the call. That program emulates the Linux system call interface
but gives a place where one can inject policy, so that (for
example) purely computation video transcoding software can't
open a TCP connection or something similar. If gVisor
determines that the sandboxed program actually needs to talk to
the system, it makes a system call on its behalf, and then
arranges for that to "return" in the VM, and asks the (host)
kernel to switch back to that by doing a VM entry. This was a
dramatic improvement over using something like `ptrace` for
sandboxing. As it turns out, the _actual_ number of system
calls required by `gVisor` itself is relatively small.

gVisor was inspired by Dune, which was a research project out of
Stanford: https://www.usenix.org/conference/osdi12/technical-sessions/presentation/belay

That model makes sense for something like VMS/XDE.

Much was made of the fact that with VMS/XDE you can use Linux tools to >operate on your code files directly and then not have to move them to a
VMS system to compile them. But the same would be true if the files
lived on decently-working NFS or SMB shares on a real VMS system. And
moving the files really isn't that hard, and would be even easier if an
rsync implementation were available.

Or for that matter if you had `git` or something like it on VMS
already. But I think it's fair to say that you'd lose a lot of
functionality going that way, as well.

Much was also made of the fact that you can, for example, run a VSCode
task that starts up a new instance of VMS/XDE and runs a build procedure >within it using native VMS tools. But you can do the same thing with an
SSH command to a real VMS system.

There was a list of DECset tools that were state-of-the art decades ago >alongside modern Linux equivalents in order to make the point that
people have different expectations now for how to do development. But
other than code editing and version control integrated into the IDE,
VMS/XDE doesn't meet any of those expectations.

There are no Linux tools that can analyze and profile your object code
or images, and you can't use Linux make utilities to build your code,
nor Linux test frameworks to test your code unless those tools have been >ported to VMS. Or unless each command generated by the make utility or
test framework starts a new instance of VMS/XDE and runs a native VMS >command, which would be extraordinarily cumbersome. You can't run the
VMS debugger unless your Linux IDE has an extension to run a remote
debugger (and a suitable debugging agent exists on VMS). Again, no >advantages here for VMS/XDE over a real VMS system.

The emulation of the system services and RTLs sounds like some pretty
neat engineering, but surely they didn't do all that for an IDE that
doesn't really offer anything new?

One of the things that a lot of modern editors provide is a
standardized way to communicate with language servers and remote
systems (usually over SSH). This opens up the possibility of a
really well-integrated environment for doing remote development
and debugging work, but it requires a lot of pieces to be in
place. With VSCode, for example, Microsoft's remote access
extension is closed-source and only supports a handful of
systems (Linux and macOS, I think). Zed is open-source, but
requires Rust and a bunch of supporting libraries. But one can
imagine language servers and similar tool that know how to
interact with VMS, which would be a very rich environment to
work with.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/3/25 11:04 AM, Dan Cross wrote:

In article <10gobsg$2uher$1@dont-email.me>,
Craig A. Berry <craigberry@nospam.mac.com> wrote:

Near the end there was a mention of a code name for the technology upon
which XDE is based (but I don't remember what that was).

I've been rewatching the video trying to catch it; so far I
haven't.

It was in the Q and A if that helps.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/2/2025 10:47 PM, Craig A. Berry wrote:

how it
came about, and what other plans there are for it, if any.-a It seems unlikely to me that it was made expressly for use in a development environment that doesn't really provide any new capabilities.

Much was made of the fact that with VMS/XDE you can use Linux tools to operate on your code files directly and then not have to move them to a
VMS system to compile them.-a But the same would be true if the files
lived on decently-working NFS or SMB shares on a real VMS system. And
moving the files really isn't that hard, and would be even easier if an
rsync implementation were available.

Much was also made of the fact that you can, for example, run a VSCode
task that starts up a new instance of VMS/XDE and runs a build procedure within it using native VMS tools. But you can do the same thing with an
SSH command to a real VMS system.

There was a list of DECset tools that were state-of-the art decades ago alongside modern Linux equivalents in order to make the point that
people have different expectations now for how to do development.-a But
other than code editing and version control integrated into the IDE,
VMS/XDE doesn't meet any of those expectations.

There are no Linux tools that can analyze and profile your object code
or images, and you can't use Linux make utilities to build your code,
nor Linux test frameworks to test your code unless those tools have been ported to VMS. Or unless each command generated by the make utility or
test framework starts a new instance of VMS/XDE and runs a native VMS command, which would be extraordinarily cumbersome. You can't run the
VMS debugger unless your Linux IDE has an extension to run a remote
debugger (and a suitable debugging agent exists on VMS).-a Again, no advantages here for VMS/XDE over a real VMS system.

The emulation of the system services and RTLs sounds like some pretty
neat engineering, but surely they didn't do all that for an IDE that
doesn't really offer anything new?

I assume the logic is something like the following.

Premise #1 = VSI need applications for VMS to sell VMS licenses - the
IT department does not get approved purchase of VMS so the IT department
can run VMS - the IT department get approved purchase of VMS so
that the VMS system can run production control system, accounting
system, inventory system, personnel system or whatever.

Premise #2 - to get those applications then developing for VMS must
be let us say not too hard. Does not matter if the development is
COTS, open source or in house development. The VMS developers over
let us say 50 typical have a long history on VMS and do not have
a problem working split on PC and VMS. Many of the younger developers
do not have much history with VMS and there is a desire to make
it easier for them to do more of the work on PC.

I completely buy premise #1. I am more skeptical about premise #2.
Younger developers do know how to work in a terminal. And DCL
is not hard to learn at the level required for a developer. But
let us say that senior management at VSI's customer push premise #2.
Right or wrong then it is customer wish. And first rule of business
is that the customer is always right.

I consider VMS IDE to be VSI's first attempt to deliver that. It
is basically VS Code with support for VMS languages and under
the hood SSH connectivity to VMS. I think it is fair to say that
VMS IDE has not been a huge success. VS Code is the worlds most
widely used IDE/power-editor, but there are still lots of
developers preferring other tools.

So now they make a second attempt with XDE. From a purpose
perspective and a high level technical perspective it is
very similar to WSL (WSL allows you do Linux dev on Windows,
XDE allows you to do VMS dev on Linux, the implementation
is somewhat similar to WSL 1). WSL is a very popular option
for developers. Trying to do something similar seems justified.

Whether it becomes a success is still to be seen. I think it
will require aggressive pricing to make it widely used.

Arne


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms


On 12/3/25 7:29 PM, Arne Vajh|+j wrote:

<comments about VMS-IDE VSCode extension snipped>

So now they make a second attempt with XDE. From a purpose
perspective and a high level technical perspective it is
very similar to WSL (WSL allows you do Linux dev on Windows,
XDE allows you to do VMS dev on Linux, the implementation
is somewhat similar to WSL 1). WSL is a very popular option
for developers. Trying to do something similar seems justified.

There are some use cases with WSL where people might build with Windows
tools to test and deploy on Linux (notably .NET) but I don't think WSL
was ever primarily about covering for the absence of modern development
tools on Linux. And in any case why build a WSL1 equivalent when you
already have a WSL2 equivalent?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/4/2025 9:07 AM, Craig A. Berry wrote:

On 12/3/25 7:29 PM, Arne Vajh|+j wrote:
<comments about VMS-IDE VSCode extension snipped>

So now they make a second attempt with XDE. From a purpose
perspective and a high level technical perspective it is
very similar to WSL (WSL allows you do Linux dev on Windows,
XDE allows you to do VMS dev on Linux, the implementation
is somewhat similar to WSL 1). WSL is a very popular option
for developers. Trying to do something similar seems justified.

There are some use cases with WSL where people might build with Windows
tools to test and deploy on Linux (notably .NET) but I don't think WSL
was ever primarily about covering for the absence of modern development
tools on Linux.

Not absence of modern dev tools.

But maybe absence of the one tool some parts of MS care about: VS.

And in any case why build a WSL1 equivalent when you
already have a WSL2 equivalent?

I don't think they have the WSL2 equivalent. They could have
done it WSL2 style and made XDE a VM and done some file system
integration (NFS based, SMB based or something else) and cross
command line integration instead of what they did.

But ...

Arne
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/4/2025 9:15 AM, Arne Vajh|+j wrote:

On 12/4/2025 9:07 AM, Craig A. Berry wrote:

On 12/3/25 7:29 PM, Arne Vajh|+j wrote:
<comments about VMS-IDE VSCode extension snipped>

So now they make a second attempt with XDE. From a purpose
perspective and a high level technical perspective it is
very similar to WSL (WSL allows you do Linux dev on Windows,
XDE allows you to do VMS dev on Linux, the implementation
is somewhat similar to WSL 1). WSL is a very popular option
for developers. Trying to do something similar seems justified.

There are some use cases with WSL where people might build with Windows
tools to test and deploy on Linux (notably .NET) but I don't think WSL
was ever primarily about covering for the absence of modern development
tools on Linux.

Not absence of modern dev tools.

But maybe absence of the one tool some parts of MS care about: VS.

-a-a-a-a-a-a-a-a-a-a-a-a-a-a And in any case why build a WSL1 equivalent when you
already have a WSL2 equivalent?

I don't think they have the WSL2 equivalent. They could have
done it WSL2 style and made XDE a VM and done some file system
integration (NFS based, SMB based or something else) and cross
command line integration instead of what they did.

But ...

My gut feeling (which is not really distinguishable from the output of
a RNG) is that the XDE implementation is a bottom-up idea (engineering
telling management: we can do this) not a top-down idea (management
telling engineering: do this).

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10gq86n$3lq0f$1@dont-email.me>,
Craig A. Berry <craigberry@nospam.mac.com> wrote:

On 12/3/25 11:04 AM, Dan Cross wrote:

In article <10gobsg$2uher$1@dont-email.me>,
Craig A. Berry <craigberry@nospam.mac.com> wrote:

Near the end there was a mention of a code name for the technology upon
which XDE is based (but I don't remember what that was).

I've been rewatching the video trying to catch it; so far I
haven't.

It was in the Q and A if that helps.

Thanks; it does. Camiel mentioned VLX, and that appears on the
forum in a few places. However, there's no mention of what VLX
itself is based on, or whether it's a completely bespoke thing.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2