LegEasy4DOS - How it works?

The interest in LegEasy4DOS has been "overwhelming" since we released it at the end of last week.

A lot of eagerly awaiting Professional clients jumped at it and the feedback was not late to come.

Most of you are overjoyed and excited by this opportunity to run DataEase for DOS in a modern environment, and more than happy to scrap your old XP computers and Novell servers that has kept you up at night with worry - when will it draw its last breath and what will I do then?

However not all feedback is good and some of you have been "disappointed" too.

Some of this disappointment is down to us having problem with our server park after the release due to an unexpected heavy load - don't they always say that - but some of you have been running bench mark tests and compared it to "Native" DfD on Native XP, WIndows 7 x32 etc. and the results has baffled you.

Why is it sometimes much slower and then sometimes much faster than the comparison?

In the article below we will try to explain this and how LegEasy4DOS is designed and how it works.

We have to start with the beginning. 

LegEasy for DOS or rather the kernel part of the product simply called DEDos is not magic way of running 16 bit code on a 64 bit system, neither is it a new version of DataEase for DOS that is compiled for 64 bit - it is simply an emulator designed to emulate the ideal environment for a DataEase for DOS session.

It emulates DOS 5 - Which is the DOS that was around at the peak of DataEase for DOS when at the same time using Windows GUI and Windows Networking etc.

An emulator basically do in software what your old computer did in hardware, so everything is emulated.

DEDos emulates the CPU in software so DataEase for DOS CPU instruction will result in many real CPU instructions CPU internals like registers are maintained in relatively slow memory so at this stage the simulated CPU will be 70-80 times slower than the real thing!

This sound a lot but remember that this is actual CPU instructions and not real overall performance. Most modern computers, and especially the ones that will run DEDos have more than fast enough processes to compensate for the ones they will replace.

Some minor first compensation comes with REP instructions that actually perform faster (!) on the simulated CPU due to 32-bit optimizations and predicting CPU instructions.

The BIOS and DOS are emulated in 32 bit, so that accounts for some further compensation, but overall processor power (running a program) you can expect DEDos to be 30-35 times slower than XP. It is already getting better.

So it would seem a "miracle" that DOS programs can be used at all in DEDos. And mind, DEDos is a single core program, better overall system performance due to more cores isn't relevant. Not directly at least. Of course if other processes on your server use another core, the core that DEDOs use will have more time for DEDos and hence it will help performance - but that is another story.

Most of the time programs just wait for user input :). The second "fun" part comes when a program needs to read or write data. Some slow CPU simulated instructions are executed before these events, but then Windows takes over. Going thru several layers of abstraction code before even the hardware is addressed to perform the actual read or write operations. And that hardware is relatively real slow.

A DOS program performing better with networking in DEDos than in XP comes down to the operation system. Windows 7/8/10 will be more effective/efficient at communicating with other (Windows!) systems. Optimistic locking, some deferred local caching, dropping non-essential data exchange…

The drawback comes on a native or local drive.

With a local drive, Windows will cache reads and writes. The bottleneck of actually reading and writing data will be less (certainly compared to a network), while that of the slower CPU will become more prominent.

Our overall tests show that running a application through DEDos compared to the same hardware spec and XP on local drive is now 2-5 times slower than XP.

The real deal clincher is when you run it in the indented scenario with a Networked Database, then our test show that DEDos for the average DFD application is 2-4 times faster than XP because you now get the benefit of the faster networking in modern Windows compared to the older ones and the processors has less impact and the I/O more.

Depending on the application and the procedures/updates being run is I/O intensive or CPU intensive the difference can be greater in both directions.

So when evaluating LegEasy4DOS you have to test and take into consideration the actual use of the System in production as well as the benefits of getting rid of old XP/Novell infrastructure and not having to run Windows x32 on new computer (limited to 4GB memory etc.)

If you have big DQL's and processes in your network that you offline and run on local standalone DFD to increase performance, then you might consider to have a native Windows 10 x32 (or 7,8.1, 2008R2, 2012 etc) machine that do this.

Or simply await LegEasyConnect which will be your bridge between DataEase for DOS 5.x and the modern world. On the LegEasyConnect Server you will be able to run native DQL's directly on your DFD 5.x data and we can promise you performance that you have never seen inn DataEase for DOS before - not even close!

Published: 09/08/16 - 08:46:27 (Ulrik J Hoegh-Krohn)

Last changed: 09/08/16 - 12:39:40 (Ulrik Jacob Hoegh - Krohn)