Program fails to run under Remote Desktop Sessions


Recommended Posts

I am using Tabworks as I have said in another thread here and for the most part it works.

However it fails to run in a Remote Desktop environment. When I first tried running it in my 2003 VM with error reporting disabled (or holding in a queue) it just quit and I didn't know why. My Desktop 2003 did the same, until I tried on XP on my Tablet and it gave an error report prompt and then I enabled error reporting on my Desktop and tried again. I realized after a while that the reason it wasn't running is because I was using RDP, as everytime I was using RDP it didn't work but when I logged on normally it worked.

I think it was working in Windows 7 on my Tablet, even over RDP. But not in XP or 2003. I can logon normally and then start it and then RDP in but the icons appear funny, and if I close it by accident I have to go again. That is not very practical.

Maybe someone here can try it and see if they can reproduce the error and solve it...

This is some ancient software right? Well I'm not going to try it, but if its so ancient, you could install it in a VM (Like Windows 7 XP Mode even, Microsoft Virtual PC is plenty for this) and see if it works in there locally.

If it works, then you can probably RDP and launch the VM to run the ancient program. Since its a VM, it should not matter that its RDP, the program will be insulated from that. Heck you could run it in Windows 98 which was DOS based so the ancient software should love it.

I didn't use the add programs wizard, I just ran the installer, actually on Windows 7 the installer doesn't work (but the program does) so I had to copy the files from \Program Files from my 2003 VM...

Would installing it using the Wizard there make it work?

It's not that ancient. The 3.1 version was ancient.

I have been running it in a VM and it does matter if you use RDP to connect to it. I know it works normally, but not over RDP and I need it to work on RDP...

It is ancient. Find a replacement. For the love it's for 3.1 and 95.

you fail to miss the point of the install process. It changes rights on files and the registry on files that get installed in the install process. Old 3.1 programs don't put files in program files, they don't modify the registry, and they don't put files in windows or system32 folders. The install mode gives rights to those files and directories for terminal server users to be able to execute properly. Which is why you can run on the desktop and not in remote desktop.

It isn't as simple as you think.

What do you mean "Install mode"

I have it installed in Vista and Seven and there are registry entries. I understand that there are programs that need to be installed with an installer, but I don't think this is one of them...

I have installed it on my Desktop using the installer and it still doesn't work in RDP...

The error report mentions Ntdll.dll if that helps...

you know what I am just posting the link....ask questions as needed.

http://support.microsoft.com/kb/320185

this applys to 2003 and 2008 server as well.

this sort of answers it, but it is much more than just "ini" files

http://www.conetrix.com/Blog/post/Using-Terminal-Server-Install-Mode.aspx

You need to do some homework son.

I have done my homework, and I have about 500 terminal servers under my belt, with aoubt 200 citrix clusters.... ask the question. don't post stupidity.

A lot of installs put the servers in install mode, however there are some that do not. Office, for instance, will initiate the install mode on a terminal server, legacy apps will not.

I have done my homework, and I have about 500 terminal servers under my belt, with aoubt 200 citrix clusters.... ask the question. don't post stupidity.

Well... I have 3000+ workstations as well as a Citrix cluster under my belt. Don't be a wise guy. Answer the question. It's an OLD piece of software. Time to move on. It's not going to run.

OK smartie pants, if it can run on the desktop what is stopping it from running in a remote desktop? other than the files needed to run not being available to the users? I have gotten plenty of legacy apps to run as a necessity in many different environments, just because you say it can't run, doesn't mean it can't run.

3000+ workstations, I dealt with more than that at the hospital I used to support.....lots of legacy make work apps there.

OK smartie pants, if it can run on the desktop what is stopping it from running in a remote desktop? other than the files needed to run not being available to the users? I have gotten plenty of legacy apps to run as a necessity in many different environments, just because you say it can't run, doesn't mean it can't run.

3000+ workstations, I dealt with more than that at the hospital I used to support.....lots of legacy make work apps there.

It's a 16Biit app. Get it to work then i''ll concede.

I have a very old app called vinassist it was written for dos 16 bit (police app to verify vin tags). I have a 16 bit mckesson app that works fine.

You seem to give up too easy. Oop its 16 bit can't work, next....

Maybe I am arrogant but I am willing to try things before just throwing in the towel and using the excuse "it's a 16 bit app and won't work".

Its funny mckesson said the same thing, I did it then they changed their tone to it isn't supported.

Wow so much willy-waving I'm not sure I want to post.

But I'm stupid, so here goes.

*always* put your terminal server in Install mode. Even if you think the package does it there are heaps of install and LUA bugs you can eliminate by doing this.

Remote desktop doesn't access the profile in the same way, if you want to know if your app is compatible then take a read of this:

http://blogs.msdn.com/rds/archive/2010/01/19/how-to-detect-rds-specific-application-compatibility-issues-by-using-the-rds-application-compatibility-analyzer.aspx

And take a look at App-V, formerly known as SoftGrid, it takes care of a number of the challenges delivering apps via RDP by virtualising chunks of the filesystem and registry. Avoid Med-V or XP-Mode unless it's an OS architecture issue, if it runs via the local console session you've already ruled that out.

Hopefully people will put their e-peens in the inert position now, the OP can investigate his problem and we can all move on with our lives :)

Re 16-bit, as most terminal server admins are now looking towards 64-bit OSes they will find 16-bit apps are incompatible as a whole, SysWOW64 which is the wrapper for legacy processes only supports 32-bit apps on a 64-bit subsystem. Bearing in mind Server 2008 R2 isn't available as x86 16-bit apps are finally left out in the cold.

I have Tabworks running under Windows 7 64 But, just the installer doesn't work. Ironically it works in RDP on Windows 7.

I can't get it to work in Vista, XP, or 2003 under RDP.

http://support.microsoft.com/kb/320185

Do the steps there apple to XP as well?

EDIT:

C:\Documents and Settings\Administrator>change user /install

Install mode does not apply to a Terminal server configured for remote administr

ation.

http://blogs.msdn.com/rds/archive/2010/01/19/how-to-detect-rds-specific-application-compatibility-issues-by-using-the-rds-application-compatibility-analyzer.aspx

Do I run that in an RDP sesssion?

EDIT: I can't download the file, is makes you fill out a stupid profile, and I am not wasting my time just to download on file, can someone put it on rapidshare or megaupload?

if it can run on the desktop what is stopping it from running in a remote desktop?

Exactly, the program does run, just not in RDP...

I used the add/remove programs wizard and it still didn't work :(

Try running it in the admin account. I am sure you already tried. Also try just running one instance, I have had issues where the app didn't like being launched several times from the same location so I have had to install the app in several directories so that it didn't step on itself.

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • Then you answered your own question as per your own words, WINE does not have feature parity in macOS vs Linux. I’m not sure what Box86 is, but Rosetta is closed source. They can’t just add support for it. Rosetta support comes from the OS itself.
    • Couldn't a custom power plan help to park the non x3d ccd's? Then that would solve this latency/performance issues people are having with the x3d chips?
    • So is Ubuntu and Fedora (with GNOME). It's a welcome move and those that need X11 can easily install as pointed out in the article it but that won't stop a loud minority from whining of course. Funny but It will actually be easier to install X11 on Ubuntu then enable Flatpak support/Flathub and use them.
    • End of an era? Kubuntu is removing default support for X11 in new installs by David Uzondu X11, the old window system whose days have long felt numbered, just saw another one of its major supporters head for the exit. Kubuntu has decided to follow its parent distro's lead, making its next release, version 25.10, a Wayland-only affair for fresh installs. It seems many Linux developers see Wayland as the future. Just recently, Linux Mint started working to improve support for the protocol in Cinnamon, tackling lingering issues with keyboard layouts and input methods. You can even see the progress in KDE's development, where an upgrade to Wayland PiP is planned for KDE Plasma 6.5. So what's the logic behind dropping a session that, for the most part, still works? According to Kubuntu's Rik Mills, the team wants to "rip off this sticking plaster" now, in an interim release, rather than ###### off a lot of people by doing it in the next Long-Term Support version, 26.04. The developers feel that maintaining code for the aging X11 system holds back progress on security and new features that Wayland can enable more easily. Plus, supporting two separate display servers is a massive undertaking. Of course, this change might have some people worried, but relax; all is not lost if you still need the old session. If you're running hardware that acts up, like some older NVIDIA cards, or who relies on an ancient application that doesn't play nicely with the XWayland compatibility layer, you can still get your familiar session back. Just enter the following command in your terminal: sudo apt install plasma-session-x11 Once that command finishes, the X11 session will appear as an option on the login screen, so you can carry on as before. As OMGUbuntu notes, not everyone in the Ubuntu family is following its lead just yet. Other official flavors like Xubuntu, Ubuntu Budgie, and Ubuntu Cinnamon are expected to keep offering an X11 session on their default installs for this cycle.
  • Recent Achievements

    • First Post
      Johnny Mrkvička earned a badge
      First Post
    • Week One Done
      viraltui earned a badge
      Week One Done
    • One Month Later
      serfegyed earned a badge
      One Month Later
    • Dedicated
      firey earned a badge
      Dedicated
    • Dedicated
      fettermanj earned a badge
      Dedicated
  • Popular Contributors

    1. 1
      +primortal
      642
    2. 2
      Michael Scrip
      221
    3. 3
      ATLien_0
      216
    4. 4
      Xenon
      144
    5. 5
      Steven P.
      143
  • Tell a friend

    Love Neowin? Tell a friend!