tags:

views:

571

answers:

3

I have a problem with a Delphi 2009 project : It can't initialize Indy 10 ! This code worked fine before in Delphi 2007 (although we might have been using an older revision of Indy, but I suspect that has not much to do with it);

The initial call to IdWinsock2.InitializeWinSock(), raises this exception (with error code 998) :

Project EAServer.exe raised exception class EIdWinsockStubError with message
'Error on loading Winsock2 library (WS2\_32.DLL): Invalid access to memory location'.

But ws2_32.dll is in C:\Windows\System32 allright, with these version details :

File Version : 5.1.2600.5512 (xpsp.080413-0852)
Description : Windows Socket 2.0 32-Bit DLL
Copyright : © Microsoft Corporation. All rights reserved.

(this shows I'm on WinXP btw).

The silly thing is, that when I look at the process itself (using "Process Explorer"), I can see the process already has this DLL open. The reason "WS2_32.DLL" is already loaded, seems to be because we use the RTL unit Winsock.pas in this project too. This unit is statically linked to "wsock32.dll", which has a dependancy on WS2_32.DLL, so there.

Does anyone know why this code worked fine before (in Delphi 2007), and now (in Delphi 2009) it suddenly breaks?

And is this inability to re-open the ws2_32 dll common knowledge, or is there really something wrong here? (I did check : I only have 1 version of these DLL's present on my system).

Better yet : Can anyone help me fixing this?

A: 

This may be overly simplistic, but have you tried changing the order in which the relevant units are listed in your uses clause? Sometimes this helps in these situations.

Argalatyr
A: 

I think it could be problem with Ansi/Unicode calls of Win32 API (including WinSock API). Check if code using AnsiString/AnsiPchar call XxxA functions (eg MessageBoxA), and String/Pchar call xxW function (eg MessageBoxW). In previous versions of Delphi String was alias to AnsiString and XxxA Win API function was used, but now String is unicode by default and XxxW functions should be used.

Michał Niklas
+1  A: 

I finally found an answer to this : The affected applications contained a bit of code-hooking that randomly damaged parts of System.dcu! (FYI : We're using a Delphi 2009 beta version of madshi's madCodeHook library). As soon as we switched to another code-hooking library, these symptoms disapeared... I guess that's what happens when you use beta-software. Anyway, sorry for bothering you with this. Problem solved!

PatrickvL