Angus Robertson

Did the German language post suggest an alternative API? 

gethostname is used by the ICS LocalHostName function, and from my reading there is no alternative API.  I guess the namespaceserviceprovider debug error is because the computer host name can come from several places, and internally an error on one location will cause it to look elsewhere. 

So it's something we just have to live with. 

A Stack Overflow suggests it's a Windows 11 bug:

The behaviour you're seeing seems to be due to Layered Service Providers being deprecated as of Win11 (and potentially an upcoming Win10 update).

GetHostByName is listed as deprecated, but GetHostName is not and also displays the same behaviour. In both cases the method queries any available namespace service providers first and then falls back to querying the NetBIOS name if none are found. As of Win11 it seems the call to enumerate the namespace service providers fails internally, generating the debug output you see.

Angus

No decision yet on how many old releases the next major version of ICS will support, partly down to age of old new language features, and partly because each time I add a new unit I have to update 100 to 200 .dpr, .dprog and .cprog files, something we should have automated a long time ago, but it's quicker to do it manually each time...

ICS V7 will still be supported for new compilers and OpenSSL versions (unless totally breaking) and major bugs, but no new components or features, unless another contributor takes over that support and testing, I've now migrated all my D2007 projects to D11 so don't need to use D2007 any longer. 

Angus

Thanks, since my last post I've updated my application from D2007 to D11.2, but still seeing debug lines.  I'll now look very closely at Ics_gethostname and change it if possible. 

Angus

Magenta Hardware Events Component is part of https://www.magsys.co.uk/delphi/maghardware.asp .  It warns if a PC is power sispending or restoring, or closing down, nothing complicated, this is just simple windows messages. 

As Peter says, OnCloseQuery should fire on normal forms, but belt and braces is often better is you really need a clean close down. And no events fire on forced termination.

Angus

Windows broadcasts power event messages before close down, WM_POWERBROADCAST or WM_POWER, I have a component for checking them. 

In theory you can suspend close down, but this can be ignored by Windows. 

If someone turns the PC power off, no events will occur, so if you really need to know it's best to write the date and time or something to a file every few seconds and on normal close down, and check it on starting up, so you know there was a clean close down and for how long.  

Angus

I too use MaxInt for new applications, but I've no idea whether it is available in all the ancient compilers ICS still supports, so always keep code a simple as possible. 

There is no complete list of new features, functions and constants added with each new release,  When I needed to use PosEx to simplify some code, I had to use three conditionals as it changed three times since Delphi 7, had to search old source directories to find out when, which all takes valuable time.

This won't matter for much longer since the next major release of ICS will cease support for compilers more than a few years old, so we can finally make use of new language features and remove lots of ANSI specific stuff.  But we will changing too much old working code, since invariably changes introduce errors and often new things don't work properly.

For instance when using TSearchRec to index files, I tried using the new TimeStamp property that returns TDateTime instead of Time that returns a file date stamp, but eventually discovered TimeStamp returns UTC time instead of local time, both undocumented in help so don't know if this is deliberate or a bug. 

But it meant my applications could not correctly compare source and destination directories when FTP or copying files, causing hundred of thousands of extra files to be copied, until I reverted to using Time.  So new is not always better.

Angus

Lost file associations may depend on how you upgrade to 22H2.  I downloaded the full ISO from Visual Studio Downloads, and did an in place update, as I've done for previous versions, since it is not available for Enterrprise from Windows Update.  All applications and setting remained okay. 

.BAT was the only association removed (I think), others remained, but multi-media files all come up once asking how do you want to open this file, offering to continue using VLC as the first option, but suggesting Clipchamp as the first option, which I assume is some new Microsoft tool added to Windows 11.

Angus 

Not sure if it's just my PC, but updating to Windows 11 22H2 last week stopped .BAT files running due to the file association being removed, it seems Windows now prefers them to be called .CMD instead.   Most other file associations disappeared as well, but that is just Microsoft wanting us to use it's own apps and not better ones.

Easy enough to rename my common batch files, but GetIt often builds libraries using BAT files, so had to restore the file association with a little REG file.

Windows Registry Editor Version 5.00

[-HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.bat]
[-HKEY_CURRENT_USER\Software\Classes\.bat]
[-HKEY_CURRENT_USER\SOFTWARE\Classes\batfile]

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.bat]
@="batfile"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\batfile\shell\open\command]
@="\"%1\" %*"

Windows Explorer also now crashes with a .NET run time error, which is pretty sad, fortunately I mainly use the Delphi UltraExplorer instead.  Possible the Explorer crash is due to third party software like Open Shell Menu.

Angus

I recently added a IcsBuiltWith function to ICS to keep track of how I'm building the samples, there are RTL variables that can be checked for recent compilers:

{$IFDEF VER350}
    Result := '11.0';
    {$IF Declared(RTLVersion111)}Result := '11.1';{$IFEND}
    {$IF Declared(RTLVersion112)}Result := '11.2';{$IFEND}  // both declared
{$ENDIF}
{$IFDEF VER340}
    Result = '10.4';
    {$IF Declared(RTLVersion1041)}Result := '10.41';{$IFEND}
    {$IF Declared(RTLVersion1042)}Result := '10.42';{$IFEND}  // both declared
 {$ENDIF}

Angus

Thanks, presumably it is conditional for Delphi 11.1 (I think) and later that contain the same ZLIB as ICS?

Angus

To be fair, it's my implementation of the ICS web server component that deliberately kills the server on an unexpected fatal error so that Service Manager Controller restarts it, because I know from 15 years experience of such servers that very rarely the server stops responding after a fatal error. 

ICS normally treats disconnection correctly, many other places don't cause the fatal error handler to be called, but just very rarely does this specific instance occur. 

For the moment, I'm now ignoring this particular error in the fatal error handler, but it's better never to happen. 

Angus

SocketError( } is important for raising terminal errors through the onBgExecption event, errors that can leave a server unresponsive, which is why I restart it. 

But SocketError( } treats all errors the same, fatal and non-fatal.  In my case, a web hacker closed an HTTP connection before the server could answer, thus no connection while trying to send a response, and a server restart.   Not common, once or twice a year from millions of connections, but still a bug. 

On reflection, I think we should raise a local exception in Send(), which the same behaviour as SocketError( } if an error handler event is not specified, which is less likely to cause backward compatibility issues.

Angus

ICS has a core function, probably unchanged for 20 years, that starts:

{ Return -1 if error, else return number of byte written                    }
function TCustomWSocket.Send(Data : TWSocketData; Len : Integer) : Integer;
begin
    if (FState <> wsConnected) and (FState <> wsSocksConnected) then begin
        WSocket_Synchronized_WSASetLastError(WSAENOTCONN);
        SocketError('Send');
        Result := -1;
        Exit;
    end;

....

My problem is that the SocketError function is quite complex, and has options to trigger event handlers with exception information.  In a server, those error handlers are often considered fatal and may raise an exception or terminate the application, despite the function being documented as returning -1 for an error. 

For servers in particular, it is common for a connection to be lost unexpectedly, and this should not really trigger major exceptions. 

So I'm proposing to remove SocketError, so that error never returns an exception but returns as documented. 

But will this break existing applications that may rely on an exception?

Angus

I build the packages on Delphi 7 periodically to ensure we've not used new language features, and until very recently all my main applications and servers were using Delphi 2007 which is only two releases later. 

The call stack you show does not appear to show any ICS components making calls. 

Angus

I've just got it working with my live.com account, after accepting several application warning screens during the OAuth2 login process, I've previously had to increase the ICS timeout to waiting long enough for all this extra padding to be clicked past.  

Sorry, no idea about specific error, Microsoft does not any of this stuff easy for developers, at least not of my age.

Angus

Sorry, the only documentation is at the top of the OverbyteIcsSslHttpOAuth.pas unit. 

I tested TIcsRestEmail against Gmail recently, but Microsoft was always much harder due to multiple APIs and account types.  It was working when I initially wrote it, but my secrets are now expired and I need to refresh them to gain access again. 

Angus

Quote

We went from sending mail through smtp (office365) to the MS Graph interface.

ICS has a TIcsRestEmail component that supports the MS Graph interface, just basic functions to read and send email at the moment, demo in the OverbyteIcsHttpRestTst sample.

Angus

ICS OAuth2 has been tested against smtp-mail.outlook.com and pop-mail.outlook.com, but they have several platforms, what changes did you need to make it work, so I can fix it for others. 

Sorry, ICS does not have IMAP4. 

Angus

I was going to suggest testing NTLM using the OverbyteIcsHttpRestTst sample which includes logging of all headers, but it seems this logging ignores the internal handshaking (and redirection) requests that the HTTP client component does, so will not help. 

Diagnosing will need some more logging added.  But probably something we should do, NTLM is not going away in a hurry, despite modern OAuth2 , etc. 

Angus

There are no NTLM settings as such, all I can suggest is looking through the version notes in OverbyteIcsHttpProt.pas and OverbyteIcsNtlmMsgs.pas about changes over the years.  You might also try tracing through the different messages passed during the handshaking to see where it dies.  Are your two environments running the Windows Server version? 

Angus

Sorry, NTLM is primarily designed for use on corporate LANs in an Active Directory domain on Windows Servers, and I don't have Active Directory set-up.  So our testing of NTLM is limited.  It was implemented many years ago for Windows Server 2003 or something, and doubtless Microsoft has been changing it regularly since. 

I did test NTLM against the ICS web server recently, and you've found it sometimes works, but I've no idea why it fails in one environment. 

Angus

I was using ICS libraries built with 11.1 for a few days after installing 11.2 without any problems.  It was only when I tried to build all packages with updated units that the Win64 issue appeared. 

Updated Delphi packages are now in SVN, sorry can not test C++.  The issue may have been the Win64 linker. 

Angus

Just remove Winapi.Winsock from uses then, your application should not need it.

Angus

We are aware of a problem building ICS packages for Win64 with Delphi 11 Update 2, aka 11.2.  Something has changed in the way Delphi searches for DCPs. 

Spent the morning making changes to the ICS packages, just finished testing, will be in SVN shortly. 

Rewrote OverbyteHttpMulti earlier this week, will check your other error, that will be in SVN by tomorrow.

Angus

Why do you have Winapi.Winsock in your uses?  It is not needed in any ICS applications, and is only used in one component, probably unnecessarily. 

Angus