flat assembler
Message board for the users of flat assembler.

Index > Windows > IMMDevice::GetId Size?

Author
Thread Post new topic Reply to topic
Overclick



Joined: 11 Jul 2020
Posts: 253
Location: Ukraine
Overclick
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?
Post 08 Apr 2021, 09:46
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3132
Location: vpcmipstrm
bitRAKE
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.
Sound like the only guarantee is that it's a string.

_________________
¯\(°_o)/¯ unlicense.org
Post 08 Apr 2021, 16:28
View user's profile Send private message Visit poster's website Reply with quote
Overclick



Joined: 11 Jul 2020
Posts: 253
Location: Ukraine
Overclick
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.
Post 08 Apr 2021, 19:05
View user's profile Send private message Visit poster's website Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 725
Location: Adelaide
sinsi
You don't allocate memory for it, the method does.
Quote:

Pointer to a pointer variable into which the method writes the address of a null-terminated, wide-character string containing the endpoint device ID. The method allocates the storage for the string. The caller is responsible for freeing the storage, when it is no longer needed, by calling the CoTaskMemFree function.
Post 08 Apr 2021, 20:49
View user's profile Send private message Reply with quote
Overclick



Joined: 11 Jul 2020
Posts: 253
Location: Ukraine
Overclick
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.
Post 09 Apr 2021, 04:53
View user's profile Send private message Visit poster's website Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 913
Location: Belarus
DimonSoft
Overclick wrote:
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.

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.
Post 09 Apr 2021, 06:14
View user's profile Send private message Visit poster's website Reply with quote
Overclick



Joined: 11 Jul 2020
Posts: 253
Location: Ukraine
Overclick
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.
Post 09 Apr 2021, 07:39
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1587
Furs
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.
Post 09 Apr 2021, 12:43
View user's profile Send private message Reply with quote
Overclick



Joined: 11 Jul 2020
Posts: 253
Location: Ukraine
Overclick
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.
Post 09 Apr 2021, 13:31
View user's profile Send private message Visit poster's website Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 913
Location: Belarus
DimonSoft
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.
Post 09 Apr 2021, 16:01
View user's profile Send private message Visit poster's website Reply with quote
Overclick



Joined: 11 Jul 2020
Posts: 253
Location: Ukraine
Overclick
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.
Post 09 Apr 2021, 16:47
View user's profile Send private message Visit poster's website Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 913
Location: Belarus
DimonSoft
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.
Post 09 Apr 2021, 18:05
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.