The Cardwin Project

At SourceForge Logo

Project Description:



  Windows 3.x and NT 3.51: both have an applet called cardwin.  It was used to keep a list of contacts in card format, alphabetically sorted on a 40-character  index.  I used it to keep a list of friends and family, and found it one of the more useful applets the OS came with.  When I moved to Win95, then WinME, I copied the old CARDWIN.EXE program to the new computer so I could keep my current lists.  Then I started using Linux, and wanted to get back into programming, which I left after finishing some database apps.  The concept  of compilers being included with an OS was  fairly new to me, which made me find Linux worth much more than other OS's.  However, this page is just about the cardwin app, so let's look at it now.

  In the KDE environment, the cardwin applet should look something like the  screenshots below.  The screenshots are just 300 by 225 thumbnails - if you want to get a better look at an image, click on it and a larger view will load, giving you better detail.


Screenshots: click to see images in better detail

Full screen image (click for larger view)
Full Screen - Cardwin shown in the foreground.

Empty Viewer (click for larger view)
The Cardfile Viewer, empty.
Viewer in action (click for larger view)
The cardfile viewer, with card data.


  This was created with the Gtk toolkit, which I find to be a good set of widgets, though too sparsely documented.  The command line used to compile the app it is shown in the release notes.  There are a few minor items that I have to adjust soon: one is a problem with the card list as it is displayed in the left hand pane: when the “Prev” and “Next” buttons are used to go through  the list, it doesn’t scroll when the item selected goes off the top or bottom of the window.  Another small item I just recently noticed is that there is no filename on the window title, even though it  appears to be specified in the code.  The next major item required, however, is the graphic image and how it should be handled.  I haven’t found much information about the actual format of graphic elements, so I’ll have  to do some experimenting. I have two sources of data: the MGC format was  found in the comp.windows.ms   newsgroup a few years ago, and is outlined below. The second source I found was the Microsoft Knowledgebase - Article Q99340, which outlines the RRG format.



Data file layout:

  There are (at least) two file formats used with the cardfile application,  which are identified by a signature in the first three bytes in the file.   All of the numeric data in the file is stored with the least significant  byte coming first.  The signatures are ASCII, either ‘MGC’ or  ‘RRG’.  The MGC format uses a header five bytes long, while the RRG's header is expanded  to nine bytes. The layout of each header is listed in the two tables below:


Header Format: MGC signature

Byte #
Description
0 - 2
Signature bytes ‘MGC’ (4D 47 43)
3 - 4
Number of cards in file (maximum 65535)


Header Format: RRG signature

Byte #
Description
0 - 2
Signature bytes ‘RRG’ (52 52 47)
3 - 6
Last object’s ID
7 - 8
Number of cards in file (maximum 65535)


  When a file is first created, it is given the MGC format. When an embedded graphic 'object' is put into any card, the file is changed to the RRG format. If all graphic objects are removed from an existing RRG format file, the file is rewritten using the MGC format.

  At the sixth MGC byte and tenth RRG byte in the file the index lines start   - the text at offset 11 in the index structure is what is displayed in the left side window.  The maximum length of index text is 40 ASCII characters.   Both formats use the same stucture for their record indexes.  Each card entry uses 52 bytes in the index, formatted as follows:


Index Entry Format: Both signatures

Byte offset
Description
0 - 5
Null bytes, reserved for future.
6 - 9
Absolute position of card data in file (32 bits)
10
Flag byte (00)
11-50
Index line text, null terminated
51
Null byte, indicates end of entry (why?)


  So the index for the first card will  start at byte 5 / 9, the second  at byte 57 / 61, third at byte 109 / 113,  and so on to the last index.
  After the indexed list (which is sorted alphabetically, by the way) comes the data for each card, in the same order as the index entries. The data will be in one of four general formats: blank, text only, graphic & text, or graphic only. A blank card will have four null bytes in this field, the data for the other card types are listed in the tables below.


Data Entry Format: MGC signature

G & T
T
G
Description
0 - 1
0 - 1
0 - 1
Length of graphic bitmap (lob)
2 - 3

2 - 3
Width
4 - 5

4 - 5
Height
6 - 7

6 - 7
X-co-ord
8 - 9

8 - 9
Y-co-ord
10 - eob

10 - eob
Bitmap Graphic
eob +1 - +2
2 - 3
eob +1 - +2
Length of text entry (lot)
eob +3 - end
4 - lot
eob +3 - end
Text data

eob: end of bitmap, calculated by adding 9 to the lob value stored in the first two bytes

end: calculated end of text entry, adding lot to start of text data.


Data Entry Format: RRG signature

G & T
T
G
Description
0 - 1
0 - 1
0 - 1
object flag - Null if no object
2 - 5

2 - 5
Unique object ID
6 - x

6 - x
OLE object
x+1 - x+2

x+1 - x+2
DIB character width
x+3 - x+4

x+3 - x+4
DIB character height
x+5 - x+6

x+5 - x+6
X coordinate U-L
x+7 - x+8

x+7 - x+8
Y coordinate U-L
x+9 - x+10

x+9 - x+10
X coordinate L-R
x+11 - x+12

x+11 - x+12
Y coordinate L-R
x+13 - x+14

x+13 - x+14
embedded=0,linked=1, static=2
x+15 - x+16
2 - 3
x+15 - x+16
length of text entry
x+17 - y
4 - z
x+17 - y
text

x = 6 + size in bytes of OLE object.

y = x + 16 + text entry length

z = 3 + length of text entry



Interesting Notes:

  When I created a new CRD file using CARDFILE.EXE, the signature bytes were set to MGC.  After I placed two images in the file, the header signature changed from MGC to RRG. The header then pushed everything after the signature back four bytes.  The number of entries was moved from  offset 3 to offset  7.  At offset 3, a value of 0002 was placed there.  Apparently,  it increments   by one with every image added to the file.  After adding and  removing images, with three images left in it, the value was changed to 0009.   Each time a picture is added to the file, the value increases by one, but it doesn’t  decrease when a picture is removed.

  Shortly, this applet will be rewritten to be able to read both file formats,  and it will be put on line when completed.

- Cam Menard , cardwin Project Administrator