I'm trying to resurrect a 1990's application that was built with Borland Turbo C++ (version unknown, maybe 3.0, maybe 4.5?), and apparently targeted for Windows 3.1.
The project contains a single .c file, and a single .res file. Rather than try to locate the ancient compiler, I've tweaked the C source into compatibility with MinGW gcc ver 4.5.2, thinking I could rebuild it for win32. Unfortunately, this is one of those windows programs where the main window is a dialog box, and the dialog specifications are embedded in the .res file. Of course modern MinGW gcc doesn't understand the old .res format.
So is there a way to recover an .rc file from a 1990's vintage Borland .res file? I know there will be other problems compiling old 16 bit windows code like this, but I can deal with that later (it's only 2K loc), right now the stumbling block is this resource file.
somewhat later ..
I have found 'Turbo C 3.1', but this thing is a trip. It can actually compile for 16-bit windows, the resulting executables requiring an NTVDM to run under XP, but the concept is proved. Tried it on a simple windows hello-world, and it worked.
Anyway, the problem is still the .res file! There was a project (.prj) file with the aforementioned material, but it apparently calls out the .rc source file. I know with gcc, I can link an already compiled resource file into an executable, but heck if I can figure out the strange command line for 'bcc' to do it. To get an idea how odd it is, bcc uses -W as a flag to 'create windows application'. It must be possible. Anybody remember?
(fwiw- i think there may be better tags for this. feel free to re-tag.)
Open Watcom C/C++'s Resource Editor (wre.exe) seems to be able to open 16-bit .res files. If the latest version doesn't work fully (which isn't totally unexpected as very few people work with 16-bit resource files), try earlier ones.
Related
Please don't answer this as a "How do I cross-compile on Linux for Windows" question, I solved that part. I need some specific instruction on configuring Netbeans. Thank you.
I'm developing a set of C functions that I want to distribute as a .dll on Windows, and a .so on Linux. (This is going to be used from java as a JNI library, but that's irrelevant to the question).
Development environment is Netbeans 8.2.
I have gcc and mingw installed, and compiling my source code for both targets works.
However, I want to create NetBeans configurations "Linux-Release" and "Windows-Release", with Linux-Release using gcc to create the .so file, and Windows-Release using x86_64-w64-mingw32-gcc. So I created a Mingw tools collection that refers to the mingw versions of the C compiler:
In my project properties, I created a Windows_Debug configuration, and told it to use the Mingw tool collection:
I can use this configuration to get a working Dll. However, the output file will be put into the dist/Windows_Debug/Mingw-Linux directory (not dist/Windows_Debug/Mingw-Windows as I'd like), and it's put there with a .so extension, not .dll. I can load this file on Windows when I rename it to .dll, but this will horribly confuse anyone I want to collaborate with.
Naively messing with the CND_DLIB_EXT macro in the generated Makefiles doesn't help at all, they just get overwritten.
I guess I have to either tell Netbeans that the Mingw Tool Collection compiles to Windows, or that the Windows_* configurations compile to Windows, so Netbeans sets the correct values for CND_* and the default output Macro
${CND_DISTDIR}/${CND_CONF}/${CND_PLATFORM}/libSMAQSJni.${CND_DLIB_EXT}
in the linker part of Project Properties works again. (Of course, as a workaround, I could just remove the variables from the macro, and replace them with appropriate constants, but I want to do this "right". I haven't found a way to tell Netbeans "this compiles to Windows" anywhere though, neither in the GUI nor in any of the config files. So, how do I do this?
It seems I've got a real problem here due to my lack of any knowledge about Linux systems:
I have downloaded some open source code, which
is written in C
uses complex.h, so I assume it is ANSI C99
comes with makefiles designed for compilation under Linux systems
provides interfaces to IDL, MATLAB, Python etc.
I am indeed familiar about compiling C/MEX files under Windows-based MATLAB environments, but in this case I don't even know where to start. The project is distributed in several folders and consists of dozens of source and header files. And, to begin with, the Visual Studio 2010 compiler I've used to compile MEX files until now does not comply with the C99 standard, i.e. it does not recognize the complex.h header.
Any help towards getting this project compiled would be highly appreciated. In particular, I have the following questions:
1) Is there any possibility to automatically extract compilation information from the MEX files and transfer it to Windows reality?
2) Is there any free compiler being able to compile C99 stuff, which is also easy to embed in MATLAB?
I have done this (moved in-house legacy code inc. mex files to Win64). I can't recommend the experience.
You will have to recompile, no way around it.
Supported compilers for mex depend on your MATLAB version
This File Exchange entry for using Pelles C may be a starting point (if it works with your version of MATLAB).
I am guessing that there is a main makefile which then works through the makefiles in the subdirectories - have a read through the instructions for compiling under Linux, it will give you some idea of what's going on and may also discuss what to do if you want to change compiler. Once you've found a compatible compiler, the next stage is to understand what the makefiles are doing and edit them accordingly (change paths, compiler, compiler flags, etc.)
Then, from memory (it was a while ago), you get to enjoy a magical mystery tour through increasingly obscure compiler errors. Document everything because if you do get it working, you won't be in a mood to do this twice.
MATLAB R2016b on Windows now supports the MinGW compiler. I'm successfully using this to compile code written primarily for Linux/gcc. I installed this from the Add-On menu in MATLAB (search MinGW).
For my case, I'm building with the legacy code tool. The only thing I needed to do differently than normal was to tell the compiler to support c99 via a compiler flag. This does the trick:
legacy_code('compile', def, {'CFLAGS=-std=c99'})
I had trouble getting the flag command just right (I had some extra quotes that apparently broke things), and asked The MathWorks, so credit is due to their support team for this.
If you are using mex, I would expect to do something very similar.
I would guess that the makefiles are irrelevant for your application; you will need to tell the mex or legacy_code function about all of the files necessary to build the whole application or link against pre-built libraries (which it sounds like you don't have).
I hope this helps!
I am unsure about compiling C files into executables by using Cygwin under Windows 7.
Can anyone please tell me how to do this?
I've read some tutorials but still don't get it. I understand that I need a Makefile, but what shall I write into it to have an executable file after the compilation process?
For the beginning I would say it is enough to Install MinGW. If you have installed it you find in the bin folder a gcc.exe which is the Compiler. Either set the PATH Variable to the bin folder or go directly to this folder.
In terminal use:
gcc your_C_file.c
The output will be an exe.
There are several ways to compile c-files. Makefiles are just one possibility. But as you proposed it... Here are two tutorials for Makefiles:
http://makepp.sourceforge.net/1.19/makepp_tutorial.html
http://mrbook.org/tutorials/make/ (Content from 2012 accessable via waybackmachine)
But note, that you will also need a compiler (installed under cygwin).
Another possibility is to use Dev-C++, a IDE (Integrated Developement Environment) for C++. Once installed you can create a project and add your source code, and just compile the project. It also contains a c++ compiler (also supports C), which is named mingw. The makefile needed is automatically generated. So that's simpler for beginners.
You can download Dev-Cpp here: http://www.bloodshed.net/devcpp.html
Note: As you spoke about cygwin I assume you use Windows. Dev++ works only under windows, and you wont need cygwin.
Q: How can i compile c-files into an executable (.exe) file?
A: Get and use a C compiler.
GCC/Cygwin is one possibility. MS Visual Studio is another: you can download the free "MSVS Express" here: http://www.microsoft.com/visualstudio/en-us/products/2010-editions/express.
How you interact with the compiler is another question.
You can certainly use a command line.
You can use a command line with or without "Make": you can let "Makefiles" do the "heavy lifting" for you, you can use .bat files, or you can type everything by hand.
Using a graphical IDE is another possibility. "Eclipse" and "MS Visual Studio" are two popular alternatives for Windows.
Even easier solution is A86 Assembler. Its old school but works perfectly, in the right hands ;)
There is few files with .c anf .h extensions (cmdline.c cmdline.h core.c core.h and so on) in src directory, also there is one file "MakeFile" without extension. Is there any possibility to build these source files into some executable file on Windows 7 (64bits) ? I think i need to download compilers for C or some sdks right?
Yes.
You need to:
download and install a C/C++ compiler (I recommend TDragon's distribution of MinGW ),
add the compiler to your PATH (the installer can do it for you most of the cases); verify it's done by opening cmd.exe and typing gcc -v and mingw32-make -v, both should give you half a screenful of version information if your path is set correctly,
via cmd.exe, navigate to the folder in which the Makefile resides and call mingw32-make.
From now on everything should compile automatically. If it doesn't, post the errors.
Update:
First of all, it'd be useful for you to get the MSys package. Install it and you'll have a more recent version of make (use it instead of mingw32-make from now on).
About the CreateProcess bug, it has to do with the system PATH variable being too long. You'd need to do something like this:
open cmd
execute set PATH=c:/mingw32/bin;c:/msys/1.0/bin (change the paths here to reflect your own installation if it's different)
then as before: navigate to your project's directory, run make. Everything should be smooth now if you're not missing any external libraries.
BTW- remember not to install MinGW or MSys in directories with spaces.
I am not a Windows Developer..
But still as per my knowledge. Visual Studio (i.e 2008, I guess) has the ability to read the Makefile.
Please have a look at it..and if needed change this makefile to their format..
There are many opensource product which are platform independent..and they get compiled on both OS with the just Makefile they provided.
Or else use 'cygwin'
Developer C++ works in windows but it is actually GCC code bought into Windows, Is anyone familiar about the procedure they used to convert the linux ( .sh) to executables ??
I think i need to download compilers for C or some sdks right?
A compiler certainly, but what additional libraries you may need will depend entirely on the code itself. A successful build may also depend on the intended target of the original code and makefile. The makefile may be a GNU makefile, but there are other similar but incompatible make utilities such as Borland Make and MS NMake. If it is a simple build, you may be able to avoid the makefile issue altogether and use the project management provided by an IDE such as Visual C++ 2010 Express.
If you do not know what this code is or what it does and what it needs to build, you are taking a risk building it at all. Maybe you should post a link to the original source so that you can get more specific advice on how to build it.
[EDIT]
Ok, now looking at the code you are attempting to build, it is a very simple build, so if you wanted to avoid using GNU make, then you could just add all the *.c files in the src folder to a project in your IDE and build it.
However there is one serious gotcha, it uses the BSD sockets API and Linux system headers. You will need to first port the code to Windows APIs such as WinSock (very similar to BSD Sockets), or build it under Cygwin (a sledgehammer for a nut somewhat). There may be other Linux dependencies that need sorting, I have not looked in detail, but it looks fairly simple. That said, if you did not have the first clue regarding compiling this stuff, then perhaps this is not a task you could do?
Of course compiling the code may only be half teh problem, if it was designed to run on Linux, there may be run-time dependencies that prevent it running on Windows. Again I have not looked in detail.
Also looking at the code, I would suggest some caution, this may not be the best quality code. That may be unfair, but one obvious flaw and an indication if inexperience is the lack of include guards in the headers.
I have a C code created in Plato3. I want to create an exe file so I can share it with others.
Can someone please tell me how is this possible ?
I have tried sending the exe file that is created when normally compiled, but it crashes every time in runs on computers other than mine ...
Please help,
Thanks :)
[EDIT]
Program running on windows xp or vista .. same error :
Compiler used : SilverFrost (Fortran/C/C++) Development Studio (Plato3)
This application has failed to start
because salflibc.dll was not found,
reinstalling the application may fix
this problem
salflibc.dll is a library installed by the compiler on your development machine.
salf = Salford C Compiler, the obscure compiler included in Silverfrost
libc = C-language runtime support library, necessary for the basic functionality of any program
.dll = dynamically-linked library, i.e. a separate file from your .exe file
You might look for a compiler option that looks like "statically link runtime library;" this might eliminate the DLL dependency. However, if the compiler were capable of doing that, one would expect it to be the default, if not the only way.
However, I recall from the olden days of Classic Mac OS that sometimes DLL runtime libraries were used, the benefit being upgradability. Sometimes is a key word, though. (I suppose when the compiler vendor is the OS vendor, as with MSVC or Apple GCC, it is the norm, though.)
Another trick from that environment was to put the DLL in question in the application's directory and distribute it with the app. Typically runtime DLLs are licensed for free redistribution.
At the very least you have to make sure that the executable is running on the same architecture/operating system that it was compiled on.
Additionally, you need to make sure that any third party, or system libraries that are needed are available on the other systems too.
update
Based on the new information and error message you provide, it looks like you need to re-distribute the salflibc.dll
I would agree with other commenter's and suggest a different platform for development that is more mainstream, or supported.