Index
> Windows > IMMDevice::GetId Size? |
| Author |
|
|
Overclick 08 Apr 2021, 09:46
Hi
What is a biggest possible size of this received endpointID on different systems? I've got 112 bytes with double zero ending. Isn't it fixed size? |
|||
08 Apr 2021, 09:46 |
|
|
bitRAKE 08 Apr 2021, 16:28
https://docs.microsoft.com/en-us/windows/win32/coreaudio/endpoint-id-strings
Quote: Clients should treat the contents of the endpoint ID string as opaque. That is, clients should not attempt to parse the contents of the string to obtain information about the device. The reason is that the string format is undefined and might change from one implementation of the MMDevice API system module to the next. _________________ ¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup |
|||
|
08 Apr 2021, 16:28 |
|
|
Overclick 08 Apr 2021, 19:05
Yeah, I read it.
256 bytes buffer should be enough I hope. Painful to extend it more for each ID I need to keep loaded. |
|||
|
08 Apr 2021, 19:05 |
|
|
Overclick 09 Apr 2021, 04:53
How do you believe to use that allocated storage for future IMMDeviceEnumerator::GetDevice ?
I have to copy IDs to Registry for future use. Not just keep it opened in some system storage. That means I need the buffers to read even from Registry any way. |
|||
|
09 Apr 2021, 04:53 |
|
|
DimonSoft 09 Apr 2021, 06:14
Overclick wrote: How do you believe to use that allocated storage for future IMMDeviceEnumerator::GetDevice ? So what? Calculating the string length is not a big deal (although they would better provide a way to get it without another pass through it, for better performance). And wherever you store it, you have control over how you store it. |
|||
|
09 Apr 2021, 06:14 |
|
|
Overclick 09 Apr 2021, 07:39
I don't have any issue to calculate the length as I do anyway. I just need to know max size of buffer where ID needs to be moved FROM REGISTRY.
I cannot to load ID directly from Registry to Interface even if I know every single bit on it. Allocating memory from the system for such small buffer is also wrong idea. Calls will cost expensive. |
|||
|
09 Apr 2021, 07:39 |
|
|
Furs 09 Apr 2021, 12:43
Typically, you use a buffer on the stack with a size that fits 99% of cases, such as 256. But to handle larger buffers, you check the actual size from the registry, and if it's larger than your buffer on the stack (256) you allocate it so it fits.
And then at the end after you're done with it, you compare the buffer pointer to see if it's the one on the stack. If it's not, you free it (since you allocated it). If you allocated with HeapAlloc you free it with HeapFree, etc. Keep in mind the registry can be manually modified. You should NEVER trust the registry and always expect it to have weird values. Unless you want to be the next poorly designed app with security exploits on every corner. Don't. Trust. Input. |
|||
|
09 Apr 2021, 12:43 |
|
|
Overclick 09 Apr 2021, 13:31
It is pointless to allocate the memory even if that ID up to kb. To prereserve that space in program is less harmfull. I just think someone know how really large that ID can be. To keep settings I have two available spaces: config file or registry. The last one is more accurate for me. Anything can happen, devices configuration can be changed at first place for example. I don't care as I should check for changes anyway. But users predefigned settings have to be in place. What is a problem to work with allowed space in registry? If user is not allowed for anything in registry then how to be sure his allowed to write any file? Anyway my project going to work with hardware so gost users is not in my interest.
|
|||
|
09 Apr 2021, 13:31 |
|
|
DimonSoft 09 Apr 2021, 16:01
Application directory is a trusted location. And storing program data there makes it portable in the sense that one can just put it onto a flash drive and have it ready to use everywhere. It also means one can easily restore program settings if for some reason the Windows installation gets broken and stops booting: by just plugging the hard drive into another computer as an external drive and copying files.
Registry hell when every single program tries to save everything in the (as a result) giant system registry, which makes it really slow, had been a big problem for quite a long time until fashion changed. And setting up the system in such a way that application has no access to its directory is a rare case of misconfiguration while having registry access limited is quite a common case. Besides, even if the directory is not write-accessible, one still has to be ready for “Out of disk space” and similar conditions and they’re generally handled the same way in this case. |
|||
|
09 Apr 2021, 16:01 |
|
|
Overclick 09 Apr 2021, 16:47
It is trusted where properly installed. Properly installed it can be via VS only. If you can teach me how to do trusted installer by fasm created soft it will be very grateful.
I do my job all-in-one. No need to install. Run from any place. It almost the same as portable. Anyway, device ID cannot be portable and I have to keep this and all rest settings somewhere. Slow registry is from past-past era ago. Registry have clear anatomy to understand what exactly you need and where it must be. Once again: guys! I don't ask you for critic my job. This topic for ID size only. |
|||
|
09 Apr 2021, 16:47 |
|
|
DimonSoft 09 Apr 2021, 18:05
Overclick wrote: It is trusted where properly installed. Properly installed it can be via VS only. If you can teach me how to do trusted installer by fasm created soft it will be very grateful. I’m not sure what you mean. Most software doesn’t really need any installation, just plain copying of files and, optionally, creating a shortcut or two. It can be done by any program, just ask for administrative priviliges (if needed!) and perform the necessary actions. VS is not a requirement at all. Do you mean the signing tool that is shipped with VS? Overclick wrote: Anyway, device ID cannot be portable and I have to keep this and all rest settings somewhere. But saving it along with some value that uniquely identifies the computer or OS installation might give better user experience. Or it might be useless, it depends. |
|||
|
09 Apr 2021, 18:05 |
|
< Last Thread | Next Thread > |
Forum Rules:
|