some dll related questions

[Rainstorm]

hi.
something came up,been away a bit.
just have some dll related questions.

- in the dll search order specified in the SDK which dir does 'current directory' refer to ?

- can a dll have the same global-variable names.. as that of its calling application ?

=  =  =  =   =

while getting the proc address if I try to use this it doesn't work (the quotes for the libname)
why is that ? - doesn't the quoted text pass a pointer totthe string ?

Code Select Expand

fn GetProcAddress, hdll,"libadd1"

the normal way like below works when i specify addr proc_name

Code Select Expand


.data
    proc_name    db      "libadd1",0
. . .

    fn GetProcAddress, hdll,addr proc_name    ; get the address of the desired function
    cmp eax, 0                                ; check for success, addr of proc in eax
    je func_addr_error

    push 6
    push 20
    call eax                                  ; call the function


- have another question too.. will ask after this.

t  y
-

[MichaelW]

From the PSDK, Changing the Current Directory:

The directory at the end of the active path is called the current directory; it is the directory in which the active application started, unless explicitly changed.

For the second question I think the answer is probably yes.

I cannot find any problems using quoted strings with fn:

Code Select Expand


; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    include \masm32\include\masm32rt.inc
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    .data
      hModule dd 0
      procPtr dd 0
    .code
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
start:
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    fn GetModuleHandle, "kernel32.dll"
    mov hModule, eax
    print uhex$(hModule), 13, 10

    fn GetProcAddress, hModule, "GetProcAddress"
    mov procPtr, eax
    print uhex$(procPtr), 13, 10

    push chr$("GetProcAddress")
    push hModule
    mov eax, procPtr
    call eax
    print uhex$(eax), 13, 10

    inkey "Press any key to exit..."
    exit
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
end start


[Rainstorm]

Michael, thanks a lot for clearing that up & testing the code.
was about to post the code, & kind of figured it out.. - the lib name in the def file had no underscore & the dll asm file had an underscore.. dunno how exactly it affected it.. but..after lining up the names everywhere including in the calling file.. the 'fn' works proper with quotes now ; )

about the 'current directory ' I asked cause in the search order, checking the dir from which the application loads is mentioned as a seperate step.. , & checking the current dir is mentioned as a seperate one.
Also, when it says it checks  'The directory from which the application loaded', does that imply the sub-directories in it also ?

posting the other question in the next post

[MichaelW]

I think the directory from which the application loaded and the current directory are listed as separate steps because the current directory can be changed, for example with SetCurrentDirectory. In my test just now the search did not include subdirectories of the current directory.

[PBrennick]

Rainstorm,
The thing to remember is that if you start your application from an icon on the Desktop, the Desktop directory will be the current directory. In this case (had to do this with Sudoku), you use something like the following:

Code Select Expand


    invoke  GetModuleHandle, NULL       ; Get handle for this application
    mov     hInstance, eax              ; Save it for later usage
    invoke  GetModuleFileName, hInstance, addr GameDir, 260


GameDir will now contain the complete path and filename to the application and you can use that to set the current directory.

Paul

[Rainstorm]

Michael, thanks for clearing that up ..& the info on the subdirectories

paul wrote

The thing to remember is that if you start your application from an icon on the Desktop, the Desktop directory will be the current directory.

didn't think about that Paul, thanks.. i get the picture.

[Rainstorm]

in this example.. think something is wrong.. with my call return flow.
its an attempt to call an editbox in a dll & basically i call the dll, passing a pointer to a buffer for the typed text. in the dll I 'call' the Messageloop.. but dunno whether its returning properly from it.

thanks

[attachment deleted by admin]

[jj2007]

Also, when it says it checks  'The directory from which the application loaded', does that imply the sub-directories in it also ?

I recently had a bug where I launched an app without path, and found to my surprise an old version popping up. So yes, Windows does include subdirectories when searching for an app without path.

Re current directory, here is a simple test. Here on Win XP SP2, the directory of the executable shows up, even when I launch it via a shortcut (*.lnk) e.g. from the desktop.

Code Select Expand

include \masm32\include\masm32rt.inc

.data?
buffer db MAX_PATH dup (?)
.code
AppName db "Current directory:", 0

start: invoke GetCurrentDirectory, MAX_PATH, offset buffer
MsgBox 0, offset buffer, addr AppName, MB_OK
exit

end start


I avoid setting the PATH environment variable, because it's an additional source of confusion: An app may work on one PC where PATH is set e.g. to D:\masm32\bin but fails on another where this is not the case. Hardcoding without drive letter like

Code Select Expand

include \masm32\include\masm32rt.inc
is much more reliable.

[MichaelW]

Rainstorm,

I'm not sure that a modeless dialog can reasonably work for this. The caller and the DLL will (at least by default) be running in the same thread, so if the caller also implemented a message loop you would have two message loops in the same thread. Since only one of them could be active at a time, the caller would be effectively frozen while the DLL dialog was open. I think there is probably some way to work around this, but the required code is likely to be more or less complex. The attachment is a simple example where the DLL uses a modal dialog, and the caller is a console app.

So yes, Windows does include subdirectories when searching for an app without path.

The question was about what the system does searching for a DLL, and this is what I tested. The system did find the DLL when it was in the current directory, which in my test was the directory from which the app was loaded, and did not find the DLL when it was in a subdirectory of the current directory. Neither of the directories involved were on my path.


[attachment deleted by admin]

[Rainstorm]

Michael, appreciate the explanation I hadn't realised all that. - I assume from your post that the rest of the  call/ret flow in the app is okay - guess for a modeless dialog i could try calling the dll with a seperate thread maybe. thx for the example.

[MichaelW]

Sorry, I didn't mean to imply that the rest of the code is OK. The app triggered an access violation exception when I tried to run it, in a function named CharPrevW, somewhere in user32. So your code has some sort of problem, but I didn't try to find it. The call/ret flow looks like it should work. Considering what I see in the stack trace:

Code Select Expand


0084F8F0 77E1622E 00410312 00000111 04000064 006403CE user32!CharPrevW
0084F920 77E17361 004A7990 00000111 04000064 006403CE user32!IsWindowVisible
0084F940 77E1C3F2 00410312 00000111 04000064 006403CE user32!SendMessageW
0084F988 77E48E7C 0000000C 0084FB0C 00000001 001341D8 user32!GetWindowTextLengthA
0084F9A0 77E18D11 40000080 0084FAD0 004A7B28 001341D8 user32!GetNextDlgGroupItem
0084FA04 77E183FD 006403CE 001341D8 00000001 00000000 user32!DrawStateA
0084FA44 77E17A0F 004A7B28 00000001 00000000 0084FAD0 user32!EditWndProc
0084FA68 77E1CF77 004A7B28 00000001 00000000 0084FAD0 user32!GetWindowTextA
0084FA98 77F91BAF 0084FAA8 00000080 00000080 0000000F user32!SetScrollPos


I suspect that the error is somewhere in the dialog code. The method that you are using to create your dialog template is error-prone. I think you should consider using the MASM32 in-memory dialog macros to create the template and the dialog, at least until you get the bugs worked out. Also, for my example I first tested the dialog as an EXE, and then modified it to function as a DLL, without changing the dialog code.

[Rainstorm]

MichaelW wrote..

The app triggered an access violation exception when I tried to run it, in a function named CharPrevW, somewhere in user32

I don't get an exception when i run the app just that the app  doesn't return the value entered in the editbox.(to the calling module) - the editbox displays.. & when i click OK it ends. am using winxp pro sp2

EDIT: sry I've come back after awhile, & I had just c/pasted the dialog stuff from my base code, & it had some stuff that hadn't been corrected.(the creation data was dword aligned not word, for 1 control). the behaviour of the app though, is still the same after that, as it was before.

I'll just use a modal dialog. ty for the help.

[PBrennick]

Rainstorm,

Still, remember that neat thing that Michael said. Build your dialog as an EXE first, then convert it into a DLL. That method saves a lot of headaches. It never occurred to me to do something like that. Too obvious and simple for my brain I guess. Remember his words, though, for all future work in this area.

Paul

[Rainstorm]

Paul, it was an .exe..  & i copy/ pasted the code.