1

I'm using the new Delphi Tokyo 10.2.2 and, in my case, I use packages loaded at runtime.

Even making a simple example and requesting EXE to load only the RTL unit occurs a run-time error, only on the Windows XP operating system:

The procedure entry point inet_ntop could not be located in the dynamic link library WS2_32.dll.

Using Delphi Tokyo 10.2.1 the problem does not happen.

Any idea?

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
Zoe Tecnologia
  • 53
  • 7
  • 5
    Delphi does not support targeting XP, and has not supported it for a long time. If you need to support XP, use an older version of Delphi that does support XP. More sensible would be to stop supporting XP. – David Heffernan Jan 04 '18 at 13:41
  • Having said that, I know that Emba planned not to intentionally stop executables working on xp. Perhaps this is unintentional. Submit an issue to QP. – David Heffernan Jan 04 '18 at 14:03
  • @Ken That's not strictly true. Those versions did not knowingly set out to block executables running on xp. Emba said that they wouldn't test on xp but that they wouldn't actively block executables running on xp. And I'm pretty sure that Berlin and previous Tokyo versions produced executables that did run on xp. – David Heffernan Jan 04 '18 at 14:23
  • @DavidHeffernan: That *is* strictly true - see [Supported Target Platforms](http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Supported_Target_Platforms), which says Windows 7 (SP1) is the oldest Windows version supported. I didn't say *actively blocked*. I said *does not support*. – Ken White Jan 04 '18 at 14:39
  • @ken That part is fine I agree. In fact I even wrote a comment to say the exact same thing. But you said more. It's this line that I was commenting on: *They depend on functionality that does not exist in XP*. That's not true. – David Heffernan Jan 04 '18 at 14:45
  • I would just reinforce what I said before, using the Tokyo version 10.2.1 the problem just does not happen! – Zoe Tecnologia Jan 04 '18 at 22:00
  • As David said, open a bug report at Embarcadero. We can't do anything about it here. If you think there's now a bug in Tokyo 10.2.2, EMBT would be the ones who can resolve it. – Ken White Jan 05 '18 at 00:49
  • You need to drop support for xp. While you are at it drop vista too. – David Heffernan Jan 07 '18 at 01:15

3 Answers3

1

I have a new project proxy functions to all exported functions of original Windows XP's WS2_32.dll including inet_pton that was missing in Windows XP's WS2_32.dll.

It tricks the Windows XP application process to think that inet_pton is available and not prompting any errors.

Repository: https://github.com/ccy/WS2_32_XP

Chau Chee Yang
  • 18,422
  • 16
  • 68
  • 132
0

inet_ntop() was added to Winsock in Windows Vista, it does not exist in XP.

Clearly, Embarcadero has added new code to the RTL in 10.2.2 that is calling inet_ntop() statically instead of dynamically. Code that did not exist in the RTL in 10.2.1. That is why the error is happening when loading 10.2.2's RTL package on XP.

There is nothing you can do about that. If you must run your app on XP, (which Embarcadero dropped support for way back in XE3), then you can't use the 10.2.2 RTL.

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
  • When the same application has the package added in the complilation, ie the RTL is not loaded at runtime, the problem does not occur. Working perfectly on Win XP! Why? – Zoe Tecnologia Jan 06 '18 at 15:13
  • @ZoeTecnologia when runtime packages are compiled into the app statically, the compiler/linker can optimize away code that is not actually used. That is not the case with runtime packages that are loaded dynamically – Remy Lebeau Jan 06 '18 at 19:18
  • thank you for the clarification. I had only one question left: I can solve the EXE problem by including RTL at design time, but when loading the system modules (in BPL) the error happens, because these modules need RTL (as you explained). Is there any way to load / include the RTL in my BPL? – Zoe Tecnologia Jan 08 '18 at 18:54
  • @ZoeTecnologia: As I said earlier, if you statically link in the RTL (which you shouldn't do when using BPLs), unused RTL code gets optimized away. If you dynamically link to the RTL's BPL (which you should do when using BPLs), there is nothing you can do, the affected code exists and prevents the RTL from loading on XP. – Remy Lebeau Jan 08 '18 at 19:16
0

All,

I was able to solve the problem by creating a package with all the necessary units embbed.

Then the executable and the other BPL (modules) referring to this single new package.

It worked again in win XP!

Thank you all for the support

Zoe Tecnologia
  • 53
  • 7
  • I forgot to tell the AUTHOR (Keith Johnson) in his article on systems using BPL Packages. (I did not find the article link anymore) – Zoe Tecnologia Jan 09 '18 at 16:02