Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > comp.os.vms > #378297

Re: VMS/XDE intro

Show all headers | View raw

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.

Back to comp.os.vms | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

VMS/XDE intro Arne Vajhøj <arne@vajhoej.dk> - 2025-11-11 08:54 -0500
  Re: VMS/XDE intro gcalliet <gerard.calliet@pia-sofer.fr> - 2025-11-25 10:03 +0100
    Re: VMS/XDE intro Chris Townley <news@cct-net.co.uk> - 2025-11-25 10:00 +0000
    Re: VMS/XDE intro Arne Vajhøj <arne@vajhoej.dk> - 2025-11-25 08:53 -0500
    Re: VMS/XDE intro Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-25 20:21 +0000
    Re: VMS/XDE intro gcalliet <gerard.calliet@pia-sofer.fr> - 2025-11-26 09:25 +0100
      Re: VMS/XDE intro Volker Halle <volker_halle@hotmail.com> - 2025-11-26 09:48 +0100
        Re: VMS/XDE intro Arne Vajhøj <arne@vajhoej.dk> - 2025-11-26 14:59 -0500
          Re: VMS/XDE intro cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-02 15:48 +0000
            Re: VMS/XDE intro "Craig A. Berry" <craigberry@nospam.mac.com> - 2025-12-02 21:47 -0600
              Re: VMS/XDE intro cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-03 17:04 +0000
                Re: VMS/XDE intro "Craig A. Berry" <craigberry@nospam.mac.com> - 2025-12-03 14:56 -0600
                Re: VMS/XDE intro cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-04 20:59 +0000
              Re: VMS/XDE intro Arne Vajhøj <arne@vajhoej.dk> - 2025-12-03 20:29 -0500
                Re: VMS/XDE intro "Craig A. Berry" <craigberry@nospam.mac.com> - 2025-12-04 08:07 -0600
                Re: VMS/XDE intro Arne Vajhøj <arne@vajhoej.dk> - 2025-12-04 09:15 -0500
                Re: VMS/XDE intro Arne Vajhøj <arne@vajhoej.dk> - 2025-12-04 09:51 -0500
      Re: VMS/XDE intro bill <bill.gunshannon@gmail.com> - 2025-11-26 09:51 -0500
        Re: VMS/XDE intro jgd@cix.co.uk (John Dallman) - 2025-11-26 23:03 +0000
      Re: VMS/XDE intro Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-26 19:46 +0000
      Re: VMS/XDE intro Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-11-27 19:18 +0000
        Re: VMS/XDE intro gcalliet <gerard.calliet@pia-sofer.fr> - 2025-11-29 18:41 +0100

csiph-web