Win16 app calling win32 dll


We have an app that we developed for a dll
the app itself is 16-bit
we formely developed a 16-bit dll for it's use.

now we have a 32-bit version of that dll and we
need it to work without recompiling the app itself.

so how is done ?

if there is no straitforward way to do that , can I do that:

-create a 16-bit dll with "ghost" functions sutiable for the
 app ( the same as the original 16-bit dll) , this dll
 will in turn call the new 32-bit dll that will also return
 values to the 16-bit dll and from there to the app.

I don't need only a answer , I need a working example in

please post your answers here and send your example file
Who is Participating?

Improve company productivity with a Business Account.Sign Up

16 bit code can call 32 bit code, but it is a real pain.  The process is called thunking and is documented in the microsoft help.  (Look up Thunk Compiler).  Since this involves changes only on the 32 bit side, I believe you do not have to write a "ghost" dll.  But, you may want to do that anyways as it would allow you to leave the main DLL unchanged when your 16 bit code is no longer needed.
Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

moshemAuthor Commented:
Sorry guys , I forgot to tell you that my dll need to
be multithreaded and I read somewhere the thunking does
not work with threads.

prove me wrong
>> prove me wrong
I cannot do that, Moshe, because you are correct.  The documentation says:
"16-bit processes cannot create new threads. Certain Win32 elements, such as the functions supporting the common dialog boxes or those supporting console applications, create threads on behalf of the calling application. These functions cannot be used in a Win32-based DLL loaded by a 16-bit process."

And, in Q133722:
"You cannot create threads inside a thunk from a Win16-based application to a Win32-based DLL."


Let's try an alternative approach.
You can run a hidden Win32 application that will load the 32bit DLL.  Your Win16 application can communicate with the Win32 application by means of WM_COPYDATA messages, named pipes, DDE, OLE or RPC.
moshemAuthor Commented:
well that mean I need to change the win16 app and I can't do
that , any other thoughts ?
>> well that mean I need to change the win16 app and I can't do that
You don't need to.

Write a replacement Win16 DLL that will communicate with The Win32 application.  For each function in the old Win16 DLL, write a replacement function in the new Win16 DLL that will communicate with the Win32 application using one of the methods I suggested.  The Win32 application will in turn invoke the needed function in the Win32 DLL and pass the results (if any) back to the new Win16 DLL.  The DllMain() of the new Win16 DLL can take care of initialization.

I think that the easiest IPC method is WM_COPYDATA messages.
Read for some details.
Get sample code from the platform SDK.
moshemAuthor Commented:
that's a very unelegent solution , can you think of something
else , maybe insted of WM_COPYDATA ?

if not , can you email me the sample from the SDK ?
to :
Moshe, there is no elegant solution for what you need, the windows model does not support it so you must "letachmen".  If the Win32 DLL wasn't multithreaded you could use generic thunks.  Since it is, your only option is interprocess communications, and that requires two processes.  If you dont like WM_COPYDATA, you can use another IPC mechanism but you'll still need two processes.

You can get the relevant SDK samples from:

moshemAuthor Commented:
can you explain in detail , why whould this work with a multithreaded application ?
Moshe, the URL I gave you is incorrect.  I'll send you the sample by email.  Subject: "INTEROP sample".
>> can you explain in detail , why whould this work with a multithreaded application?

We seem to have a misunderstanding there, a Win16 application cannot be multithreaded.  Maybe you mean a multithreaded DLL?

A Win16 application cannot be multithreaded.  While it can load a 32bit DLL (using thunks) the code in that DLL is executed in the context of the Win16 application and must abide by the restrictions of the Win16 model.

If you're communicating between a Win16 app and a Win32 app, the Win32 app can be multithreaded.

This is getting cumbersome to explain.  Drop me a call (I'll send you my phone number in email).
moshemAuthor Commented:
Thanks Alex.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.