Thing is, decompiling the program won't be very useful; unless you happen to know an assembly language expert- and one well versed in 8086 instructions as well as the CPM Operating System; in which case you'll just be confirming what is already known- it is written for an older operating system. The only recourse at that point would be to literally write a new application from the ground up that is fully compatible with it, but that would have a rather limited usage for your particular case- it certainly isn't something that somebody will decide to do on a forum such as this one; generally forums such as this may help with problems in a program that you've written, batch code that doesn't work, or help writing a small snippet- not the decompilation and rewriting of a very old program.
One might ponder "well, why would it need to be rewritten?"
It's not that the program is doing something wrong- as far as the program is concerned, it's interfacing with CP/M; but what it's really interfacing with is a DOS emulator running on a Windows system. Problem is, the DOS emulator was written to be compatible with DOS programs, not CP/M programs. It works for the most part because DOS and CP/M share a similar architecture; it's the differences that are causing the problems you are seeing.
The program, however- is not doing anything "wrong" since it is no doubt doing everything right in the context of CP/M; could it be "changed" to make the more appropriate DOS calls? probably. But again, that would require the time (and thus payment) of a Assembly expert versed in both writing 8086 Assembly for CP/M as well as DOS, as well as porting between the two; and if one is willing to invest in that, you may as well invest in migrating to a new system.
I believe I've mentioned this before in one of the other threads, but I'm all for the "if it isn't broke, don't fix it" line of thought, but that's the thing- it's broken. It's not easily fixed, so it should be replaced. The compatibility of a program is it either works on a newer Operating System, or it doesn't. In this case, you got lucky- the program does work, but with several caveats (including the network issue you stumbled on).Continuing to rely on FMS80 for your business is akin to relying on a house of cards to hold up in a strong wind; the odds are very much against you, and while some people get a perverse thrill out of being the one told "it'll never work" and "you can't do it", that hardly makes it a reasonable choice.
The reason the CP/M program chokes on a network drive may very well have to do with the fact that the network redirector isn't exposing the drive in a manner to which it is accustomed to seeing. What specifically this means I can't really say; it is more a guess then anything, but trying to figure out why seems somewhat fruitless, since even if you do determine the exact cause the only recourse will no doubt lead you back to requiring the hiring of somebody to perform tweaks to the application.
I see other apps written for our type of business and they are so out of touch
Do not take this the wrong way- but how can you be sure it is them that are out of touch, and not you- the person using a 25+ year old program? Is it not generally the person clinging to the old technology who is "out of touch"? Also, What visible problems do these newer applications cause to businesses that use them as a result of the application being "out of touch"?
because programmers and business people will never think the same.
I cannot speak for business people- mostly because I really cannot tease out what particular context that has here- but as for programming, of course it's changed.
With CP/M and DOS based business applications, particularly in the case of databases, you had text based prompts, where you almost always directly typed in queries using that programs query language. This required quite a lot more training and in general more technically inclined personnel. Now, you can generally get a usable database for a small business using Access, and it can include forms for data entry, with labels- all of which can be easily explained to data entry personnel.
While the power of the command-line interface in any number of applications, and computers in general- are very powerful, they are not something that you find in everyday, modern applications, because those everyday modern applications are written with the goal in mind, not the path to that goal. You no longer need to memorize a series of otherwise irrelevant database insertion, deleting, editing, and updating commands to manage your business data, instead you deal with more intuitive interfaces that allow you to get at the data you want; if a user has to learn how to do a basic task in your application- you've failed. That is the general consensus. So yes- programmers will "never think the same" but to say that in a manner that denotes that the change is negative is to ignore the fact that that very change- for better or for worse- has made computers far more accessible to everybody the world over.
I have had a lot of successes - sending HP control codes from my program to an HP network printer - opening a comport in NTVDM.
I wouldn't call those successes, as much as I would call them brash workarounds and hacks for a problem that is far easier to eliminate and will only grow exponentially with time.
