Setting an Application's Default Directory in Service Mode

[Mephisto]

I have successfully gotten my bot to fully function as a Windows NT service.  However, there is a major problem that has arrisen when a user wants to have more than one bot service run.  The problem is that unlike a console application, a service sets the default directory to C:\WINDOWS\system32.  Because a service does this, it's impossible for the service to read the configuration files of the place where the user unzipped them.  I have come up with a farfetched way of solving this issue by having the user put a servicepath.ini file which contains a string providing the path to where the configuration files are.  The problem with this is that the user would have to keep changing that path when he/she wanted to run another service.  By having to do this it's pretty much impossible for the bot to reconnect itself, reload configuration files, and run in 'automatic' mode, and regardless of that, each time the user restarted the services he/she 'd have to change the path file again and again.  Bottom line is that my solution is useless.  So to solve this I need to make the default directory that of the executable even when running in service mode, or some other way...

My question is simply: Is there a way to have the directory be that of the executable when running in service mode like a console does?  Instead of having it be C:\WINDOWS\system32 which causes these problems.

[Adron]

Just ask windows where your executable is located and use that path to open all your files?

You could also store the path to your files in the Parameters subkey of the service key.

GetModuleFileName(0, .....)

[Mephisto]

I already thought of using that function, but it gives you the fully qualified path to the executable, so it will contain the extra \ApplicationName.  But perhaps (a bad way maybe) I can just cut off the last '\' in the string and everything following it...

[MyndFyre]

Why aren't you using the registry like the Windows best practices ask you to?

Get your folder path from the registry.  If you use Windows Installer, I believe you can write an entry into your registry and have it write the installation folder using the variable [INSTALLDIR].

For instance, when I use InstallShield to create the setup for my bot, I let the user decide the path to install to, but then I tell it:

HKLM\Software\ArmaBot Beta 1\InstallPath=[INSTALLDIR]

Upon load, retrieve that value and concatenate it with your configuration filename(s).

[Mephisto]

I'm not using an installer.  What I had done at one point (most recently) was when they went to install the service it would create a registry key with the key named after the name of the service in the configuration file (AFAIK you can't have duplicate key names nor can you have duplicate service names, so for each new service they have to specifiy a new name in the configuration.ini file).  But this wouldn't work since when the service loads it would have to first open configuration.ini to figure out which registry key to open.

[Adron]

I already thought of using that function, but it gives you the fully qualified path to the executable, so it will contain the extra \ApplicationName.  But perhaps (a bad way maybe) I can just cut off the last '\' in the string and everything following it...

Cutting off the last '\\' in the string is a good way. You might even just replace the last three letters "exe" with "ini" or whereever you store your settings.

HKLM\Software\ArmaBot Beta 1\InstallPath=[INSTALLDIR]

The problem with that is that he wants to run multiple instances of the bot. Those settings should be stored in the registry under the service's key, so you get one set of settings for each instance.

[MyndFyre]

In that case I would say you might want to re-think your application architecture.  Rather than go through a hassle of making two instances of your bot, why not make *one* instance that can manage multiple connections?

[Mephisto]

That's something which can be implemented later -- thank you for the suggestion though, it's something I will implement in the near future. 

However, the above discussed method works just fine for the time being.

[MyndFyre]

That's something which can be implemented later -- thank you for the suggestion though, it's something I will implement in the near future. 

However, the above discussed method works just fine for the time being.

Cool.  Make sure to not shoot yourself in the foot, though, and have to go back and re-code.  Between, as I recall, preview 3 and 4 of my bot, I moved from having "3 connections," selectable via a list box, to having tab-based MDI.

The problem was, I had hard-coded 3 into the user interface, and I had to go back and completely change the architecture (well, not COMPLETELY, but you know what I mean) of my user interface to do so, as well as make some changes to the way the connection API functioned.

[Mephisto]

I know what you mean; it's frustrating, especially when you accidently break something when you redo it and forget to back your original working problem up  .  But there's good to it, often when you have to redo something you're doing it for the better and you also pick up bad-code and make it better. 

[Kp]

As a good reason for why you should not go storing lots of paths in the registry, I've lost count of the time wasted trying to correct a broken program that stored many copies of its absolute path (usually one for each file) when I needed to move it to a different directory.

Also, with your example Myndfyre, I hope your program is meant only to be installed by system administrators.  I use a "normal" account for most of my work, which means that anything which is designed to write to HKLM flat out fails until I restart it in privileged mode.  In general, running things with privilege just to work around design flaws is a bad idea, IMO.

[MyndFyre]

As a good reason for why you should not go storing lots of paths in the registry, I've lost count of the time wasted trying to correct a broken program that stored many copies of its absolute path (usually one for each file) when I needed to move it to a different directory.

Well that's silly. 

Also, with your example Myndfyre, I hope your program is meant only to be installed by system administrators.  I use a "normal" account for most of my work, which means that anything which is designed to write to HKLM flat out fails until I restart it in privileged mode.  In general, running things with privilege just to work around design flaws is a bad idea, IMO.

That's a good point.    That's the only setting that uses HKLM, and only the installer writes to it.  :/