WinInet compiling errors.

[440bx]

I'm guessing that there are .o files left over from the wininet.lpr project in the lib\x86_64-win64 directory and the linker takes that file.

I'll have to check that out.

Can't do it right now, life wants attention at time... but, sometime today for sure.

I am a bit surprised that the compiler doesn't seem to take the extension into account.  I don't think a .lpr file is ever supposed to be a unit.  Am I mistaken about that ?

The extensions are mostly convenience functions. The only thing the compiler knows is a list of extensions to test if you pass a name without extension.

But the compiler can't pick any file with the same name regardless of extension, if it did, it could pick a .exe or .dll that happens to have the same name as a unit and, that would be a mess.

[jamie]

I would say that is a crutch in the compiler and could be the cause of many unexplained errors like unit CRC/Date has changed for example.

 I can see where that could cause issues.

 Jamie

[Thaddy]

I still can't replicate.
This simply works:

Code: Pascal  [Select][+][-]

1. {$mode objfpc}{$H+}
2. uses
3.   WinInet, SysUtils, Windows;
4.  
5. procedure SimpleWinInetExample;
6. var
7.   hSession, hConnect: HINTERNET;
8.   Buffer: array[0..1023] of Char;
9.   BytesRead: DWORD;
10.   Response: string;
11. begin
12.   // Initialize the WinINet session
13.   hSession := InternetOpen('Freepascal WinINet Example', INTERNET_OPEN_TYPE_PRECONFIG, nil, nil, 0);
14.   if hSession = nil then
15.   begin
16.     Writeln('Failed to open Internet session. Error: ', GetLastError);
17.     Exit;
18.   end;
19.  
20.   try
21.     // Open an HTTP connection
22.     hConnect := InternetOpenUrl(hSession, 'https://www.example.com', nil, 0, INTERNET_FLAG_RELOAD, 0);
23.     if hConnect = nil then
24.     begin
25.       Writeln('Failed to connect to URL. Error: ', GetLastError);
26.       Exit;
27.     end;
28.  
29.     try
30.       // Read the response
31.       Response := '';
32.       repeat
33.         FillChar(Buffer, SizeOf(Buffer), 0);
34.         if InternetReadFile(hConnect, @Buffer, SizeOf(Buffer) - 1, BytesRead) and (BytesRead > 0) then
35.           Response := Response + Copy(Buffer, 1, BytesRead);
36.       until BytesRead = 0;
37.  
38.       // Output the response
39.       Writeln('Response:');
40.       Writeln(Response);
41.     finally
42.       InternetCloseHandle(hConnect);
43.     end;
44.   finally
45.     InternetCloseHandle(hSession);
46.   end;
47. end;
48.  
49. begin
50.   try
51.     SimpleWinInetExample;
52.   except
53.     on E: Exception do
54.       Writeln('An error occurred: ', E.Message);
55.   end;
56. end.

Win11. Even TLS resolves OK. (https URL tested)
Only thing I can think of that you are using Win7 or something....That will fail indeed.
Not because of Freepascal, but because of unsupported/outdated Microsoft Windows  networking libraries.
Win7 for sure does not support modern TLS standards 1.3 and 1.4.
(Vista also does not work anymore)

[jamie]

I don't know where you get this "Ship high in Transit" from but whatever.

[Thaddy]

Simple: if you are on XP, Vista or Win7 you ran out of options regarding OS supported security.
My code is a simple common test, with a check for TLS1,3 added. (https)
Wininet solely relies on Microsoft Windows API's and then only on ones of a particular - deprecated - kind, unlike OpenSSL based solutions.

[440bx]

The problem resides in Lazarus because compiling directly from the command line using FPC works fine.  The same project with Lazarus' default options fails to compile.

In the attachment there are two projects in separate directories.  Both projects compile without any problems using FPC from the command line.  With Lazarus, the first project fails to compile.  The second compiles fine.

Suggestion: create a new directory (e.g, test) and expand the archive there.

[korba812]

The first project does not compile both in Lazarus and using FPC from the command line. And it shouldn't, since the program name is the same as the unit name in the same project (wininet.lpr and wininet.pas, both of which produce wininet.o).

[440bx]

The first project does not compile both in Lazarus and using FPC from the command line. And it shouldn't, since the program name is the same as the unit name in the same project (wininet.lpr and wininet.pas, both of which produce wininet.o).

It compiles just fine for me.  Here is the compiler's output:

[H:\Dev\Tests\00_Names\01_lpr]fpc wininet.lpr
Free Pascal Compiler version 3.0.4 [2017/10/06] for i386
Copyright (c) 1993-2017 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling wininet.lpr
Compiling wininet.pas
Linking wininet.exe
16 lines compiled, 0.2 sec, 25616 bytes code, 1268 bytes data

[H:\Dev\Tests\00_Names\01_lpr]dir

 Volume in drive H is TA8TB-2 Data - H   Serial number is 6a1d:5e63
 Directory of  H:\Dev\Tests\00_Names\01_lpr\*

 6/22/2025   8:24         <DIR>    .
 6/22/2025   8:24         <DIR>    ..
 6/22/2025   8:24          31,744  wininet.exe
 6/21/2025  15:51           1,669  wininet.lpi
 6/21/2025  15:51              87  wininet.lpr
 6/21/2025  16:01           2,113  wininet.lps
 6/22/2025   8:24           2,111  wininet.o
 6/21/2025  15:47              52  wininet.pas
 6/22/2025   8:24             629  wininet.ppu

ETA:

Just noticed that, the active alias used v3.0.4, here is the compile using the current version:

[H:\Dev\Tests\00_Names\01_lpr]D:\v4.0rc3\fpc\3.2.2\bin\x86_64-win64\fpc.exe wininet.lpr
Free Pascal Compiler version 3.2.2 [2025/03/22] for x86_64
Copyright (c) 1993-2021 by Florian Klaempfl and others
Target OS: Win64 for x64
Compiling wininet.lpr
Compiling wininet.pas
Linking wininet.exe
16 lines compiled, 0.3 sec, 32928 bytes code, 1524 bytes data

As you can see, it compiles just fine no matter the FPC version.

[korba812]

It does indeed compile under x86_64. I tried with i386 and it does not compile.

Code: [Select]

d:\lazarus-projekty\test-440\01_lpr>fpc wininet.lpr
Free Pascal Compiler version 3.2.3-1412-gd6d047d8a4-dirty [2025/05/20] for i386
Copyright (c) 1993-2024 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling wininet.lpr
Linking wininet.exe
wininet.lpr(10,1) Error: Undefined symbol: DEBUGSTART_$WININET
wininet.lpr(10,1) Error: Undefined symbol: DEBUGEND_$WININET
wininet.lpr(10,1) Fatal: There were 2 errors compiling module, stopping
Fatal: Compilation aborted
Error: d:\fpcupfix\fpc\bin\i386-win32\ppc386.exe returned an error exitcode

d:\lazarus-projekty\test-440\01_lpr>fpc -Px86_64 wininet.lpr
Free Pascal Compiler version 3.2.3-1412-gd6d047d8a4-dirty [2025/05/20] for x86_64
Copyright (c) 1993-2024 by Florian Klaempfl and others
Target OS: Win64 for x64
Compiling wininet.lpr
Compiling wininet.pas
Linking wininet.exe
16 lines compiled, 0.1 sec, 39744 bytes code, 1556 bytes data
However, if I use an external linker (-Xe option) under i386 it also compiles.

Code: [Select]

d:\lazarus-projekty\test-440\01_lpr>fpc -Xe wininet.lpr
Free Pascal Compiler version 3.2.3-1412-gd6d047d8a4-dirty [2025/05/20] for i386
Copyright (c) 1993-2024 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling wininet.lpr
Compiling wininet.pas
Linking wininet.exe
16 lines compiled, 0.8 sec
My guess is that the cause may be the order of the paths given to the compiler (in the configuration file and via the -Fu or -Fo option).

[440bx]

It does look like the problem is rooted in the linking step.

[PascalDragon]

I had a small program called wininet.lpr (note the .lpr extension, not .pas), in the same directory as TestWininet.lpr, in spite of the extension being .lpr, the compiler apparently thought that it was the source for the wininet unit. 

I am a bit surprised that the compiler doesn't seem to take the extension into account.  I don't think a .lpr file is ever supposed to be a unit.  Am I mistaken about that ?

The unit itself is not the problem (FPC will pick the correct one), however the issue is the object file. Your wininet.lpr will also result in a wininet.o and for some reason the linker picks up that object file instead of the one that matches the unit and that in turn will lead to linker errors. You could try to use -Xe to check whether the external linker behaves the same way. If it does, then it's an issue with the internal linker that should be reported, if not it maybe should be reported as well to check whether it can be improved somehow...