I'm trying to import a third-party .NET type library (COM server DLL) using tlibimp.exe (version 11.0). This basically works fine, but the results differ when I run it on different computers, one running Windows XP, the other Windows 7. What's worse, the code generated on the Win7 machine doesn't compile.
Both machines have:
Borland C++ (RAD Studio) 2007
tlibimp.exe version 11.0
the same .NET framework versions installed (as far as I can tell,
Borland 2007 uses .NET v2)
bcc32.exe version 5.93
The compiler fails in the OCX.h with:
Parameter mismatch in write access specifier of property Font
The relevant line of code on the XP machine (which compiles ok) is:
__property Graphics::TFont * Font={ read=GetTFontProp, write=_SetTFontProp, stored=false, index=-512 };
The same line on the Win7 machine (which fails) is:
__property IFontDisp* Font={ read=get_Font, write=set_Font, stored=false };
Now I'm not really sure where this difference comes from. Any ideas?
cheers
Hendrik
This may or may not help but I had a similar issue trying to import two type libraries into delphi, from c sharp assemblies.
One type library (A) inherited from TOLeServer, the other (B) from TOleControl and I couldn't see why, as both assemblies which generated the type libraries were virtually identical.
The issue turned out to be that B had been registered with regasm and A hadn't. Registering A and re-generating the type library solved the issue.
Related
I would like to port a DLL that was compiled for Windows Embedded Compact 7 into a Windows CE 5.0 / 6.0 environment. I'm fairly certain the target assembly language is compatible but from my experimentation it appears that there is something fundamentally different about the DLL's in WEC 7 than in WCE 5. Does anyone know what specifically is different about how the DLL's are compiled in WEC 7 than in WCE 5/6?
I'm assuming the source code for this dll is not available, which could make it difficult to use on earlier versions of Windows CE.
Newer versions of CE have added security features to the CRT library, so if the dll depends on any of those, it would not run on earlier versions.
Besides the target architecture, the OS images would also have to be built using a similar set of OS/SYSGEN features, or, again, the dll might fail to load or run if those dependencies are not satisfied.
The dll could be attempting to dynamically load other dll's, or could be relying on OS behaviour specific to CE 7.0.
In short, a potentially very difficult task without the source code.
A way to get started would be to use the Microsoft dumpbin tool with the /imports option to produce a list of dll's and entrypoints that the dll depends on. Similarly, use dumpbin /exports on the earlier builds of Windows CE that you want to use the dll on, to see what entrypoints are available, and work from there.
Another approach, in case you have access to Platform Builder and are able to generate OS images yourself, would be to use the kernel debugger to examine what happens when the dll is loaded.
I'm stuck in a deployment issue with my Qt 5.4.0 application.
After two days of research, my app really doesn't want to execute on Windows XP !
I have created my deployment folder with windeployqt provided by my Qt installation. When I double-click on *.exe, I have always :
The procedure entry point vsprintf_s could not be located in the dynamic link library msvcrt.dll.
Dependency walker hasn't really helped me and I don't know what I can try now.
Note :
SDK : Qt 5.4.0 (MSVC 2010, 32 Bits)
IDE : QT Creator 3.3.0
Compiler : MinGW 4.9.1 32 Bits
Need to run on : Windows XP Pro SP2 32 Bits
App works like a charm on Windows 7 with same configuration (IDE, compiler, etc.)
While Guilhem G. is correct in the broader sense, it doesn't mean you actually called that function yourself (speaking now to a theoretically other person running into this issue like me, heh). I believe it's a bug with MinGW's XP support; I've seen bug reports of similar issues, including nearly the exact same issue in a much earlier version of Qt that was then fixed. I haven't seen this particular incarnation, which I actually ran into myself. I suppose I should probably submit a bug report!
Anyways, I've fixed it without changing any of the code I've written myself. What I had to do to fix it was twofold:
Switch over to using the msvc2010 compiler, since that set of C++ libraries rather unsurprisingly runs fine on Windows XP (AFAIK they still haven't dropped XP support with the latest version).
Switch over to Qt 5.5 (I'll explain why at the end).
For the compiler, you'll need then either Microsoft Visual Studio 2010 (hence the name), or the older Windows SDK that ships with it; the "Microsoft Windows Software Development Kit for Windows Server 2008 and .NET Framework 3.5" release should do the trick for you if you don't have a Visual Studio 2010 license.
Once one of those is installed, I'd encourage you to install Qt 5.5 as compiled by MSVC2010. You can either start a fresh installer or use the Qt Maintenance Tool which should already be installed.
Once that kit is installed, within your project (selecting "Projects" from the left-side menu) you should be able to go "Add Kit" and select Qt 5.5 msvc2010 32-bit, and if you now recompile and redeploy your application, it should run fine on XP.
Now, why did I insist on you upgrading to Qt 5.5? Well, there's some underlying issues with choosing a working OpenGL renderer on each version of Windows, and Qt 5.5 simplifies that a lot by having it fall back on OpenGL or ANGLE depending on what capabilities are actually detected, plus IIRC some other related fixes. So certainly if you're deploying a QML / Qt Quick 2.0 app across multiple Windows versions like I'm doing, it's worth upgrading to Qt 5.5.
The error was I called "sprintf_s" somewhere in my code (ok for recent windows on my dev machine but not for XP).
If you have the same problem when you search in your code don't use exactly the name of the function in the error message but an expression like *_s.
You probably call a secure API function somewhere !
Are the dynamic runtime libraries for Visual C++ (more specifically 2008) part of the Windows OS nowadays? I noticed that at least on Windows 8 you no longer need to ship these with your application or have the user install the redistributable package from Microsoft.
Is this true? If so, for what Windows versions and for what versions of Visual C++ does this apply to?
No, they've never been part of the Windows distribution. Deploying them yourself is a hard requirement.
It certainly may seem that they are. Starting with msvcrt.dll in the system32 directory, it has the same name as the C++ runtime dll in Visual Studio versions prior to VS2002 (VS6 and earlier). It is however a private copy of the CRT that is used by Windows executables. And protected by the File System Protection feature in Windows, preventing old installers from destroying the operating system.
It certainly often works by accident. There are many programs that need the Microsoft CRT so it isn't unlikely that the user has run an installer before that got the DLLs installed. Clearly you cannot depend on that common accident.
Similarly for Windows 8, the pre-installed Microsoft.VCLibs.110 package matches the package you need for a Store app written in C++. But that's for the same reason as above, Microsoft Store programs were also built with VS2012, just like yours. What's going to happen in the upcoming VS2013 is a bit muddy right now, we'll know soon.
In my opinion, the answer would be both: Yes and No.
Yes: More recent Windows OS are generally shipped with VC runtimes pre-installed (along with more recent versions of the .NET framework). It is because Microsoft uses the latest/newer Visual Studio before they release VS to the public (or even to MSDN subscribers). If not this way, whenever you install some application (legacy application or some downloaded application), the setup would anyway install the required VC++ runtime. Another way is through automatic updates.
No: In case where none of the above mentioned rules applies. Or, when the VC runtime shipped with a new service pack or a patch. You might have developed your application with newer patch/SP, and that must be installed (as Side-by-Side, of course).
I have been working on a VS 2005 project and have successfully generated an exe file which works fine on my system. However when I tried to run it on some other pc it didnt run. It throws up the error message "the system cannot run the specified program". Can someone tell me how to make my code immune to such message i.e. system independent?
platform used: Windows XP, VS 2005
the extension of all my code files is cpp but I know only c and thats what I wrote inside them.
I have seen before exe created on Windows Sp1 not working on SP2 and problems such as that.
This should help you perhaps.
I've seen this when you run on a different version of Windows that doesn't have some DLL you depend on. The easiest thing to do is statically link the C runtime (that's the usual culprit) and use depends.exe to see if there are any others.
You will almost certainly need to create an installer that installs your executable and any non-OS-included DLL's it relies upon. It is not always possible or desirable to statically link all dependencies. You can in many cases simply copy the DLL's to the same folder as the executable.
By default, even the C/C++ standard library is provided by a DLL. While the MSVCRT.DLL used by VC++ 6 is included with the OS since later editions Win95, the MSVCRT required by VS2005 is not included with XP installations (other versions I do not know). The run-time support is included VC redistributes package. You may need to arrange for your installer to include that installation, or you could be more selective is you know your dependencies.
Some Win32 API calls if you are using them are dependent on the OS version (check the documentation), but if you built and rin it on XP, it should normally work of any subsequent version of Windows. You need to define various API version macros if you want to extend support to earlier versions of Windows (which seems unlikley).
You might need to install the VS 2005 redistributables on the other machines, depending on how you have compiled your program.
What's in MS Visual C++ runtime library? I mean, I googled it, and I always found things like help, app xxxx gives me MS Visual C++ runtime library error, with no explanation.
I thought that Windows C runtime libraries come with Windows? Not with VC++? Thanks.
EDIT:
First, thanks for answers. I thing now I have bad idea of runtime libraries in windows. I mean, the first part, that Windows internally has its win32 API and so, that's OK, I knew it. Also, that Win32API are from kernel and user parts.
But I always thought that functions like GDI are accessed as DLL (which I still believe they are). But I thought even functions like printf and so are in some windows file.
So, am I right, when I know get it that "simple" functions like printf need to be linked directly and than use only Kernel part of OS directly, and more sophisticated Windows API functions are linked as dlls, therefore ARE NOT distributed with compiler but with OS? And they subsequently access Kernel?
I mean, lets say GDI, I tell it to draw picture, it makes all the hard work in user mode and than call kernel function which puts it all in framebuffer?
And last thought, why is this even solved this way? I mean, if VC++ runtime is just layer between C and WinAPI, why cant VC++ call directly WinAPI?
This is an oversimplification, but it will give you the gist. The MSVCRT is a set of DLLs that implements parts of the C++ language. Functions like printf, memcpy and the like are implemented in these DLLs.
Every program that is compiled with a particular compiler and dynamically linked to the C++ runtimes must somehow have the correct version of the CRT binaries on the target machine. As a result, applications that ship to end users are often (usually?) also shipped with a package of these DLLs. This package is called a "redistributable" (or "redist"), and there is a different one for every combination of exact compiler version and target platform. For example, there are seperate and distinct redists for each of the following:
MSVC 10, 64-bit windows
MSVC 10, 32-bit windows
MSVC9, 64-bit windows
MSVC9 SP1, 64-bit windows
et cetera.
Yes, Windows usually "comes with" some version of the CRT. However, it comes with the version(s) that it needs in order to run the apps that shipped with Windows. If Windows and all it's apps were compiled in MSVC8 SP2 and your app is compiled in MSVC10, the CRT you require won't be present on the box simply because it's running Windows.
This is why its common practice to ship apps along with redists.
EDIT:
By way of Houdini like magic, I predict your next question will be "where do I get the redists?"
The answer is, from MicroSoft. Try a google search for "msvc 9 x64 redist" and you will find:
http://www.microsoft.com/downloads/en/details.aspx?familyid=bd2a6171-e2d6-4230-b809-9a8d7548c1b6&displaylang=en
A brief answer would be that the MSVS C/C++ runtime implements functions like malloc/free, stdio, iostream and some c++-stuff like dynamic_cast and exception handling. These differs between versions of visual studio, so there are different runtimes for different versions.
Windows ship mostly with a C API (the Win32 API) which rather different from the C/C++ standard library. The MSVS C/C++ runtime calls into this API to allocate memory, etc etc.
(I suppose some of the applications included with Windows are written with MSVS and in C++, so they do include the MSVS runtime for that version.)
Also, the runtime changes as new Visual Studio versions are released. A Windows release lasts much longer than that.
They are the libraries that implement the C and C++ standard library functions. Standard functions such as printf are implemented in these libraries.
The core Windows libraries only provide interfaces to system calls, i.e. the Win32 API, since that is all you need to build a full-featured Windows application. The VC++ libraries are mostly wrappers around this API, and are analogous to the glibc library on Linux.
As an example, malloc from the C library might in turn use the VirtualAlloc API to allocate memory.
Programs compiled with Visual C++ require a "runtime" - this is a bit of code that handles application startup/shutdown, memory allocation/deallocation, support for reading and writing files, etc.
This is not part of the operating system, and not part of the final application - Because all C++ applications can share it, by default the runtime is a separate installation.
In addition, each version of Visual C++ has its own runtime installer, because with each version there are slight differences and improvements in the way all this works. There are also different verisons of the runtime for different platforms (e.g. x86 and x64)
Hence, there are a number of "Visual Studio XXXX runtime installer (YYY)" downloads available from Microsoft, where the XXXX is the visual studio version (2005, 2008, 2010, etc), and YYY is usually "x86" or "x64".
Most applications that need the runtime will automatically install it if needed, so generally end-users are not very aware of these redistributables.