• VMS/XDE intro

    From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@arne@vajhoej.dk to comp.os.vms on Tue Nov 11 08:54:46 2025
    From Newsgroup: comp.os.vms

    https://zoom.us/webinar/register/WN_oWhs35HjRcOLjRDSoollNQ

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From gcalliet@gerard.calliet@pia-sofer.fr to comp.os.vms on Tue Nov 25 10:03:06 2025
    From Newsgroup: comp.os.vms

    Le 11/11/2025 |a 14:54, Arne Vajh|+j a |-crit-a:
    https://zoom.us/webinar/register/WN_oWhs35HjRcOLjRDSoollNQ

    Simple question from a total ignorant:

    I understood VMS/XDE needs WSL. And you can use WSL on windows to run
    some Linux, for example Ubuntu. Ok.
    I'm not sure, but it seems not possible to instal some WSL on some LInux (absurd or impossible?).
    So am I right if I say that VMS/XDE cannot be used without some Windows?

    G|-rard Calliet
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Chris Townley@news@cct-net.co.uk to comp.os.vms on Tue Nov 25 10:00:35 2025
    From Newsgroup: comp.os.vms

    On 25/11/2025 09:03, gcalliet wrote:
    Le 11/11/2025 |a 14:54, Arne Vajh|+j a |-crit-a:
    https://zoom.us/webinar/register/WN_oWhs35HjRcOLjRDSoollNQ

    Simple question from a total ignorant:

    I understood VMS/XDE needs WSL. And you can use WSL on windows to run
    some Linux, for example Ubuntu. Ok.
    I'm not sure, but it seems not possible to instal some WSL on some LInux (absurd or impossible?).
    So am I right if I say that VMS/XDE cannot be used without some Windows?

    G|-rard Calliet

    It will run on Linux out of the box, as long as your machine and linux
    distro meets some basic requirements listed in the release
    notes/installation guide.

    WSL is only needed it if you want to run it on Windows, which is not
    available if you have a virtualised VMS installation!

    It seems to work well on Linux - I have it running under Ubuntu 14.04
    --
    Chris
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@arne@vajhoej.dk to comp.os.vms on Tue Nov 25 08:53:46 2025
    From Newsgroup: comp.os.vms

    On 11/25/2025 4:03 AM, gcalliet wrote:
    Le 11/11/2025 |a 14:54, Arne Vajh|+j a |-crit-a:
    https://zoom.us/webinar/register/WN_oWhs35HjRcOLjRDSoollNQ

    Simple question from a total ignorant:

    I understood VMS/XDE needs WSL. And you can use WSL on windows to run
    some Linux, for example Ubuntu. Ok.
    I'm not sure, but it seems not possible to instal some WSL on some LInux (absurd or impossible?).
    So am I right if I say that VMS/XDE cannot be used without some Windows?

    VMS/XDE requires Linux. I don't think it matters what Linux runs on.

    Linux on physical hardware. Linux on VMWare Player/Workstation on
    Windows. Linux on VirtualBox on Windows. WSL on Windows.

    WSL 2 is just a lightweight VM with good integration between
    Linux and Windows.

    I think there was a thread in the forum where it was said that
    XDE performance would be bad if it was hosted in WSL using
    a Windows file system aka XDE doing VMS to Linux translation
    and WSL doing Linux to Windows translation. No surprise.

    On the other hand WSL allows for indirect Windows VMS
    integration.

    But if you like Linux on physical hardware then you just
    do that.

    Arne




    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Lawrence =?iso-8859-13?q?D=FFOliveiro?=@ldo@nz.invalid to comp.os.vms on Tue Nov 25 20:21:29 2025
    From Newsgroup: comp.os.vms

    On Tue, 25 Nov 2025 10:03:06 +0100, gcalliet wrote:

    I understood VMS/XDE needs WSL.

    It looks like it needs Linux, not Windows or WSL per se. WSL is just a way
    of running Linux on Windows.

    That applies to WSL2, not WSL1, which merely offers a Linux-like
    environment on top of the Windows kernel. Not sure if that will be
    sufficient for this VMS/XDE thing.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From gcalliet@gerard.calliet@pia-sofer.fr to comp.os.vms on Wed Nov 26 09:25:47 2025
    From Newsgroup: comp.os.vms

    Le 25/11/2025 |a 10:03, gcalliet a |-crit-a:
    Le 11/11/2025 |a 14:54, Arne Vajh|+j a |-crit-a:
    https://zoom.us/webinar/register/WN_oWhs35HjRcOLjRDSoollNQ

    Simple question from a total ignorant:

    I understood VMS/XDE needs WSL. And you can use WSL on windows to run
    some Linux, for example Ubuntu. Ok.
    I'm not sure, but it seems not possible to instal some WSL on some LInux (absurd or impossible?).
    So am I right if I say that VMS/XDE cannot be used without some Windows?

    G|-rard Calliet
    Thanks. Ok for me using this "thing" on Linux on hardware.

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

    The next question is a consequence. What level of opening, documenting, offering access for that? It's somehow strange offering a proprietary
    tool on Linux: cultural conflict?

    G|-rard Calliet
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Volker Halle@volker_halle@hotmail.com to comp.os.vms on Wed Nov 26 09:48:20 2025
    From Newsgroup: comp.os.vms

    Am 26.11.2025 um 09:25 schrieb gcalliet:
    Le 25/11/2025 |a 10:03, gcalliet a |-crit-a:
    Le 11/11/2025 |a 14:54, Arne Vajh|+j a |-crit-a:
    https://zoom.us/webinar/register/WN_oWhs35HjRcOLjRDSoollNQ

    Simple question from a total ignorant:

    I understood VMS/XDE needs WSL. And you can use WSL on windows to run
    some Linux, for example Ubuntu. Ok.
    I'm not sure, but it seems not possible to instal some WSL on some
    LInux (absurd or impossible?).
    So am I right if I say that VMS/XDE cannot be used without some Windows?

    G|-rard Calliet
    Thanks. Ok for me using this "thing" on Linux on hardware.

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

    The next question is a consequence. What level of opening, documenting, offering access for that? It's somehow strange offering a proprietary
    tool on Linux: cultural conflict?

    G|-rard Calliet

    G|-rard,

    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.

    Regards,
    Volker.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From bill@bill.gunshannon@gmail.com to comp.os.vms on Wed Nov 26 09:51:17 2025
    From Newsgroup: comp.os.vms

    On 11/26/2025 3:25 AM, gcalliet wrote:

    The next question is a consequence. What level of opening, documenting, offering access for that? It's somehow strange offering a proprietary
    tool on Linux: cultural conflict?


    Not really. Oracle, SPSS, Minitab, MATLAB. And I am sure there are
    a pile more of proprietary programs that run on Linux. There is a
    big difference between Operating Systems and applications. Without applications Linux never would have survived.

    bill


    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Lawrence =?iso-8859-13?q?D=FFOliveiro?=@ldo@nz.invalid to comp.os.vms on Wed Nov 26 19:46:27 2025
    From Newsgroup: comp.os.vms

    On Wed, 26 Nov 2025 09:25:47 +0100, gcalliet wrote:

    It's somehow strange offering a proprietary tool on Linux: cultural
    conflict?

    Linux itself is not against proprietary tools. Obviously the company has
    to make money somehow, and this is how theyrCOve chosen to do it.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@arne@vajhoej.dk to comp.os.vms on Wed Nov 26 14:59:48 2025
    From Newsgroup: comp.os.vms

    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.

    Arne

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From jgd@jgd@cix.co.uk (John Dallman) to comp.os.vms on Wed Nov 26 23:03:00 2025
    From Newsgroup: comp.os.vms

    In article <mooif5Fk1vlU1@mid.individual.net>, bill.gunshannon@gmail.com
    (bill) wrote:
    On 11/26/2025 3:25 AM, gcalliet wrote:
    It's somehow strange offering a proprietary tool on Linux:
    cultural conflict?
    Not really. Oracle, SPSS, Minitab, MATLAB. And I am sure there are
    a pile more of proprietary programs that run on Linux.

    These days, anything that's intended to run on a server, in the cloud, or
    in any kind of research organisation has to have a Linux version. Without
    it, you aren't a serious player.

    John
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Simon Clubley@clubley@remove_me.eisner.decus.org-Earth.UFP to comp.os.vms on Thu Nov 27 19:18:04 2025
    From Newsgroup: comp.os.vms

    On 2025-11-26, gcalliet <gerard.calliet@pia-sofer.fr> wrote:

    The next question is a consequence. What level of opening, documenting, offering access for that? It's somehow strange offering a proprietary
    tool on Linux: cultural conflict?


    Hello Gerard,

    Since you are clearly new with Linux, there is one "cultural conflict"
    I should make you aware of, to avoid you wasting time and frustration
    in case you come across the same issues.

    Linux has, until now, used the X11 windowing system in the same way as
    other Unix systems and VMS has done.

    A new windowing system, called Wayland, is being introduced to Linux
    and unfortunately the people doing this appear to have designed this
    in isolation without listening to the creators of the major applications running on Linux and are saying that their new way of doing things in
    Wayland is by design.

    This is causing some major problems. The most high-profile one I am
    aware of is KiCad at https://www.kicad.org/ and which is a major open
    source PCB design package.

    The KiCad developers have documented their problems with Wayland here:

    https://www.kicad.org/blog/2025/06/KiCad-and-Wayland-Support/

    Use it as a checklist in case you run into the same kinds of problems
    while using Linux. If the problems you encounter are on that list,
    then you know it is not you. :-)

    Simon.
    --
    Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    Walking destinations on a map are further away than they appear.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From gcalliet@gerard.calliet@pia-sofer.fr to comp.os.vms on Sat Nov 29 18:41:13 2025
    From Newsgroup: comp.os.vms

    Le 27/11/2025 |a 20:18, Simon Clubley a |-crit-a:
    On 2025-11-26, gcalliet <gerard.calliet@pia-sofer.fr> wrote:

    The next question is a consequence. What level of opening, documenting,
    offering access for that? It's somehow strange offering a proprietary
    tool on Linux: cultural conflict?


    Hello Gerard,

    Since you are clearly new with Linux, there is one "cultural conflict"
    I should make you aware of, to avoid you wasting time and frustration
    in case you come across the same issues.

    Linux has, until now, used the X11 windowing system in the same way as
    other Unix systems and VMS has done.

    A new windowing system, called Wayland, is being introduced to Linux
    and unfortunately the people doing this appear to have designed this
    in isolation without listening to the creators of the major applications running on Linux and are saying that their new way of doing things in
    Wayland is by design.

    This is causing some major problems. The most high-profile one I am
    aware of is KiCad at https://www.kicad.org/ and which is a major open
    source PCB design package.

    The KiCad developers have documented their problems with Wayland here:

    https://www.kicad.org/blog/2025/06/KiCad-and-Wayland-Support/

    Use it as a checklist in case you run into the same kinds of problems
    while using Linux. If the problems you encounter are on that list,
    then you know it is not you. :-)

    Simon.

    Thanks a lot. Yes very new in Linux.

    I have to install all the Gnat Ada stuff, and then then Gnat Ada on LLVM project. Because perhaps it would be a way to get Ada on VMS/x86.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From cross@cross@spitfire.i.gajendra.net (Dan Cross) to comp.os.vms on Tue Dec 2 15:48:02 2025
    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 Craig A. Berry@craigberry@nospam.mac.com to comp.os.vms on Tue Dec 2 21:47:26 2025
    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 cross@cross@spitfire.i.gajendra.net (Dan Cross) to comp.os.vms on Wed Dec 3 17:04:50 2025
    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 Craig A. Berry@craigberry@nospam.mac.com to comp.os.vms on Wed Dec 3 14:56:55 2025
    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 =?UTF-8?Q?Arne_Vajh=C3=B8j?=@arne@vajhoej.dk to comp.os.vms on Wed Dec 3 20:29:00 2025
    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 Craig A. Berry@craigberry@nospam.mac.com to comp.os.vms on Thu Dec 4 08:07:39 2025
    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 =?UTF-8?Q?Arne_Vajh=C3=B8j?=@arne@vajhoej.dk to comp.os.vms on Thu Dec 4 09:15:46 2025
    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 =?UTF-8?Q?Arne_Vajh=C3=B8j?=@arne@vajhoej.dk to comp.os.vms on Thu Dec 4 09:51:17 2025
    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 cross@cross@spitfire.i.gajendra.net (Dan Cross) to comp.os.vms on Thu Dec 4 20:59:52 2025
    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