Windows?? *GASP!*

Sometimes you just have to compile Windows programs from the comfort of your Linux install. This is a relatively simple process that basically requires you to only install the following (Ubuntu) packages:

To compile 32-bit programs

• mingw32 (swap out for gcc-mingw32 if you need 64-bit support)
• mingw32-binutils
• mingw32-runtime

Additionally for 64-bit programs (*PLEASE SEE NOTE)

• mingw-w64
• gcc-mingw32

Once you have those packages you just need to swap out “gcc” in your normal compile commands with either “i586-mingw32msvc-gcc” (for 32-bit) or “amd64-mingw32msvc-gcc” (for 64-bit). So for example if we take the following hello world program in C

#include <stdio.h>
int main(int argc, char** argv)
{
printf(“Hello world!\n”);
return 0;
}

we can compile it to a 32-bit Windows program by using something similar to the following command (assuming the code is contained within a file called main.c)

i586-mingw32msvc-gcc -Wall “main.c” -o “Program.exe”

You can even compile Win32 GUI programs as well. Take the following code as an example

#include <windows.h>
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
char *msg = “The message box’s message!”;
MessageBox(NULL, msg, “MsgBox Title”, MB_OK | MB_ICONINFORMATION);

return 0;
}

this time I’ll compile it into a 64-bit Windows application using

amd64-mingw32msvc-gcc -Wall -mwindows “main.c” -o “Program.exe”

You can even test to make sure it worked properly by running the program through wine like

wine Program.exe

You might need to install some extra packages to get Wine to run 64-bit applications but in general this will work.

That’s pretty much it. You might have a couple of other issues (like linking against Windows libraries instead of the Linux ones) but overall this is a very simple drop-in replacement for your regular gcc command.

*NOTE: There is currently a problem with the Lucid packages for the 64-bit compilers. As a work around you can get the packages from this PPA instead.

It’s no secret that while Java possess probably the most widely distributed, cross-platform, and common user interface libraries, graphical Java applications on the whole simply stand out for the wrong reasons. Whether the GUI comes in the form of the Abstract Window Toolkit (AWT) or Swing, each can be far from pretty and often do not mesh well with the platform they are being run on. For instance, running an AWT or Swing application can be an almost alien experience, no matter what operating system you are using, because neither uses the native control widgets. Even AWT, being a ‘thin’ layer above the native controls, often looks completely bizarre. On Windows Vista AWT looks more like Windows 3.1 than anything else. Thankfully there is a nice alternative in the IBM created (and now Eclipse maintained) SWT.

The Standard Widget Toolkit, or SWT, passes all GUI rendering responsibilities onto the host operating system. This allows for some interesting advantages like hardware rendered drawing for free (as an example). It also provides for a native look and feel because its actually using the real native widgets. So when run on Windows it looks like a regular Windows application and when run on Linux it looks like a Linux (GTK+) application. It also works on the Mac as well as a few other obscure platforms.

Unfortunately because the application is now creating widgets outside of the JVM you are suddenly responsible for freeing the memory. There is no automatic garbage collection in the world of SWT. It’s not all bad however as freeing a parent object, like a window (referred to as a shell in SWT lingo), automatically frees all of its related child objects as well. Simply call the .dispose() method and 9 times out of 10 you are done.

Another other caveat is that you will still need to package the correct swt.jar file for your target platform. For instance Windows has its own version of swt.jar, as does Linux, and Mac, and so on and so forth. While this is rather annoying it does offer some interesting trade-offs. For instance you do not need to recompile your code just because you want to run it on a different platform; simply swap out the swt.jar file and watch as the exact same code generates completely different native GUIs. I even wrote a simple program that first checks what platform it is being run on and then downloads the correct swt.jar file before launching the GUI. This makes releasing the exact same package very simple.

So how do you start using SWT? Head over to http://www.eclipse.org/swt/ and download the newest stable version for your platform of choice. Depending on how you will be programing, all you have to then do is add the enclosed swt.jar to your class path. If you’re using Eclipse, or a similar IDE, you can simply add the source as either part of you project, or as a separate referenced one, and take full advantage of the auto-complete as well. Perhaps I’ll get around to posting a more thorough how-to guide at some point in the future.

Like most things in software SWT is not perfect. There are still other challenges to overcome, such as creating each individual platforms’ unique user experience to compliment their native GUI toolkits. That said if you’re looking for a way to leverage the widespread nature of Java, while still creating an application that looks like it belongs, SWT might just be what you’re looking for.

As a long time Windows user I have had my fair share of dull, gray toolbars, buttons and controls. Prior to Windows Vista, Microsoft’s first real attempt to pretty up the system – sorry XP, making the taskbar blue just doesn’t cut it – I even looked to Mac OSX with some jealousy.

Flash forward to The Linux Experiment and I have been introduced to a whole new set of environment graphics. Some of them are quite beautiful and some are just… plain ugly. On the plus side, the nice thing about Linux is it’s ability to customize just about every detail, including how my desktop looks. But is there really any excuse for some of the horrible themes, colour choices (*cough* Ubuntu *cough*), and graphics that are still present in Linux today? Surely there are some artists out there in the open source community that could be let loose on these problems? Come on people, I know you can do better!

With some ‘leaked’ information about Microsoft’s plan to include brand new IA-128 computer processor architecture in their next version of Windows (8 & 9) it got me thinking about the need for 128-bit CPUs. What’s the point?

Memory Addressing

This is often cited as the reason for needing to increase the number of bits in a CPU. With a 32bit register you can address approximately 2^32 bytes of RAM, or about 4GiB system wide. Windows itself imposes a limit of 2GiB of RAM for user processes and about 3.12GiB for total RAM, which is why there is a such a push to 64bit architecture. 64bit versions of Windows allow you to address far more memory. Except, this isn’t really true.

Physical Address Extension

PAE is an old technique used to address more memory than you should be able to, up to 64GiB on 32bit CPUs. It is similar to bank switching in that it uses the addressing register to split up your total memory into different banks of space which it can then switch into allowing you to access the full memory. There are a number of reasons why this is efficient and safe, and in fact Windows already does it. This is why the 32bit version of Windows server can address a full 4GiB of RAM even though the 32bit consumer version cannot. Well actually you can force it to do that as well.

How much memory do you really need?

Let’s assume that 32bit architecture, without PAE, only lets you access half of what it should be able to, 2GiB of RAM. That means that the maximum amount of RAM you could access in a 64bit architecture would be (2^64 / 2). This equates to 8,388,608 TiB of RAM that you would still be able to access. Most computers being sold today come equipped with 2GiB of RAM total, or 2.3*(10^-10) % of just half of the total addressing space allowed for with 64bit architecture.

Speed improvements

The next argument for increasing the bit size of the architecture is to get speed improvements. By increasing the length of every register you no long have to straddle registers when you are dealing with large numbers. For example, if you are doing math using a 64bit number on a 32bit CPU you will need to use two registers to fit the whole number. On a 64bit CPU you just need one, thus freeing up the second register for something else.

Certainly moving to 128bit CPUs will also improve speeds? Well… sort of. You see a lot of the large number math instructions that a CPU can do already make use of specialized 128bit registers inside of existing 32bit CPUs. I highly doubt there will be a large need for 256bit data types moving forward (super big long unsigned int?), so most of the real speed improvements you will see on a 128bit CPU will be when you are using 128bit numbers.

Another issue is existing software. The vast majority of software currently available are 32bit programs, meaning that they will see very little speed increases on 64bit or 128bit CPUs. In fact 64bit software is only now starting to become common place, with many applications still lacking true 64bit support.

Yes, 128bit registers will be beneficial for some computations such as encryption (128bit-256bit keys) and hash algorithms (some of the SHA-3 candidates keep an internal state of 512-1024bits) but so will the addition of specific instruction sets to make use of the existing hardware.

Progress moves forward

I don’t mean to rain on the 128bit architecture parade, I just merely mean to point out that what has been said so far about it really isn’t that different from what we already have. One day I do expect 128bit CPUs to replace 64bit ones, just as they are now slowly replacing 32bit CPUs. In the mean time I would much rather have additional registers or more hardware functionality because they will actually be taken advantage of.

I just finished up a quick post over on The Linux Experiment about how to share one keyboard and mouse among multiple computers using software, in this case a Windows Vista desktop and a Fedora 11 laptop.

Check it out here: Setting up some Synergy

Some friends and I have decided to give Linux a run for its money. Most of us are experienced Window’s users so we figured making the transition to Linux would be 1) a good thing for the resumé and 2) a pretty easy switch. Boy were we ever wrong about #2… #1 is still debatable

The basic premise is this:

1. Is Linux really a practical desktop computer for the masses?
2. Can someone really make the switch from the far more popular proprietary operating systems and applications to the free and open source alternatives?

The experiment is govern more or less by the following two rules:

1. You must use Linux as your primary computing platform for 4 months
2. You cannot use a distribution of Linux that you are familiar with or have used in the past

Follow us through the highs and lows of getting everything working just right, as we learn new things, and share our user experiences!

www.thelinuxexperiment.com