DOS problems - differences between NTVDM in XP and Vista/7

[cwathen]

OK,

This year's technical query from me. My work uses a fairly prehistoric DOS-based EPOS system written 20+ years ago. Presently, it's deployed on a network with a Windows 2000 server, and a mix of Windows 2000 pro and Windows XP pro workstations.

It might be old but it's perfectly fit for purpose, everyone knows how to use it, and from a support point of view it's easy and cheap to keep running, being that it can run on generic (and basic) PC's rather than the more specialised equipment which modern systems need.

It runs quite happily under NTVDM on these platforms (I'm realiably informed that it actually runs better under NTVDM than it did when run under the native MS-DOS system which was installed before I worked there).

Now that Windows 2000 is unsupported, and XP is all but impossible to source, we are faced with the possibility that migration to a newer operating system will be necessary soon. At present you can use downgrade rights to get new hardware with XP rather than Windows 7 but this isn't going to be a long term option.

My understanding was that 32 bit builds of Windows 7 still featured the same NTVDM subsystem that was in NT/2000/XP and so should have the same level of support for DOS programs. I was aware of the full screen issue, but that in itself is easy to solve by changing to a standard VGA driver which is written as XPDM and supports the full screen modes.

However, even when running it in a window for testing, there are problems in Windows 7 which don't exist in XP - things aren't lined up properly on the screen, the option to 'back date' the system to review previous days doesn't work properly, and whenever any sound is generated (it makes various little chips through the PC's internal speaker in response to completed tasks and errors much like Windows does - and there is no option to turn these off in the program) instead of the correct noise through the speaker a horrible screaching through the soundcard is generated instead which goes on for several minutes each time.

I've read on the internet that the NTVDM in Vista was different from that in XP, in that 16 bit Windows programs can only be allocated 32MB of memory wheras under XP they could take as much as they wanted which caused problems with some resource intensive 16 bit Windows software. It would appear that there are also fundamental problems with DOS support under that version of the NTVDM and this has been carried on into Windows 7.

The thing is, I can't find anything on the internet referring to any DOS problems other than the full screen issue. It's also not just a weird problem with the particular machine I'm testing on - the same thing happens on another Win7 machine I've tried which uses completely different hardware.

Has anyone else come across similar issues with DOS programs?

DOSBOX is not an option - I've tried it in that and although the program works properly on a standalone machine, DOSBOX does not support SHARE.EXE or parallel port redirection, so I can't network it nor would I be able to get the receipt printers working. Neither is Windows XP mode. Not only would it mean needing to licence 7 Professional on all of the clients, but there would still be no proper full screen support.

One option I'm thinking of is using the NTVDM files from an XP installation. Does anyone know A) If this would work, B) what files would be required and C) would it break the licence agreement to do this?

Or ideally, is there some magical registry setting I can change to make the DOS support the same as that under XP??!??

[Dr Lobster*]

i don't know if it will work or not, but i suspect not. it will almost certainly have undesirable side-effects mixing and matching binaries from different versions of windows like that. all you can do is set up a dummy box and give it a try.

i think most it professionals come up against this brick wall every so often so a couple things i've either considered or had to do in the past in my line of work to keep things running:

1) virtualise
can you not use freedos or similar and the generic intel driver to create a virtual machine which runs in your client windows 7 installation? you should then be able to map to your windows printers using the share/net use command with the generic network card drivers. if you can get this working then you'll be able to keep it running forever like this.

2) remote desktop + virtualise
possible to virtualise your windows 2000 server and use it as a terminal services server to run the software?although windows 2000 is unsupported you could keep it running in a virtual machine forever too. you might not be able to run proper full screen like this but it would probably work.

3) try to get it running in Windows XP mode. this is probably going to be by far and a way the cheapest and easiest option. i know XP mode has it's quirks, but it does mean really easy deployment. set it up once and just copy the vhd over on each client. a windows 7 pro license for each client is a far cheaper option than a whole new system i suspect.

virtualising freedos might be a good way forward though, it should give you at the very least full-screen "windows" support, it will just be seeing if you can print using it. in theory it should work - i've had the generic intel drivers working on freedos in the past for such an a project, but never needed to print.

[Neil Jones]

virtualising freedos might be a good way forward though, it should give you at the very least full-screen "windows" support, it will just be seeing if you can print using it. in theory it should work - i've had the generic intel drivers working on freedos in the past for such an a project, but never needed to print.

The only problem with virtual machines is that they tend to literally live in worlds of their own and where they are able to branch out to other machines across a "real world" network, they almost always won't play nicely together out of the box. Windows 7, wonderful as it is for Joe Public to use on a standalone machine, it is a pain in the arse as it is to do any form of networking with it on its own, never mind adding other hoops that it has to jump through.

The main issue would appear to have a need to get it on the network in the first place. Virtual PC used to want to use its own networking adapter for network access (thus trapping it in its own world) and it used to take three or four goes through ghost network adapters to find one that actually connected to a a physical network port to get it on the network. Once you get it connected to a "proper" network, the next question needs to be can anything else get back to it, as I presume Cwathen's situation will need to work both ways. Usually if it can get back in it'll go out again.

[Dr Lobster*]

i don't deny virtualisation has it's pitfalls, but the problems you highlight neil are pretty easy to workaround and document within the organisation. i've certainly not had any network interface problems in my dealings with Virtual PC, but in my particular configuration the network was simple and had a DHCP provided address so it all just worked.

nevertheless it's certainly a more sustainable solution than hacking the operating system with previous versions of files, something which could break the next time you run windows update or install the latest service pack.

With a virtual machine, you've basically got a little machine stuck in a bubble that you can just keep going forever, if it gets trashed you just put a fresh copy back or restore the vhd file from backup.

i think that in cwathen's scenario virtualisation is probably going to be the best long term solution for him, it will take some r&d time to get working, and perhaps cost a few quid to get the licenses for Win 7 Pro, but that cost is fairly insignificant when weighed against the cost of a new system, migrating data and training staff etc etc. that's what i'd do, anyway.

my only worry is printing - it might be a problem, i'm not familiar with the system he uses so can't offer any specific advice.

[cwathen]

Thanks for the replies. TBH I was hoping that I'd be advised that there is simply a setting change needed to make NTVDM work the same way as it used to - being that there is nothing at all about DOS problems on the internet I'm seemingly the first person in the world to have an issue! Fortunately it's unlikely that I'll actually have to implement any of this for the forseeable future, but I want a contingency now so that I know how we're going to proceed when we end up with hardware which doesn't run 2000/XP - sadly it's a timebomb which those higher up in the company don't appreciate exists!

i don't know if it will work or not, but i suspect not. it will almost certainly have undesirable side-effects mixing and matching binaries from different versions of windows like that. all you can do is set up a dummy box and give it a try.

I've got it at the back of my mind also that it technically breaks the licence agreement to use files that are part of the operating system without the operating system that they came with.

1) virtualise
can you not use freedos or similar and the generic intel driver to create a virtual machine which runs in your client windows 7 installation? you should then be able to map to your windows printers using the share/net use command with the generic network card drivers. if you can get this working then you'll be able to keep it running forever like this.

That sounds worth investigating. I did try today running it under XP in VMWare Virtual Box and whilst performance was a bit slower, it was still acceptable. The full screen mode it gave me was odd though - the picture was squashed to 16:9 on my 4:3 monitor. Not got as far as printing yet. The other problem is that all of our 2000/XP licences are OEM licences which came with the hardware, so we can't (legally) just use them in virtual machines. The Freedos solution does sound worth investigating though.

2) remote desktop + virtualise
possible to virtualise your windows 2000 server and use it as a terminal services server to run the software?although windows 2000 is unsupported you could keep it running in a virtual machine forever too. you might not be able to run proper full screen like this but it would probably work.

Good idea, but I don't think we'd be able to print with this setup - there is only one copy of the program stored on the server so every station uses the same copy (this is why I can't run without SHARE.EXE being supported, as different copies of the program access the same files at the same time). On each workstation the shortcut to the program runs a small local batch file which maps drive X: to the network share on the server, maps LPT1: to the laser printer for reports, maps LPT2: to the particular receipt printer which that workstation has to use, and then changes to drive X: and runs the program. So as far as the program is concerned every receipt is simply sent to LPT2: and it has no knowledge that this is 3 different printers depending on which workstation the receipt is printed from. If I loose the ability to run the program locally on each workstation I don't see how I'd get around this.

[Gavin Scott]

Might be a better use of your time researching an EPOS system that runs on modern architecture and platforms, with a nice slow roll-out and training period.

[cwathen]

OK, latest update on this. Of all the virtualisation options around, only DOSBOX seems to operate with anything approaching the speed of running it natively. It also opens and closes lightning fast, rather than waiting for virtual machines to boot and shut down.

I did think DOSBOX was a dead end with it's lack of file locking and parallel port support, but I'm now persevering with it again. I'm playing around with one of the CVS builds (megabuild 5) which does provide parallel port passthrough (and a useful virtual printer which would work quite well for reports as it'd mean we could use any printer we wanted rather than needing to stick to a parallel port printer with native HP LaserJet II emulation).

I then found out that you can actually boot real MS-DOS inside DOSBOX rather than using the built-in operating system. You loose support for mounting real folders as drives, but you can mount hard drive images and run everything from that. Crucially, because I'm on real MS-DOS I should just be able to add 'install=share.exe' to my config.sys and then I should have the share support which the program needs.

This is when I hit another dead end. Although I'm running real MS-DOS and the program detects that SHARE.EXE is running so I get no error messages (if it can't lock files then it moans about it every 2 microseconds which it was doing under the native DOSBOX OS) but actual file locking support doesn't seem to be working properly. Data from one DOSBOX instance can be viewed on another, so data is being shared, but it doesn't seem able to actually lock the files down. A crucial problem is that it will let me perform the end of day process with multiple copies running (it's supposed to refuse to let you do it unless only one copy of the program is running to prevent data corruption).

Anyone ever tried to use DOSBOX in this way? Specifically, do any DOS masters know if there is anything which can stop share.exe from working?

Might be a better use of your time researching an EPOS system that runs on modern architecture and platforms, with a nice slow roll-out and training period.

Well obviously that may be what has to happen, but the idea is to avoid that. As I said the system we have now is perfectly fit for purpose and we're keen to avoid change for change's sake. Also, quite apart from technical issues from a usability point of view I'm not a big fan of modern EPOS systems. True, old systems are often illogical and come with a steep learning curve, but once you've got someone trained up I *know* that we can work with our rattly old keyboard and text system much quicker than someone can jab at a poorly calibrated touchscreen which then takes an age to respond - even if it is easier to learn.