How to use resources in a DLL

For a long time, it has been the practice of many commercial software, such as VC, InstallShield and so on, to save the information of the interface as a DLL, so the advantage is that if you want to do more than one language, just write different DLLs and call different DLLs when you use them in the main program. Of course, there is also a popular way to use the INI, read and save is also very convenient. Recently turned around on the internet, found that there is no article on how to read resources in the DLL, although Iczelion's win32asm Tutorial in the 26th lesson "Splash Screen" to read the DLL in the picture, but I do not know whether this problem is too simple or other reasons, Iczelion did not explain the meaning of the code, and decided to write an article about DLL resource reading.
Let's take a look at these functions:
Hbitmap LoadBitmap (hinstance hinstance,lpctstr lpbitmapname)
Hicon LoadIcon (hinstance hinstance,lpctstr lpiconname)
Hmenu LoadMenu (hinstance hinstance,lpctstr lpmenuname)
int LoadString (hinstance hinstance,uint uid,lptstr lpbuffer,int Buffermax)

int Dialogboxparam (
HINSTANCE hinstance,//handle to application instance
LPCTSTR Lptemplatename,//Identifies dialog box template
HWND hwndparent,//Handle to owner window
Dlgproc Lpdialogfunc,//Pointer to dialog box procedure
LPARAM Dwinitparam//initialization value
);

HWND Createdialogparam (
HINSTANCE hinstance,//handle to application instance
LPCTSTR Lptemplatename,//Identifies dialog box template
HWND hwndparent,//Handle to owner window
Dlgproc Lpdialogfunc,//Pointer to dialog box procedure
LPARAM Dwinitparam//initialization value
);
These are the common functions of reading resources, they all have one thing in common: the first parameter requires the module handle of the program containing the resources to be read, and then the key is in the handle, because when we read our program resources, we must provide a handle obtained with the GetModuleHandle function, This handle is the instance handle of the current program, if you want to read the resources in the DLL, it is obvious that we need to provide a handle to the DLL, so how does this DLL handle get? Quite simply, when we use the LoadLibrary function, the value returned is the handle of the read DLL, so we read the resources in the DLL, which is all we need to do:
Invoke Loadlibrary,dll_filename
MOV dll_handle,eax
Invoke loadbitmap,dll_handle,bitmap_id
Invoke loadicon,dll_handle,icon_id
Invoke loadmenu,dll_handle,menu_id
Invoke Loadstring,dll_handle,string_id,strbuffer,sizeof Strbuffer
Invoke Dialogboxparam,dll_handle,dlg_name,hparent,dlgproc,lparam
Other functions are not much said, highlighting Dialogboxparam and Createdialogparam, because other functions do not need a callback function, after reading the handle can be until the end of the program to release. What we're talking about is the method of Dialogboxparam and Createdialogparam callback functions.
I used to write the callback function of Dialogboxparam and Createdialogparam in the main program, I believe a lot of friends are also written in the main program, And then directly to the callback process address to Dialogboxparam and Createdialogparam, in fact, this is a wrong way, the correct way is that we have to write the callback function in the dialog box resource itself in the DLL, Provide the callback function address in the DLL when the main program displays the dialog box with Dialogboxparam and Createdialogparam, of course, for purely resource-only DLLs, they differ only in the interface language, which writes the callback function better in the main program, if it's a plugin? What if the main program uses a lot of DLLs? For Plug-ins, the callback function must be in the DLL, when the main program uses many DLLs, the callback function is written in the main program, even if it works, but the DLL changes, even if it is a small change, you have to change the main program, so my advice is: In addition to a pure resource DLL, writing a DLL, The callback function of the dialog box must be written in the DLL itself.
However, if the DLL dialog box is used in this way in the main program, the callback function of the DLL dialog box must be raised so that the main program can get the callback function address, like this:
Invoke Getprocaddress,dll_handle,dlgprocname
Invoke Dialogboxparam,dll_handle,dlg_name,hwnd,eax,null
;D Lgprocname is the callback function that is drawn from the DLL
This piece of code looks very concise, also completely normal work, but think about, if in the rest of the program to use the dialog box in the DLL, not only the work is very annoying, even more annoying, we have to all of the callback function out of all, in fact we can do so:
Write a function loaddialog in the DLL, as follows:
Loaddialog proc Hinstance,hwnd,id
. If id==100
MOV Eax,offset DlgProc0
. ElseIf id==101
MOV Eax,offset DlgProc1
. ElseIf id==102
MOV Eax,offset DlgProc2
. ElseIf id==103
MOV Eax,offset DLGPROC3
. End If
Invoke Dialogboxparam,hinstance,id,hwnd,eax,null
Ret
Loaddialog ENDP
;D lgProc0, DlgProc1, DLGPROC2, DlgProc3 are all callback functions in DLLs
So that's all we need to do when we call in the main program:
Invoke Getprocaddress,dll_handle,dlgprocname;D lgprocname= "Loaddialog"
MOV loaddialog,eax
Push ID
Push HWnd
Push Dll_handle
Call [Loaddialog]
Simply by getting to the Loaddialog address at the beginning of the program, calling a different dialog at any place requires only a different ID, like this:
Push 101
Push HWnd
Push Dll_handle
Call [Loaddialog]
In doing so, not only do the callback functions in the DLL need to be drawn, they are also more convenient to use in the main program than each read callback function address.