3

Hey, I'm trying to get the path to a dll located in the same folder as my exe file. The way to go seems to be to use one of either QueryFullProcessImageName() or GetModuleFileName() to get the path to the running executable and then use string manipulation to make it a path to the required library instead.

Unfortunately, neither of these two functions provide a way to find out in advance the size buffer required. I've tried passing zero in for the nSize parameter, but this doesn't have the desired effect.

What's the best practice way of doing this?

KJ Tsanaktsidis
  • 1,255
  • 1
  • 17
  • 28
  • possible duplicate of [How can I calculate the complete buffer size for GetModuleFileName?](http://stackoverflow.com/questions/805814/how-can-i-calculate-the-complete-buffer-size-for-getmodulefilename) – In silico Jan 30 '11 at 06:47
  • I did see that, but I'm open to useing API's other than `GetModuleFileName` (tried `QueryFullProcessName` and `GetProcessImageFileName` too) – KJ Tsanaktsidis Jan 30 '11 at 06:50
  • All of these APIs (except for retrieving the module file name) eventually involve calling `NtQueryInformationProcess` or even `NtQuerySystemInformation` (`SystemProcessIdInformation`). If the Win32 APIs aren't good enough, call `NtQueryInformationProcess` directly. There's no way kernel-to-user APIs are going to allocate the buffer for you, though. – wj32 Jan 30 '11 at 06:52

2 Answers2

3

In practice you can use Windows API MAX_PATH as your buffer size, perhaps add 1 for extra safety.

In theory a Windows path can be much larger. As I recall MAX_PATH is like 270 or thereabouts, while in the NTFS file system a path can be up to around (roughly) 32767 chars. However, for that large size it has to be handled as Unicode, and, importantly, Windows Explorer does not support such large paths, so it's not an issue in practice.

In practice, again, if you should ever encounter such large path, apparently impossible to remove, then you can use the Unicode naming (there's a special prefix to use for long paths), and/or equivalent shortnames (DOS 8.3 names), and/or define logical drives to shorten the path, so that the directory/file can be removed.

Cheers & hth.,

Cheers and hth. - Alf
  • 142,714
  • 15
  • 209
  • 331
  • If Windows explorer doesn't support the longer paths, I suppose the probability of my executable winding up somewhere longer than 270 characters is somewhat low then lol. Thanks – KJ Tsanaktsidis Jan 30 '11 at 07:07
  • `MAX_PATH` is defined as 260 characters. There's no reason to add 1. Read more here: http://msdn.microsoft.com/en-us/library/aa365247.aspx – Cody Gray - on strike Jan 30 '11 at 08:19
  • I'd be a bit careful about this -- I've encountered and worked with paths longer than MAX_PATH. It's arisen frequently enough that I've written a complete backup/restore/delete/etc. kind of thing for directory structures with longer paths. – Jerry Coffin Jan 30 '11 at 16:15
0

GetModuleFilename returns the number of characters copied to your buffer. If it's less than the size of your buffer, you're fine. If it's equal to the size of your buffer, allocate a larger buffer and try again.

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111
  • But continually looping and calling this until you find the right length seems extraordinarily wasteful considering the API must itself know how long the path is... I was hoping for a Better Way, if possible – KJ Tsanaktsidis Jan 30 '11 at 06:44
  • 2
    @KJ Tsanaktsidis: just use `MAX_PATH`. But if you want to be able to support arbitrarily large paths (silly, since Windows Explorer doesn't support them), then for Jerry's "a larger buffer" increase the previous buffer size by some factor, such as doubling it. – Cheers and hth. - Alf Jan 30 '11 at 06:57
  • This also checks after-the-fact memory overwriting. By this point the memory has already been written over if your buffer was too small. This is definitely not safe – Ramon Zarazua B. Jan 30 '11 at 07:10
  • @Ra,m Zarazua: No, it doesn't. You pass a maximum size to GetModuleFilename, so it doesn't overrun the buffer. – Jerry Coffin Jan 30 '11 at 16:12