Paco's Blog

Corrections and Expansions

A lot of you showed some interest in the topics covered in my last two blog entries. There are a few things that may be worth correcting here or at least expand some of its coverage.

The Nokia 770 is not a phone. It has speaker and headphone jack but does not have an input jack for a microphone. However, you can establish a Bluetooth connection to a (Nokia brand works for sure) Bluetooth capable phone and do Internet connectivity that way.

Just as I mentioned in my previous post, I had decided not to carry two devices (phone and PDA), but now days I am making an exception with the 770 and will be looking for a Nokia phone that can work well in partnership with it. Keep in mind that the 770 is a relatively new offering from Nokia and that its next evolutionary incarnation will likely improve on a lot of the shortcomings that the trade press and existing user base has pointed out to its maker.

My next endeavor related to the Nokia 770 and to mono is to create a deb package for mono so that it can be installed an uninstalled by using the package manager that comes with the 770. Later I will create another package that will probably install PEditGtkSharp just as a sample of a simple mono app that can be install using menus and checking for the prerequisite mono package etc. If anyone has experience creating Debian packages and wants to point me to a the "Hello World" of deb package creation tutorial, send me an eamail or leave a comment on this blog entry with a URL and I will be very grateful.

Clarifications on the Feb 2nd Conference in Puerto Rico

The name of the conference is the Caribbean Software Conference. It will be held in the very nice San Juan Mariott Ballroom in Condado. There is a $80 attendance fee but I believe it includes lunch. This also means that it is open to the general public!

Return to the Island and The Hall

My good friend PJ Cabrera left some comments on my previous blog entry, and I wanted to highlight it for anyone interested in software development that targets Linux base hand held devices.

The Bayamon Campus of the Interamericana University in Puerto Rico has invited me to take part of a conference in which I will give a 45 minute presentation on the use of Open Source in the enterprise. Their conference will be held at the Baymon Campus on February 2nd. I don't know if it is open to the general public but I presume that it is intended for their Computer Science alumni. I will be in Puerto Rico until the 8th of February, so if you want to get together to talk about mono or other cool stuff, send me an email to paco at mfcon dot com.

Mono Hall of Fame

Back in September 2004, my reporting official at Healthvision asked me during my annual evaluation what were my goals for 2005. I told him that I was going to work very hard that year to make it into the Mono Hall of Fame. He said that this was a good goal but that he was looking for something a bit more associated with our department goals. Is a good thing that both my ex boss and I are no longer employed by Healthvision and that I left before the next reporting period because I would have had some points taken towards my next pay increase ^_^.

Now that I made you smile, I would like to call your attention to someone that I truly believe is an unsung hero. This guy is always helping others both in IRC and in the Mailing list and has also contributed with Mono.Posix libraries as well as great helpful tools like type-reflector. He has also done the technical review for a pretty good book on cross platform .NET development and as far as I know he is not in the Novell payroll as a mono developer. Jonathan Pryor (jonp) does not have a blog (that I know of) so I can't link him directly, but if you see him over in IRC or if you want to leave a comment in this page feel free to give Jon a pat in the back.

Thank you jonp.

Update:
Turns out that Jonathan does have a blog.

Mono and the Nokia 770

My house has over 8 hand held devices that have accumulated over the past 9 years and range from casio units that run the earliest versions of Windows CE to Kyocera SmartPhones that run Palm OS. These mobile units were acquired most often as part of some software development project that required it.

I will admit that my last three phones have always been a smart phone type capable of some mobile computing for pim and even web browsing. I can program on Palm OS, Windows CE C/C++ and even did some development using MS Compact Framework on Pocket PC 2002.

Here is my revelation to you. I had given up on carry a separate personal digital assistant (PDA) and a phone. It just did not make sense to have your agenda, contacts and todo list on a device but still have to carry another piece of equipment to make phone calls.

One day I got a hold of the Kyocera 6035, a palm powered CDMA cell phone that to this date has come closest to the ideal device. In fact, my wife and I got matching his and hers units – she still uses hers. However, I am nothing short of clumsy and abusive with my cell phone equipment and eventually broke it (only after having it for 2 years!). Have any of you ever programed a Palm OS application? How about a Windows 16 bit application with a nice segmented memory model? Well, suffice it to say that I am not into self flagellation.

Then came a couple of Pocket PC devices. I am an old MFC programmer so programming for it was both easy, fun and very well documented. There were two reasons why I never really felt I had reached Nirvana. First you still needed to have a separate set of development tools to write these applications and the second problem was that I could never find or at least afford decent hardware.

So, for the last year and some change I have settle for a Treo 600 to get a good phone and PDA features (although some clown decided not to include a digitizer for hand writing grafiti). This also meant that I gave up on programming for my mobile unit.

A NEW ERA

I had read Paolo Molaro's September 2005 blog entry when he heralded mono running on the Nokia 770. I did very little homework then and only knew that it was a PDA (or something like it) that use Linux. Hey, for all I knew, it was just a Nokia made Zaurus. More than once I picked up Sharp Zaurus units and took them as far as the cash register over at Fry's Electronics, but would always chicken out when I had to shell out the $500. My Zaurus stalking period was at a time when I was impressed with Qt and had not yet fallen in love with the back then “new born” mono project.

Finally, a couple of weeks ago I asked lupus while conversing on the #mono channel, if he found himself using the 770 beyond just programming. He told me that he really liked it. Well, I bought one and finally had some time in my hands to install mono and a few other niceties like a Bluetooth keyboard and some additional apps.

As you can see on the picture below, you can run Gtk# 2.0 applications. The picture shows the same PeditGtk application I have been bundling with the Mono Combined Installer for Windows (samples directory).

If you don't have a Nokia 770, buy one or two. I have a feeling that I will be making a few more blog entries in relation to this awesome device.

Gtk# Experimental Runtime for .NET

Just a quick note. Just finished the Gtk# 2.7.1 Installer for .NET Framework Runtime 1.1. Like its older brother (the SDK one) it includes GNOME 2.12 and GTK+ 2.8. The biggest difference is that this one is as light as I could make it -- a single exe file that weights under 15 MB. This is possible because it does not include header files and development libraries, nor does it include samples or glade-2.exe (the GTK GUI designer tool).

Starting Monday, I will begin working on the mono project Wiki trying to clarify the difference between all the installers I have been putting out lately and the great timely ones that Novell puts out.

The last thing I want to point out, is that the Windows folks will probably be quite in synch with the technologies that will be available once SUSE 10.1 gets released. This is no coincidence, I was burning all of this midnight oil because I want it for all of us to get ready for the multi-platform goodness that mono 1.2 will achieve.

Along those lines, I have been playing with the idea of creating a simple Gnome# application that will be wizard (druid) driven so that developers can create, installers for their mono/.NET Gtk# applications with relative ease. Even though it will initially generate Inno Setup *.iss files, the community will be able to contribute by adding other installer formats and build systems. In the end, it could even create makefiles (nmake and gmake), NAnt files, auto* tools files (*.am, *.in) and maybe even package in archives like zip, gz and/or bz2. The app will run cross platform (for sure Windows and Linux -- will see about Mac afterward) and the output it produces will be aimed at distributing your applications in a platform optimized way. This mean creating Start Menu shortcuts for your Windows deployment target and Gnome menu and application registration for Linux.

MonoDoc in Windows

Last night we finally managed to build a slightly modified version of MonoDoc -- the changes may already exist in SVN trunk -- that runs in Windows. A new version of the Mono Experimental Combined Installer has been uploaded to Novell Forge so that it includes this much needed breakthough.

You can view a demonstration on how to launch MonoDoc in Windows.

Notice that you have to launch it with the --no-gecko parameter so that it falls back to using gtkhtml as its renderer.

Enjoy!

Gnome# in Win32 for the .NET Framework

In the spirit of all this experimental work, I am proud to present a Gtk# installer for the .NET Framework SDK 1.1 that includes Gtk# 2.7.1 and working Gnome# libraries that bind against GNOME 2.12 platform and desktop for Win32. A runtime installer for .NET will soon follow.

My most sincere gratitude goes to my usual supporters like Daniel Morgan, Paolo Molaro, Atsushi Enomoto, Sebastien Pouloit and Todd Berman.

I want to make a special mention of appreciation:

Peter Johanson and the Medsphere company for using and constructively comment on the installers for .NET. Paolo Borelli and the rest of the GtkSourceView hackers. Jonn Luke, Todd Berman and all other contributors of the GtkSourceView# library. Finally, the greatest applause goes to Miguel de Icaza, Mike Kestner, and Tor Lillqvist who's hard work makes it possible for Windows, mono and .NET developers everywhere to realize the dream of cross-platform development in a way that is fun an creative.

Harvest Time

Just a quick update. Enough advances have been made, and although there is still a lot of work to be done to get MonoDoc and MonoDevelop working in Win32, I did not want to keep folks that want to begin experimenting with Gnome# in Windows.

Therefore, I have put together another incarnation of the Mono Experimental Combined Installer for Windows. Some of the highlights are:

* Use of mono 1.1.13 and Gtk# 2.7.1 bound to GTK+ 2.8

* Inclusion of libmono.a so that folks trying to work with mkbundle can work with it.

* A sample application (PEditGtk2) that demonstrate GtkSourceVeiw# and some use of FileChooserDialog

NOTE: The installer is pretty big (over 54 MB). This is why I have used a segmented approach (an exe and 4 companion bin files) to make it a bit more tolerable. Should you want to run the installer, you would have to download all files to a common directory and run the exe from that directory.

Gnome# in Win32: Closer, Closer...

A considerable breakthrough was achieved yesterday. Using the MinGW/MSYS build environment provided by the installer I had been working on. I got the GtkSourceView 1.4.2 unmanaged component to build right. Later, I figured how I could make GtkSourceView find the language spec files. I had to create a .gnome2/gtksourceview-1.0 directory in my Window's user %HOMEPATH% and move all the spec files there rather than in the customary /usr/share/gtksoruceview-1.0.

PEditGtkSharp2

Another Gnome on Win32 discovery came when I realized that gnomeui-2 opens some sockets during it's initialization. This may not be the case in Linux (there, it probably uses file sockets). However, before I figured what was going on, anything (for example a simple invocation of Gnome.About) would make programs crash in a less than friendly stack trace that was clearly way down in the unmanaged bowls of the system.

Finally, it turns out that ws2_32.dll (Winsock 2) does not have the same exports in Windows 2000 than it does in Windows XP. As a result, the Gnome/Gnome# is working good in Windows XP but breaks in Windows 2000. I will keep everyone posted as I tackle MonoDoc -- specifically browser.exe which now compiles but craps out at runtime.

Building Mono in Windows for 2006

Background

On the one year anniversary of the article that Kevin and I put together about building mono in Win32, we are still missing important pieces that keep us from realizing our original goal. The goal was to document this tricky process well enough so that more than a handful of folks could build and or patch their mono runtimes and programming kits with relative ease. A mayor contention point remains the core environment that up until now, remains being Cygwin.

Cygwin is a *NIX emulation layer and environment that provides all of the GNU pieces needed to build and even run a great number of traditional as well as new Linux applications in Windows. Depending on how you decide to configure it, you could get a great selection of programs that rage from utilities like tar and grep to servers like PostgreSQL and Apache as well as everything else in between! As with many other great Open Source projects Cygwin has progressed to even include X windows and almost all of the Gnome desktop (KDE is also available). A lot of these applications and other facilities are designed and are dependent of the cygwin1.dll (the main function repository for the *NIX emulation layer it provides).

Mono as well as the Microsoft .NET Framwork are examples of very far reaching systems that are made up by a multitude of components and subsystems. Unlike a stand alone software notepad or calculator which may only have a dozen or so source code files, mono has over 13,000 of them. Building such a system requires a great degree of sophistication and experienced developers that devote a lot of their hours to the build system itself. In the world of Open Source software, the GNU project has had a collection of subsystems that facilitate the compilation, testing and packaging of software projects sometimes referred to as the auto*. These include Automake, Autoconf, Libtool and a few others. The mono project's build system was designed to take full advantage of the GNU auto* tools. In operating systems like Linux and FreeBSD these tools are a mainstay and are usually included even with the most minimalistic package selection that hints of a software development intention by the configuring user.

This is were a system like Cygwin comes in when one tries to write a single build system that will work for all operating system platforms that mono targets. In Microsoft Windows (2000, XP, 2003, etc) one can use Cygwin to build mono. It is important to note that we only use Cygwin for the auto* tools and that we are able to create a "Cygwin Free" product thanks to a gcc compiler flag (CC=gcc -mno-cygwin) that forces independence from the cygwin1.dll.

The -mno-cygwin flag alerts the linking process to use MinGW libraries. MinGW and MSYS are themselves a fork of the original Cygwin project that have the same objective of bringing GNU and POSIX functionality to Windows but effectively cut down on the complexities, dependencies and weight that Cygwin could impose.

In fact, many of the ported components that are at the root of GTK+, mono and applications like the Gimp for Win32 were built using MinGW so that they would not depend on cygwin1.dll.

The Problem

You see, when O'Reilly published our article, I tried to "bottle" a vintage of Cygwin in a CD that would be optimized for would be mono builders in Windows, but it came at an enormous 400+ MB. It took me about three weeks to understand and learn how to transform the proprietary on-line installer and software distribution system that Cygwin uses, in order to make it run from a CD by clicking on a menu option on an autorun application I created.

Today you could get the latest and greatest Cygwin but you would have to be so careful to not pick and install components like their glib or GTK parts since it would be incompatible with the ones that we use for mono and Gtk#. There are articles out on the mono wiki that are very well written and will even tell you what to do and what to stay clear off, but I believe there has to be a better "one installer does it all" way of doing this.

The Proposed Solution

For the past couple of weeks I have been putting together an installer that brings MSYS, MinGW and some additional tools and configuration settings with the mono developer in mind. A design objective has been to try to keep it down to one downloadable file that weights in under 30 MB. It should be parallel installable with existing copies of Cygwin or Microsoft Windows Services for Unix. It should use an Inno Setup installer that will use similar conventions as the Mono Combined Installer for Windows and the Gtk# Installer for .NET Framework. Should there be any environment variables that are determined needed by the mono build system, these would be already included in the /etc/profile so that all users inherit them on first use. Finally, instead of lumping all subsystems and components into an opaque blob, there would be a detailed granular selection that clearly states that component's name its size and the version packaged.

I already have a first prototype that is quite complete in content but did not effectively build a mono tarball on my first try. You can find the installer here.

At this point I ask for anyone that has made it this far into reading this long blog post to leave me feedback and tell me what he/she thinks about this endeavor. Ideally, the mono community could polish a build environment that we can call our own and that can be consistently depended on and shaped to our liking and needs.

Choosing a runtime for your .NET App while in Windows

Almost a year ago, we gave a presentation to what was then the Plano .NET User Group. Some of the highlights of that evening were captured on video. A CD size download was later put together -- with a lot of trouble and thanks to the generosity of community members -- we managed to distribute it to a lot of folks. My good friend Erik Dasque commented then that he thought it would be even better if we could create some flash presentations of what we had on the CD.

Meanwhile, back at the [Mono-hispano] mailing list... A few folks had an ongoing discussion about launching a .NET application but ensuring it would be handled by the mono runtime. This one fellow, not knowing any better, was describing a way of creating more batch files to launch applications in Windows. The wise Mario Carrion came to the rescue pointing out that a lot of this had already been thought about and that a work around existed called the "mono Runtime Seletor" (a.k.a MonoLaunch). The one guy then pointed out that it was all nice and great but, there seem to be no documentation on how to employ this "MonoLaunch".

This has prompted me to put together a few descriptive pages along with some brief videos that can further depict the use of VSPrj2make#, MonoLaunch and a couple of other new developments like availability of Gnome# in the Experimental Mono Combined Installer for Windows.

VSPrj2make

• Installing VSPrj2make
• Using Test in Mono to Run a Windows Form Application
• Using Test in Mono to Run an ASP.NET application

MonoLaunch

• Create .NET app using Visual Studio .NET 2003 and execute with the Microsoft .NET Framework Runtime
• Run a .NET application using mono as the runtime -- allowing a win32 console to show stdout.
• Run a .NET application using mono as the runtime -- without a win32 console.
• Build a .NET application that uses Gnome# from the mono command line.
• Execute a mono program using different mono versions using the Mono Runtime selector to switch between versions.