Reads ancient .crd files (created with Microsoft cardfile.exe (part of Windows up to Win-98 or so)) and converts the information to a text format, written to new files for further usage.
Output formats so far:
- simple text list (that's the default)
- WikidPad wiki page (it's a text format too, see http://wikidpad.sourceforge.net/)
All .crd files in the current directory are read and converted. If a target file is already existing it will not be overwritten unless "-f" is given.
A config file (cardreader.ini) can be created via option --config. It contains the found .crd files with the default or given target format (options -w and -l).
While reading the .crd files only the MGC format is supported yet. That means: Text only, no graphics or other embedded binary data!
Required software and usage - details for beginners, on Windows. Hi Oliver! ;-)
Install Python - Version 3e.g. the most recent one yet (Oct 2015):Python 3.5.0 - 2015-09-13 - Windows x86 executable installer (python-3.5.0.exe)
Save script cardreader.py somewhere on your disk, e.g. in C:\tools
Change to a directory with .crd files
or (if there might be Python 2 installed as well):
py -3 C:\tools\cardreader.py
-h, --help show this help message and exit -w, --wiki use WikidPad as output format -l LINE, --line LINE use line number # as title -f, --force overwrite target file(s) if already existing --config create config file in current directory
Based on information found on the following websites (partly cited):
by Cam Menard
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
https://support.microsoft.com/en-us/kb/99340 - Windows 3.1 Card File Format
SUMMARY This article documents the file format used by Microsoft Windows version 3.1 Cardfile. Please note that the Cardfile file format (.CRD) may change in future versions. All numbers in this document, including those in the descriptive text, should be interpreted as hexadecimal numerals. All data pointers and count bytes in the file are unsigned binary/hexadecimal integers in least-to-most significant format. All text in the file is saved in low ASCII format. In the text section of a card's data, <CR> is always followed by <LF>. MORE INFORMATION Card File Changes in NT 3.51 The only difference in the unicode format is the signiture (DKO) and the characters, now 16-bits wide. The Signature can now be MGC. The Cardfile file format is as follows: Byte # Description ------------------- 0 - 2 Signature bytes--always "RRG" (52 52 47). 3 - 6 Last object's ID. 7 - 8 Number of cards in file. Beyond the first 9 bytes are the index lines--the information about the top line of each card. The first index entry begins at byte 9 in the file, and successive entries begin 34 bytes after the beginning of the last index entry (the second entry at byte 3D, the third entry at byte 71, and so forth). The format for each index line entry is as follows: Byte # Description ------------------- 0 - 5 Null bytes, reserved for future use (should all be 00). 6 - 9 Absolute position of card data in file. A Flag byte (00). B - 32 Index line text. 33 Null byte; indicates end of index entry. After the last index entry, each card's data is stored. Card data is in one of four general formats: graphic and text, text only, graphic only, and blank. Blank cards consist of 4 null bytes; the other card formats are below: Graphic Text Graphic & Text Only Only ------------------------------------------------------------------- 0 - 1 0 - 1# 0 - 1 Flag Determining whether or not the card contains an object. 2 - 5 * 2 - 5 Unique object ID. 6 - x * 6 - x The OLE object. x+1 - x+2 * x+1 - x+2 Character width, used for device independence. x+3 - x+4 * x+3 - x+4 Character height. x+5 - x+C * x+5 - x+C RECT: left - X-coordinate of the upper-left corner. top - Y-coordinate of the upper-left corner. right - X-coordinate of the lower-right corner. bottom- Y-coordinate of the lower-right corner. x+D - x+E * x+D - x+E Object type embedded=0, linked=1, or static=2 (values may change in the future). x+F - x+10 2 - 3 x+F - x+10# Length of text entry. x+11 - y 4 - z * Text. NOTE: x = 6 + size in bytes of the entire OLE object (the entire size of the object is not stored anywhere within the .CRD file). See below for more information on the OLE object size. y = x + 10 + length of text entry. z = 3 + length of text entry. # - These bytes are null if no object/text. * - These bytes do not exist if no object/text. The first byte of any card's data entry is pointed to by bytes 6-9 in the index entry. Note that no null byte is used to indicate the end of the card's data entry; the next card's data entry immediately follows the last byte of the previous entry, which is null only if the previous card has no text (null length of text entry). OLE Object ...