Does anyone know of any issues with the ILClone() function on Windows 2000? Is it fully supported? MSDN says it runs on Windows 2000 but I have a user reporting that my program will not run on Windows 2000 because of that function.
EDIT: I was able to get a hold of a Win2K system and I can confirm the issue.
Shell32.dll version installed is 5.0.3700.6705. The error message shown when running the program is: The procedure entry point ILClone could not be located in the dynamic link library SHELL32.DLL
iirc ILClone was available on Windows 5, but it was exported from shlwapi.dll, so you had to load it using LoadLibrary & GetProcAddress() to be compatible.
Related
I have some VBscripts that automate IBM Personal Communications
Since I have to use the version 14 (64 bits) sometimes I get errors:
If I use the function CreatObject the error is: The specified module could not be found.
If I use the Wscript method Wscript.CreateObject the error is: WScript.CreateObject: Could not create object named "PCOMM.autECLConnMgr.1"
I have tried 2 ProgID for each of the 4 DLL
"PCOMM.autECLConnMgr" or "PCOMM.autECLConnMgr.1" "PCOMM.autECLPS" or "PCOMM.autECLPS.1" "PCOMM.autECLConnList" or "PCOMM.autECLPS.1" "PCOMM.autECLOIA" or "PCOMM.autECLPS.1"
I'm using LENOVO workstations with Windows 10 Enterprise Build 1809 64 bits
And also tried
C:\Windows\SysWOW64\cscript and C:\Windows\System32\cscript
Both works and both sometimes return the errors
Also have tried 2 different workstations in spite of those machines have the same "image" of software...
With IBM PC Version 12 this didn't happen!
And here is my pain... The error happens just the first time the script runs... Then okay.
I even can't induce the error !!
Any hint would be appreciated.
João
In my application, I am using the following Win32 API to before loading the mapi32.dll.
win32 API: ::GetProfileInt(_T("MAIL"), _T("MAPI"), 0);
This API is consistently failing on Windows 8.1 Italian 64-Bit PC.
But, this API is succeeding on all other PCs like Windows 8.1 English(US) 64-Bit PC, Windows 8.1 Japanese 64-Bit PC.
Kindly provide your kind help for fixing the above issue.
To find MAPI32.dll look in either of these paths:
C:\Windows\SysWOW64\mapi32.dll
C:\Windows\System32\mapi32.dll
or use this
GetWindowsDirectory(buf, 260);
lstrcat(buf, TEXT("\\SysWOW64\\mapi32.dll"));
...
To access old win.ini settings, look in this registry key:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\win.ini
But there is probably nothing there about MAPI, it's about 20 years out of date.
The code you originally got this from was probably very old and is no longer supported. If you read the documentation for GetProfileInt, you'll see that its purpose is to support 16-bit applications.
I recommend removing the call. I have also observed it failing on Windows 7 machines while succeeding on Windows 10 machines. I think the more appropriate calls are to use SearchPath(nullptr, L"MAPI32.DLL", nullptr, 0, nullptr, nullptr) to see if MAPI32.DLL would even be found. An alternative is to just attempt the LoadLibrary(L"MAPI32.DLL") and check the returned handle.
An even better solution might be to change your code to call MAPISendMailHelper as it will do the LoadLibrary, GetProcAddress, etc. for you.
I have an executable compiled by MSVS2013 on Windows 7 SP1 32 bit with C runtime statically linked and platform toolset "Visual Studio 2013 - Windows XP (v120_xp)"
It runs perfectly on Win7 (see attached screenshot of Dependency Walker profiling).
It fails to run on WinXP:
Here is the profile log:
Starting profile on 12/9/2014 at 2:55:03 AM
Operating System: Microsoft Windows XP Professional (32-bit), version 5.01.2600 Service Pack 3
Program Executable: c:\temp\OCTOPUS.EXE
Program Arguments:
Starting Directory: C:\Temp\
Search Path: C:\Program Files\ActiveState Komodo Edit 8\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\MATLAB\R2009b\runtime\win32;C:\Program Files\MATLAB\R2009b\bin;C:\VisaPoint\sbperl\perl\bin
Options Selected:
Simulate ShellExecute by inserting any App Paths directories into the PATH environment variable.
Log DllMain calls for process attach and process detach messages.
Log DllMain calls for all other messages, including thread attach and thread detach.
Hook the process to gather more detailed dependency information.
Log LoadLibrary function calls.
Log GetProcAddress function calls.
Log thread information.
Use simple thread numbers instead of actual thread IDs.
Log first chance exceptions.
Log debug output messages.
Use full paths when logging file names.
Log a time stamp with each line of log.
Automatically open and profile child processes.
--------------------------------------------------------------------------------
00:00:00.000: Failure starting the process. %1 is not a valid Win32 application (193).
[1]: http://i.stack.imgur.com/m82n6.png
[2]: http://i.stack.imgur.com/6Yr37.png
Modern versions of Visual Studio, starting with VS2012, use linker settings that marks the executable image compatible with the current generation of Windows. Version 6, started with Vista. XP and Server2003 were in the previous generation, version 5.
You can still build programs that run on XP with VS2013. But you have to make a setting change. Right-click the project, Properties, General. Change the Platform Toolset setting to v120_xp.
There are a few consequences, your program gets built with an old version of the Windows SDK. V7.1, the last one that was still compatible with XP. The C runtime library makes a bunch of operating system calls that are only available in generation 6. It will stumble along without them, affecting relatively minor details related to threading and culture. This is the kind of FUD that ought to remind you that it might not be the best idea to still promise support for such an ancient operating system. Make sure you keep a running version of XP around so you can properly test and repro. And keep in mind that you can't install VS on it anymore so if you do get a support call from an XP user then you tend to get a fairly heavy migraine.
Ok, just forgot to set SUBSYSTEM in Linker options.
Here is a link with explanations:
https://software.intel.com/en-us/articles/linking-applications-using-visual-studio-2012-to-run-on-windows-xp
I have set up the QODBC driver and was able to connect to my QB file and run queries in the VB Demo 32.
I am looking at one of the Sample Files, found here - http://support.flexquarters.com/esupport/index.php?/Default/Knowledgebase/Article/View/506/57/examples-of-how-to-use-qodbc-via-visual-basic
I did what this article said - copied all of the text into a text file, saved it as "Customer.vbs". I created a Customer named "Kim Garland", closed the dialogue box, double clicked on the file. The msgbox never displayed, and this error message came up - "[Microsoft][ODBC Driver Manager] The specified DSN contains an architecture mismatch between the Driver and Application; Code: 80004005; Source: Microsoft OLE DB Provider for ODBC Drivers"
Any idea what is going on here? After looking through the knowledge base, I thought it might have something to do with 64-bit vs 32-bit... but that didn't seem to get me anywhere. I do have Visual Studio installed, but don't quite know enough about VB6 apps to know what I'm doing.
EDIT
By the way, the line that is giving the error is:
oConnection.Open "DSN=Ben Test 2;OLE DB Services=-2"
I originally was using the same exact line that was in the article that I linked to, but that was not working either. I used the c:\windows\syswow64\odbcad32.exe to create a 32-bit DSN called "Ben Test 2". It didn't seem to change anything.
Please take a look at the Microsoft's website where they talk about it.
It is not VB issue, it is 32/64bit issue as you suspect.
http://social.msdn.microsoft.com/Forums/en/sqlgetstarted/thread/702f0d9b-6cb9-49cf-9953-80d059711e60
Since you are using 64-bit system, your VBS will be execute as 64-bit (by default).
QODBC is 32-bit driver, and can work with 32-bit applications. A 64-bit applications cannot talk to a 32 bit Driver and same is with 64bit application to 32 bit Driver.
For 64-bit applications use QRemote (which is a 64-bit Driver driver).
Solution 1
You can try to use QRemote to bridge QODBC and your application. Here is an article about how to use QRemote:
http://www.qodbc.com/qremoteconnect.htm
Solution 2
and there is another solution for you issue. Please call your VBS as 32 bit. Please follow the steps below:
1) Click Windows Start
2) Click Run, in the window, type "%windir%\SysWoW64\cmd.exe"
3) Click OK, then type "cscript vbscriptfile.vbs" in the cmd window
This will make your VBS run in 32-bit mode even thou you are in 64-bit machine
-Regards
Rajendra Dewani
I really hope someone can be of help to me because this problem has me totally stuck and frustrated.
Yesterday I installed a fresh and shiney new Windows 7 x64 onto a development box.
I got VS2008 installed, Tortoise SVN, did a checkout, compiled my currently project, all fine and dandy.
But when I go to run (either F5 in VS or just running the exe from the shell) I get a dialog box that looks like this:
(source: aliparr.net)
So I fiddle around and can't see an obvious problem. I bust out depends.exe, thinking maybe there's a dll missing, and I get this:
(source: aliparr.net)
So I play, finding different versions of gpsvc.dll and ishims.dll and putting them in with the .exe, No luck.
If I do a profile in depends (which follows the Output window of vs), I get this:
..
Loaded "c:\windows\syswow64\ADVAPI32.DLL" at address 0x75F20000 by thread 1. Successfully hooked module.
Loaded "c:\windows\syswow64\LPK.DLL" at address 0x76B20000 by thread 1. Successfully hooked module.
Loaded "c:\windows\syswow64\USP10.DLL" at address 0x761C0000 by thread 1. Successfully hooked module.
Loaded "c:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4926_none_508ed732bcbc0e5a\MSVCR90.DLL" at address 0x70570000 by thread 1. Successfully hooked module.
Loaded "c:\users\ali\desktop\repository\development\trunk\spree\bin\debug\OPENLDAP.DLL" at address 0x001E0000 by thread 1. Successfully hooked module.
Exited "c:\users\ali\desktop\repository\development\trunk\spree\bin\debug\SPREE.EXE" (process 0x5D4) with code -1073741701 (0xC000007B) by thread 1.
So it seems openldap.dll is the last thing to get loaded before it all goes wrong. I require this dll because I use cURL within the application to do a little JSON communicating...
I've tried playing with moving files and trying differing dlls, but honestly I'm acting a little blind here. Can someone please help or point me in the right direction?
It should be noted these dlls and setup work fine in Windows Vista x64 and x86 - is this a Windows 7 thing?
Massive thanks in advance, I might still have some hair left after this is done.
Edit
I've now realised curl.exe dies in exactly the same way with openldap.dll - I guess some windows 7 issue?
Can you/does anyone have a curl without the dependency on openldap? Is there another lightweight C/C++ library out there that'll let me fetch a document over http and do the odd http POST ?
Thanks
I had a very similar problem myself: I was developing a C program (using the MinGW gcc compiler) which used the curl library to do http GET operations. I tested it on Windows XP (32-bit) and Windows 7 (64-bit). My program was working in Windows XP, but in Windows 7 it crashed with the same 0xc000007b error message as the OP got.
I used Dependency Walker on a down-stripped program (with only one call to the curl library:curl_easy_init()). I essentially got the same log as yours, with OPENLDAP.DLL as the last successfully loaded module before the crash.
However, it seems my program crashed upon loading LIBSASL.DLL (which was the next module loaded according to the log from Dependency Walker run on Windows XP).
When looking again in the log from Dependency Walker on Windows 7, LIBSASL.DLL indeed shows up a x64 module. I managed to get my program to run by copying a 32-bit version of the DLL file from another application on my harddisk to my program's directory.
Hopefully this will work for other people having similar problems (also for the OP if the problem still wasn't resolved after these years). If copying a 32-bit version of LIBSADL.DLL to your program's directory doesn't help, another module might cause the crash. Run Dependency Walker on both the 32- and 64-bit systems and look up the module name from the log of the successful run.
I cannot answer your questions completely, I've compiled libcurl on Windows 7 Professional x64 and I don't have any issues. Although I haven't compiled it with OpenLDAP support so I suppose that's where the issue lies.
Regarding the IEShims.dll, Dependency Walker usually reports this as a missing module. Can't remember the exact reason but it was something about loading it dynamically when it's not found in %Path%.
If you however need to debug this and are on Windows 7 then try doing a hard link from %ProgramFiles%\Internet Explorer\IEShims.dll to %windir%.
Although, I see on the screen dump that it sure looks like Spree.exe isn't loaded as a x64 binary, which could very well be it. There's a difference in loading exported functions and piping or exec() a binary, the first mentioned requires that the architecture is the same for both the importer and exporter.
I've also found that mine is trying to load a 64 bit version of LIBSASL.DLL - the one that came with my 64 bit Tortoise distribution. I also only need curl for pulling a bit of JSON data. I think the best solution is going to be to rebuild libcurl from source and exclude the LDAP since I don't need it anyway.
Similar issue here. DLL dependents GPSVC.DLL and MSVCR90.DLL.
I managed to get rid of IESHIMS.dll by setting my environment variables path to C:\Program Files (x86)\Internet Explorer. Surely that shouldn't need to be done!
Is there a fix to this yet?
libsasl requires ieshims.dll, if you don't have sasl support in openldap, then ieshims.dll won't be required.
If you use windows x64 you have to copy your dll to c:/windows/SysWoW64. I have had the same problem when i wanted use pthreads in windows os 8. When I was copied pthreads dll to SysWow64 the program was run sucessfully.