Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - JTA

Pages: [1] 2 3 4
Virtualization / Re: ArcaOS in VirtualBox and mouse.
« on: April 05, 2024, 01:21:44 pm »
Not sure what version of vbox you are using, and on what Host OS?

Only similar problem I can find, with a bit of googling, is that within vbox, this kind of problem could be caused by your ArcaOS vm settings, display, monitor count being set to anything other than 1.

You can also test a brand new install of ArcaOS (from your registered ISO) into a new vm, and don't fiddle with the vm settings too much, until you know if that new test vm has the mouse issue or not. ArcaOS comes with a set of vbox drivers built-in, so you should be able to test the issue right away.

Hope this helps ...

Storage / Re: Boot from iscsi or fiber channel
« on: February 13, 2024, 03:46:19 pm »
I would offer that you can build up a Windows or Linux OS that boots diskless in your corporate environment. All infrastructure is 64-bit (OS, hba software, etc.), and the OS is up and running.

On that minimal HostOS that now has all the infrastructure in place, run only Virtualbox and ArcaOS within a VM, and run that VM full-screen. Within the VM, ArcaOS has access to all resources of the HostOS, including 64-bit apps. If the HostOS can provide it, most likely ArcaOS can access it virtually. At this point, you've captured the ArcaOS setup via the HostOS, wrt backups & such.

You'll need to license ArcaOS, and most likely Virtualbox (in a corporate environment), in addition to whatever HostOS requirements might be needed for ISCSI, FC, etc.

Look in the Virtualization category of OS2World for all the AToF documents which describe the approach to virtualizing ArcaOS, and which gets you around all this device driver grief.

Hope this helps!

Hardware / Re: The last nail in OS/2's coffin
« on: January 25, 2024, 01:41:54 pm »
Poked around on other forums, mentioning the X86-S spec, and folks there pointed out some VirtualBox tidbits:

  - old versions of VirtualBox emulated enough of a CPU such that they could run OS/2 when other virtualization products couldn't.
  - newer versions of VirtualBox no longer needed that emulation layer, as they could pass things thru to the CPU directly. But, to this day, VirtualBox still has pieces of QEMU in it.

Most likely, both VirtualBox and QEMU will be able to run OS/2 long after a particular x64-only CPU can't. I'd guess that Intel needs a new line of x64-only CPU's to carry them further into the server ecosystem. But I'd also guess that they'll continue CPU's that support legacy business apps for a long time (lots of money there).

If DOS, an OS that is older than OS/2, can be emulated and survive & thrive to this day, there shouldn't be any reason why OS/2 (all variants) can't be emulated as well, and prosper long into an x64 world. VirtualBox (virtualization) and QEMU (emulation) will get us there.

CPU's might take away a needed "layer of compatibility" on the one hand, but they almost always give back with "speed" on the other hand. Emulation developers do the rest ...

General Discussion / Re: Reg article on CUA
« on: January 25, 2024, 01:26:40 pm »
It *is* interesting, in more ways than the CUA interface aspect. It points at another "Register" article (16-bit DOS), which says:

"ms removed the 16-bit compatibility layer from x64 Windows OS's of the time, and you could no longer run 16-bit apps. Developers responded with DOSEMU", and many other flavors of DOS emulators. To this day, you can run such emulators to get at the many versions of DOS OS and applications, "on x64 Windows & Linux".

That's an OS that is older than OS/2, and if it can be emulated and survive & thrive to this day, there shouldn't be any reason why OS/2 (all variants) can't be emulated as well, and prosper long into an x64 world.

Hardware / Re: The last nail in OS/2's coffin
« on: January 22, 2024, 06:34:56 pm »
There are two ways to run OS/2, better than it runs on hardware (which does have its limitations) ... the first is virtualization (Virtualbox), and the second is emulation (QEMU).

WRT virtualization (and OS/2), it allows things to be used long after most folks can't figure out how to keep using them on existing hardware ... their hardware dies, and they just stop using the old stuff. By virtualizing, the old stuff pretty much runs forever ... implement virtualization, perhaps by the AToF methods in the virtualization sub-forum, and OS/2 will run many, many years past the point where folks have stopped using OS/2 on "old" hardware.

WRT QEMU, it emulates the processor(s) that OS/2 ran on, and given a reasonable platform, you probably couldn't tell that OS/2 was being emulated.

I'd believe that both of these methods, and others that I haven't explored yet, will keep OS/2 running long past the point of current "old" hardware methods.

Given the popularity of all things "vintage", I'd also believe that OS/2 will be running such that the baton will be handed off to many more "generations" of OS/2 users.

I'm not sure we've seen all that virtualization & emulation has to give us ...

Applications / Re: ArcaOS 5.1 - First Impressions
« on: January 18, 2024, 12:27:33 am »
If you look on the ArcaNoae website, they seem to be adamant about supporting ArcaOS on a physical machine *and* in a VM (at least in terms of voicing that support on the webpages). You have a choice, and I hope they continue to support both approaches *equally* into the future:

  - every advancement in device drivers, app dev, plugs a current hole
  - continued Guest Additions dev keeps ArcaOS entirely problem-free

This is an important point, because you can run ArcaOS on a physical box as the primary OS, which does open yourself up to the problems with that approach ... lack of device drivers, applications that aren't quite modern enough, etc. UEFI allows you to multi-boot your way out of this. Or, ...

Run ArcaOS in a VM, with the HostOS providing *everything* that ArcaOS can't, or may not get to until future releases. There are no major device driver problems, no lack of access to modern apps, and so on.

If you go the AToF path of virtualization (shameless plug, see virtualization sub-forum), then you also get x64 app access within ArcaOS, and more.  Everything available at once, no multi-booting.

A (more) modern version of OS/2, and more choices for each on how to run it.

That's progress ... and why OS/2 (ArcaOS 5.1) is still relevant today!

Article Discussions / Re: Too many cases of "OS/2 is dead, dying, etc"
« on: January 17, 2024, 09:35:45 pm »
Sent a "tip" (ArcaOS article) in to a day or so ago, via the site's submittal form:

No idea if it'll get published or not, but others are welcome to try as well. If anything shows up at their main page, we'll know that this site "accepts" ArcaOS (OS/2) articles, vs dropping the submittals for whatever reason, as in, they may not want to publish anything but "OS/2 is dead" types of articles.

Article Discussions / Too many cases of "OS/2 is dead, dying, etc"
« on: January 16, 2024, 01:05:33 am »
The most recent article pointed at on these forums (was it Informer?), was typical. In the same article describing how OS/2 is dead, they mentioned ArcaOS, which to me implies OS/2 is anything but dead ... it is still very actively developed and very useful! But, they write the article as if OS/2 were dead anyway.

Hackaday was a tad bit better ... they had this: "The Hobbes OS/2 Archive is a large collection of OS/2 software that has been publicly available for many years, even as OS/2 itself has mostly faded into obscurity." It hasn't faded, it has exploded, but who knows this?

In fact, there is a naming/association problem ... many know the term OS/2, and not as many know the term ArcaOS. So that's an issue ... if OS/2 is considered dead, mentioning ArcaOS in the same article doesn't do anything to resurrect OS/2, and perhaps, ArcaOS is also being considered dead, by association. That is a huge problem.

32-bit OS's are very much alive, and still in use. Millions use 32-bit versions of Windows (XP or older, thru to 8.x) ... they aren't going away, and probably won't switch to anything else until forced to (their hardware dies, and the replacement has Windows 10 or later on it).

Many dozens more use 32-bit versions of Linux distros, or RPi OS's, or whatever ... obviously, I don't know what these numbers are, but I'd guess they are up in the 10's of 1000's, and possibly 100's of 1000's (if not millions).

And of course, many billions use ArcaOS, which is 32-bit ... actually, I don't know what these published numbers are either (anyone?), but if I don't, I'd imagine many others don't either, and the message isn't getting out there to everyone else. At Warpstock '23, I think I overheard that, commercially, many 1000's or 10's of 1000's of copies are in use. What are the official numbers?

So, where's the beef (the articles)? There's some writing to be done ...

1. How do we refute the constant drone of OS/2 is dead, when it is very much alive? Write more articles, ourselves, and figure out how to get them published. Did ArcaOS ever sort out "tech evangelists", as these have an important role as well?

2. What forums, online magazines, and more do we need to target (blanket) with articles showing what we can do with ArcaOS right now? Get the list of such, and determine their "publishing rules" (many of which might block OS/2?). Have to figure out who to send the articles to, what objections that need overcoming, etc.

3. Boilerplate some articles? I can produce a boilerplate article in about 5 seconds; writing content is easy ... cleaning it up, peer review, and revising it is what takes time.

4. ArcaOS - Thrusters on Full (AToF)? All my articles on this are in the Virtualization folder, so they just need reworking into "article-length format". These basically take away any argument that OS/2 can't be used, because of this (only 32-bit), that (no 64-bit app access), or the other (old stuff, when many active ports from the Linux world are everywhere).

... and so on. Need lots of feedback here ...

Virtualization / AToF - 03 - Platform Build - to UEFI or not to UEFI
« on: January 15, 2024, 09:15:28 pm »
In the beginning, there was BIOS ... and life was somewhat simple. However, every computer manufacturer out there decided to "fix" this problem. The internet provides all the gory details of various BIOS issues, but most folks have by now figured out how to maneuver around in their computer's BIOS and get things done.

Along came dual-boot, and various boot managers of those times. Mostly outside of BIOS, you could install a boot-manager, then proceed to install various OS's side-by-side, and hopefully, nothing went wrong or ever will go wrong. This also introduced us all to partitioning, disk drive sizes and filesystems, and filesystem viewers/device-drivers/etc., wrt boot managers. OK, a little harder, but we got through all of that.

Then, along came EFI and UEFI, yet another "fix" to the BIOS problem, although this seems more of a bait and switch to me. It's now either BIOS (possibly Legacy CSM) or it's UEFI ... pick one, and choose wisely.

If you chose UEFI, or if the choice was thrust upon you by your computer manufacturer (and Microsoft), and you didn't fix this choice in your favor, you are now in the midst of a UEFI revolution. Do I accept the UEFI overlords, do I rip them out and do something else, will they stage a COUP if I do rip them out and now they have reinserted themselves?

Plus, it all still seems like dual-boot (more appropriately, multi-boot) to me. OS's are installed side-by-side, and we are all hoping nothing goes wrong. Reports on the internet are that, yes, occasionally things go wrong. It might even be possible to brick your laptop in certain ways, if you had the right combination of a certain Linux distro, and you were installing it onto a certain laptop with UEFI; this doesn't apply to the majority of Linux distros, but it's out there.

ArcaOS folks gave a great presentation (Warpstock '23) on UEFI and AOS 5.1 support for it, and how to get everything working ... looks good. rEFInd might also possibly help in this matter ... but, it's still in "beta" stage. I'm self-printing everything I can find, both UEFI history, and rEFInd-like technology, and I'm getting near 150 pages of ... something. The next phase in our computing journey seems to be that we'll all become UEFI system administrators.

So, wrt AToF, what do we need to do? As best I can tell ... absolutely nothing.

As in, don't use UEFI, or revert to BIOS if you can, or just leave the computer the way you found it, hopefully running either Windows 10 or 11 pro/enterprise, or Linux, and with whatever BIOS or UEFI choice they made for you. In AToF terms, this is the HostOS, and whatever boot method was running that OS when you got the computer. It doesn't really affect AToF.

Personally, I'd tend to rip out UEFI as being too complicated to be helpful in an AToF scenario, as the hypervisor is pretty much acting like UEFI. The difference is that UEFI is either-or (run this OS or that OS), whereas a hypervisor is all-you-can-eat (run as many as hardware resources allow, all at once).

I'd revert back to BIOS (where possible, and my 2018 Dell Laptop allows this), and proceed with AToF. But, I don't know all of the ramifications of this, and perhaps you'd want UEFI to permit better recovery options or whatnot. So far, it hasn't impacted me in my implementation of AToF on top of BIOS, and I don't thing it will impact those who just have one HostOS in an AToF scheme (and they left either BIOS or UEFI in place as they found it).

So, if we have implemented AToF, there shouldn't be any need to further fiddle with UEFI or BIOS, because whatever supports that single 64-bit HostOS is fine. The magic is in the fact that all other OS's won't be in a dual-boot or multi-boot scheme (the problem UEFI purports to fix), they'll be in a *multi-VM* scheme, and a key advantage to ATOF over UEFI alone is that all of them are running at once.

Contrast that key advantage to an old dual-boot or multi-boot boot manager, or a newer UEFI implementation (perhaps rEFInd), where you pick the OS at boot time, use it for awhile, then realize you need to do something in another OS, so you shut down the original OS, boot another and finish the task, then shut it down, and boot the original ...

The appeal for UEFI might be there for others ... the siren call to run ONE OS at a time, and have all the hardware features of a 64-bit computer working with that OS is strong.

ArcaOS folks are working hard to make things better under OS/2 (ArcaOS 5.1 and later), and all hardware features work if under Linux or Windows x64 OS's. But, OS/2 is 32-bit, and will be for the forseeable future. Unlike all of today's current articles in the world about OS/2, which either proclaim it's death, or it's zombie-like hanging on, or whatever, 32-bit OS's are still in use. Windows x32, ArcaOS x32, Linux x32 ... these are all still prevalent and viable.

AToF makes them better, because you can run multiples of these 32-bit OS's, all at once, and switch between them with a mouse click. They all inherit, through VirtualBox, the x64 feature set of the HostOS. All limitations of a 32-bit OS are removed.

No bios fixes (UEFI) needed ...

As a sidebar, we just need more, and better-written, articles showing the alternatives! I'm pondering articles and venues (who to submit them to, and would they even accept them), because I'm tired of seeing "OS/2 is a dead OS" and such.

As another sidebar, it's beyond my timeline and hardware resources to test (I don't own any ThinkPads), but theoretically, it's possible to have an AToF solution with ArcaOS running in one or more VM's, and ArcaOS running under UEFI as a multi-boot OS. Thus, you could compare for yourself how ArcaOS runs on native hardware (the standard for ArcaOS seems to be a ThinkPad), and how it runs in a (AToF provided) VM. Perhaps those folks with Thinkpads, old or new, could consider testing this out, and reporting back to this Virtualization forum.

Note: AToF utilizes VirtualBox (vbox), and vbox understands UEFI from within a VM. You can install an OS into a VM, choosing either BIOS or UEFI. BIOS is simpler, but the latter means you can test out all kinds of UEFI scenarios, including rEFInd. This is one of the strengths of vbox, and therefore of an AToF implemenatation. Your HostOS, your ArcaOS (or three), and any number of VM's for testing things, without polluting your critical HostOS & ArcaOS build efforts.

As always, any feedback on AToF would be greatly appreciated!

Sigurd, as I follow this thread, it's great news that you got both Win11 and AOS up and running on this Thinkpad. If I'm following correctly, it means you can dual-boot (multiboot) into one OS or the other.

One remaining task seems to be preserving all this effort, as in, imaging both OS's plus the EFI stuff, to the point where you can resurrect the entire machine from scratch, and get it right back to where this known-good state.

I also assume that AOS can see 1.4GB of "free" RAM, as this seems to be a 64GB ram system. This means you'll have one OS/2 running at any time, and you'll still be somewhat RAM-bound at times, depending on what you're doing. Possibly, you'll still be fiddling with hardware issues here and there, under OS/2. If you need something under Windows, you'll be rebooting into that OS, and losing access to OS/2 temporarily.

In the meantime, there are plenty of powerful hardware resources left over on your machine needing exploitation, and perhaps not just as a RAM drive?

Might I suggest AToF'ing (ArcaOS - Thrusters on Full) this system? All the docs are in the "virtualization" forum of These docs have received lots of "views", but not much in the way of feedback. AToF docs are at:,24.0.html

From where you are right now, I'd suggest this quick test, which shouldn't risk any changes to your existing build in which you've invested so much time:

1. boot to Win11, install Virtualbox, and then install AOS in a VM, and see how it works for you, including how much free RAM is available inside that VM. Note that both OS's are running at once, which is powerful magic, as you can switch between them with a mouse click.

2. now install another AOS in a VM (for test purposes, just reuse your AOS license), and perhaps even another. Each has 4GB of RAM to play with, and you are no longer bound to one AOS. In the meantime, each is accessing the resources available to the Win11 OS above it, meaning wireless network access, etc., and everything is running at once, with no multi-booting.

This test doesn't really change anything on your current Thinkpad build, as you can throw the test parts back out again (remove Virtualbox and the VM's). But, it does let you, or anyone else with a similar laptop setup, see the power of running everything at once, with virtualization and multiple VM's. You'll still have more resources for other VM's, for Linux, for development, or whatever.

I don't have Thinkpads myself, and am not tied in to the "experience of ArcaOS on any given model of Thinkpad", but I've run a similar test on my Dell laptops, and others, and it works well. It would be helpful if you ran the same (reasonably quick) test, and reported your experiences back to the forums. No other part of AToF needs to be done, just this part of Virtualbox and VM's.

You'll be in a unique position where you can test things under AToF (ArcaOS in a VM), and/or test things under a boot straight into ArcaOS via rEFInd, and compare/contrast both experiences.

Plenty of folks might have all kinds of issues with running OS's in VM's (particularly OS/2), and until that gets exposed by folks running more tests, we don't really know if AToF is all that helpful, especially to the ArcaOS/Thinkpad set of folks.

Obviously, you can disregard my whole post and continue running one OS at a time, out of your current two OS's under the EFI/rEFInd setup. Again, it's really great that you got to this point! But, if you can run the test, it would help plenty of others who might be considering AToF but not wanting to take the risk until others have tried it and reported back ...

I might be able to add to AToF the ability, as noted by others, of running ArcaOS in a VM or easily booting directly into ArcaOS, if any issues need comparison to sort out.

A long post, but your new machine should rip right through it in seconds! Good luck with your new build!

Applications / Re: ArcaOS is the best multitasking system there is
« on: January 08, 2024, 04:29:43 pm »
... in Windows.  The desktop gets cluttered.  You can only open one instance of the program.

While not arguing whether Win or OS/2 is the better OS for app development, I did ponder the "can you open multiple copies of same app, under windows" piece. I believe this is dependent upon the developer of the app, and if they restrict it, or if it doesn't make sense for there to be two or more copies of their app running under windows, there could be difficulties?

Launch a windows app, and then hold shift key and click the app on the windows toolbar, and see if a second copy of the program launches ... if a very specific program doesn't seem to work well with this method, then the developer may be checking for and restricting a 2nd running copy. In which case, we have to cheat ...

Use Sandboxie Plus, or create a 2nd acct & have that acct run another copy on the same machine.

Or, my personal favorite (a bit biased here) is to use virtualization, and just spin up multiple vm's running the same program, all accessing data on the shared filesystem space. Works for Windows, and for OS/2 (just not needed in OP's case) ... could be a tad expensive in licensing costs, though.

OP has a good scenario for *why* we use OS/2 instead of Windows, and I'm adding it to "the sales list" ... alongside OO desktop & such, where things just aren't as polished under Windows, to this day. Such examples make it easier to show OS/2 strengths to someone who thinks in only Windows or Linux terms ...

Hope this helps ...

Sidebar: AToF and the HostOS update process

If Windows is your primary OS, you are the proud *lessee* of a Microsoft (MS) OS. They own it (as the "lessor"), and do all kinds of things to it in the "update process". They still allow you to pay for the OS, for the privilege of belng the "lessee" (owner) of the OS. Sometimes you get what you think you're getting in the patch process, and the OS is patched for bugs or for security reasons. Many times, you get what you don't think your getting, and the base OS is "upgraded", not updated. New features come down, old things get taken away. If you've applied a customization, some of these "updates" may undo it for you. Nobody really ever knows what is coming down the pipe on "patch tuesday", when the OS is Windows.

The AToF HostOS mechanism is about ending this MS update process, and making the OS your own again. Not only is it "lean and mean", it no longer participates in "updates" the MS way. The HostOS is truly more of a service, and exists only to provide core services to the AToF machine and VM environment. However, now that the OS is your own, it also means you have to be responsible for patching it, with just those patches that you truly need (bug fixes only).

Why "bug fixes" only? We don't use the HostOS for anything on the internet, nor do we use it for anything on the HostOS "desktop". It is not our "daily driver" OS. Therefore, it isn't exposed to the security dangers of our daily driver desktop, where we are browsing the internet, or using applications that reach out into the world, and where all of these things could bring dangers back into our desktop, if not fully patched each month.

What *is* exposed to the dangers of the world is your "daily driver" VM, and that could be a Windows, Linux, ArcaOS, or any other VM where your "desktop" lives. It is our use of the desktop OS that makes the OS insecure and in danger.

This daily driver VM (DDvm) is the machine that you need to keep up to date on patches, security best practices, and anything else you can think of, to keep the dangers of the world at bay. So, the update process has moved down from the HostOS to the DDvm (running ArcaOS, or Windows, or Linux). Inside of a Windows DDvm, we still restrict the MS update process to a degree by using the WAU Manager binary, which at least turns off automatic MS updates, and allows you to review the available updates and have a degree of choice in applying those updates. But, the Windows DDvm is not AME'd (ameliorated), which removes the majority of MS controls over your OS.

What about the HostOS running Windows ... who is keeping that up to date? Well, you are. Believe it or not, it is still possible to update the OS by hand.

When the Windows HostOS is operating as a service (because it's been AME'd), it doesn't really change. It stays at whatever OS level you built it at. Forever (in computer terms). MS isn't upgrading the OS in the background, each and every month. If you ever choose to "update" the HostOS running Windows, you'd just go to the Microsoft Update website (aka the "Catalog"), find the latest bug fix or security updates, pull them down, apply them, and then re-AME the HostOS. You can't do these steps with the nifty WAU Manager, you'll have to do them by hand. But, it isn't really even *necessary* to do these, unless there is a critical bug fix or security update that has the world in a panic, *and*, you agree that you need to panic as well.

Inside your daily driver VM (DDvm), which could be running Windows, Linux, or ArcaOS, you *would* be patching the OS using the native update mechanisms, because it is this DDvm OS that is exposed to the dangers of the world, and needs all the update help you can give it. If ArcaOS, then ANPM. If Linux, then package manager. If Windows, then WAU Manager (if you want control over the updates).

If your AToF HostOS is Linux, then there is no AME process (it isn't needed for this OS type), and your standard Linux package managers do (or help you to do) all the update work.

What if we want to *upgrade* the HostOS running Windows? This, too, is possible, but will have to be another sidebar.

Virtualization / Re: ATof - Usage - Programmer's IDEs and Editors
« on: December 11, 2023, 05:38:39 pm »
True ... a Windows app isn't ever going to be a native OS/2 app, taking full advantage of the Workplace Shell. But, they will typically have other very modern features and UI improvements that won't happen in the OS/2 world until ArcaOS has penetrated the OS market to the point where software vendors and developers sit up and take notice. Then, they might start porting their Windows apps to a true, native 32-bit OS/2 platform ... if they consider it possible or viable.

I hope this comes to pass, and that more development happens ... I also hope that Arca Noae gets more technical evangelists out into the world to spread the message about ArcaOS, as mentioned at Warpstock 2023. More messaging, more application development, more OS/2!

In the meantime, programmers and others would probably use whatever tools they find to be the most useful, maybe even more than one, on whatever platform supports their development. It is possible that an AToF system, with everything all running at once on one machine, would make it *easier* to use multiple OS's and multiple applications, and boost their productivity even higher.

Perhaps VSE in a VM, or via FreeRDP or Winflector, alongside whatever is being used in ArcaOS, all on the same machine?

Virtualization / ATof - Usage - Programmer's IDEs and Editors
« on: December 11, 2023, 02:18:33 pm »
Many OS/2-specific editors & IDE's have ... quirks; having been built years ago, if not decades ago, and source code for them is iffy at best (closed, lost, old, etc.), so what do we do?

If you only run ArcaOS as the HostOS, then you are limited to what runs as a native app, or what runs in a FreeRDP desktop on a machine somewhere else on your home network.

If you have an AToF system on your DT/LT, then you just run the best programming editor (ide or editor) out there that you want, and AToF will:
  - run it side-by-side with ArcaOS (a pair of VM's under the HostOS)
  - deliver it within ArcaOS (a window running the IDE or Editor)

In the case of Visual Studio Code (an IDE), I looked into VSCodium (the telemetry-free version of VSCode). It's a full-blown IDE (more like a browser), and when you run it, it launches half a dozen or more child processes (just like a browser). If you test it on Winflector, the client window won't properly display VSCodium, so it's not a good app (yet) for serving up as a single Window in AOS. Not to worry, as we can still run two VM's side-by-side. So, VSCodium and AOS are shown in the pics below, running side-by-side in VM's, and accessing the same source code file in the AToF common filesystem space. You could also FreeRDP the side-by-side Windows VM (the desktop view) with VSCodium directly into ArcaOS, if you prefer that method. See the attached pics for VSCodium.

In the case of Notepad++ (a programmer's text editor), when looking at how to get access to it in ArcaOS, it runs as a single process, and does indeed run well in a single window in AOS, served up by Winflector. You could get access to Notepad++ directly within AOS (as demonstrated at Warpstock 2023), or also run it as side-by-side VM's. See the attached pics for Notepad++.

In an AToF dt/lt, this is how you'd handle getting a modern Programmer's IDE or Editor into (or next to) ArcaOS, all on one machine. The number of VM's you can run side-by-side (SxS) is limited only by the RAM on your dt/lt, and a rough rule of thumb is 4GB/vm. As in, HostOS = 4gb, AOS#1 = 4gb, winVM = 4GB, ... on my $200 32GB lt setup for AToF, there's room for lots of VM's.

At least, until the issues of finding old source code for the original app, porting/coding, etc. get sorted out, and then you'll have a native version of the app directly in ArcaOS.

Virtualization / Re: AToF - Platform *Built* - how do I buy one!
« on: December 11, 2023, 12:03:19 pm »
Another build option ...

4. Remote setup - As AToF relies on a HostOS to be installed, a totally remote setup of AToF seems possible, and could survive reboots (resume session). Customer has shiny new DT/LT (or used, as in my test case), and installs Teamviewer host component (or any similar product), with internet connectivity. AToF tech remotes in, owner authorizes the session, and the AToF process starts. This is more for Windows as HostOS, as folks on Linux as HostOS probably don't need the assistance. steps:
  - review remote access & system (can reboot occur, and session resume?)
  - WAU Manager
  - prep for amelioration (AME)
  - Virtualbox
  - final review
  - build VM's (ArcaOS, others)
  - handoff to owner

Again, all viable options (as in, someone wants to do it this way) are for those who just don't have the time to set up AToF themselves, and *want* to pay someone else to do it.

Pages: [1] 2 3 4