Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Dynamic service GUIDs (Read 3192 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Dynamic service GUIDs

My new component (VST adapter) creates variable number of dsp services. All of them need to be bound to specific VST plugins. Thus service GUIDs are generated from VST unique IDs. It's ok for the user, isn't it? But what about crash reports? They become meaningless, don't they? I can make the greater part of GUID to be constant. Would that be a good solution?

Dynamic service GUIDs

Reply #1 –
I'm a bit curious, when do you instantiate your service factories? I'm under the impression that behavior is quite undefined for anything later than creating service factories with global storage duration.
I did consider making multiple instances on demand in a DSP component of mine, but figured that it was quite unhealthy to assume such things about service enumeration and caching.
Stay sane, exile.

Dynamic service GUIDs

Reply #2 –
Quote from: Entrase on
Thus service GUIDs are generated from VST unique IDs. It's ok for the user, isn't it?
User as in your mom doesn't care at all - as long as you generate the same GUID for the same DSP each time, naturally. User as in dsp_manager or whoever cares a lot, but must be prepared to see DSP factories appear or go missing during restarts, so no worries there too.

Now I don't know what exactly "VST unique ID" is, but it's quite common to generate dynamic GUIDs using MD5 of file path or preset name for menu items, for example.

Quote from: Entrase on
But what about crash reports? They become meaningless, don't they? I can make the greater part of GUID to be constant. Would that be a good solution?
I wouldn't worry about crash reports at all regarding this. Most of the information they supply comes from crash location, call path, stack dump, module list etc. I don't remember ever having to look at service GUIDs without their owner being easily apparent by other means while analyzing a crash.
Full-quoting makes you scroll past the same junk over and over.

Dynamic service GUIDs

Reply #3 –
VST unique ID is a 4 character string returned by the component, preferrably generated by Steinberg's online database which is guaranteed to prevent conflicts with other registered components. Of course, not all VST developers use that database, so there may be conflicts between different components. There may also be conflicts between different versions of the same component, if they are registered simultaneously in the same host application. So it may also be a good idea to hash up some other identifiers, such as the component name, filename, or even complete path.

Dynamic service GUIDs

Reply #4 –
Quote
I'm a bit curious, when do you instantiate your service factories?
You wouldn't believe. I wince looking at how it's done :-D Drum-roll.........

Code: [Select]
BOOL WINAPI DllMain(HINSTANCE hinstDll, DWORD fdwReason, LPVOID lpvReserved)
{
    if (fdwReason == DLL_PROCESS_ATTACH)
    {
        // Whatever
        if (n > 0) static dsp_factory_t<foo_vst<0>> dsp;
        if (n > 1) static dsp_factory_t<foo_vst<1>> dsp;
        if (n > 2) static dsp_factory_t<foo_vst<2>> dsp;
        // and so on in a copy-paste style
    }
}

I should kill myself for that, shan't I? It does work however. And that's why I have to keep settings in the registry, not in the foobar's configs.

Quote
I wouldn't worry about crash reports at all regarding this. Most of the information they supply comes from crash location, call path, stack dump, module list etc. I don't remember ever having to look at service GUIDs without their owner being easily apparent by other means while analyzing a crash.
The answer I was waiting for. Thanks.
Quote
So it may also be a good idea to hash up some other identifiers, such as the component name, filename, or even complete path.
I thought the same thing. And I think it's not a big deal to generate random GUID if some duplicate UID is to be added to the list. This is where other identifiers should be compared. And if some uncertainty is left after all, then we can still ask user if they insist on adding “duplicate” to the list.