Service Applications - Windows vs Linux.
Service Applications - Windows vs Linux.
Coming from Free Pascal, a Windows Service or Unix Daemon application is a 100% non-visual application with no GUI dependencies. In Delphi XE3, the TServiceApplication (Vcl.SvcMgr.pas unit) has loads of references to Forms, Dialogs and such. That's a pretty terrible design.
Anybody with a Delphi version that supports Linux, did Embarcadero clean up the TServiceApplication class to be 100% non-GUI? Otherwise, how do they expect someone to develop a Linux Daemon that runs on a truly headless server? I'm very curious to know how Delphi for Linux fixes this - hopefully like what Free Pascal does - 100% non-GUI, otherwise Delphi for Linux is going to be pretty useless in the server environment.
Coming from Free Pascal, a Windows Service or Unix Daemon application is a 100% non-visual application with no GUI dependencies. In Delphi XE3, the TServiceApplication (Vcl.SvcMgr.pas unit) has loads of references to Forms, Dialogs and such. That's a pretty terrible design.
Anybody with a Delphi version that supports Linux, did Embarcadero clean up the TServiceApplication class to be 100% non-GUI? Otherwise, how do they expect someone to develop a Linux Daemon that runs on a truly headless server? I'm very curious to know how Delphi for Linux fixes this - hopefully like what Free Pascal does - 100% non-GUI, otherwise Delphi for Linux is going to be pretty useless in the server environment.
I guess my mistake was assuming that Delphi is trying to be cross-platform (like FPC), in that you can share code between Windows, Linux and OSX. I guess that assumption was flawed.
ReplyDeleteGraeme Geldenhuys That's true for the FireMonkey libraries, and much of the RTL. But there are gaps. This is one.
ReplyDeleteGraeme Geldenhuys i advise you to review the chapmanworld article above. Sometimes having everything as 'set and forget'/cross platform isn't always the best and as linux daemons/services are very different to windows ones you should read the code on chapmanworld and setup your service as per the way linux does things. You can use {$IFDEF MSWindows} {$IFDEF Linux} to separate startup code to get the service up and running then use shared code after that once the service is 'started'. With Linux you'll need to manage the complex forking process and also create your own /install process to create the file/settings in the appropriate init manager for the operating system(s) you need to support. Because Linux uses a completely different memory (ARC) concept to windows it is dangerous to just port existing code across as is anyway - you'll end up with memory leaking apps without the tools to detect them easily.
ReplyDelete