{"id":4416,"date":"2018-03-01T07:09:56","date_gmt":"2018-03-01T15:09:56","guid":{"rendered":"https:\/\/www.coretechnologies.com\/blog\/?p=4416"},"modified":"2022-04-19T22:08:54","modified_gmt":"2022-04-20T05:08:54","slug":"legacy-desktop-application-questions","status":"publish","type":"post","link":"https:\/\/www.coretechnologies.com\/blog\/windows-services\/legacy-desktop-application-questions\/","title":{"rendered":"Wondering if Your Legacy Desktop Application Will Work as a Windows Service? Answer These 3 Questions to Find Out"},"content":{"rendered":"
\"3<\/div>\n

Does your old (but important) desktop application need to run all the time?<\/p>\n

Should it start immediately after a reboot, even when no one is there to log on and kick it off?<\/p>\n

If so, you should consider installing your program as a Windows Service<\/a> — the technology Microsoft invented to support mission-critical, 24×7 applications. Use a “service wrapper” (like our AlwaysUp<\/a>) to install your application as a service in 5-10 minutes.<\/p>\n

But not all legacy applications will operate smoothly when installed as a service. Here are three questions you should ask to determine if a windows service is a good fit for your situation:<\/p>\n

    \n
  1. \n

    Do you need to see (or interact with) your program while it’s running?<\/b><\/h2>\n

    \nWindows services run in the background. Any windows displayed by a service appear on a “hidden desktop” called Session 0<\/a>. When your legacy application is running as a service, you will not see its windows on your own desktop.<\/b>\n<\/p>\n

    \nAs a consequence, it doesn’t make much sense to run an intensively interactive application (like a word processor) as a windows service. Indeed, any application that demands your constant attention will be a poor fit. Does yours?\n<\/p>\n

    \nBut if you only need to see your application from time to time, a service may still be an option because you can quickly switch to the Session 0 desktop<\/a> whenever you need to see your application.\n<\/p>\n

    \nFor example, when running Apple’s iTunes as a windows service<\/a>, here is what the Session 0 desktop looks like:<\/p>\n

    \"iTunes<\/a><\/div>\n<\/p>\n

    \nEven though there is no taskbar and the usual desktop icons have vanished, we can interact with iTunes just fine in Session 0. For example, we were able to add tracks to iTunes, create a playlist, and even change settings — just as we would if iTunes was running on our regular desktop.\n<\/p>\n

    \n(The only exception is on Windows 10 and Windows 2016, where a particularly annoying bug will prevent you from moving the mouse and keyboard in Session 0<\/a>. Come on Microsoft! Please fix this defect soon.)\n<\/p>\n

    \nSo is occasionally switching to Session 0 good enough for your situation? If not, you should rule out a windows service.\n<\/p>\n<\/li>\n

  2. \n

    Will your application occasionally prompt for input?<\/b><\/h2>\n

    \nAn application that periodically pops up windows and expects you to respond can be a problem when installed as a windows service. Those popups\/windows will appear on the Session 0 desktop — effectively hidden from you. You will not know that your program is stuck waiting for you to enter a password or click the OK button!\n<\/p>\n

    \nSo a “needy” application is not a great candidate for running in the background<\/b> as a windows service. Does your legacy application fit the mold?\n<\/p>\n

    \nHowever, if you only have to get past one or two prompts, our AlwaysUp service wrapper may provide an elegant solution. Simply write an automation script that dismisses the prompt and plug the script into AlwaysUp. This page<\/a> dives into the details.\n<\/p>\n

    \nFor example, when launching iTunes as a service, this error message is the first to appear:<\/p>\n

    \"iTunes<\/a><\/div>\n<\/p>\n

    \nClicking the “X” in the title bar will expel the window and allow iTunes to start. To achieve the same effect when no one is around to click, we provided this simple one-line script<\/a> (which sends the “ESC” key to the iTunes window) to AlwaysUp. Now AlwaysUp automatically dismisses the warning on our behalf whenever it appears!\n<\/p>\n<\/li>\n

  3. \n

    Does your application read from or write to files on a network drive?<\/b><\/h2>\n

    \nLike a regular application, a windows service can access remote\/network devices. Permissions are granted based on the account running the service.\n<\/p>\n

    \nHowever, a service can’t use a mapped drive<\/a><\/b> — at least not without some extra work to explicitly map the drive letter.\n<\/p>\n

    \"Mapping<\/a><\/div>\n

    \nSo if your legacy application references network files via their full UNC path<\/a> (like “\\\\ServerName\\ShareName\\Path”<\/nobr>) it will be fine as a windows service. But if your program uses files via a mapped drive (like “J:\\Path”<\/nobr>, where J is mapped to “\\\\ServerName\\ShareName\\”<\/nobr>), a service may not be in your future.\n<\/p>\n

    \nMapped drives may not be an issue when using AlwaysUp though. Most drives will be mapped and available to your application if you check the “Attempt to automatically reconnect all network drives” box on the Startup tab<\/a> when configuring your application.\n<\/p>\n<\/li>\n<\/ol>\n

    Next step? Try it yourself!<\/b><\/h2>\n

    \nIf none of these questions have ruled out your legacy\/desktop application, you should go ahead and try it as a windows service. Any service wrapper (like AlwaysUp<\/a>) will do the trick in a few minutes. What have you got to lose?<\/p>\n