Hello Paul, >From: Paul Reeves >On Monday 27 October 2014 17:28:27 Martijn Tonies (Upscene Productions) >wrote: >> >> I know next to nothing about Firebird engine development, but at least >> in Windows, many applications set a mutex (or other shared structure) >> that's being checked against in the Uninstaller (like InnoSetup can do >> automagically for you, Database Workbench is detected as running, >> for example). > >Sure, but that mutex is currently hard-coded at compile time. What you are >suggesting is that InstanceN sets a mutex to distinguish it from Instance0. >That might work but I'm not sure that InnoSetup supports it (although it >can >do pretty much anything.) I'm also not sure if that would solve the >problem.
If you installed a service, the mutex could change with the service identifier, the installer could save that for uninstall. I guess the installer could register itself with Windows with the service name as well, and the uninstaller would automatically know which instance to uninstall (and use the folder for that particular instance, via the install log). >have some skills in building simple native gui apps. Although maintenance >is >slightly harder they are far more lightweight in comparison to having to >create cross-platform gui's that require shipping runtime libraries that >are >larger than firebird itself. Right, there's some stuff it can do, but yeah, a native GUI application, I've done a form and a few buttons and edits once, as an exercise compared to Delphi ;) It's a pain! The control applet would be Windows only, of course. I've just checked with Delphi 2009 (first Unicode version), newer versions will add more stuff. I've created a control applet GUI once, only a single form, the version I compiled back then was about 400Kb, I just recompiled the source from 2001 and the new result is 540Kb. Not overly large, I think. >> > There is also the fact that we can't easily track Firebird running as >> > an >> > app. And neither the task bar icons nor the dialogue indicates anything >> > about the port or the architecture the fb app is using. So work would >> > be >> > needed there, too. >> >> Are you sure? On the development machine that I used to install Fb 3.0, >> there were two instances running, both as an application instead of a >> service, and the installer responded saying there's an existing server >> running. > >The installer checks for fb running on port 3050. I'm not sure if it checks >for an instance in the process list. I've checked again to make sure: no Firebird running on port 3050, the installer still detects it running. >> It does what it can and is quite >>thorough but it can only check for what it knows about or can reasonably >>guess. If you install fb as a service and then start an instance of fb as >>an >>app on port 3051 there is no way that the installer will detect that Apparently, it does. >>instance. And if the service is not running and it detects that you are >>installing over an existing v3 install it will assume you are doing an >>in-place upgrade. I'll look into that a bit more. As I wrote, I've noticed that it detects non-v3 servers running, even on other ports than 3050. Just ran v3 on port 3050, the installer detects it. Hope this helps. With regards, Martijn Tonies Upscene Productions ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
