Identical Resource IDs
-
If one or more resource IDs in a DLL are the same as what is in an MFC application that is being developed, will there be a problem? The DLL is being loaded at run-time and there is a resource header being linked into the main application. SJ Manufacturing Software Developer Hewlett-Packard Company
-
If one or more resource IDs in a DLL are the same as what is in an MFC application that is being developed, will there be a problem? The DLL is being loaded at run-time and there is a resource header being linked into the main application. SJ Manufacturing Software Developer Hewlett-Packard Company
If you are using MFC I'm pretty sure you won't have a problem as it uses the hInstance for the DLL or the EXE as required. If you aren't using MFC then make sure you set hModule correctly in the call to LoadResource() or whatever you are using and you should be ok. Neville Franks, Author of ED for Windows. Free Trial at www.getsoft.com
-
If one or more resource IDs in a DLL are the same as what is in an MFC application that is being developed, will there be a problem? The DLL is being loaded at run-time and there is a resource header being linked into the main application. SJ Manufacturing Software Developer Hewlett-Packard Company
Unfortunately, yes. I discovered this working inside the company I'm currently employed during the Veritest's "exam" for Windows 2000 Logo. The problem occured having a central executable and a set of DLLs called from it. Everything is MFC. Suppose you have into dll 1 a string resource with IDC_STRING, and into dll 2 a string resource with ID = IDC_STRING2, and IDC_STRING1 = IDC_STRING2. If dll 1 is loaded, loading dll 2 will give in the point of IDC_STRING2 loading a call to FindResource with ID = IDC_STRING1 = IDC_STRING2. Most probably it will find it in dll 1 and load from there, since all are mapped in the same process. If you manually specify the dll instance, that's ok (I think...) but I don't think you call ::LoadString(hInstDll2, IDC_STRING2, szText, sizeof(szText)); instead of CString str; str.LoadString(IDC_STRING2); or AfxMessageBox(IDC_STRING2). Things are even worse if you have different or custom resource types. I've seen several crashes so bad just because this resource clash. In fact this made us to write a resource align tool that reads resource ranges for a dll. The basic idea is to make a resource partitioning tool (parses .rc and rewrites resource.h) in such a way that: ResourceIDs(dll_i) AND ResourceIDs(dll_j) = EMPTY for any i <> j, 1 <= i, j <= n (number of modules using resources you have). The thing may not be so simple as you think, there are external details to consider. Think a MDI application that has to specify a CLIENTCREATESTRUCT's ID for first MDI child window. Accordingly to MSDN (and this one is true :) ) these IDs should not conflict with existing resource IDs. There may be other restrictions as well, I've pointed only one of the most obvious. A dll starts with a default range of resources of 100. If the internal parser decides that this is not enough, it will modify the input "ranges" file and adds a new 100 sized range and try to resort the IDs in such way that each resource ID will be placed inside that range. The process is performed until all resource IDs from dll have room in the allocated ranges. A rebuild all is, of course, required after resource alignment. In this way, there is no worry that a dll will ever have a resource ID conflicting with another dll's resource IDs. Now we all live happily :), having 3 different development offices compiling all in the same place over main website. The internal objects detects if there are resource changes, these MUST be recorded inside the task (I'm no