What were the rules on x64 exe and x32 dll?

[Norman Diamond]

Part of this message should not be surprising, but part of it is.

In Visual Studio 2008 plus recently released SDK, I compiled a C# program
for x64, including calls to functions in a C++ DLL. I forgot that the DLL
was 32-bit only.

Running the debug version under control of Visual Studio 2008, the program
started running. It did its C# initializations, called functions in the C++
DLL, did more C# initializations, and displayed its main form. It continued
running until I stupidly told it to call some DotNet methods to open an
OleDb connection to an Excel file. Microsoft's efforts to get vendors to
support x64 didn't include Microsoft as a vendor. OK, that's a separate
issue, and we're getting ahead of ourselves here. Nonetheless, *how* did we
get ahead of ourselves here?

Running the release version by double-clicking in Windows Explorer, the
program started but didn't get very far. It did its C# initializations,
tried to call its first function in the C++ DLL, and crashed long before it
would be ready to display a form.

Task Manager says that both the vsshost version and the standalone version
are running as native x64 executables, not as *32 wows.

How did the debug version get to call that 32-bit DLL and not crash?

[Norman Diamond]

OK, solved, more or less. The call crashed. The Visual Studio 2008
debugger prevents debugging of the Form Load handler, displaying the form as
if everything worked perfectly.
"Norman Diamond" <nd******@newsgroup.nospamwrote in message
news:O1**************@TK2MSFTNGP03.phx.gbl...

Part of this message should not be surprising, but part of it is.

In Visual Studio 2008 plus recently released SDK, I compiled a C# program
for x64, including calls to functions in a C++ DLL. I forgot that the DLL
was 32-bit only.

Running the debug version under control of Visual Studio 2008, the program
started running. It did its C# initializations, called functions in the
C++ DLL, did more C# initializations, and displayed its main form. It
continued running until I stupidly told it to call some DotNet methods to
open an OleDb connection to an Excel file. Microsoft's efforts to get
vendors to support x64 didn't include Microsoft as a vendor. OK, that's a
separate issue, and we're getting ahead of ourselves here. Nonetheless,
*how* did we get ahead of ourselves here?

Running the release version by double-clicking in Windows Explorer, the
program started but didn't get very far. It did its C# initializations,
tried to call its first function in the C++ DLL, and crashed long before
it would be ready to display a form.

Task Manager says that both the vsshost version and the standalone version
are running as native x64 executables, not as *32 wows.

How did the debug version get to call that 32-bit DLL and not crash?