Member Avatar for waves

Hi all

I have an old windows server 2003 (32bit) with a shared folder containing an executable. The exe is old and I think possibly 16bit. I am trying to run the exe on a networked pc through a mapped folder / network location.

The pc is running win 7 (32bit) and after clicking the exe shortcut a message appears asking whether I want to allow the program, which I allow but then nothing happens.

I have two pc's already running the exe this way and installed win 7 from the same disk onto an older laptop which was also able to run the exe, unfortunately the drive on that died so I am unable to compare settings. The other two pc's are at a remote location so I am also unable to compare settings with these.

Is there a hardware restriction with newer cpu's, motherboards that could be causing this issue or can anyone please suggest a something I may have missed.

I have removed the av and disabled the firewall to simplify diagnoses and the connection with the server is definitely established.

Any help would be most gratefully appreciated.

  • 2 Contributors
  • 8 Replies
  • 527 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by waves

Dani AI

Generated

Short expert summary and practical checklist.

Good outcome: ’ RDP workaround is exactly the pragmatic fix when a client PC refuses to start an older program — it simply runs the program in the server’s environment instead of depending on the client’s compatibility. Below are focused checks and low-risk fixes to try on machines where the app still won’t start, plus safe alternatives if the app really is legacy 16‑bit.

Troubleshooting checklist (do these in order)

  • Confirm the binary type (16-bit / 32-bit / 64-bit). On Windows use a PE/bitness tool such as Sigcheck or dumpbin to see if the file is 16‑bit/PE/NE.
    Example:

    sigcheck -a "C:\path\to\app.exe"
dumpbin /headers "app.exe" | findstr /i machine

  • If the EXE is 32‑bit but still silently exits, capture what it’s doing with Process Monitor (Procmon) to see which files/registry keys or DLLs fail when you double‑click the EXE. That reveals missing VC++ runtimes, access-denied errors, or DLL load failures.

  • If the program is launched from a mapped drive and the UAC elevation prompt appears, an elevated process may not see the mapped drive. Workaround: run from a UNC path or enable the linked‑connections registry key (requires admin and reboot):

    Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"EnableLinkedConnections"=dword:00000001

  • Compare DLL dependencies on a working machine vs the failing machine (Dependency Walker / list of installed MSVC redistributables).

If it’s a true 16‑bit Windows/DOS app

  • 16‑bit code only runs natively under the 32‑bit NTVDM subsystem on x86 Windows; 64‑bit Windows has no NTVDM. Options: run the app on a 32‑bit host (or enable NTVDM where supported), run the app inside a VM (XP/Win7 32‑bit), or use a 16‑bit interpreter/emulator such as OTVDM/WineVDM on 64‑bit Windows. (learn.microsoft.com)

Notes and safety

  • Procmon and Sigcheck are the quickest ways to see why an EXE silently exits. If the working machines are remote, capture their Procmon traces or dependency lists and compare them to the failing box. If a permanent multiuser solution is needed, RDP/Terminal Services or a centrally hosted VM avoids per‑client compatibility work. (learn.microsoft.com)

This keeps the troubleshooting focused (identify bitness and missing DLLs, check UAC/mapped-drive elevation) and explains why running the program on the server via RDP (what implemented) bypasses client-side compatibility issues that otherwise chew up time. (learn.microsoft.com)

Recommended Answers

All 8 Replies

Member Avatar for rproffitt

That's a good guess. Rather than run it from the server, why not install it from the maker as intended and test if it runs on W7?
If it doesn't run, then back to it's maker to ask about updates or requirements.

For example I had an old old app that would not run if there was more than 16MB memory on a DOS machine. While it was possible to work around that, your everyday user would break if you told them how.

Member Avatar for waves

Thanks for your quick reply. The other pc's run win 7 so I know it works with that OS.

I think you are onto something with your post that it's nothing to do with the network but the actual pc not able to run the program. On my drive home I remembered that the other pc's have the ms c++ libraries so will check that in the morning.

I think the company that wrote the software have long since gone out of business so that avenue is probably closed.

Member Avatar for rproffitt

I wish it was that simple. Win 7 (W7 for short) can be all over the map with you discovering that one W7 is 32 or 64 bit and one may have CPU extensions and the next does not. I take it that you are just learning about the PC in general.

If it is C++ libraries, the app's installer could clear that up.

Member Avatar for waves

I'm not even sure if we still have the installation disks, but good shout on that I will check in the morning. All pc's running the software this way are 32bit.

A few years back I built 6 pc's all with the same hardware bought from the same company at the same time. I installed W7 from the same disk and each pc behaves differently. For example 3 would remember mapped drive credentials but the other 3 wouldn't?

I try to avoid windows normally and usually concentrate on Linux servers but unfortunately have inherited responsibility for the windows side of our network.... It drives me nuts as my brain can't find any kind of flow when working through win problems. I guess now I will have to put the effort in to advancing my win knowledge, however a daunting prospect that feels to me.

Member Avatar for waves

Ok I've tried installing the program from the disk, it won't even run the setup exe, asks for permission then nothing. After bashing my head against the wall I resorted to a remote desktop connection, that didn't work. Reinstalled win 7 o/s as 64 bit as with remote desktop as local os is irrelevant with rd. Didn't work.

Got so frustrated thought I'd put linux on it .... didn't work???? I'm very confused as I can connect my pc with linux to it with rd, I've even used my pc's IP but guess what... didn't work either.

I'm going to try another windows pc (different hardware) and see if I can get that to work.

Member Avatar for rproffitt

Is there any detail you can share about this software? Maybe it requires a CPU feature or turning off DEP or something else?

I know you claim the machines are identical but if they were, why did you install Windows on each one? A clone of the HDD would have worked (along with the small changes after that.)

Member Avatar for waves

The identical pc's were prior to this and you are right, I should have just cloned the first one.

I have now resolved my problem, unfortunately not by getting the software running on the pc but by setting up a windows remote desktop connection to the server and running the software on the server through the rd. The initial problems setting up the rd was mainly due my ignorance of the win server os but I've managed to muddle through it.

Thanks for your help with this rproffitt, much appreciated.

Cheers

commented: + for keep trying and keep discussing. +11
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.