shellapi.pp definitions for non-existent functions lazarus / 67-Windows ---------------------------------------------------------------------- 440bx · 2025-09-11 16:32 Hello, shellapi.pp defines: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i function SHEnumerateUnreadMailAccountsA(hKeyUser:HKEY; dwIndex:DWORD; pszMailAddress:LPSTR; cchMailAddress:longint):HRESULT;external shell32 name 'SHEnumerateUnreadMailAccountsA';function SHEnumerateUnreadMailAccountsW(hKeyUser:HKEY; dwIndex:DWORD; pszMailAddress:LPWSTR; cchMailAddress:longint):HRESULT;external shell32 name 'SHEnumerateUnreadMailAccountsW'; function SHEnumerateUnreadMailAccounts(hKeyUser:HKEY; dwIndex:DWORD; pszMailAddress:LPWSTR; cchMailAddress:longint):HRESULT;external shell32 name 'SHEnumerateUnreadMailAccountsW'; the only function that exists is the "W" version.  Neither the "A" nor the plain/"non-A" functions exist.  Therefore using either one in a program will result in a load failure due to a non-existent entry point. The above applies to Win XP up to Win 11.  I have not checked any version of Windows prior to Win XP.  HTH. ETA: the same applies to: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i function SHGetUnreadMailCountA(hKeyUser:HKEY; pszMailAddress:LPCSTR; pdwCount:PDWORD; pFileTime:PFILETIME; pszShellExecuteCommand:LPSTR;cch ShellExecuteCommand:longint):HRESULT;external shell32 name 'SHGetUnreadMailCountA';function SHGetUnreadMailCountW(hKeyUser:HKEY; pszMailAddress:LPCWSTR; pdwCount:PDWORD; pFileTime:PFILETIME; pszShell ExecuteCommand:LPWSTR;cchShellExecuteCommand:longint):HRESULT;external shell32 name 'SHGetUnreadMailCountW';function SHGetUnreadMailCount(hKeyUser:HKEY; pszMailAddress:LPCSTR; pdwCount:PDWORD; pFileTime:PFILETIME; pszShellExecuteCommand:LPSTR;cch ShellExecuteCommand:longint):HRESULT;external shell32 name 'SHGetUnreadMailCountA';function SHGetUnreadMailCount(hKeyUser:HKEY; pszMailAddress:LPCWSTR; pdwCount:PDWORD; pFileTime:PFILETIME; pszShell ExecuteCommand:LPWSTR;cchShellExecuteCommand:longint):HRESULT;external shell32 name 'SHGetUnreadMailCountW'; Only the "W" version exists.  The others do not. ETA2: same as above for: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i  function SHSetUnreadMailCountA(pszMailAddress:LPCSTR; dwCount:DWORD; pszShellExecuteCommand:LPCSTR):HRESULT;external shell32 name 'SHSetUnreadMailCountA';function SHSetUnreadMailCountW(pszMailAddress:LPCWSTR; dwCount:DWORD; pszShellExecuteCommand:LPCWSTR):HRESULT;external shell32 name 'SHSetUnreadMailCountW';function SHSetUnreadMailCount(pszMailAddress:LPCSTR; dwCount:DWORD; pszShellExecuteCommand:LPCSTR):HRESULT;external shell32 name 'SHSetUnreadMailCountA';function SHSetUnreadMailCount(pszMailAddress:LPCWSTR; dwCount:DWORD; pszShellExecuteCommand:LPCWSTR):HRESULT;external shell32 name 'SHSetUnreadMailCountW'; Only the "W" version exists. ---------------------------------------------------------------------- Zvoni · 2025-09-12 06:27 Disagree. https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf- shellapi-shenumerateunreadmailaccountsa Haven't looked at the other functions ---------------------------------------------------------------------- 440bx · 2025-09-12 06:47 There is nothing to disagree. Those are facts  You can verify them using dumpbin.  Of course, feel free to disagree with dumpbin.  Good luck with that one. ---------------------------------------------------------------------- AlexTP · 2025-09-12 07:54 Agree. Maybe it is better to write to FPC bugtracker? (With nearest issue.) ---------------------------------------------------------------------- Zvoni · 2025-09-12 08:27 Quote from: 440bx on September 12, 2025, 08:47:48 amThere is nothing to disagree. Those are facts  You can verify them using dumpbin.  Of course, feel free to disagree with dumpbin.  Good luck with that one. OK, i'll take your word for it. It just rubs me the wrong way, when the official MS-Documentation says nothing resp. otherwise. OTOH, i think to have read something, that some API's haven't been "removed" as such, but are only accessible via ordinal, not via Function-Name-Symbol. Maybe those are some of those? EDIT: regarding the functions above https://learn.microsoft.com/en-us/windows/win32/api/shellapi/ They are still in the shellapi.h-Headerfile Huh? ---------------------------------------------------------------------- 440bx · 2025-09-12 14:09 Quote from: Zvoni on September 12, 2025, 10:27:08 amIt just rubs me the wrong way, when the official MS-Documentation says nothing resp. otherwise. OTOH, i think to have read something, that some API's haven't been "removed" as such, but are only accessible via ordinal, not via Function-Name-Symbol. Maybe those are some of those? EDIT: regarding the functions above https://learn.microsoft.com/en-us/windows/win32/api/shellapi/ They are still in the shellapi.h-Headerfile Huh? yes, they are still in the header file in spite of the fact that they do not exist. In general, MS' documentation is _mostly_ right but, there are a _large_ number of mistakes which range from defining APIs that are long gone, claiming an API is not available when in fact, it is available all the way to Windows 11.  Other mistakes include declaring the wrong result type which ranges from mistaking a BOOL for an int or even worse, mistaking a DWORD for an int64. Literally, between what is documented and what is declared in the C headers, there are _hundreds_ of problems.  The reason MS gets away with it is because there are extremely few people that verify what is declared in the C headers with what is documented and cross reference that with disassemblies of the function (of which there may be multiple because some functions are implemented in more than one dll.)  Doing that is very revealing and, what's revealed is that MS has made quite a mess.  I only report a very small number of the problems because the number of Pascal programmers interested in this low-level stuff is small, which means very few will experience the problematic definitions.  Still, at least in theory, the definitions should be correct.