From a Microsabio bulletin board discussion "Suggested Platform - OS for A-shell " of November 2012.

Question

My client is running A=Shell 4.8 on Linux, and is considering moving to Windows. They have approximately ten users on the system, and we originally went with Linux because it was a better choice than Windows for that many users. However, that was more than ten years ago.

Would Windows now be reasonable for ten users? And if we convert to Windows, how much recompiling of their .bas files will be required?

Reply

There is a range of possibilities for a Windows environment (P2P workgroup, domain server, ATS, Terminal Server), but all of them would work fine for 10 users if properly configured.

Most A-BASIC applications are disk-bound, rather than CPU bound, and rely on shared access to files with some kind of locking scheme. So in choosing a configuration, you should give more consideration to that aspect of performance.

The peer-to-peer (P2P) workgroup is the simplest and probably the cheapest Windows configuration, but has the lowest file I/O performance and the greatest exposure to network problems, particularly if different versions of Windows are in the mix. /

A domain server is a step up in terms of overall network reliability, but not a big step in file i/o performance.

The ATSD (A-Shell Telnet Server) and Windows Terminal Server (along with its competitors - Citrix, etc.) put all the CPU and file activity load on the server (as in Linux), but end up giving you much better performance by eliminating all the network file sharing overhead. Given the same hardware, Linux will still be faster, but the point is probably moot given the performance of modern hardware.

If your server is old, tired, or short on memory, ATSD might be a better choice since it has relatively tiny overhead (less than 10 MB per connection), and is probably cheaper. But any decent modern server with 4GB+ of RAM and a quad-core CPU can easily handle ten Terminal Services connections, and does give more flexibility in client devices.

Note that ATSD, unlike Windows Terminal Server and its ilk, does not strictly require a "server" version of Windows; an ordinary "professional" version will work just as well, at least from A-Shell's perspective, for a system of modest size. This can further reduce your costs for licensing and the expertise required, if you don't have any other reason to use the features of a true Windows "server". At some point, perhaps above 20 users, the advantages of the "server" editions in terms of resource management become more substantial or even necessary.

As for the recompiling, you may not need any, either for the platform change or the A-Shell update. Regarding the platform, the only issue would be if your application had extensions that specifically related to the UNIX environment (e.g., referenced native filespecs, launched native LINUX commands via HOSTEX, etc.) As for the update, the old RUN format is still supported by both the runtime interpreter and the compiler. It's always possible though that in the intervening updates between 4.8 and the current 6.0, some fix, change or enhancement might inadvertently affect your app.

The main compatibility issue that I know of is the switch from octal to decimal for the [p,pn] system in 5.0. This was done to expand the range of PPNs from 255x255 to 999x999, which was important to some developers with large sites subdivided by PPNs into companies, departments, profit centers, etc. The change does not affect RUN programs per se, unless you used a subroutine to manipulate PPNs that stored each as a single binary byte. Obviously, to handle 999, you need either two bytes or a three-character string.) If unsure whether that might be an issue, you should probably grep your source for SUBROUTINEs and generate a list of all the different SUBROUTINEs you use, which you could either look up in our documentation or send to us for review. Fortunately it's usually pretty easy to swap out or upgrade such calls, assuming it's even an issue at all.