Currently we are migrating our applications developed in Borland C++ 5.02 on Windows XP to Windows 7. While executing the application on Windows 7, I am getting the error message
VBX library init Failure.
While trying to find the cause on the Internet, I was able to identify the error was because of BIVBX31N.EXE and BIVBX31N.dll.
How can I port a Borland C++ 5.02 application to Windows 7, solving the BIVBX31N.EXE and BIVBX31N.dll related issues?
If you're stuck using this product, here is what I recommend.
Simple answer: Don't use the IDE, but continue to use the command line tools:
bcc32.exe (the compiler) still works fine in Windows 8.
ilink32.exe (the linker) still works fine as well.
Both can be found in the bin sub-folder.
You can get some of the command line information by opening the IDE (project) file in Notepad or a hex editor (it isn't a text file, but you can read most stuff in Notepad). Or if you do have access to Windows XP you can open it there just to copy the settings for usage in the command-line tools.
Just use some other IDE or editor like Notepad++ to edit your source files. You can use an older version of Visual C++ to edit the RC files, or Notepad or other tools.
If you want really want to make it slick, set up your IDE to run an "external tool" when you click a toolbar button, to have it run your command-line tools to compile + link (and optionally run the EXE file). You can probably find a debugger tool as well, but I haven't needed that yet, so haven't checked.
My best recommendation is to start the process of porting your code to Visual Studio.
You can use a library like OWLNext if you've used the OWL library in Borland.
The other alternative is is to use Windows Virtual PC (or other such virtual machine) to run Borland in an integrated Windows XP mode. See an example here.
This can be probable answer ???
You have to download configured Borland Compiler from http://www.4shared.com/get/Gs41_5yA/borland_for_graphics.html or http://dwij.co.in/graphics-c-programming-for-windows-7-borland-compiler/.
Put your Borland’s ‘bin’ folder into Environmental Variables.
Now go inside folder ‘bin’ & edit file bcc32.cfg as per your folder structure. This file contains settings of headers & libraries.
-I"D:\Borland\include;"
-L"D:\Borland\lib;D:\Borland\Lib\PSDK"
Now create any C/C++ Program say myprogram.cpp
Use following command to compile this bunch of code:
F:\>bcc32 myprogram.cpp
Congratulations !!!.
Related
I have installed Qt-5.7 on windows 8 because I couldn't build my released .exe from Linux (my favorite) in order to be used on Windows OS even after searching a lot on internet (Where there have to be cross-compilation...). After the installation, I just want to make sure that I can build/run a first application (one of the examples provided by default by Qt-creator "filesystembrows") and I have follow the official guide in order to build Qt as shared libraries, but the issue is that when I type the first command line I get: 'nmake' is not recognized as an internal or external command' Also it still show the same message even though a update the variable environment of the system with C:\Qt\Qt5.7.0\5.7\mingw53_32\bin which one is the default path set-up when installing Qt on windows. Any help just to make a stand alone .exe for Windows (as shared libraries ) please
Why not build your project by using qtcreator ?
Did you test your build environnement by making a test application with qtcreator ?
P.S.: If you want, I can explain how to build application using Visual Studio as a compiler and QtCreator as an IDE.
nmake is a build tool provided with Visual Studio and with Windows SDK. You don't have it, apparently.
It seems you're using a mingw build of Qt; it comes with a bundled copy of mingw. There, the build tool is simply called make.
Based on http://arcsynthesis.org/gltut/Building%20the%20Tutorials.html - the book Im reading to learn openGL, I need to build my file projects with premake4. The book says:
"The SDK his library uses Premake to generate its build files. So, with premake4.exe in your path, go to the glsdk directory. Type premake4 plat, where plat is the name of the platform of choice. For Visual Studio 2008, this would be “vs2008”; for VS2010, this would be “vs2010.” This will generate Visual Studio projects and solution files for that particular version."
So, I've put the premake4.exe file inside but the problem is: When I execute it, one black command window shows up for a few ms, then fades and nothing happens.
I made one research on google about how to work with premake4 but I couldnt find nothing useful, even here on stack or you tube. Anyway, This seems weard since premake4 is really known, then I ask: Does anyone know what Im missing or could point me to somewhere which I can understand how to build my openGL "sdk" files?
Im using premake 4.3 with Windows 8.
Edit: I just found someone with the same problem - but the solution isnt really applying for me: Can't get premake working - gltut demos
Edit 2: Found once again someone with the same problem, but this no solution on the topic and also the OS is different from mine.. http://industriousone.com/topic/terminal-logout-when-running-premake4exe
As it says in the documentation you quoted:
Type premake4 plat, where plat is the name of the platform of choice. For Visual Studio 2008, this would be “vs2008”; for VS2010, this would be “vs2010.”
Just running it with no arguments (which is what double-clicking on it does) is not sufficient. You need to open a command prompt, cd to the directory the project is in, and then run premake4 vs2008 (replacing vs2008 with the name of the platform you're targeting).
The most recent version of Visual Studio supported by Premake is 2010, so for later versions, you'll still have to use premake vs2010 - later versions of VS should still be able to load the project.
ToxicFrog's answer was extremely helpful, but just to be a little more blunt and clear about the answer for someone who might not how to use the command prompt very well.
Place 'premake4.exe' inside your 'glsdk directory (file).
In Windows, hold down the 'Shift' key and right-click the glsdk directory.
Select "Open Command window here" from the drop-down box .
Type premake4 vs2010 (or whichever platform you are using. For example, if you are using Visual Studio 2013, use vs2013 for your platform.).
Note: According to ToxicFrog and Victor Oliveira the platform vs2010 is the highest it will support . However, I recently tried it with vs2012 and it worked just fine).
I am a teacher's assistant for a C programming class, and the instructor uses Dev C++ as the compiler for the class. Personally I would use a different one, but the choice is not mine here. Recently I installed the Windows 8 Professional 64 bit that is available on Dreamspark though my university, so I can start with some metro app development for some contests. Unfortunately, Dev C++ has stopped compiling. It previously worked fine with Windows 7 64 bit.
I get an error when compiling that reports back:
Compiler: Default compiler
Executing gcc.exe...
gcc.exe "C:\Users\James\Documents\Homework\TA_CPRE_185\counter.c" -o "C:\Users\James\Documents\Homework\TA_CPRE_185\counter.exe" -I"C:\Dev-Cpp\include" -L"C:\Dev-Cpp\lib"
gcc.exe: Internal error: Aborted (program collect2)
Please submit a full bug report.
See <URL:http://www.mingw.org/bugs.shtml> for instructions.
Execution terminated
Compilation successful
It says the compilation is successful but it is not, so no executable is made. I want to know if anyone has any ideas of what might get Dev C++ to work on this version of Windows, so I don't have to run Dev C++ in a virtual machine? I need it working, so I can do class demonstrations.
Please tell your teacher to update Dev-C++ instead:
http://sourceforge.net/projects/orwelldevcpp/?source=directory
This one ships with a working MinGW 4.7 or a TDM-GCC 4.6.1 (x64) compiler, fixes endless amounts of bugs, and is also portable.
I believe that Dev-C++ comes with a very old version of MinGW (3.4.x if I'm not mistaken). MinGW versions before 4.2.2 will have problems compiling programs on Windows Vista and later unless they are on the PATH.
So you can either update your version of MinGW (as you mentioned in a comment that you have already done), or you can add the MinGW\bin directory to the system path.
If you cannot change your MINGW version, you can try to rename the following file :
MinGW\libexec\gcc\mingw32\3.4.2\collect2.exe to collect2.exe.old
(this solution worked after a migration from W7 to W10).
I received the same error, but was able to get around it by doing the following.
Remove application using add/remove programs
Disable user access controls
Reboot
Download Dev-Cpp 5.4.0 TDM-GCC x64 4.7.1 Setup.exe
Right-click on downloaded file and change to "win7 compatability mode" for all users and select "run as administrator" and click "OK".
Right-click downloaded file and choose "run as an administrator" (note: this shouldn't be necessary, but it's windows so cover your bases)
Choose all the defaults, but on the last screen, deselect "run Dev C++ now" and then select "finish"
Open windows explorer and browse to the install directory C:\Program Files (x86)\Dev-Cpp and locate "devcpp.exe"; right click and choose "win7 compatability mode" for all users and select "run as administrator" and click "OK" (again, this is probably not necessary, but it doesn't hurt anything either).
Double-click the application and pin to your taskbar for ease of use.
Open a new project and test it out, it should work w/o issue.
I used MinGW Installation Manager to download the last version of C Compiler (5.3.0-3 at this moment) and I repliced the files in the folder of Dev-Cpp. Now, its working perfectly in my Windows 10.
I am using Qt 4.6.3 with MinGW on Windows to build Qt apps and now need to add a COM interface to my application. I enabled ActiveQt but was getting post-link errors because I was missing a copy of the MIDL compiler. I downloaded a copy of the latest MS Windows SDK, which includes MIDL, but now MIDL complains it cannot find cl.exe. The only conclusion I can draw is that you can only build ActiveQt applications using the MS compiler, which I would rather avoid. Is a way to get this working with MinGW or am I out of luck?
Using the MS compiler and tools seems to be the only reliable way to get this working.
Well, you can build ActiveQt with MinGW, but using a bunch of COM stuff on top of that may not be possible, because it may or may not be present in MinGW. Some thoughts:
Using any MS SDK tools with MinGW won't work (exception is mingw.org + DXSDK which should work most of the time).
Are you sure you are linking all necessary libraries when compiling? I can't help more if you don't show the exact error messages.
The mingw-w32/w64 project tries to provide a completer "Windows SDK for GCC"; it may contain the libraries/files you are looking for. They provide a x64 and x86 compiler, and pretty good DX support. I have no experience with their COM stuff, but I believe it would be a bit more complete than mingw.org's. You can always contact the developers on the forums or mailing list, they are very helpful.
You could try the Wine implementation of midl, widl. See the Wine wiki page regarding building on Windows.
If you want to give it a quick run, get wine-prgs-0.9.14-mingw.zip and see how it works.
I agree with Rob's second post: it's a very bad thing using mingw for construction of ActiveX objects. Mingw has some bugs regarding ActiveX: https://bugzilla.mozilla.org/show_bug.cgi?id=203299 and also: https://qt.gitorious.org/qt/qt/merge_requests/2710. I kill the whole day to discover it. Use Qt for MSVS instead and all will be ok. ;)
I've solved this problem next way:
Got QtCreator, Msys2 and VS2015 Community installed.
Launching Qt Creator with batch script:
#echo off
call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86 8.1
setlocal
set MSYSTEM=MINGW32
set MSYS2_PATH_TYPE=inherit
start "" "C:\msys64\usr\bin\mintty" -i /msys2.ico -e /usr/bin/bash --login -c "/c/Qt/Tools/QtCreator/bin/qtcreator.exe"
exit /b 0
I am launching QtCreator out of Msys2 envioronment because it provides standart Unix tools needed to build 3rd party in my project.
So in theory this is not mandatory to have Msys2 for you.
Please note: do not use WinSDK 10.0 (or above) because it does not have midl.exe in PATH variable.
Doing this way will create PATH environment variable with Qt Creator on top priority (so you will use gcc from Qt installation), Msys2 next (so you can use standard Unix tools) and MSVC and WinSDK 8.1 at last place (so while building you will find midl compiler).
Right now I succeed building dll and passed it to midl form WinSDK, but as for now I am stil trying to register it in system.
I did actually succeed in creating and invoking in-process and out-of-process servers using QT+mingw-w64 today, so here is a write-up.
This was based on the instructions at https://doc.qt.io/qt-5/activeqt-server.html , although they were written for the Windows-native build of QT and using MSVC, so some changes were needed .
Tools installed
MSYS2 updated to latest version (as of 29 Oct 2020).
qtcreator and mingw64/mingw-w64 (64-bit target), installed via MSYS2.
Package mingw64/mingw-w64-x86_64-qt5-static installed (this causes the "Qt5 Static" kits in qtcreator to be enabled).
Visual Studio 2019 Community edition (this provides midl.exe).
https://github.com/lucasg/Dependencies - lucasg Dependencies walker. (Not essential but good for checking your static build worked).
Creating the COM DLL (without a type library yet)
These steps assume prior familiarity with QtCreator+qmake for "normal" executables.
Copy the example project from qtactiveqt/examples/activeqt/simple . I actually couldn't find this anywhere in the MSYS2 installation of QT so I cloned the QT source directly and picked out the example.
In the Kit Management in QtCreator, I selected the qt5-static 64-bit kit. This is to avoid any issues due to DLLs not being found at runtime.
This example is an out-of-process server, so to change to in-process, add to the simple.pro file the lines: TEMPLATE=lib and CONFIG += dll.
Enable static linking in GCC as I describe in this answer: https://stackoverflow.com/a/64583309/1505939
Build the project . This will give a warning that it couldn't read simple_res.o but that can be ignored. This should successfully create the output file simpleax.dll, but then there are some error messages to do with widl not found -- which we will address in the next section.
Writing the type library to the DLL
Other Windows tools (e.g. regsvr32, and any other client who wants to use the DLL) expects to be able to read the type library out of the DLL.
The DLL which was created in the previous steps does not contain a type library. I think this is because none of our toolchain tools know how to create a type library. Instead, we have to use midl.exe supplied with VS Community to generate the type library.
In QtCreator there is a post-build script that's supposed to invoke midl . However that doesn't work in the MSYS2 flavour of QtCreator. It seems it was only written for the native flavour using MSVC as the kit.
So we have to manually do the post-processing, which involves:
In the MSYS2 shell, go to the directory of simpleax.dll.
Run this command: idc simpleax.dll -idl simpleax.idl -version 1.0
Start the "x64 Native Tools Command Prompt" start menu item that came with the VS Community installation.
Navigate to the directory of simpleax.dll
Run the command: midl simpleax.idl /nologo /tlb simpleax.tlb. (Note - just adding midl to the MSYS2 path doesn't work as it can't then find a bunch of other dependencies).
Back in the MSYS2 shell, go idc simpleax.dll -tlb simpleax.tlb.
Note that you only need to do all this if the type library changes (i.e. you make a change to the class definition of your exported COM objects). If just rebuilding the project then only the last step would be needed, which you probably can add as a manual build step in the QtCreator config.
Registration and run test
Congratulations! You should now be able to open an elevated command prompt and run regsvr32 simpleax.dll and have it succeed. (If it doesn't work, run dependencies -chain simpleax.tlb and then at the end it will list any DLL dependencies).
After registration succeeded, I was able to invoke the COM object using VS Community (New C++ Console project, and #import "D:\path\to\simpleax.dll", build, and then it creates a .tlh C++ header file that contains wrappers for the DLL).
Cleaning up the type library
The type library that was created contains a whole bunch of annoying QT guff. I discovered that if you want to create a COM object that's not an ActiveX control, you can use QObject instead of QWidget as the base class. Then you don't get most of the guff that is to do with GUI elements.
Also, taking out the Q_CLASSINFO("EventsID",... line from the COM object's class definition means you don't get all the source/sink guff in the type library (for some reason it decides it has to put all the QT event sinking stuff in there).
After doing that, there is only about one screenful of guff left, including the definition of QPoint and so on, that I would consider to be a bug on the part of QT (since the stuff is not needed). I found I could just remove that from the .idl file prior to invoking midl, and hey presto we have a clean interface that can be published.
The out-of-process server
This also worked for me, identical to the above steps but without step 3 (i.e. leave it as app instead of lib). The procedure for attaching the type library via midl is the same.
Registering the type library via testobject.exe -regserver gives no message to tell you if it succeeded or failed, so another way is to use idc -regserver testobject.exe from elevated MSYS2 prompt, then it will give you a failure message.
I was able to invoke the object via VS Community just the same as for the in-process server.
Further issues still to work out
Figure out how to do this in CMake.
Automate the post-build type library procedure.
Get non-static linking working.
Automate removal of the type library guff (or report a bug)
I installed XP on a virtual machine, updated it to SP3 and then tested a small program compiled with Visual C++ 2008 on my real computer - however it didn't start but outputted only an error saying that a problem had been detected and that a reinstall of the application (mine is 10KB in size and doesn't even have an installation) could fix the problem.
What is required to run programs compiled with MSVC 9?
Can I just include some dlls for it to work everywhere?
Either link statially against the runtime library (select multithreaded instead of multithreaded-dll) or follow tommieb75's advice and install the MSVC9 runtime redistributable (copying to system32 or to the application's folder works as well, but is not the way to go, afaik). For small applications with no need for an installer, I'd prefer the first option. Deploying runtime installers is annoying.
You could be missing the MCVC9 runtime library, try copying that over to the Windows System32 folder...
It may depend against which DLLs your project is linked. Inspect the assemblies manifest and check if those DLLs are installed on your VM.
What does your program contains? Dependencies on dynamic C/C++ runtime? Then you need to either include the C++ redistributable runtime DLLs in your app, or change the program to use the static C++ runtime. Similarly, do you use ATL? MFC? Custom 3rd party libraries? They all add dependencies to your executable and Win32 will refuse to load your application.
One easy step is to check with Dependency Walker what dependencies your application has.
It could be a dll you application links against. The depends tool is a must have in every programmers toolbox for debugging dll dependency issues.
If you have the commercial rather than express msvc edition, what you really should do is copy the msvcmon redist components to your VM, run the remote debug monitor there, and attach to it from your desktop dev environment. This page explains the basic principal. Because it sounds like your app is causing an exception on XP.
If you can't remote debug and if dependency checker does not indicate a dll issue, then you could look in the systems application event log to see if there is any more information there. Or try install Dr Watson as a post mortem debugger. Open a command prompt and enter
drwtsn32 -i
to install Dr Watson as the post mortem debugger, and
drwtsn32
to get a config screen allowing you to browse for the location of crash dumps. You can load crash dump files directly with Dev Studio 2005 and later. (I don't think Dr Watson ships with Vista and Windows 7 anymore).