Developing for Windows on Linux
Like most people who read Linux Journal, I am a rabid fan of all things Linux, GNU and open source. I run Linux on all of my personal machines, program on them, play on them and evangelize to others whenever possible. But, a large portion of the programming jobs out there involve writing applications for an operating system from Redmond, Washington.
For my job, I've had to write some smaller applications for the Microsoft Windows platform. Because speed of execution was an issue, I was going to have to write them in C, directly using the Win32 API. It occurred to me that if I was going to be using a standard language such as C, I might be able to develop in my nice and cozy Linux home.
This article is a short guide on developing an application for Windows completely within a Linux environment. I give a short introduction to Windows programming and step through compiling and testing a sample program. I also discuss Wine to simplify porting Windows source code to Linux.
For those of us raised on the wholesome nutrition of a UNIX-style process abstraction, the Windows model might seem downright heretical. The Windows model is a preemptive, multitasking, multithreaded, message-passing operating system. I'm limiting myself here to NT and its derivatives, 2000 and XP. All processes are considered threads by the operating system. This makes the process context slightly lighter than the traditional heavyweight process model used in UNIX-like operating systems. As a consequence of this everything-is-a-thread model, however, everything sits in global memory address space. With the correct permissions and the correct address, one program could twiddle another program's bits.
Another consequence of this is data structures created by the kernel don't sit at any fixed address. This means it is up to the user program to lock down the associated memory before using any global data structures, such as graphic contexts. You also must remember to unlock these structures once you are done with them, or they may help cause memory fragmentation.
Listing 1, available from the Linux Journal FTP site (see the on-line Resources section), is a basic Hello World program. Most of it is boilerplate, and only the portion within the switch statement is of any real interest. It does seem like quite a bit of code for a basic program, but that is the problem with using a low-level API. A good comparison on Linux would be writing code for X using Xt.
Instead of a main() function, a Windows GUI program starts at WinMain(). It's in this function that your program does all of its initialization. Part of this initialization includes defining the window class for the main window and associating a callback function for it. Next, create the main window and show it on the desktop. Control then passes to the message loop, and the callback function processes the messages that are sent to the main window.
A good quick introduction to writing Windows programs is available from winprog.org (see Resources). The authors of this Web site offer a good FAQ and a fairly good tutorial covering all of the basics. Of course, the bible for Windows programming is the massive book Windows Programming, by Charles Petzold. If you can't find what you need in this tome, you always can use it to beat the information out of your friendly neighbourhood Windows guru.
One of the amazing things about GCC is that it has been ported to so many different platforms and operating systems. A great gift that comes from this is the ability to compile binaries on one platform that are destined for a completely different one. I regularly compile binaries for Solaris or Windows on my Linux laptop. This is an amazing advantage, allowing development to occur in a familiar, comfortable environment.
The purest way to set up is to go back to the source (see Resources). This way you can compile code with the exact settings and for the exact platform you want. Thankfully, this work has already been done. The good people at the MinGW Project maintain a port of GCC for compiling Windows binaries. This includes all of the associated files, such as the headers. The sources are available here along with binary tarballs. These programs also have been packaged for RPM-based and deb-based distributions. If you are running Debian, you can use apt-get to retrieve the mingw32 and mingw32-runtime packages. If you are running testing or unstable, you also should grab mingw32-binutils.
Most of the compilation options in GCC are available here in MinGW, along with a few extras. If you simply compile a program without any extra options, it can be run from the console. This is what you would do if you wanted to write a small, simple program that did not need a GUI. Because this is Windows, we want a GUI program, so we write all of the required boilerplate we saw above and add the -mwindows option to the compilation command. This sets up the macros and library links you need in order to compile a standard Windows executable. If you decide to write a more complicated Windows program that uses some other Windows' feature, you need to add in the libraries explicitly that you want linked.
In Windows you can define resources for your program. These include such items as menus, bitmaps and text strings, among others. These resources are defined in a separate file and need to be compiled separately before being linked to your executable. That job falls to the program mingw-windres, which creates an object file you subsequently can link to your executable.
To compile our simple example program shown in Listing 1, we use the command:
mingw-gcc -o example1.exe example.c -mwindows
Joey Bernard has a background in both physics and computer science. This serves him well in his day job as a computational research consultant at the University of New Brunswick. He also teaches computational physics and parallel programming.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide