For a workplace we are migrating to new desktops. We migrate from Win NT4.0 to Win XP and we have a problem with our financial software Exact.
We still use the old DOS application. This worked fine under NT4.0 running from the network. But with Win XP there are known problems in the DOS management wich can cause data corruption. This is verified with Exact and Microsoft. They changed a few things with memory/data handling and the old Exact can't handle it well.
To use Exact it need to load share.exe in its memory. This seems to be a standard component in NT4, Win2000 and WinXP. Probally also in MS-DOS since the finacial application was made for this. But in DOSBox it is not.
Is there a way to get it working or is it not supported? Command that needs to be loaded is:
I tried the SHARE.EXE from MS-DOS 6.22 (disk2) but when executed it imediatly exits DOSBox. When trying the SHARE.EXE from WinXP it runs fine. But Exact may have the same problem. I will try to get the one from NT 4.0 and try that one in DOSBox and see if it will work.
-- edit --
I tried to load the SHARE.EXE from NT 4.0 but when executed it displays as normal. But when Exact is started it says SHARE.EXE is not loaded. Anyone knows how to load executables in memory of DOSBox?
The command:
LH D:\SHARE.EXE /F:6000 /L:100
executes itself but Exact doesn't see SHARE.EXE loaded in memory.
As it sees now we should upgrade the package to windows version (very costly) or keep an NT 4.0 station to use.
We still use the old DOS application. This worked fine under NT4.0 running from the network. But with Win XP there are known problems in the DOS management wich can cause data corruption. This is verified with Exact and Microsoft. They changed a few things with memory/data handling and the old Exact can't handle it well.
Give us a hint as to what changed from WinNT4.0 and WinXP as far as DOS data management 'data' corruption... You said that Microsoft has confirmed this, can you post the relevant details. Is this perhaps corruption of the ES or DS registers on return from an Int 21h call?
What does the company which makes 'Exact' say about the error which does not exist in the NTVDM of WinNT4.0 (assume SP6) and the NTVDM of WinXP (what SP?) What fails in WinXP's NTVDM when it works in the older WinNT4.0's NTVDM? Is it networking, specifically concurrent file access and data corruption due to problems with file/record locking?
Well Microsoft has confirmed it to Exact who confirmed it on the phone of technical support. (Exact - www.exactsoftware.com ) I am not sure what causses the corruption. I think it is partly file handling/network related. So far i know it uses it own file-based database structure. When the program crashed on WinXP it generated two files that stopped at 4GB. But normally these files are around 20 MB for storing customer data.
It appears that there was a loop somehow. Accourding to the technical support of Exact it was to blame on WinXP. Best sollution of them was to downgrade to Win98 🤐
It worked perfectly in the same setup on NT 4.0 . I am a bit puzzled how to solve it. Since we would like to have all clients on WinXP.
If it does not work in normall DOSBOX, You can try to use disc images - in that case you can install another version of DOS in DOSBOX... (see DOSBOX Guides forum/README/WIKI).
Well Microsoft has confirmed it to Exact who confirmed it on the phone of technical support. (Exact - www.exactsoftware.com ) I am not sure what causses the corruption. I think it is partly file handling/network related. So far i know it uses it own file-based database structure. When the program crashed on WinXP it generated two files that stopped at 4GB. But normally these files are around 20 MB for storing customer data.
Just a little more detail. Is this particular Exact v7.1 Line-of-Business software used as a 'single-user' stand-alone database per workstation or does one workstation hold the master files and all the other workstations do updates against these master files via Windows/DOS file/record locking?
The reason I ask is that DOSBox might not be the solution you are looking for (even though it can boot a DOS image) unless you understand what type of application you are using. I can't imagine that multiple single-user databases would be that effective in a business situtation. If you can't define the problem it is hard for anyone to recommend a solution. The 'go back' to Win98 or the WinNT4 NTVDM does not work since you want to keep all your workstations at WinXP level.
Of course, the obvious question, does ExactSoftware make an updated Windows version of the older DOS software that your company could upgrade? Or is this particular DOS application a DOS-only legacy application which was never updated to a Windows version???
I tried to load the SHARE.EXE from NT 4.0 but when executed it displays as normal. But when Exact is started it says SHARE.EXE is not loaded. Anyone knows how to load executables in memory of DOSBox?
I have some bad news for you, the 882 byte "SHARE.EXE" file from WinNT4 and WinXP does the following:
1xxxx:0100 start: 2xxxx:0100 B4 4C mov ah,4Ch ; Dos Services 'Terminate' 3xxxx:0102 32 C0 xor al,al ; Zero register 4xxxx:0104 CD 21 int 21h ; DOS Services ah=Func 4Ch 5 ; terminate, al=return code
The SHARE.EXE file from WinNT4 and WinXP is identical, it is a 'place-holder' for older batch files which insist on loading SHARE.EXE, since all of that functionality is built into the WinNT/WinXP NTVDM operating under the WinNT/WinXP operating system. The above code means that as soon as the SHARE.EXE file is loaded, its only action is to Terminate. The reason the the Exact v7.1 application reports that "SHARE.EXE is not loaded" is that it is correct, there is no TSR in memory by the name SHARE.EXE, it was never loaded.
The actual SHARE.EXE from MS-DOS v6.22 is over 12,000 bytes large... The Win9x series of operating systems also do not include SHARE.EXE since they too incorporate that functionality via VSHARE.
I do not believe that using DOSBox with a MS-DOS v6.22 image, then using the MS-DOS v6.22 version of SHARE.EXE will help since the hosted DOS re-director has no way of communicating to other workstations from inside DOSBox. However, if this Exact v7.1 is really just a single-user version database software then the hosted MS-DOS v6.22 via DOSBox may be your answer.
Just a little more detail. Is this particular Exact v7.1 Line-of-Business software used as a 'single-user' stand-alone database per workstation or does one workstation hold the master files and all the other workstations do updates against these master files via Windows/DOS file/record locking?
The software is placed on a networkshare (that is connected as a local drive mapping). So all workstations that use Exact 7.1 are running on the same files on the same networkshare. Only one of the users has the rights to change data, the others only use the application to read data or print reports.
Of course, the obvious question, does ExactSoftware make an updated Windows version of the older DOS software that your company could upgrade? Or is this particular DOS application a DOS-only legacy application which was never updated to a Windows version???
The application was long time ago upgraded by ExactSoftware to a Windows version. We even have a license and the software in our vault. But when they tried migrating in the past, several tables went corrupt. It appeared that the structure between the used DOS application how it is implemented in this organisation and the Windows version was a bit different. And it would take a lot of manhours to check and import data by hand. At least that is what is documented in the company archives here.
A migration to the new version would be the most welcome, but with the current budgets and deadlines it is not possible. To strict bosses and to strict budgets.
Thanks for explaining the SHARE.EXE on WinNT, i will give the image of MSDOS 6.22 a try, but i am afraid that it will not give a solution to this problem. For the current time they can use a WinNT station which works without a problem.