Oscar Papel's Web Log

Windows.Forms and Mac OS/X

2005-04-05T16:49:00.000-04:00

I decided to create a step-by-step tutorial on how to get Windows.Forms based PC apps running on Mac OS/X. As an outsider to the project, I'm going to restrict myself to public releases.

Prerequisites:

Before we begin, we need to check the minimum system requirements:
- Mac OS/X Panther 10.3.x (I used 10.3.8)
- X11 for Mac OS/X ( this is an install option for Panther located on the third CD ). This requirement may go away in the future but for now just make sure you have it installed.

Step 1: Get Mono

Download Mono.Framework-1.1.6.dmg from the Mono website (http://www.mono-project.com/Downloads).

Double click on the .dmg file to mount the disk image. A drive icon like the one above should now be on your desktop. Double click on the drive in order to see it's contents.

Step 2: Install Mono

Double click on the package file. This will start an installation of Mono onto your hard drive.

You need to follow the instructions and complete the installation. Once you are done, you will be ready to begin writing your first Mac Windows.Forms "Hello World" program.

Step 3: Creating Hello World

In this step, we will be creating a simple Message Box based program to test our installation. Start TextEdit and lets write a simple C# Windows.Forms program.

This program won't win any design awards but it will create a Message Box with a text message (the ubiquitous "Hello World"), and an OK button. Make sure that when you save this file that you don't add a .txt extension to the file!

We now need to compile this simple program. We need to start Terminal in order to do this. Launch Terminal and change your directory to the directory that you saved your Hello.cs file to. I saved it to a subdirectory of "Documents" so at the command prompt I typed:

cd ~/Documents/Hello

You'll need to do something similar.

we can now launch the compiler. At the prompt, type:

mcs Hello.cs /r:System.Windows.Forms.dll /out:Hello.exe

If you didn't make any typing errors, you should now have Hello.exe in addition to Hello.cs.

If this was a PC, we would be done now but since we are on the Mac, we need another step. We need to MacPack the exe we created so that it can play nice with the Mac's GUI. Type the following command at the same prompt you used to compile.

macpack -n:Hello -a:Hello.exe -o:. -m:1

This will create a Mac bundle that contains our sample and that can be launched by clicking on it in the finder.

Step 4: Hello World

Clicking on the Hello App in the finder should give you the following message box.

Clicking the OK button closes the app.

Addendum: MacPack, an explanation.

Mac Applications exist as App bundles. A bundle is just a subdirectory containing an executable as well as all the resources that the executable may need (such as icons, images, sounds, plugins, help, language packs, etc). In fact, the bundle we created above (called Hello) is really just a subdirectory called Hello.app. These bundles need to conform to a particular structure so that they interact with the finder and dock properly. This is where macpack comes in. It creates the necessary directory tree, a configuration file, and a launch script for your exe.

The finder reads the directory tree and realizes that it is really an App and treats the bundle like a single file. If you want to explore the subdirectory, you need to right click (or Ctrl-click for single button mice) and select "Show Package Contents". This will let you bypass the Mac "magic" and explore the contents of the subdirectory. This magic doesn't exist when you are in terminal. Terminal always shows the App as a directory. The only thing that should be in the root directory of the App is a Contents subdirectory. Inside this subdirectory are the Resources and MacOS subdirectories as well as the Info.plist file.

Info.plist
The Info.plist file configures the bundle. Double clicking on it should launch the property list editor. There are two entries created by default when you use macpack. CFBundleExecutable specifies which executable (located in the MacOS sub) should be run when the app is launched. CFBundleIdentifier specifies what name should be displayed for this app in the finder. There are a few others that you might like to use.

Custom Icons
First, you may want to use a custom icon. Create a new Hello.icns file using Icon Composer (part of the XCode Developer tools, another optional install included with Panther) or just borrow an icon from the Resources section of another App. Copy this file to the Resources section of Hello.app and add a new entry to the Info.plist file where key=CFBundleIconFile and value=Hello.icns (or whatever it is called). You now need to force the finder to update it's picture for this app. Dragging the app to the desktop and then back again should do it. Making a duplicate of the App also works.

"APPL" status
Your app is ALMOST a fully fledged Mac App. One thing it can't do, however is get dragged to the dock. That's because the dock doesn't know that it is an App. There are many bundle types used by Panther and an App is only one of them. Frameworks are also bundles. So are installation packages. Obviously it doesn't make sense to drag a framework (like Mono.Framework, for instance) to the dock so we need to tell the Dock that this bundle is really an App. We do this by adding another entry to the Info.plist file where the key=CFBundlePackageType and the value="APPL" (for application). Once you have done this, your app can now be dragged to the dock like any other Mac App.

Epilogue:

The astute among you will realize that although I stated that X11 was a requirement, we didn't actually do anything with it. It does not even need to be running for S.W.F apps to work. This is because, as it has been explained to me, the only part of X11 that is being used is in the text rendering. This means that it is theoretically possible to remove the X11 requirement in the future. As you can see from the screenshot, the X11 rendering is far from exceptional. Also, I have been told that S.W.F on Mac is still considered to be in the Alpha stage. Therefore, not all S.W.F apps will run flawlessly. My advice is to not rely on full S.W.F functionality until at least beta :)

Oscar

When is a sort not a sort...

2005-01-18T22:15:00.000-05:00

I've been expanding on the classical image processing in Damocles lately. Specifically the Rank Operator. It works like this, take all the pixel values around a central pixel, sort them by value, then replace the central pixel with the minimum / maximum / median / r th pixel from the sorted list.
Now, it seems obvious that you don't need to actually sort data to find the min or max value from a list. Finding the min/max of a list is an O(n) operation. Any other position in the list, however, is usually calculated by doing a full sort, then returning the rth ranked item from the list. A quick glance at this shows that you are performing an O(n log(n)) or O(n^2) sort in order to generate one number, then throwing away most of the data. Yet, this is how most software performs median filtering. It's really no problem when your neighbourhood is small (3x3 cross or box) but as your kernel size grows, the sort becomes the biggest concern.
So how do we avoid it? By using a slightly different definition of median. Traditional processing says that for any N items, the median value is the N/2th value after sorting. We can also use the following definition: the median value is the value that has the same number of values greater than it as smaller than it. Formally,

Median when either
1) smaller=larger
2) smaller < larger AND smaller+equal>=larger

The second test allows for duplicate values in the list and for even values of N. This is a generalization of the min test or max test. The min test is smaller==0 while the max test is larger==0.
You can generalize this to any position in the list as follows:

(zero based) r'th in list when either
1) smaller=r
2) smaller<r AND smaller+equal>=r

In this manner, we only need to keep track of how many items are smaller and how many are equal.

Also, every time we test a value, we can use the results to fine tune the next iteration. For example, if a value of, say, 63 is determined to be too small to be the median, we can ignore any values in the list <=63. Likewise for values that are too big. By doing this, you progressively narrow the allowable range and avoid testing many values in the list.

Finally, when largest_possible==smallest_possible, you don't have to do any more testing at all, just return smallest_possible.

 

// ----------------------------------------------

// Function: Rank

// Parameters:

//    list: an array of (type)

//    length: number of entries in list

//    rank: rank within list [0..length-1]

// (floating point data needs code changes)

// ----------------------------------------------

(type) Rank((type) *list,int length,int rank) {

   (type) temp;

   (type) smallest=Smallest(type), largest=Largest(type);

   int i,j,lower,same;

   for (i=0;i<length;i++) {

      temp=list[i];

      if ((temp<=largest) && (temp>=smallest)) {

         for (lower=0,same=0,j=0;j<length;j++) { 

            if (list[j]<temp) lower++; 

            else if (list[j]==temp) same++; 

         }

         if (lower==rank) return temp; 

         else if (lower>rank) { 

            if (temp<=largest) { 

               largest=temp-1; 

               if (smallest==largest) return smallest; 

            } 

         } else { 

            if (lower+same>rank) return temp; 

            if (temp>=smallest) { 

               smallest=temp+1; 

               if (smallest==largest) return smallest; 

            } 

         }

      } 

   }

   return (smallest+largest)/2;

}

A 3x3 rank is usually done with a modified bubble sort (for simplicity, code size, and partial sorting capability) that stops after r iterations in the outer loop. This routine compare well with this.
This code performs well on random data usually beating O(n log(n)) (quicksort et al). On identical data, it is O(1). The pathological worst case is when the numbers are sorted into max, min, max-1, min-1, max-2, min-2, etc. In this case, the operation performs O(n^2) or O(n*range(type)) whichever is smaller. This is not a naturally occuring pattern in image data, however. On large lists, the range(type) clamps the log(n) term to log(range(type)) so performing extremely large ranking operations becomes possible with no additional computation (free!)

Oscar

Firewire is an onion...

2004-12-08T23:23:00.000-05:00

I've spent about a week pouring over Firewire documents. There are a few. I've summarized the important specs and tech data below.
The first document is commonly known as CSR although it is formally known by ANSI/IEEE 1212-2001 or by ISO/IEC 13213:1994. CSR stands for Control and Status Register and describes a method for devices to communicate via a shared memory address (64 bits). The basic operations are read/write a quadlet (a 32 bit value), read/write an octlet (a 64-bit value), read/write a block (arbitrary size) and lock. The commands are completed asynchronously (i.e. non-blocking) but a software abstraction layer can create the illusion of synchronous calls. CSR describes how a bus can work but is not tied to any particular implementation.
The next document is known as IEEE 1394-1995 or 1394a-2000 or 1394b-2002 High Speed Serial Bus. It is an implementation of CSR. It describes a hot-pluggable bus that can provide power as well as data transmission, typically at 400Mbps (the most common) but can go faster (3200Mbps) or slower (100Mbps) with the newer "b" spec. The bus creates a tree topology with a "root" having possibly multiple children. This tree can contain up to 63 nodes but due to bandwidth reasons there is usually far fewer (eg 1 or 2) devices. Unlike the popular USB2.0 spec, this bus is equally at home connecting computer to device, device to device or computer to computer. This allows it to be equally at home connecting consumer A/V equipment or connecting two (or more) computers. It does have a weakness, however. It's enumeration mechanism does not handle circular connections well. In other words, there can only be one path along the tree from one device to any other.
Another key capability of this bus is isochronous communications. This allows you to pre-allocate bandwidth so that time based data (audio/video) will be guaranteed to have the bandwidth available. Asynchronous communications have to use the remaining unallocated bandwith. There is a minimum amount of bandwidth reserved for asynchronous so that other devices are not starved out (typically 20%). This means that the maximum isochronous bandwidth a S400 device can allocate is about 320Mbps.
Due to it's "hot pluggable" nature, every time a device is plugged in or unplugged, the bus is reset and re-enumerated. The devices that were transmitting isochronously get a chance to reallocate their bandwidth. This can cause a "blip" in the data stream. Software can be notified of a bus reset and take appropriate action. Since the node address can change with a reset, each device has a unique ID available known as an EUI-64. This ID is formed from a 24 bit Vendor ID (assigned by a central authority) as well as a 40 bit serial number assigned by the vendor. Two otherwise identical devices will have distinct EUI-64's.
Every Firewire device must implement a minimum amount of CSR registers. This allows the enumeration mechanism to work as well as determine what protocols the device understands. It also determines the bus capabilites of the device. A device can be a cycle master (it can generate the bus start of cycle packets), an isochronous manager (isoch. bandwidth and channel allocation mechanism), or bus manager (supply and manage power, bus optimization and root determination). The bus can operate without a bus manager but both devices must supply their own power. A device does not need to be any of the above.
The CSR's form directories with offsets pointing to where to find other directories. This allows for a generic tree configuration. The Bus Info Block is first and is always located at offset 0x400. Immediately following is the Root Directory that describes the device and contains offsets to unit directories. A device can support multiple protocols and multiple versions of the same protocol. Each unit dependant directory lists a protocol by Protocol ID and spec version # and the offset where to find the CSR's that control the device using that protocol and version #.
The next spec to read up on is the IIDC 1394-based Digital Camera specification version 1.30, 1.20 or 1.04 (also known as DCAM). It is a defined by the 1394 Trade Association Instrumentation and Industrial Control Working Group, Digital Camera Sub Working group (II-WG DC-SWG). It's purpose is to define a command set for digital cameras that use the firewire bus. This is a completely separate group from the DV group which comprise a whole laundry list of specs. More importantly, it defines uncompressed digital camera operations. DV cameras use a lossy MPEG2 video compression variant to transmit data.
The spec provides several inquiry registers that allow you to determine what data formats, frame rates, image sizes, etc. are available. This allows software to choose a configuration that it can deal with and ignore the others if it wants. There are 5 standard formats each with standard image sizes and frame rates available for compatibility purposes as well as a fixed image format (for still cameras) and a flexible format where you can configure your camera's options known as Format 7. This is by far the most flexible format and allows you to change every aspect of your image data.
The spec also defines standard image controls (Brightness, Auto-expose, Sharpness, White Balance, Hue, Saturation, Gamma, Shutter, Gain, Iris, Focus, Temperature, Trigger, Zoom, Pan, Tilt, Optical Filter) as well as the level of support for each of these capabilities (not present, read only, read-write, auto-mode, one-push mode, disable mode, valid range). Format 7 also allows you to specify the Region of Interest within the image as well as the valid sizes available. Finally, you can choose your data format (YUV4:2:2, YUV4:1:1, RGB8, Y8, Y16, etc). Additional, camera specific, controls can be added in an advanced CSR controls directory but additional info is required from the manufacturer in order to identify and translate these CSR's into camera features. The most important of these is binning options. Finally, once you have set up your camera, you can tell it to acquire one image (one-shot) a series of images (multi-shot) or a stream of images (stream). Of course, if your camera is a still camera, isoch stream will not be available.
In general, the specs work together as a protocol stack to cover and define a very wide range of objects. There is a spec for Hard Disks, printers, keyboard, mice, generic masss storage (media keys), CD/DVD drives known as SBP-2 and more recently SBP-3. As mentioned before, consumer DV video falls under many specs such as AV/C and HAVi. RFC 2734 defines how to layer the IP network protocol on the 1394 bus. Peruse these at your leisure the next time you get insomnia. Oh, and by the way, the official PDF of the specs are all sold online for about $100 a pop. Happy reading.

29.97 fps? what's up with that...

2004-11-26T20:23:00.000-05:00

I've been recently delving into the IEEE-1394 specs (also known as Firewire or i.Link). It is a general purpose bus that, unlike USB, is not PC specific. The various specs work together in stack fashion similar to the ISO network stack with each layer building upon the layer below. The bus is capable of asynchronous communication but it is it's isochronous capabilities that make it suitable for carrying time-based data such as video and audio.
The Firewire 400 spec (1394a) uses a native 125 ns clock. When video transfers over firewire isochronously, the necessary bandwidth is reserved first. Once this is done, you just start streaming and wait for the video to pour in. Each frame of video is divided into bus frames. When the first frame's reserved bandwidth is filled, the remaining data is sent in subsequent bus frames. Well, it turns out PAL video (25fps) transfers just fine since a new video frame starts every (8000/25) 320th bus frame. However, NTSC video (30fps) has a problem. 8000/30 is approximately 266.6666 repeating. This means that a minimum of 267 frames are necessary (the last frame is padded out). This means that a 1/30th of a second is really 267/8000 of a second which gives you a frame rate of 29.962546816479 fps.
Audio is different. Audio has no inherent audio frame the way that video has a video frame. You can sample audio at whatever frequency you want and with as much precision you want from as many independent sources you want. You can divide it up into packets of whatever is convenient for transport without any fuss at all.
So what happens when you try and sync separate audio and video sources? Well, if the video is timed at 29.97 fps but the software assumes it is 30fps then after an hour, the lip movements will be almost 135 video frames out of sync.
It is important to realize that you can avoid this problem completely if you change your camera so that video frame boundaries do NOT coincide with bus boundaries. Then, your video data is just a stream of bytes that will always fit neatly into bus frames, albeit starting generally somewhere inside a bus frame instead of at the beginning. You need to add information to your video data to recognize a frame start. A little bit of overhead and complexity solves this problem.
So there you go. Crazy frame rates explained.

How sharp is sharp?...

2004-11-18T01:24:00.000-05:00

Ok, I just came across an article over at cross-platform.net that talks about doing precisely what I am doing with Damocles, namely, writing cross-platform native code that has a managed cross-platform binding in C#. The article mentions that my design pattern has a very subtle bug that can occur due to the fact that the C# garbage collector might kick in AFTER marshalling the args to an interop call but before the call actually finishes, causing the (admittedly highly unlikely) problem where the finalizer gets called and frees the unmanaged object too soon.
Now, this can't occur if you always dispose of your objects properly. It is slightly more likely to occur in a multithreaded scenario since the GC can run simultaneously with unmanaged code. Regardless, the solution is easy, and so I've decided to add it to the DamoclesSharp project.
It boils down to this: Instead of storing a private IntPtr, you instead store a HandleRef which contains an IntPtr. It also contains a reference to the managed object forever tying the managed and unmanaged sides together. This way, the managed object is held until the HandleRef is disposed of, thereby guaranteeing the lifetime of the original object.
Is it a bug? Is it just a theoretical possibility that would never happen in real life? It sure hasn't happened yet, but I haven't run any multithreaded tests either. Also, even though the possibility is very small, the consequences are huge. Processing memory that has been freed can result in a segfault or even cause the Blue Screen of Death if processing a buffer owned by the kernel, (say a video buffer that was wrapped).

So the code now looks like this:



public class Image : IDisposable {



private HandleRef native=NULL;



public Image() { ... }

public Image(IntPtr NativePtr) { native=new HandleRef(this,NativePtr); ... }

~Image() {....}



#region IDisposable implementation

...

#endregion



#region Interop calls

[DllImport(Damocles.DllName)] private static extern IntPtr AllocateImage(...)

[DllImport(Damocles.DllName)] private static extern void AddImageReference(...)

[DllImport(Damocles.DllName)] private static extern void FreeImage(...)

... other Interop functions here ...

#endregion



}

So this way, we avoid getting cut with DamoclesSharp (I'm sorry, I couldn't resist the pun!)

Damocles is Sharp!

2004-11-11T20:18:00.000-05:00

Damocles can also be used from any managed language. Known as DamoclesSharp, it is a library that provides managed wrappers or equivalents to the C "objects" of Damocles. A typical class looks like the following:



public class Image : IDisposable {



private IntPtr nativePtr=NULL;



public Image() { ... }

public Image(IntPtr NativePtr) { ... }

~Image() {....}



#region IDisposable implementation

...

#endregion



#region Interop calls

[DllImport(Damocles.DllName)] private static extern IntPtr AllocateImage(...)

[DllImport(Damocles.DllName)] private static extern void AddImageReference(...)

[DllImport(Damocles.DllName)] private static extern void FreeImage(...)

... other Interop functions here ...

#endregion



}

The class is implemented with the unmanaged resources design pattern. That is, it creates, modifies, and frees an unmanaged resource (in this case, our C "object"). It implements IDisposable to signal that it contains unmanaged resources and it implements a finalizer that works with the IDisposable implementation to ensure that the C "object" will be freed when the managed object is. Again, the object can create the underlying C "object" or can be created to wrap an existing one.

Just like the ObjC implementation, the C# implementation works with the C memory management to ensure no memory leaks.

Also like the ObjC implementation, there are some optimizations in place. Since the IntPtr is just a managed wrapper around a pinned address to memory, there is no need to cross the interop boundary to read/write the contents of the underlying object. Care has been taken to compensate for the size of the pointer during this. As a result, reading and writing the object properties can be done without incurring an interop penalty. Again, just like the ObjC optimizations, any code using the class is completely unchanged and continues to work as before.

This code wraps Damocles.dll on the PC and libDamocles.dylib on the Mac. A simple config file makes this interop layer code portable.

Damocles from C to ObjC

2004-11-11T18:16:00.000-05:00

Now that we have some memory managed "objects" in C with some functions that use them, we need to make real OO objects. Each ObjC object has a corresponding C "object".



@interface NSImage : NSObject {

Image *image;

}

- (id)init;

- (id)initWithImage:(Image *)pImage;

- (void)dealloc;

..... other messages ...

@end

When you allocate a NSImage object, with the init message, it allocates an underlying C "object". When the dealloc message is called, either through a release message or indirectly via a [NSAutoReleasePool release] message, the underlying C "object" is released. This way, ObjC object memory management works with C "objects" to make memory management seamless.

When you allocate a NSImage object with the initWithImage message, it performs an AddRef on the C "object". This way, it gets it's own reference to the C "object" which it can release in the same way that the first NSImage object does.

All these ObjC objects get compiled into a native Mac Framework and can be directly used by any Cocoa-based Mac project. This is how EyeImage (one of our commercial products) gets it's functionality.

There are some minor variations. For instance, an ObjC NSImage object might temporarily allocate a C Image "object" in order to generate a displayable image then immediately deallocate it. For performance reasons, no ObjC object wraps this temporary object. Such cases are rare, however. Premature optimization is the root of all software evil. In this case, however, the optimization was deemed worth it. This optimization does not cause a change in any software that uses NSImage. Optimization across an interface boundary is almost always an indication of bad design.

Memory management in Damocles

2004-11-11T17:49:00.000-05:00

Memory management is a tricky subject when dealing with native code. ObjC uses reference counting similar to COM's. Managed code uses a garbage collector. In order to be flexible, Damocles has to be able to "wrap" buffers it didn't allocate and support multiple pointer references. This way, it can support multiple views/subviews of the same data. as well as be "held" by more than one object.

I came up with a reference counting mechanism that does both and simplifies memory management for non-trivial cases.

Each "object" is really a c-style structure that has fields, a pointer to it's data payload and a reference count.

example:



typedef struct {

void *pData;

S32 RefCount;

U32 width;

U32 height;

} Image;

S32 and U32 have been defined in os.h as a signed and unsigned (respectively) 32bit integer. os.h shields Damocles from platform differences in C's integer definition making the code more portable. Also, void * will be a 32bit value on 32bit systems and a 64bit value on 64bit systems.

When an Image struct is allocated, you have 2 options. You can pass a pointer to an existing buffer in which case RefCount will be set to -1. Calling AddRefCount on Image will cause RefCount to go to -2. Calling Free on Image causes RefCount to go back to -1. Calling Free again causes Image to throw away the pointer and deallocate the structure.

If you DON'T pass a pointer to an existing buffer, one is allocated for you and RefCount=1; Calling AddRefCount on Image will cause RefCount to go to 2. Calling Free on Image causes RefCount to go back to 1. Calling Free again causes the pointer to be freed and then the structure to be freed.

In this way, you can have multiple references to a struct that holds data that may or may not be wrapped. You can Free the Image in an arbitrary order to the order they were Allocated or AddRef'd and the last one will properly give up or deallocate the buffer properly.

This was critical to correct operation where you need to return a linked list of objects. This way, the list holds it's own reference. you can select an object from the list, AddRef it, destroy the list, use the object then Free it and everything works the way it should.

Obsidian, meet Damocles.

2004-11-11T17:22:00.000-05:00

As started in the previous post, Damocles was born out of the need to get native performance in my C# classes. Damocles is implemented in portable ANSI C. It is a collection of very low level functions to do imaging. It is not optimized to favour one CPU or another although I did do a lot of work to minimize the working set and instruction count. It is fast but not hand-tuned assembly fast. It does NOT use the Altivec instructions on the PPC or the MMX/SSE instructions on the PC. These will be addressed later. Damocles was designed to be a well performing PORTABLE base.

Considering the lack of niceties in plain C, it is amazing that elegant code can be written using it. Granted, when you are writing 18 versions of Boolean XOR, programming niceties aren't what gets the job done. It's small, efficient, tight code that does.

I mentioned 18 because that's how many different pixel formats that Damocles currently supports. That does NOT count paletteized versions. Due to the need to support higher than 8 bits per channel images as efficiently as possible, there is direct support for 8,10,12,14 & 16 bits per channel as well as single precision floating point support. Since there can be Gray, RGB, and RGBA colorspaces, that makes 6 choices for channel depth x 3 colorspaces = 18 pixel formats.

How to write Software... (part 4)

2004-11-11T16:09:00.000-05:00

I should mention that I have a bias towards C# as a language. It is modern, OO, and has lots of language features that lend themselves to writing elegant programs. I also follow the progress of the Mono:: and DotGNU Portable.NET open source projects that allow C# to run on several platforms. The platforms I am most concerned about are (in order) Windows XP, Mac OS/X, and Linux (x86 & PPC).

What is NOT available is a cross platform UI for C#. There are candidates (wxNET, GTKSharp, TK#, SWF, SWT) but they are either incomplete, defunct, or just not ready yet for all my platforms.

Well, the obvious choice was to separate UI from functionality (always a good decision anyway) and write my imaging library first in C#. By then, surely, there would be a UI that I could use. If I put my UI behind a C# interface, then I could even load a different UI for each different platform. The same with hardware support. Everything behind an interface. I just need to do a little reflection discovery at load time to see what I have available.

I designed the project and called it Obsidian. Why not. I wrote the discovery code and the library. Lots of formal interfaces.
It was implemented in several assemblies. A real medium-to-large size C# app sans a UI.

A year passed. I kept up to date with all kinds of projects, both commercial and free. And guess what. I got burned. No UI materialized that was even a 1.0 release. I even tried starting interest in creating a project called CocoaSharp. It was supposed to bring Cocoa (the Mac's native Object framework) into the managed world. I worked a few weeks on it and released a version 0.1 that wrapped a few key Cocoa UI classes. Nobody was interested in contributing to the work and I was looking at wrapping by hand hundreds of classes (which were changing underneath me with new OS/X updates). I gave up and e-mailed the code so someone who asked for it and called it a life lesson. Note that my CocoaSharp project predated but was otherwise unrelated to the current CocoaSharp project underway, at least to my knowledge.

As it turns out, processing pixels (even in unsafe code) is not a performance demon under dotNET 1.0 or 1.1 so I got to thinking that C# might not be the full answer.

I had some experience with Interop (the method that managed code interfaced with native code) while writing managed camera classes that linked with some native libraries on the PC and the Mac. It even chose at runtime which native library to use through the same discovery mechanism I had written for the rest of Obsidian.

I decided it was time to bite the bullet. Write the lowest level functions in C. Plain C. K&R C. no modern conveniences C. portable C. Then, I could wrap them into ObjC objects on the Mac, C++ objects on Linux, and C# objects wherever a CLR was available. Damocles was born.

How to write Software... (part 3)

2004-11-11T15:24:00.000-05:00

So, let's start. I need to write imaging software that is cross-platform. It should perform and feel like a native application on every platform it supports. It should also be able to take advantage of any platform specific features but degrade gracefully on platforms that lack those features. It should be capable of taking advantage of multiple processors. It should be pointer size agnostic (32 or 64 bit)

Programming language choices available to me:
C
C++
Managed C++
ObjC
C#
Java
Visual Basic
VB.NET

C : Granddaddy of them all
pro's - ubiquitous. performs well. portable.
con's - low level, lack of object oriented concepts, verbose.

C++ : C with objects
pro's - same as C but with OO concepts
con's - interfacing and binding are more difficult than C

Managed C++ : Managed C with objects
pro's - same as C++ but runs within the confines of the CLR.
con's - performance is not as good as C++, not portable.

ObjC - Native objects on OS/X
pro's - interfacing done at runtime
con's - not portable, message based calls slower than direct function calls.

C# - Managed C with objects
pro's - easy language, portable using mono or pnet on non MS platforms.
con's - performance is not as good as C, C++

Java - portable C-like language
pro's - portable
con's - different platforms have slightly different implementations, performance

Visual Basic, VB.NET - missing critical pointer manipulation

In the next part, we'll see what I chose and why I chose it.

How to write Software... (part 2)

2004-11-11T15:01:00.000-05:00

I guess I should mention that I'm talking here about writing imaging software. In other words, the software that I write creates, enhances, processes, analyzes and extracts and captures images. If I were a database programmer then this thread would be very different.

The first step in writing any software is gathering your requirements.

The "What's"
What should the software do?
What O/S does it need to run on?
What software does it need to interact with?
What hardware does it need to interact with?
What are the time constraints?

The "Who's"
Who is the end user/operator?
Who is paying for the software?
Who will maintain the software?

The "Where's"
Where does the software need to be developed?
Where will training/installation take place?

The "When's"
When does the software need to be done?
When is the software finished?
When are updates needed?

The "How's"
How will feedback take place?
How will upgrades occur?

There are a lot of questions. And I haven't asked them all.
Since software is never really done, the more questions you ask now, the better off you will be later in the product life cycle.
Note that these questions assume that you are being paid to write software. When you write software for free, most of these questions can be answered by "whenever I get to it" or "next time I'm doing something with that". There is a lot of freedom in NOT getting paid.

How to write Software... (part 1)

2004-11-11T14:47:00.000-05:00

This seems like such an easy thing to do. I mean, people write software every day. I don't pretend to know everything about writing software. There is so many different kinds of software out there that it would be foolish to think that there is ONE way that is best. But I have been thinking about this so I thought I'd write down what I've come up with as well as talk about some of my recent attempts at it. I don't have all the answers. I don't even have all the questions. Let's dance.