I got gcc working to compile BREW apps for Win32 in the simulator. The key is the -mno-cygwin option to gcc. I will elaborate soon on the full rundown. I still don’t have the debugger quite working. It seems to be able to load in the symbols from the DLL, but it doesn’t hit the breakpoints properly. I think the situation is tricky because we are debugging an EXE that has no symbols that dynamically loads a DLL with symbols via Eclipse/GDB, which is a pretty exotic setup.

I can also say that the Microsoft debugger I mentioned previously is pretty user unfriendly. It’s kind of like command line gdb, except more clunky, from what I could tell.

So, I think up until a little after I graduated from college, I was a pretty closed minded person in terms of software development. I felt that my education was a waste of time and I knew all there was to know. Some of this was due to personal arrogance, and some of it was due to the lack of an environment which drove me to do better. I think one of the turning points for me was my first JA-SIG conference. JA-SIG is an organization of University IT staff who get together and talk about Java in their organization. I went in thinking I knew quite a bit about Java, but left realizing there was a lot of cool stuff I’d never done before. It was the first time I saw the Eclipse IDE, which converted me to a die-hard vi/command line person to an IDE user. Things like continuous integration, unit testing, web services, etc. were new things I hadn’t tried and didn’t really think I needed to know anything about.

Anyway, the whole realization I had starting with that conference was that you need to keep an open mind and try new things with respect to technology. You should also seek out the experts in your domain and follow their examples. In terms of their conventions and styles, you may think you can come up with the best solution yourself, but experience of others cannot be written off as useless. Follow their example, and if it doesn’t work, revise it. And constantly search for ways to do things that other people have come up with and you haven’t seen yet.

Once you start following these philosophies, you will find that you are discovering all sorts of new and exciting ways to improve your productivity instead of following the same boring old routine.

Basic intro: BREW is a C API for programming cell phones. It is mainly for CDMA devices using Qualcomm chips. Basically, in the US it is used to program Verizon phones. All of the other (major) carriers use Java and J2ME.

Getting started with the BREW dev tools, the environment seemed really nasty to me, so I was going to try to swing something cleaner. They tell you to use Visual Studio, but all of their samples reference VS 6.0 although they have a tool set and one document for VS.NET 2003. Even that version, however, is outdate since VS 2005 is out. On top of that, VS is getting notoriously expensive (up to $10k/year per developer for some MSDN plans). So, in order to avoid this hell of versions and paying lots of money to MS, I ventured to get BREW stuff to compile under Eclipse using CDT.

CDT is a little out of place on Windows, you have to install Cygwin to get it working right. You should install Cygwin BEFORE CDT, otherwise bad things happen. The default “managed make” setup didn’t work for me, so I started writing makefiles like a normal person. I managed to get a build of the BREW app with GCC, but it would hang when I tried to run it in the BREW simulator. So, I switched to Microsoft’s compilers to see if it would work. After a bit of farkling, I was able to build the app with cl.exe and link.exe and run it in the emulator. For anyone that wants to avoid Visual Studio, you can now download the compilers for free (minus the IDE) from here:

http://msdn.microsoft.com/visualc/vctoolkit2003/

I believe those would be the VS.NET 2003 equivalents, so maybe they are a bit out of date, but they work fine. You may also need the platform SDK to get windows.h etc.

Now, I had a build that worked.

The next step was to actually do something. I’m a little rusty on my C and BREW uses some particularly nasty constructs, so I ran into a lot of segfaulting in my first run. Up until recently, I wasn’t much of a debugger person, but now I felt that I would need the debugger to get this BREW crap working in a timely manner.

CDT only supports GDB for debugging at this point. I was able to attach GDB to the brew simulator, but I could not seem to get debugging symbols loaded into GDB for my app’s DLL. Microsoft’s C compiler creates .PDB files which contain debugging information, which I don’t think GDB can understand. So, that was a no go. My next step is to try these tools to see if they
are usable without Visual Studio:

http://www.microsoft.com/whdc/devtools/debugging/default.mspx

We shall see…