Related
I work in a factory where 80% of our equipment uses an MS-DOS interface. None of our engineers have experience in c/c++ programming, and it was requested we add some features to the machines interface. Our automation group has abandoned the MS-DOS platform in favor of Allen-Bradley controls. I'm feeling ambitious and decided to take on this project, even though I have next to no experience in c/c++.
On to the question:
All of the programming was written and compiled in Turbo C++. I would prefer to use DEV++ for various reasons (ease of use, additional headers, more developed C++ platform, ect.). The problem is the existing programming relies heavily on non-standard headers from TC++. There are 10 or so headers unavailable in DEV++ in the source code, and rewriting the code using more modern constructs is not an option; we would lose what little support we have from our AG, time, ect.
Is there a way I could add all the headers from TC++ to DEV++? For example adding the graphics.h to DEV++ and have it be fully functional? I have tried adding it to the include folder, calling it with #include"graphics.h", and if DEV++ manages to recognize it, it throws a ton of compiling errors because it doesn't recognize the internal commands in the graphics.h file.
Unfortunately I cannot include any example code from this project, due to non-disclosure and copy-write policies.
My programming experience:
DABBLE in RSLogigx500,5000 ; Arduino IDE (don't judge) ; Parker 6K ; PanelView ; ~40hrs of self-taught c and c++.
Any help would be much appreciated.
UPDATE
Very helpful information. It seems like this isn't going to be possible given how outdated the hardware is and the restrictions I have on this project, but thank you all for your input.
Most of the headers from old Turbo C are really just the MSDOS API, in a way. So it doesn't make any sense to attempt to use those headers in any other environment and you can't port them to a Windows compiler. Similarly, graphics.h is for a Borland-specific DOS graphics library called BGI and will not work on any other compiler.
It should be noted that old Turbo C++ (I'm assuming version 3.1?) didn't follow the C or C++ standards much. The C++ version it used is completely antique.
Also note that the Dev C++ IDE is outdated and doesn't update the GCC compiler any longer. The CodeBlocks IDE is a better alternative.
This is more of a "long comment" than a direct answer to your question, trying to guide you to a better understanding of what MAY be your challenge in your project.
I personally would choose a more "professional" level development tool. Either Eclipse (positives is that this is portable and looks/feels the same whether you use Windows or Linux), XCode (works only on Mac) or Visual Studio (which works only on Windows). These are full featured integrated development environments, and they are all very slick. All of them are free or nearly free.
Compiling OLD code, that is written for DOS into a modern compiler with on a modern OS may be quite a challenge, depending on what the application does and how much in the way of assumptions about it's environment the code is written with:
does it assume int is 16 bits
does it call direct to DOS to get file info, opening/reading/writing/closing files
does it do raw keyboard input
does it poke characters and/or pixels directly at the screen
does it use far and near pointers, are there driver-like components that interface directly to hardware interrupts
One thing that stands out in your question is the mention of graphics.h, which I believe is very Borland specific. Which means you'll have to write your own replacement functions - either a replacement graphics.h set of functions (I expect most functionality is available in any modern OS, it's more a case of "what is it called and what do I need in order to call that function"). This can be quite a task in itself.
The tricky part here is not only to identify what the code does, but to replace it with similar logic, that does the same thing in your new environment.
And of course, it all depends on what you want to do with the code, how well written it is - is it nicely modular, does each function do one thing and one thing only, or are there functions that "This calculates the value of , and then reads some data from disk, then does some I/O to the screen, and then talks to some external hardware, and because it gets calls frequently, also updates the time on the screen if it has changed".
I'm not sure the way I'm organising my library is the most elegant way to organise it. I'm mainly concerned about making all the code that I type compile/run for all systems that I'm targeting (keeping it portable), and also keeping it up-to-date for every system.
For example:
I'm not sure using __declspec(dllexport/dllimport) would be used for Mac or Linux. I assume that it's not, but I don't know what the equivalent is for Mac/Linux is. Or another example might be calling specific Operating System functions, which I try to avoid. However, things such as: measuring how long something takes to happen*, in a precise manner, does require me to call OS specific functions.
*as in getting the user's time precisely (down to micro/milli-seconds).
The systems that I am currently (perhaps more in the future) aiming for is Mac, Windows and Linux. But testing that the code compiles (and runs correctly) for every system just seems like a waste of time. As currently, the way I'm proposing to do it, requires me to make a separate project for every system. i.e. I create a Visual Studio Project for Windows, an Xcode project for Mac, and use the command line for Linux or use some other IDE.
Okay, so my main problems with the way I organise things are:
1. Time Consumption, as in creating the projects for all systems and keeping each indiviual project, for each system up-to-date.
2. Knowledge on all IDE's/Compilers that I require to use
Please note, I've never really used* Linux before, I'm thinking about switching. The only problem that I'm concerned about is finding the right tools for me to use with it, and finding the right Distro that would suit me, for what I need. I would really appreciate if someone that is experienced with Linux could guide me, or give me some advice whether to switch or not.
I really like Visual Studio, and it's been my main IDE for quite a while now. I'm just not sure if I want to ditch Visual Studio or not, for Linux; as I don't know if the tools that are available for Linux can do what Visual Studio can or not. What I mean is, it being as user friendly as Visual Studio is. I'm afraid to learn how to use Linux's tools, I'm just not sure if it's worth doing so. Time isn't a major factor on this library, I have plenty of time, I'm fairly young and determined to program as my career in the future.
*I have used it before, but I've never replaced it for Windows.
I am currently hosting all my source code for my project on BitBucket, but at the moment, I only have the RAW code on my repo. There is no project files or any other tool to compile it with, just the code and a readme file. I was thinking of using Makefiles, since they seem popular. But I've never made a Makefile before, don't get me wrong, I am willing to learn. I'm just not really sure where to start. I've heard that people use CMake to create portable libraries, such as SFML and Ogre3D. I've built a couple of libraries with CMake, but I have no clue on how to actually make my own library with it to make my project/make files. Should I learn and incorporate CMake with my library, or is there a better option available?
EDIT:
I'm not aiming to write a library for actual Software that uses a GUI. I'm mainly aimed to write games.
1 - Boost. Boost will help your portability more than you can imagine. Its only real sticking point is, believe it or not, OS X.
2 - Use CMake. It integrates with Visual Studio project files as the build tool, and you can put most of your different-platform compilation voodoo in there.
3 - If you're seriously writing a portable library, consider writing it in C/writing a C wrapper, or making it header-only, or providing the source-code. Making it a shared or statically linkable library does not mean that it will play nice. Name mangling leads to inconsistencies that will blow your mind.
4 - Always be explicit about the number of bits in each variable.
5 - use git. It'll allow you to setup a crappy local server for a repository very easy and get very fast transfers of the kind of huge changes MSVC will make annoyingly
There are a lot more best-practices that can be discussed about cross-platform development. All of that advice isn't applicable in every case; I have a very code-heavy Linux/Windows library that I code almost exclusively in MSVC2k10 and mostly build/test for in Linux, and it is nowhere close to header-only.
EDIT in response to comments:
git was suggested because I find it very easy to use and manage locally. I've use svn before and liked it, I won't really endorse any others, but there are probably plenty of fine ones.
To expound on point 3,
A C wrapper would make it so that anyone anywhere could use your library - FORTRAN developers, Ruby, even Java.
Otherwise you generally have to have similar compiler versions to link properly and it will only link to other C++ code, outside the case of DLLs, and there are still versioning issues. It's one of the stupidest problems in C++ left over, check "name mangling" on Wikipedia. There is a reason widely-used libraries are written in C or have C wrappers, such as libz, openssl etc.
There are other advantages to it. Exception propagation across dynamic libraries is non-existent; with static libraries it can be inconsistent or non-existent.
You'll find that the most widely-used C++ libraries are mostly header-only, like Boost. A header-only library solves many problems by putting all the code directly into a project in a relatively intuitive way, and modern compilers can still optimize away much (but certainly not all) of the extra compile time associated with it.
With all this said, it is certainly possible to do without a C wrapper or header-only, it is just annoying and very troublesome. DLL hell and its Linux equivalents still exist.
You also asked about Boost. That depends. If you're distributing the sourcecode then you certainly must distribute Boost with your code/have people install it. Having people install libraries in order to compile other libraries or use programs is common practice. Think of how specific versions of DirectX come with games for an example.
However if you are distributing binary versions of your library, statically linking against Boost will eliminate any need to include it as long as you are careful to keep Boost headers out of the outward-facing parts of your library. This is where you start seeing things like void * pointers inside C++ headers; an unfortunate side-effect of some of the shortcomings of C++ compilation and library distribution unfortunately.
CMake is a good choice. You can learn to use it. Read a tutorial:
http://www.cmake.org/cmake/help/cmake_tutorial.html
But, if your targets are Linux and Windows only. It is probably OK, in your case (small/average first multi-platform project), to maintain 2 separate build systems.
On Linux, Use Make. It is standard and has a very good reference manual:
http://www.gnu.org/software/make/manual/make.html
On Windows. Use your IDE project file, be it Visual, DevC++ or other. That is the simplest way to go.
Most important, make it easy to test your library/software on different platforms. Install a virtual machine on your desktop. Or at least compile your library into Cygwin.
Once you are here come back on stackoverflow and we will help !
Personally I'd leverage a framework like Qt, because it is quite portable, it does abstract a lot of OS functionality (files, timing, threads, networking), and you get a decent, free IDE (Qt Creator) that is also portable and runs on Windows, OS X and any Unix flavor that runs Qt. It'd give you the lowest barrier to entry. Qt Creator can leverage the Visual Studio compiler and the CDB debugger if they are available.
You do not need to use OpenGL to use Qt, in fact you're not bound to any particular graphics subsystem. Qt only "uses" OpenGL in Qt 5 for the Qt Quick 2 graphics backend. It's not needed for Qt 4, nor for Qt Quick 1 (even in Qt 5!).
You can use any 2D or 3D framework you fancy to push images and other content to the screen. What Qt is good at is creating the kind of 2D imagery that is often needed in games - menus, configuration screens, HUDs, etc. There's a lot of controls and drawing primitives that Qt makes easy to leverage for your purposes.
Qt also lets you use a reasonably powerful model-view and networking frameworks, thus you'd be able to reasonably easily generate server or client lists that update in real time.
There'd need to be a small amount of shim code between Qt and DirectX, of course. On the output side, you typically end up with a QImage in Qt, and then use DirectX, SDL, OpenGL, etc. to push it to the screen. On the input side, you need to call qApp->processEvents() within your main game loop, and you will need to post user input events from DirectX etc. to Qt's event queue using qApp->postEvent(...). This would be only needed if, say, DirectX main loop consumes all Windows messages and won't let standard winapi/win32 code (Qt's windows event dispatcher) see them. I haven't deal with DirectX much, so others feel free to chime in with details, of course.
Perhaps some of you people have heard of http://suckless.org/ and their set of Unix tools. Basically, they're a set of programs that each aim to do one thing but do it well, while still being as simple and resource-light as possible.
I've been trying to find a way to reproduce this style of programming on Windows with C++ but all the libraries I know of would produce binaries that are huge with respect to their function. Even the simplest of anything Qt, for example, is generally several megabytes large. I'm not against packaging dependencies along with distributables but I wouldn't want to do it to that level.
Binary size is not one of my main goals but simplicity is and big libraries like these are, by construction, not simple. If binary size were your primary concern you could use runtime compression just like kkreiger or malware.
A possibility would be to go commando and use only ISO Standard C++ libraries but rebuilding a sockets or networking system for a small single-purpose application is not really something anyone would want to be troubled with.
For some reason I thought there was some general-purpouse library that Windows developers could count on everyone and their grandma having readily accessible but now I don't know if anything like that exists. What can you use to write code that adheres to the Unix Philosophy but for Windows targets?
You should target the Win32 API directly. You can't get much lower level than that. In the Windows world, everything directly or indirectly wraps the SDK functions, including the so-called "standard C++ libraries".
Alternatively, you could use something like MFC or WTL, which are relatively thin C++ wrappers over the Win32 API. Because of the overhead of the class libraries, such programs will be slightly smaller than those created using only the SDK, but nowadays, the actual overhead is completely insignificant.
The desires expressed in your question are precisely why I learned and still use the Win32 API today, so that's definitely what I would go with. Plus, your programs will look and feel native, which is way better than the crap most "cross-platform GUI toolkits" put out. The advantages of this can't be underestimated.
But if you just open up Visual Studio and compile a simple little SDK "Hello World" app, it'll still be awfully large. Kilobytes, to be sure, but that still seems like a lot for about the simplest app imaginable. If you really need to cut things down further, you can try telling Visual Studio not to link to the C runtime libraries and define your own main entrypoint. This does mean that you'll have to implement all of your own startup initialization code, but this can reduce the size of a trivial app substantially.
Matt Pietrek had this same idea some years ago, although you'll probably want to take time to "modernize" his original code significantly if you decide to go this route.
FLTK is a popular cross platform minimal gui toolkit.
Or a popular alternative if you don't need too much detailed interaction is just to fire up a minimal embedded webserver and do all the 'gui' in html in a browser.
I am a software engineer and i work in VC++, C++ in WIndows OS.
Are there any major differences when it comes to coding in C++ in Linux environment.
Or is it just some adjustments that we have to make when we need to code in C++ in Linux.
It would depend on the types of projects you've worked on and what native windows APIs you made use of. For example if you used the native Windows API for everything, you're going to have a pretty big task ahead of you, it'd be worth making your project(s) work nicely with Wine instead.
In the Linux environment you have the man pages, quite detailed documentation of almost everything :). As mentioned above, look at POSIX, and while I recommend Qt - it provides a LOT of abstractions for things you might want to learn to do the Linux way (eg sockets, filesystem...)
Use the POSIX API instead of the Win32 API.
Use gtkmm, Qt, or wxWidgets instead of MFC.
Linux programming world is very different from you are familiar with in Windows world. You have to understand it and get used to it. Once you understand you will not want to come back.
You have many small/good tools that works with each other rather then all-in-one MSVC solution. For example:
In Linux you have a compiler as stand-alone tool (Gnu compiler collection), you have build system as stand-alone tool (autotools, CMake). You have GNU Debugger as stand alone tool and you have very good editors as stand alone tool (like hard core vim/emacs).
There are integrated development environments like Eclipse, Netbeans, KDevelop, Anjuta
but still you have to understand how stuff works.
You should understand that each separate tool is very powerful and integrates with others.
OS Level API is designed for simplicity. You'll rarely will find calls like CreateProcessEx with bizzilion parameters rather you have simple fork()+exec(). man is you real friend in all connected to system API and standard C library.
GUI - You have two big GUI libraries Qt/GTK. Qt is great C++ library that makes GUI development enjoyable work (unlike MFC). GTK has both C and C++ APIs GTK and GTKmm (no experience with them).
i18n/l10n/unicode - this is where Linux programming makes life easier. Almost everything is UTF-8. No wide API crap, no issues with opening Chinese file names with simple fopen or ifstream, no 3rd part library that can't open file with Unicode name. Great built in tools available like gettext, and good translation toolkits like KBabel.
Libraries - this is where Linux programming makes you hate Windows. Almost every single free library is already installed or available with simple apt-get or yum install. no debug/release incompatibility crap, no DLL_EXPORT-ing, simple robust, making shared objects is as simple as working with static libraries (and most do not use static libraries at all).
My $0.02
(I'm Linux programmer that have deal a lot with windows development)...
It depends on how many windows-specific things you've been using. The standard part of C++ is the same, but using that will not get you much further than command-line applications.
There's also the whole makefile-instead-of-letting-VS-build-for-you thing. Depending on what tool (or IDE) you decide to use in Linux, that could be a big difference.
I have worked quite a bit on both platforms and like them both, but in general I found most developers to like one and hate the other.
I would describe *nix environment as "geek friendly": many excellent and very flexible tools on your disposal. Some of them introduce hard learning curve, and some are simply broken but still popular for some reason (make) but if you are willing to invest some time in properly learning them, the reward is high. In fact, I use many *nix tools even when working on Windows: vim, grep, perl, etc...
On the other hand, Windows platform offers Win32 API which has way more functionality than POSIX, is very well documented and supported by very good tools. Debuggers on Windows (especially windbg) are generally more powerful that any *nix debugger I have tried, although gdb is generally good enough for most tasks. Deployment of executables is also easier than in Linux world - in fact the only truly reliable way to deploy software on Linux is to ship source code and build it on clients' machines via config/make.
I would suggest to use a Buildsystem like SCons which works very well on both Linux and Win32.
Take a look at the source to some open-source project that runs on both Linux and Windows. Typically, over 80% of the code is identical, and the bigger the project the less the system-specific part tends to be. Unfortunately, there can be hard parts (threading, non-blocking network IO, GUI details) in the system-specific code.
There are some major differences that I can think of:
Tools. Good and bad points. If you are used to Visual Studio, there is nothing quite like that available. Each Linux IDE has some issues. On the other hand, especially debugging tools are very good. But all in all, you are supposed to create your own working environment from what's available.
API's. Documentation varies wildly. Some components are well documented, but often you end up reading the source code to figure out how something is supposed to work. On the other hand, you have source code so eventually you have all the tools possible to figure out why something doesn't work.
The Linux programming community is usually very good as long as you remember to behave and you find the right places. SO isn't half bad in some issues, but sometimes you need to find other places.
Things are not quite as automatic as you might have learned in the Windows world. Yes, some tools allow you to create projects without Makefile knowledge, but really, you should learn how to use them. In Windows it's much more common that you never edit the project files (e.g. Makefiles) by hand.
If you want to work in kernel space (drivers etc) C is a better bet than C++ since the kernel is written with that.
And I agree with people suggesting Qt. Very nice widget set. Beats at least Swing (yes, I know, it's Java) hands down. And Qt Creator isn't half bad.
Don't underestimate the power of shell scripting! Something very few Windows programmers have figured out, but you can do a hell of a lot with them to help your work.
A typical windows programmer who is used to Visual C++ might find the following aspects of Linux C++ programming novel, or difficult:
Linux programming isn't linux programming, it's Unix programming. Unix programming's roots go back a lot further than the MS-DOS roots of Windows, and it shows in a lot of places.
Windows programmers tend to think about the environment, they tend to think about the IDE tools (your GUI editor, compiler, debugger) first. Unix programmers tend to be arranged in various tribes, many core Unix (linux) C++ programmers are very comfortable working from the command line without an IDE, and some, I'm sure, use visual-studio style IDEs on Linux, of which there are many.
I personally found I had to learn how to read (and maybe write) a makefile, build a bunch of standard Linux/Unix applications from source (and understand how to type my way through steps like 'autoconfiguration' and the various "--command-line-options" one might select there), before I get the feel, and the flavour of the environment.
Until you are a seasoned Linux system administrator you might want to stick with the newbie-friendly Linux distributions (like Ubuntu).
I am going to start a game in about 3 weeks and I would really like the game to run at least on another platform (linux, MacOS) but my team thinks that's a lot of work. I am up for it but wanted to know what are the things I should watch out for that won't port to linux (apart from Windows specific APIs like DirectXsound)?
I've been reading online and Windows "_s" functions like sprintf_s appear to exist only on Windows; is this correct or are they implemented on linux also?
No, the _s functions are NOT implemented in the standard gcc library.
(At least, grepping the include files for 'sprintf_s' turns up nothing at all.)
It might be worth looking at cross platform libraries like boost and apr to do some of the heavy lifting work.
A sample of specific things to look for:
Input/Output (DirectX / SDL / OpenGL)
Win32/windows.h functionality (CreateThread, etc)
Using windows controls on the UI
Synchronization primitives (critical sections, events)
Filepaths (directory separators, root names)
Wide char implementations (16 bit on windows, 32bit on linux)
No MFC support on linux (CString, etc)
If I were you I would use some of the available Frameworks out there, that handle Platform independence.
I wrote a 3D-Game as a hobby project with a friend of mine, the server being in Java and the clients running on Windows and Linux. We ended up using Ogre as 3D-Engine and OpenAL as Sound-Engine, both platform independent and available under LGPL.
The only things I really had to write separately were the whole Socket-handling, reading the config from file system and the initialization of the System. Compared to the rest of the Program, that was almost nothing.
The most time consuming will be to set up the entire project to compile under Windows and Linux (or Mac), especially if you're concentrating on one and only occasionally check the other for problems. If you have one in your team who checks regularly for these problems while they're being produced you won't have that much overhead from that as well.
All in all compared to the programming of the game itself, adapting it to different platforms is almost no effort, if all frameworks used are well written, platform independent systems.
Try to encapsulate any non-standard extentions like DirectX, OpenGL, SDL, etc. Then you only have to rewrite those parts based on platform.
I also would make it playable on one OS before even thinking of porting.
For the 'safe' functions: they are non-standard, and almost safe :)
Endianess is something look out for.
Endianess is the order of the bits in a byte. Some platforms are big endian while some are little endian.
This can affect how cross-platform your program is. But the biggest impact this would have would be in network communications. You have to convert from one endian to another before sending or receiving a network message.
If you focus on gameplay, design a game, and them implement that porting should not be especially onerous. If you implement it simultaneous on several platforms it should be straight forward.
But if you focus on effects, design something that you feel is going to "blow the others out of the water," and try to paste a game idea onto them, you are doomed.
So really it is up to you.
Don't know much about windows-apis, but I set up a daily (or on-commit) fully automatic build-system on all platforms you want to support. If you develop something on your windows-box that doesn't work on the others, your build-system should notify you of "failed build on platform x, see logfile/attachment/whatnot for details". It'll catch a lot of cross-paltform issues. Unittests will help as well.
Whether or not to target multiple platforms from the start is a good idea is another question.
Personally I'd start developing on another platform and then see about porting it to windows at a later time ;-)
Just remember that you are creating a model of game that does not depend on the details of any operating system. Your game depends on state management and algorithms which don't depend on the OS. The key is to write your game logic without dependencies to specific libraries which means a lot of encapsulation.
You shouldn't call sprintf_s directly you should write an routine, class, or MACRO that can be changed based on the platform, Don't use DWORD when you can use a class or typedef that can be tailored to different platforms.
For instance if you where making a football game, then algorithms for throwing the ball, running, tackling, positions of the players could be done completely in standard C++ without platform dependencies. If your encapsulation was good you could dump the state of you game to a file and display it separately with a rendering program.
If you truly want to do cross platform development easily I would suggest using one of the already built cross-platform engines like Unity or one of the Garage Games stuff like Torque Game Builder (2D).
I have virtually zero experience in either so can't tell you which is better but the Torque Game builder demo couldn't get through the first tutorial without having problems and they don't answer tech support questions in their forums like they claim to do so I can say avoid them if you are a novice in game design like myself. The big thing about Garage Games was supposed to be their great support, I saw zero support and in fact only saw a bunch of, "Hey, anybody here?" posts with no answers so I guess they are pretty much giving up on supporting their products.
http://unity3d.com/
http://www.garagegames.com/
I'm surprised nobody mentions libSDL and OpenGL because most cross platform games were written using those libraries.
If your game is 2D, you can use libSDL. A good example of game written using it is The Battle of Wesnoth. SDL uses DirectX on Windows, it's just a thin wrapper on it.
If your game is 3D, use OpenGL. For example, Quake 3 uses that library. You can find tons of examples and documentation on it. Of course, there are many libraries that wrap OpenGL, so you don't have to do low-level stuff. Look into OGRE, Crystal Space, etc.
As for the basic C/C++ libraries and functions compatibility, it's best you install some Linux and simply run man page for the function to see if it exists. Of you can look it up on the Internet.