Creating Links On windows 2000
-
Let me state the problem ANOTHER way: Microsoft says that The IShellLink interface has an ANSI version (IShellLinkA) and a Unicode version (IShellLinkW). The version that will be used depends on whether you compile for ANSI or Unicode. However, Microsoft® Windows® 95 and Windows 98 only support IShellLinkA. My question is this... Is there a way to compile a SINGLE CLASS that will work on BOTH Windows 98 and Windows 2000 to create Links depending on the platform? For example, can you do something like: if (b2000 || bNT) { // Use IShellLinkW } else { // use IShellLinkA } Do you have to compile 2 separate programs to create links? :-O Bill SerGio, The Infomercial King
-
Let me state the problem ANOTHER way: Microsoft says that The IShellLink interface has an ANSI version (IShellLinkA) and a Unicode version (IShellLinkW). The version that will be used depends on whether you compile for ANSI or Unicode. However, Microsoft® Windows® 95 and Windows 98 only support IShellLinkA. My question is this... Is there a way to compile a SINGLE CLASS that will work on BOTH Windows 98 and Windows 2000 to create Links depending on the platform? For example, can you do something like: if (b2000 || bNT) { // Use IShellLinkW } else { // use IShellLinkA } Do you have to compile 2 separate programs to create links? :-O Bill SerGio, The Infomercial King
Two more thinks to check for are if it works in both NTFS and FAT. Also NT5 /2000 uses shell link tracking, so check to see if a shortcut is moved that it still works. Regardz Colin J Davies
Sonork ID 100.9197:Colin
More about me :-)
-
Two more thinks to check for are if it works in both NTFS and FAT. Also NT5 /2000 uses shell link tracking, so check to see if a shortcut is moved that it still works. Regardz Colin J Davies
Sonork ID 100.9197:Colin
More about me :-)
It seems that the more I test code and research this problem, that it is IMPOSSIBLE to write a single class and compile it to work for both Windows 98 and windows 2000. The ONLY solution seems to be to create 2 versions of a DLL or an EXE, one for UNICODe and one for ASCII to create links. Bill SerGio, The Infomercial King
-
Let me state the problem ANOTHER way: Microsoft says that The IShellLink interface has an ANSI version (IShellLinkA) and a Unicode version (IShellLinkW). The version that will be used depends on whether you compile for ANSI or Unicode. However, Microsoft® Windows® 95 and Windows 98 only support IShellLinkA. My question is this... Is there a way to compile a SINGLE CLASS that will work on BOTH Windows 98 and Windows 2000 to create Links depending on the platform? For example, can you do something like: if (b2000 || bNT) { // Use IShellLinkW } else { // use IShellLinkA } Do you have to compile 2 separate programs to create links? :-O Bill SerGio, The Infomercial King
-
Am i missing something? Why doesn't IShellLinkA work on both '98 and 2k? They both work on XP AFAIK. :confused: --------
Have you hugged your monitor today?
--Shog9 --
Email me a release to test please Shog, It might be Bill's 2000 has a problem. Regardz Colin J Davies
Sonork ID 100.9197:Colin
More about me :-)
-
Am i missing something? Why doesn't IShellLinkA work on both '98 and 2k? They both work on XP AFAIK. :confused: --------
Have you hugged your monitor today?
--Shog9 --
It ONLY works only Windows 98 and I was surprised to learn this as you are! If you set _UNICODE, and compile it under UNICODE, as a SEPARATE exe or DLL then it works ONLY on Windows 98. So far, nobody has created a class or piece of code that will compile and create a SINGLE exe or DLL that works on BOTH Windows 98 and Windows 2000. Bill SerGio, The Infomercial King
-
It ONLY works only Windows 98 and I was surprised to learn this as you are! If you set _UNICODE, and compile it under UNICODE, as a SEPARATE exe or DLL then it works ONLY on Windows 98. So far, nobody has created a class or piece of code that will compile and create a SINGLE exe or DLL that works on BOTH Windows 98 and Windows 2000. Bill SerGio, The Infomercial King
Please excuse my type... i meant... If you set _UNICODE, and compile it under UNICODE, as a SEPARATE exe or DLL then it works ONLY on WINDOWS 2000. Bill SerGio, The Infomercial King
-
It seems that the more I test code and research this problem, that it is IMPOSSIBLE to write a single class and compile it to work for both Windows 98 and windows 2000. The ONLY solution seems to be to create 2 versions of a DLL or an EXE, one for UNICODe and one for ASCII to create links. Bill SerGio, The Infomercial King
There is no reason to build both a UNICODE and ASCII version. Just call the W and A routines directly based on the OS. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
-
There is no reason to build both a UNICODE and ASCII version. Just call the W and A routines directly based on the OS. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
That is what I thought originally and it turns out NOT to work which surprised me. the reason that it fails is that if you include a condition based on the operating system as follows: if (b2000 || bNT) { // Use Unicode } else { // Use ASCII } The reason it fails has to do with the fact that you can't get the code to compile on Windows 98. Remember I am developing on Windows 98 and this is the problem. For example, "SHGetSpecialFolderLocation()" works on Windows 98 but the call for the UNICODE function, "ShGetFolderPath()" FAILS to compile on a Windows 98 machine using Visual Studio UNLESS YOU COMPILE with unicode which renders the code useless on Windows 98 Bill SerGio, The Infomercial King
-
That is what I thought originally and it turns out NOT to work which surprised me. the reason that it fails is that if you include a condition based on the operating system as follows: if (b2000 || bNT) { // Use Unicode } else { // Use ASCII } The reason it fails has to do with the fact that you can't get the code to compile on Windows 98. Remember I am developing on Windows 98 and this is the problem. For example, "SHGetSpecialFolderLocation()" works on Windows 98 but the call for the UNICODE function, "ShGetFolderPath()" FAILS to compile on a Windows 98 machine using Visual Studio UNLESS YOU COMPILE with unicode which renders the code useless on Windows 98 Bill SerGio, The Infomercial King
Bill SerGio wrote: For example, "SHGetSpecialFolderLocation()" works on Windows 98 but the call for the UNICODE function, "ShGetFolderPath()" FAILS to compile on a Windows 98 machine using Visual Studio UNLESS YOU COMPILE with unicode which renders the code useless on Windows 98 You may have a problem with your VS installation. Or possibly need updated SDK header files, not sure.
SHGetFolderPath()was introduced as a shortcut for the most common use ofSHGetSpecialFolderLocation(), and requires that a separate DLL (SHFolder.dll) be installed. It does however work on both Win98 and Win2k should these criteria be met. Or you can just useSHGetSpecialFolderLocation()andSHGetPathFromIDList()to accomplish (mostly) the same thing (but you'll have to do your own handling for CSIDL that are user-specific or not implemented on 98 (ex:CSIDL_PROGRAM_FILES_COMMON,CSIDL_COMMON_DOCUMENTS). --------Have you hugged your monitor today?
--Shog9 --
-
That is what I thought originally and it turns out NOT to work which surprised me. the reason that it fails is that if you include a condition based on the operating system as follows: if (b2000 || bNT) { // Use Unicode } else { // Use ASCII } The reason it fails has to do with the fact that you can't get the code to compile on Windows 98. Remember I am developing on Windows 98 and this is the problem. For example, "SHGetSpecialFolderLocation()" works on Windows 98 but the call for the UNICODE function, "ShGetFolderPath()" FAILS to compile on a Windows 98 machine using Visual Studio UNLESS YOU COMPILE with unicode which renders the code useless on Windows 98 Bill SerGio, The Infomercial King
-
Please excuse my type... i meant... If you set _UNICODE, and compile it under UNICODE, as a SEPARATE exe or DLL then it works ONLY on WINDOWS 2000. Bill SerGio, The Infomercial King
I'm confused, Shog9's app work on my Win 2000 and 98 for me. Have you mangled your 2000 ? Regardz Colin J Davies
Sonork ID 100.9197:Colin
More about me :-)
-
You dont need to do any test for OS just call CoCreateInstance(CLSID_ShellLink, NULL, CLSCTX_INPROC_SERVER, IID_IShellLinkW, (void**) &pShellLink); if it succeedes use the IShellLinkW interface. If it fails create the IShellLinkA interface.
I am impressed! I must admit that I did not think of this as a switch instead of a switch based on the operating system. i will write a demo program and post it and see if what happens--let you know in a little while. By the way--this is a BRILLIANT suggestion to first try for IID_IShellLinkW and if it fails use IID_IShellLinkA. And I might point out that in all the samples of code to create links, nobody has thought to do this! Bill SerGio, The Infomercial King
-
That is what I thought originally and it turns out NOT to work which surprised me. the reason that it fails is that if you include a condition based on the operating system as follows: if (b2000 || bNT) { // Use Unicode } else { // Use ASCII } The reason it fails has to do with the fact that you can't get the code to compile on Windows 98. Remember I am developing on Windows 98 and this is the problem. For example, "SHGetSpecialFolderLocation()" works on Windows 98 but the call for the UNICODE function, "ShGetFolderPath()" FAILS to compile on a Windows 98 machine using Visual Studio UNLESS YOU COMPILE with unicode which renders the code useless on Windows 98 Bill SerGio, The Infomercial King
I had a similar problem once - I had to call a Windows 2000 machine but I was developing on NT. The solution (in pseudocode) was something like this: if(IsOs2000()) { Explicitly load the system DLL that has the function using LoadLibrary Get the function poitner using GetProcAddress Call the function Unload the DLL if necessary } Just a thought. Ugly, I know, but it might work in your situation. Even if you win the rat race, you're still a rat.