64-bit job control in OS/2, via AToF

[JTA]

In an AToF machine, the HostOS (Windows 10 for example) provides 64-bit functionality, the NTFS filesystem, and other services. ArcaOS (or OS/2), running in a virtualbox VM with guest tools installed, can access that HostOS 64-bit capability via the shared filesystem and "jobs".

For example:

1. You can place all of your OS/2 data files on "z:", which actually resides on the HostOS (NTFS); it can be managed and backed up by the HostOS, with 64-bit tools, automatically.

2. create & "drop" a command string into a jobs folder on the same shared volume, to execute a 64-bit tool on the HostOS like WizTree64.exe, which scans file sizes on z: and produces a graphical map to find excessively large files.

3. HostOS, perhaps with regina rexx (or a service, or powershell), watches job folder, parses and executes the job's command string, screen captures the graphical result, and returns job results to a sub-folder.

4. OS/2, perhaps with REXX, scans subfolder for job results, displays the .png, and you see the output of WizTree64, and know what files are currently taking up the most space in your data location's filesystem.

5. This is not interactive, but you could leave the graphical WizTree program running, and if the screen capture results sent to OS/2 justify it, you can switch to the HostOS desktop, and drill down further ... or, the WizTree program reaches a time limit, and exits, while you remain in OS/2.

OS/2 is executing 64-bit commands or programs on the HostOS, against *your* OS/2 data files, and results flow back to and are visible in your OS/2 desktop ... all via relatively simple job control scripting.

This isn't going out over the network, so no TCP/IP configuration or programming, it's just VM to HostOS integration via VirtualBox guest tools, and simple task scripting, along with numerous 64-bit apps running on the HostOS. As fast as you drop jobs into the job folder under OS/2, the HostOS is processing them, and returning results to OS/2.

There's really no limit to what can be done ... consider:
  - utilizing Wolfram Engine (free math tool running on the HostOS), and you could be executing complex math from OS/2, or sending AI queries from OS/2 out to Wolfram AI services via the Wolfram Engine, and getting AI results back into OS/2.
  - running 16-bit Wordstar or Wordperfect (dos, dos/win) under OS/2, creating documents, and then post-processing them into PDF's or other document conversions (on the HostOS) you might need.

Extend this with nearly any 64-bit application you can conceive of, as long as you can initiate it via external commands, or scripting and/or job language. Rexx or other scripting languages can make the job control effortless.

To give it a try ... AToF your system and see all it can do for you and your OS/2 efforts. More AToF details at:

    os2world.com/forum/index.php/topic,3498.0.html

[Neil Waldhauer]

I think you should focus more on extending the basic API of OS/2 to 64 bits.

Think about the task of moving 8 GB of memory around a 64-bit memory space.

[JTA]

My process has always been something like:

1. first, make it work
2. then, make it work right
3. finally, make it work better

So, to get 64-bit stuff "into" OS/2, I had to figure out the AToF methods (virtualization of everything on one machine, which presents 64-bit apps inside of OS/2), and this job control method running under AToF (which presents 64-bit job output into OS/2). This all works, so it fits #1 and was done fast ... either method gets just about any 64-bit app or app output into OS/2!

Doing API work seems to fall under #2 (for me), as there is a ton of programming to do ... it's better than job control, but obviously much harder to get done. At various times, some programmers have done bits & pieces of this, per threads in this forum, but this hasn't seemed to get anywhere?

Not sure, because I don't have OS/2 Warp for Powerpc (old microkernel version of OS/2) up and running to explore things (and this might not come to pass), but this seems to be #3 ... replacing the old microkernel with a modern seL4 microkernel, and building the OS/2 pieces on top of that.