I'm looking to compile some old source code in Visual C++. However, the first of many errors I am receiving is:
vcl.h: No such file or directory
This appears to be in reference to the Visual Component Library, native to Borland compilers it seems. I downloaded the free Borland C++ 5.5 command line compiler, but it doesn't seem to contain a vlc.h in its include directory.
How can I resolve my issue? Many thanks.
This old code must have come from C++Builder. If it actually uses the VCL, you won't be able to build it with any other compiler. If there are other VCL includes like classes.hpp, system.hpp, controls.hpp, etc. it is using the VCL.
If it is a console application and doesn't actually use any VCL classes, then you can probably just remove the include, but the chances are slim.
Borland C++ 5.5 and C++ Builder are two different products.
The VCL components are in the C++ Builder product and can't be compiled with Borland C++ 5.5 which is a pure C/C++ compiler (I think OWL is included there).
So you have to get your hands on C++ Builder to be able to compile it.
Related
As I am compiling my program I am not able to include the header files as shown by the compiler, I've changed the environment variables and configured the bcc32.cfg and Ilink32.cfg file but still It didn't helped.
which version of Borland C++ are you using?
If it is Borland C++ 5.01/5.02, then it is including the OWL headers and libraries - check if they are installed.
If, on the other hand, you are trying to use the free compiler, Borland C++ 5.5, or even C++Builder, then it does not include OWL headers and libraries. Your best bet is to head over to OWLNext (the open-source upgrade for OWL) and get a version of the library that is compatible with your compiler.
I asked this question yesterday about using the Cygwin compiler to produce a C++ DLL that can be used by .NET: Using C++ app in .NET
The solution was to compile the C++ application using Visual C++ rather than Cygwin i.e. I was able to call a C++ function from .NET.
Why am I able to do this in Visual C++ and not Cygwin? The code can be found in my linked question. Here is a screen shot of Dependancy Walker for the Visual C++ DLL in case it helps answer my question:
Name mangling schemes are different in gcc/mingw/cygwin and msvs. You'll have to use the pure-C interface if you want to share DLLs between compilers.
Alternatively, you could use .def files as is described in the bottom answer to this question: How to use libraries compiled with MingW in MSVC?
Thinking of using MinGW as an alternative to VC++ on Windows, but am worried about compatibility issues. I am thinking in terms of behaviour, performance on Windows (any chance a MinGW compiled EXE might act up). Also, in terms of calling the Windows API, third-party DLLs, generatic and using compatible static libraries, and other issues encountered with mixing parts of the same application with the two compilers.
First, MinGW is not a compiler, but an environment, it is bundled with gcc.
If you think of using gcc to compile code and have it call the Windows API, it's okay as it's C; but for C++ DLLs generated by MSVC, you might have a harsh wake-up call.
The main issue is that in C++, each compiler has its own name mangling (or more generally ABI) and its own Standard library. You cannot mix two different ABI or two different Standard Libraries. End of the story.
Clang has a specific MSVC compatibility mode, allowing it to accept code that MSVC accepts and to emit code that is binary compatible with code compiled with MSVC. Indeed, it is even officially supported in Visual Studio.
Obviously, you could also simply do the cross-DLL communication in C to circumvent most issues.
EDIT: Kerrek's clarification.
It is possible to compile a large amount of C++ code developed for VC++ with the MinGW toolchain; however, the ease with which you complete this task depends significantly on how C++-standards-compliant the code is.
If the C++ code utilizes VC++ extensions, such as __uuidof, then you will need to rewrite these portions.
You won't be able to compile ATL & MFC code with MinGW because the ATL & MFC headers utilize a number of VC++ extensions and depend on VC++-specific behaviors:
try-except Statements
__uuidof
throw(...)
Calling a function without forward-declaring it.
__declspec(nothrow)
...
You won't be able to use VC++-generated LIB files, so you can't use MinGW's linker, ld, to link static libraries without recompiling the library code as a MinGW A archive.
You can link with closed-source DLLs; however, you will need to export the symbols of the DLL as a DEF file and use dlltool to make the corresponding A archive (similar to the VC++ LIB file for each DLL).
MinGW's inclusion of the w32api project basically means that code using the Windows C API will compile just fine, although some of the newer functions may not be immediately available. For example, a few months ago I was having trouble compiling code that used some of the "secure" functions (the ones with the _s suffix), but I got around this problem by exporting the symbols of the DLL as a DEF, preparing an up-to-date A archive, and writing forward declarations.
In some cases, you will need to adjust the arguments to the MinGW preprocessor, cpp, to make sure that all header files are properly included and that certain macros are predefined correctly.
What I recommend is just trying it. You will definitely encounter problems, but you can usually find a solution to each by searching on the Internet or asking someone. If for no other reason, you should try it to learn more about C++, differences between compilers, and what standards-compliant code is.
I have an old Borland project which I would like to port to Visual Studio 2008. Is there a way to dump, in a human-readable format, the source file, compile options and dependency information from a .ide file?
I'd like something a bit more comprehensive than the 'Generate Makefile' option.
I think it will be easier just to create a new project in Visual Studio and then add all your source files and libraries into it.
I don't think Visual Studio supports OWL (or any Borland libraries).
If this is a VCL application, options and settings are the least of your concerns, since the VCL API is completely different from MFC.
A lot of the Borland compiler options are actually to provide compatibility with MFC. Other than that there isn't actually much overlap in the compiler options.
I occasionally provide Visual Studio 'solution' versions of my Borland projects to colleagues, and normally is simply a matter of selection the .cpp files in the solution and setting any global defines (these is console mode programs mind you, no GUI).
The greater issue is minor inconsistencies in stream classes,
values.h and deprecated functions that Microsoft has dropped.
That is, _stricmp(), _chdir(), _mkdir() _getcwd() instead of stricmp() chdir() mkdir() getcwd(), etc...
I have generally not found the various Borland generated makefiles very compatible with any other compiler (or even with the Borland compiler for that matter).
I don't know about Borland 5, 6 or latest compilers (latest version I've used is Borland C++ 3.1 back in 1994/95 ...), but if you have the chance to generate a Makefile maybe the best solution is to use that Borland makefile to write a NMAKE compatible makefile by hand, if it's not too large.
Another option is to manually import the header, source files and edit the project (compatibilize source and compilation settings) until the build is successful. I think this can be achieved in a short time.
To what dependencies is your project tied to? VCL? MFC? Just standard libs?
I'll preface this by saying I'm a C# programmer who inherited horrible code with no documentation. I have an unmanaged C++ library wrapped with managed code that worked fine in VS2003 with .Net 1.1 Framework. I'm trying to get it upgraded to at least .Net 2.0.
I have the unmanaged C++ library that was compiled with "MSVC 8.x" (thus equivalent to VS 2005, I assume). I've been trying to migrate everything to VS2008 and still have some issues with this library at runtime.
My question is this: should this library work with VS2008? Or should I be developing in VS2005 if the library was compiled with VC8.x?
Any thoughts would be greatly appreciated. Thanks!
It should work, I expect that you are having issues with your marshalling. It is probably stuff that was declared incorrectly for PInvoking that managed to work in .NET 1.1 but not in later versions.
You don't say what sort of problems you are having at run time, nor do you state how you access your library. For example, do you compile your library along with your project? If so, can you turn on unmanaged debugging in your C# project and step into the code you are having trouble with? How are you calling the unmanaged code? Is it through PInvoke, or do you have managed C++ wrappers?
In my experience, the best solution for calling out to a legacy unmanaged library is to add a managed wrapper library for your legacy library written in managed C++. This way you present a managed interface for your library for all .NET languages to consume and you don't have to worry about getting your PInvoke signatures correct.
Your project should look something like this.
C# Application -> Manage C++ Wrapper DLL -> Legacy DLL
It can depend what else the lib relies on. For example, if you are using the STL across the library interfaces then it would be a bad idea to have the library compiled with a different version to the client. However, if the library presents a simple C style function interface then you shouldn't have problems.
If you have the source code for the library then I would recommend trying to port it to VS2008. In general it is much less hassle in the long run to have everything in the same development environment.
How are you wrapping the unmanaged lib ... presumably using managed extensions for C++ if it dates back to VS2003. This is now deprecated and has been replaced with C++/CLI as of VS2005. Whilst the newer compilers support a /clr:oldSyntax switch to still compile the old code there are definitely issues with it. We have old code that will not compile on VS2005(8) using this switch.
--Rob Prouse:
The wrapper uses managed C++, no PInvoke. The wrapper is compiled into a DLL that is then used by another application (as you illustrated).
The legacy code produces graphics objects. When I try to get the handle to an image, I get a null exception instead. The debugger doesn't let me get farther into the code to figure out why. Everything else seems to run ok - the other data objects needed to create the image exist and appear to be correct. (Sorry, I know that is still a pretty vague description.)
--Rob Walker:
I unfortunately do not have the source code.
Not sure about "using the STL across the library interfaces". Does graphics fall under that category?
I was able to get my application to run with using the /clr:oldSyntax switch, but that's where I get the null handles to images. I tried to put in all the modifications so that it would compile with /clr, but then I kept getting link errors that I couldn't resolve. (The linker kept complaining about not being able to find files even though those files were in the folder where it was looking.)