During some application testing, we discovered that WinE does not correctly mimic the WinINet function InternetCrackUrl. The real WinAPI sets the dwUrlPathLength member of the URL_COMPONENTS structure to additionally hold the extra info of the given URL if the extra info is not requested as a separate component. Although this behaviour is not well documented by the Win SDK, it is for instance implemented on WinXP, Win2000 and WinME and therefore might be considered to be intended by Microsoft.
The following lines of code demonstrate the problem:
LPCTSTR lpszURL = _T("http://www.myserver.com/myscript.php?arg=1";);
URL_COMPONENTS url;// call 1: crack out url path and extra info ::ZeroMemory(&url, sizeof(url)); url.dwStructSize = sizeof(url); url.dwHostNameLength = 1; url.dwUrlPathLength = 1; url.dwExtraInfoLength = 1; ::InternetCrackUrl(lpszURL, 0, 0, &url); // dwUrlPathLength is 13, holding "/myscript.php"
// call 2: only crack out url path ::ZeroMemory(&url, sizeof(url)); url.dwStructSize = sizeof(url); url.dwHostNameLength = 1; url.dwUrlPathLength = 1; ::InternetCrackUrl(lpszURL, 0, 0, &url); // now, dwUrlPathLength should be 19, holding "/myscript.php?arg=1", // while WinE still sets it to 13
OK, it is of course no great deal to write code that correctly runs on real Win systems and on WinE (2-3 lines did it). But programers who rely on this behaviour will for example wonder why their applications don't transmit any HTTP GET parameters when they call HttpOpenRequest with lpszObjectName set to the URL path component returned by InternetCrackUrl...
This applies to Wine 20031016, haven't found any recent report on this though.
/jan.
