A second and increasingly important goal of DPT was to provide an alternative platform for running production User Language applications. After all if you can run code on DPT during testing and debugging, you can run it live as well. Some Model 204 customers have a large body of User Language code but no longer need the power of a mainframe, and DPT gives them a small-platform option other than rewriting all their applications in a different language.
To answer another common follow-up question, DPT does not sit atop any off-the-shelf DBMS such as Microsoft Access, Berkeley DB etc., but has its own custom-built file system, emulating the Model 204 file system. Obviously this was "reinventing the wheel" to a certain extent, but the need to support various specialised bits of User Language functionality steered things that way. For example FILE RECORDS and DELETE RECORDS rely on invisible keys and existence masks respectively, neither of which are universally standard DBMS features. Plus believe it or not it was a lot of fun to code!
The DPT host component has just one or two direct Windows hooks for performance reasons so a port, if one were attempted, might be relatively straightforward. The client on the other hand involves a lot of GUI stuff which talks directly to Windows, so it would probably take longer to port. Starting from scratch with the client and using a cross-platform IDE framework such as Eclipse would probably be the better way to go. A partial solution of just porting the (easier) host would make a lot of sense since *nix servers are more prevalent than workstations, and the existing Windows client could connect to a *nix host.
On a similar subject, a host port to something like native Z/OS would also be a possibility. Since mainframes now run Linux programs though there would be less incentive to do that (see Wine comment).
If you're interested in making some kind of non-trivial change/enhancement and need help getting to grips with the source code, please get in touch. Likewise if you just want to see if you can sweet-talk somebody else into doing something :-)
Firstly note that DPT is entirely legal. It consists of brand new code written without looking at the underlying M204 code. Actually the term "emulator" does not strictly apply to DPT (see comment in the strategy introduction).
The other main thing for Model 204 users to remember is that their User Language code is their own intellectual property, not that of a vendor. No (civilized) law will ever make it compulsory to buy a particular vendor's product in order to exercise your own IP rights - i.e. run your own code.
There is a lifetime's reading on this subject out on the internet, and you can easily do your own searches. Much of the debate is not really relevant in this case though, as it concerns games, and things are complicated there by the habit of emulator providers of distributing copyrighted games along with their "warez". The emulators themselves are usually law-abiding software.
Another extremely common question: how will it make money like this? The only answer to this is that DPT was never a money-making exercise, more of a gift to the M204 community. Maybe it will make money somehow, some day, maybe not. It doesn't matter so long as users like it and use it, and it works reliably for them.
More seriously, without DPT or something like it Rocket/Sirius hold a monopoly in the market for Model 204 compilers/runtimes, and a near monopoly on development tools. Monopolies are not good for anybody with a large demand for the monopolized goods - in this case that means users with a lot of M204 code they can't easily port to other platforms. Competition is good.