Many of the Shell functions accept or require a PIDL as a parameter. A while back I wrote a function that returns a PIDL from a given path but I have found a better way. This is an undocumented Windows function but I have tested it under Win95, Win98SE, WinNT4, and Win2K and it works perfectly under all those OS versions, I don't have XP so I can't test under that one. It is exported by Ordinal from Shell32.dll and since GoAsm has the best system for importing ordinals it is perfectly suited to using these functions...

First to make it more intuitive we set it up as an equate..

SHSimpleIDListFromPath = SHELL32.DLL:162

ILFree = SHELL32.DLL:155

Then we just call it giving the path, the path must be Unicode for NT/2K/XP and ANSI for 9x/ME, this example is for Unicode...

invoke SHSimpleIDListFromPath,L"C:\Documents and Settings\Administrator\Desktop"

push eax
invoke SHGetPathFromIDList,eax,offset szPath
pop eax
invoke ILFree,eax
invoke MessageBox,NULL,offset szPath,NULL,MB_OK

All this does is verify that it works by converting to/from a PIDL. You must free the PIDL once you are done with it by calling the ILFree function that is another undocumented function that wraps the IMalloc interface specifcally for PIDLs.
Posted on 2004-05-13 14:28:22 by donkey
*mumble grumble* undocumented functions, ordinal importing *mumble grumble*
Posted on 2004-05-13 15:56:55 by f0dder
Hi f0dder,

I geuss I should have qualified the "undocumented" part. It is exported by Ordinal in all Windows versions and though not garanteed to be exported in future verisons it probably will be as there are many internal functions that depend on it across a wide range of libraries. It was documented as part of the settlement API and exported by name beginning with Shell32 version 5. However, the ordinal version is available right down to NT4/95 which are never going to change as you well know.

Posted on 2004-05-13 16:41:31 by donkey
Hm, okay Donkey. I might be overly zealous on these matters, but it's happened too many times that I've had software that ceased to work because it depended on semi-documented functions. And it's not always a trivial fix to get it running >_<. In this case it also seems like the workaround is pretty simple.

But thanks for showing the stuff, nevertheless :)
Posted on 2004-05-13 20:19:12 by f0dder
Yeah, I am not big on undocumented functions either but there are some that have always been there and MS only admitted it with the settlement API. For example all of the DPA and DSA functions (Dynamic Pointer Array and Dynamic String Array) are available down to NT and as named exports above 2K. The thing is that MS used these functions in their applications and in order to preserve compatibility they have to keep the ordinal versions as well.
Posted on 2004-05-13 20:43:27 by donkey
yes, you are right - and I think it's lousy of MS to have done this. It's not that it gives them that big an advantage to their competitors, and for a large part I don't think it's why they didn't publish them either - it's more like "oh, it would be handy to have this library function and not having to bloody document it to hell". I know *I* would feel that way if I had to manage a project their size ;)

But knowing MS and some of their less lovable facets, they might choose to remove the interace in the future. "Hah, so we had to expose this? Well, we TOLD them it was deprecated!"...
Posted on 2004-05-13 20:54:54 by f0dder
I am currently going through the settlement API and the ordinals that they were exported under but if I use them and they are removed, I can replace the function or at least provide equivalent functionality. In GoAsm it is not really a problem as I can use them in-program then with a simple change to the equate move them to my own DLL, transparently to the application. This is why I had originally said that GoAsm is well suited to imports by ordinal, the nice thing is that I can force load the wrapper DLL with the PELoader as I don't have to use LoadLibrary/GetProcAddress as in MASM.

I agree with you on the intentions of MS, most of the functions are just easy wrappers to speed up development and do not add any new functionality to Windows. I don't think it was an oversight, just that they wrote their own wrappers for in-house use (something we all do) but in their case they could distribute them directly in the OS. This had the effect of them doing more with less memory, that is only thing I find wrong with it, the functions themselves are nothing really special (except a few of the Shell commands).
Posted on 2004-05-13 21:14:55 by donkey

I can replace the function or at least provide equivalent functionality.

Yup, you can, as the developer - it's a bit different when you only have a binary to work with >_<. I've had had to do this a couple of times, the 'public' application being X-COM. And that's the only reason I really bring this up - because I've seen what depending on "this works on all windows versions" can bring :/
Posted on 2004-05-13 21:43:54 by f0dder