--------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: F5G00004 Date: 04/12/98 From: ADAM MAJER Time: 06:30pm \/To: BRYAN JOYCE (Read 3 times) Subj: BMP 1/4 BJ>Hi All , hope you are having a nice day BJ>Recently someone posted some code for loading 320x300x256 PCX to the BJ>screen. It was interesting stuff though I couldn't work out what was oing BJ>on. Surely the easiest to start with would be the BMP format as I thought BJ>that PCX's were slightly compressed? BJ>Have I got this right? If so how's a BMP loaded? Some BMP are also compressed but it's very easy to decompress them. I'll give you the structure of the BMP file then you'll be able to write something to display it. Bitmap-File Formats Windows bitmap files are stored in a device-independent bitmap (DIB) format that allows Windows to display the bitmap on any type of display device. The term "device independent" means that the bitmap specifies pixel color in a form independent of the method used by a display to represent color. The default filename extension of a Windows DIB file is .BMP. Bitmap-File Structures Each bitmap file contains a bitmap-file header, a bitmap-information header, a color table, and an array of bytes that defines the bitmap bits. The file has the following form: BITMAPFILEHEADER bmfh; BITMAPINFOHEADER bmih; RGBQUAD aColors[]; BYTE aBitmapBits[]; The bitmap-file header contains information about the type, size, and layout of a device-independent bitmap file. The header is defined as a BITMAPFILEHEADER structure. The bitmap-information header, defined as a BITMAPINFOHEADER structure, specifies the dimensions, compression type, and color format for the bitmap. The color table, defined as an array of RGBQUAD structures, contains as many elements as there are colors in the bitmap. The color table is not present for bitmaps with 24 color bits because each pixel is represented by 24-bit red-green-blue (RGB) values in the actual bitmap data area. The colors in the table should appear in order of importance. This helps a display driver render a bitmap on a device that cannot display as many colors as there are in the bitmap. If the DIB is in Windows version 3.0 or later format, the driver can use the biClrImportant member of the BITMAPINFOHEADER structure to determine which colors are important. The BITMAPINFO structure can be used to represent a combined bitmap-information header and color table. The bitmap bits, immediately following the color table, consist of an array of BYTE values representing consecutive rows, or "scan lines," of the bitmap. Each scan line consists of consecutive bytes representing the pixels in the scan line, in left-to-right order. The number of bytes representing a scan line depends on the color format and the width, in pixels, of the bitmap. If necessary, a scan line must be zero-padded to end on a 32-bit boundary. However, segment boundaries can appear anywhere in the bitmap. The scan lines in the bitmap are stored from bottom up. This means that the first byte in the array represents the pixels in the lower-left corner of the bitmap and the last byte represents the pixels in the upper-right corner. The biBitCount member of the BITMAPINFOHEADER structure determines the number of bits that define each pixel and the maximum number of colors in the bitmap. These members can have any of the following values: Value Meaning 1 Bitmap is monochrome and the color table contains two entries. Each bit in the bitmap array represents a pixel. If the bit is clear, the pixel is displayed with the color of the first entry in the color table. If the bit is set, the pixel has the color of the second entry in the table. 4 Bitmap has a maximum of 16 colors. Each pixel in the bitmap is represented by a 4-bit index into the color table. For example, if the first byte in the bitmap is 0x1F, the byte represents two pixels. The first pixel contains the color in the second table entry, and the second pixel contains the color in the sixteenth table entry. 8 Bitmap has a maximum of 256 colors. Each pixel in the bitmap is represented by a 1-byte index into the color table. For example, if the first byte in the bitmap is 0x1F, the first pixel has the color of the thirty-second table entry. 24 Bitmap has a maximum of 2^24 colors. The bmiColors (or bmciColors) member is NULL, and each 3-byte sequence in the bitmap array represents the relative intensities of red, green, and blue, respectively, for a pixel. The biClrUsed member of the BITMAPINFOHEADER structure specifies the number of color indexes in the color table actually used by the bitmap. If the biClrUsed member is set to zero, the bitmap uses the maximum number of colors corresponding to the value of the biBitCount member. An alternative form of bitmap file uses the BITMAPCOREINFO, BITMAPCOREHEADER, and RGBTRIPLE structures. Bitmap Compression Windows versions 3.0 and later support run-length encoded (RLE) formats for compressing bitmaps that use 4 bits per pixel and 8 bits per pixel. Compression reduces the disk and memory storage required for a bitmap. Compression of 8-Bits-per-Pixel Bitmaps When the biCompression member of the BITMAPINFOHEADER structure is set to BI_RLE8, the DIB is compressed using a run-length encoded format for a 256-color bitmap. This format uses two modes: encoded mode and absolute mode. Both modes can occur anywhere throughout a single bitmap. Encoded Mode A unit of information in encoded mode consists of two bytes. The first byte specifies the number of consecutive pixels to be drawn using the color index contained in the second byte. The first byte of the pair can be set to zero to indicate an escape that denotes the end of a line, the end of the bitmap, or a delta. The interpretation of the escape depends on the value of the second byte of the pair, which must be in the range 0x00 through 0x02. Following are the meanings of the escape values that can be used in the second byte: Second byte Meaning 0 End of line. 1 End of bitmap. 2 Delta. The two bytes following the escape contain unsigned values indicating the horizontal and vertical offsets of the next pixel from the current position. Absolute Mode Absolute mode is signaled by the first byte in the pair being set to zero and the second byte to a value between 0x03 and 0xFF. The second byte represents the number of bytes that follow, each of which contains the color index of a single pixel. Each run must be aligned on a word boundary. Following is an example of an 8-bit RLE bitmap (the two-digit hexadecimal values in the second column represent a color index for a single pixel): >>> Continued to next message * SLMR 2.1a * We all live in a yellow subroutine. --- FMail 0.92 * Origin: The Programmer's Oasis on FIDONET! (1:348/203) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: F5G00005 Date: 04/12/98 From: ADAM MAJER Time: 06:30pm \/To: BRYAN JOYCE (Read 3 times) Subj: BMP 2/4 >>> Continued from previous message Compressed data Expanded data 03 04 04 04 04 05 06 06 06 06 06 06 00 03 45 56 67 00 45 56 67 02 78 78 78 00 02 05 01 Move 5 right and 1 down 02 78 78 78 00 00 End of line 09 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 00 01 End of RLE bitmap Compression of 4-Bits-per-Pixel Bitmaps When the biCompression member of the BITMAPINFOHEADER structure is set to BI_RLE4, the DIB is compressed using a run-length encoded format for a 16-color bitmap. This format uses two modes: encoded mode and absolute mode. Encoded Mode A unit of information in encoded mode consists of two bytes. The first byte of the pair contains the number of pixels to be drawn using the color indexes in the second byte. The second byte contains two color indexes, one in its high-order nibble (that is, its low-order 4 bits) and one in its low-order nibble. The first pixel is drawn using the color specified by the high-order nibble, the second is drawn using the color in the low-order nibble, the third is drawn with the color in the high-order nibble, and so on, until all the pixels specified by the first byte have been drawn. The first byte of the pair can be set to zero to indicate an escape that denotes the end of a line, the end of the bitmap, or a delta. The interpretation of the escape depends on the value of the second byte of the pair. In encoded mode, the second byte has a value in the range 0x00 through 0x02. The meaning of these values is the same as for a DIB with 8 bits per pixel. Absolute Mode In absolute mode, the first byte contains zero, the second byte contains the number of color indexes that follow, and subsequent bytes contain color indexes in their high- and low-order nibbles, one color index for each pixel. Each run must be aligned on a word boundary. Following is an example of a 4-bit RLE bitmap (the one-digit hexadecimal values in the second column represent a color index for a single pixel): Compressed data Expanded data 03 04 0 4 0 05 06 0 6 0 6 0 00 06 45 56 67 00 4 5 5 6 6 7 04 78 7 8 7 8 00 02 05 01 Move 5 right and 1 down 04 78 7 8 7 8 00 00 End of line 09 1E 1 E 1 E 1 E 1 E 1 00 01 End of RLE bitmap Bitmap Example The following example is a text dump of a 16-color bitmap (4 bits per pixel): Win3DIBFile BitmapFileHeader Type 19778 Size 3118 Reserved1 0 Reserved2 0 OffsetBits 118 BitmapInfoHeader Size 40 Width 80 Height 75 Planes 1 BitCount 4 Compression 0 SizeImage 3000 XPelsPerMeter 0 YPelsPerMeter 0 ColorsUsed 16 ColorsImportant 16 Win3ColorTable Blue Green Red Unused [00000000] 84 252 84 0 [00000001] 252 252 84 0 [00000002] 84 84 252 0 [00000003] 252 84 252 0 [00000004] 84 252 252 0 [00000005] 252 252 252 0 [00000006] 0 0 0 0 [00000007] 168 0 0 0 [00000008] 0 168 0 0 [00000009] 168 168 0 0 [0000000A] 0 0 168 0 [0000000B] 168 0 168 0 [0000000C] 0 168 168 0 [0000000D] 168 168 168 0 [0000000E] 84 84 84 0 [0000000F] 252 84 84 0 Image . . Bitmap data . Hope that helps! PS The structures that are in the header are: BITMAPFILEHEADER (3.0) typedef struct tagBITMAPFILEHEADER { /* bmfh */ UINT bfType; DWORD bfSize; UINT bfReserved1; UINT bfReserved2; DWORD bfOffBits; } BITMAPFILEHEADER; The BITMAPFILEHEADER structure contains information about the type, size, and layout of a device-independent bitmap (DIB) file. Member Description bfType Specifies the type of file. This member must be BM. bfSize Specifies the size of the file, in bytes. bfReserved1 Reserved; must be set to zero. bfReserved2 Reserved; must be set to zero. bfOffBits Specifies the byte offset from the BITMAPFILEHEADER structure to the actual bitmap data in the file. Comments A BITMAPINFO or BITMAPCOREINFO structure immediately follows the BITMAPFILEHEADER structure in the DIB file. >>> Continued to next message * SLMR 2.1a * We all live in a yellow subroutine. --- FMail 0.92 * Origin: The Programmer's Oasis on FIDONET! (1:348/203) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: F5G00006 Date: 04/12/98 From: ADAM MAJER Time: 06:30pm \/To: BRYAN JOYCE (Read 3 times) Subj: BMP 3/4 >>> Continued from previous message BITMAPINFOHEADER (3.0) typedef struct tagBITMAPINFOHEADER { /* bmih */ DWORD biSize; LONG biWidth; LONG biHeight; WORD biPlanes; WORD biBitCount; DWORD biCompression; DWORD biSizeImage; LONG biXPelsPerMeter; LONG biYPelsPerMeter; DWORD biClrUsed; DWORD biClrImportant; } BITMAPINFOHEADER; The BITMAPINFOHEADER structure contains information about the dimensions and color format of a Windows 3.0 or later device-independent bitmap (DIB). Member Description biSize Specifies the number of bytes required by the BITMAPINFOHEADER structure. biWidth Specifies the width of the bitmap, in pixels. biHeight Specifies the height of the bitmap, in pixels. biPlanes Specifies the number of planes for the target device. This member must be set to 1. biBitCount Specifies the number of bits per pixel. This value must be 1, 4, 8, or 24. biCompression Specifies the type of compression for a compressed bitmap. It can be one of the following values: Value Meaning BI_RGB Specifies that the bitmap is not compressed. BI_RLE8 Specifies a run-length encoded format for bitmaps with 8 bits per pixel. The compression format is a 2-byte format consisting of a count byte followed by a byte containing a color index. For more information, see the following Comments section. BI_RLE4 Specifies a run-length encoded format for bitmaps with 4 bits per pixel. The compression format is a 2-byte format consisting of a count byte followed by two word-length color indexes. For more information, see the following Comments section. biSizeImage Specifies the size, in bytes, of the image. It is valid to set this member to zero if the bitmap is in the BI_RGB format. biXPelsPerMeter Specifies the horizontal resolution, in pixels per meter, of the target device for the bitmap. An application can use this value to select a bitmap from a resource group that best matches the characteristics of the current device. biYPelsPerMeter Specifies the vertical resolution, in pixels per meter, of the target device for the bitmap. biClrUsed Specifies the number of color indexes in the color table actually used by the bitmap. If this value is zero, the bitmap uses the maximum number of colors corresponding to the value of the biBitCount member. For more information on the maximum sizes of the color table, see the description of the BITMAPINFO structure earlier in this topic. If the biClrUsed member is nonzero, it specifies the actual number of colors that the graphics engine or device driver will access if the biBitCount member is less than 24. If biBitCount is set to 24, biClrUsed specifies the size of the reference color table used to optimize performance of Windows color palettes. If the bitmap is a packed bitmap (that is, a bitmap in which the bitmap array immediately follows the BITMAPINFO header and which is referenced by a single pointer), the biClrUsed member must be set to zero or to the actual size of the color table. biClrImportant Specifies the number of color indexes that are considered important for displaying the bitmap. If this value is zero, all colors are important. Comments The BITMAPINFO structure combines the BITMAPINFOHEADER structure and a color table to provide a complete definition of the dimensions and colors of a Windows 3.0 or later DIB. For more information about specifying a Windows 3.0 DIB, see the description of the BITMAPINFO structure. An application should use the information stored in the biSize member to locate the color table in a BITMAPINFO structure as follows: pColor = ((LPSTR) pBitmapInfo + (WORD) (pBitmapInfo->bmiHeader.biSize)) Windows supports formats for compressing bitmaps that define their colors with 8 bits per pixel and with 4 bits per pixel. Compression reduces the disk and memory storage required for the bitmap. The following paragraphs describe these formats. BI_RLE8 When the biCompression member is set to BI_RLE8, the bitmap is compressed using a run-length encoding format for an 8-bit bitmap. This format may be compressed in either of two modes: encoded and absolute. Both modes can occur anywhere throughout a single bitmap. Encoded mode consists of two bytes: the first byte specifies the number of consecutive pixels to be drawn using the color index contained in the second byte. In addition, the first byte of the pair can be set to zero to indicate an escape that denotes an end of line, end of bitmap, or a delta. The interpretation of the escape depends on the value of the second byte of the pair. The following list shows the meaning of the second byte: Value Meaning 0 End of line. 1 End of bitmap. 2 Delta. The two bytes following the escape contain unsigned values indicating the horizontal and vertical offset of the next pixel from the current position. Absolute mode is signaled by the first byte set to zero and the second byte set to a value between 0x03 and 0xFF. In absolute mode, the second byte represents the number of bytes that follow, each of which contains the color index of a single pixel. When the second byte is set to 2 or less, the escape has the same meaning as in encoded mode. In absolute mode, each run must be aligned on a word boundary. The following example shows the hexadecimal values of an 8-bit compressed bitmap: >>> Continued to next message * SLMR 2.1a * We all live in a yellow subroutine. --- FMail 0.92 * Origin: The Programmer's Oasis on FIDONET! (1:348/203) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: F5G00007 Date: 04/12/98 From: ADAM MAJER Time: 06:30pm \/To: BRYAN JOYCE (Read 3 times) Subj: BMP 4/4 >>> Continued from previous message 03 04 05 06 00 03 45 56 67 00 02 78 00 02 05 01 02 78 00 00 09 1E 00 01 This bitmap would expand as follows (two-digit values represent a color index for a single pixel): 04 04 04 06 06 06 06 06 45 56 67 78 78 move current position 5 right and 1 down 78 78 end of line 1E 1E 1E 1E 1E 1E 1E 1E 1E end of RLE bitmap BI_RLE4 When the biCompression member is set to BI_RLE4, the bitmap is compressed using a run-length encoding (RLE) format for a 4-bit bitmap, which also uses encoded and absolute modes. In encoded mode, the first byte of the pair contains the number of pixels to be drawn using the color indexes in the second byte. The second byte contains two color indexes, one in its high-order nibble (that is, its low-order four bits) and one in its low-order nibble. The first of the pixels is drawn using the color specified by the high-order nibble, the second is drawn using the color in the low-order nibble, the third is drawn with the color in the high-order nibble, and so on, until all the pixels specified by the first byte have been drawn. In absolute mode, the first byte contains zero, the second byte contains the number of color indexes that follow, and subsequent bytes contain color indexes in their high- and low-order nibbles, one color index for each pixel. In absolute mode, each run must be aligned on a word boundary. The end-of-line, end-of-bitmap, and delta escapes also apply to BI_RLE4. The following example shows the hexadecimal values of a 4-bit compressed bitmap: 03 04 05 06 00 06 45 56 67 00 04 78 00 02 05 01 04 78 00 00 09 1E 00 01 This bitmap would expand as follows (single-digit values represent a color index for a single pixel): 0 4 0 0 6 0 6 0 4 5 5 6 6 7 7 8 7 8 move current position 5 right and 1 down 7 8 7 8 end of line 1 E 1 E 1 E 1 E 1 end of RLE bitmap * SLMR 2.1a * We all live in a yellow subroutine. --- FMail 0.92 * Origin: The Programmer's Oasis on FIDONET! (1:348/203) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: F5G00008 Date: 04/12/98 From: DARIN MCBRIDE Time: 08:51pm \/To: BLAKE GAFFNEY (Read 3 times) Subj: Local static BG> You know that in good OOP you should avoid global BG> data/functions. I try to do that as often as possible, BG> but sometimes I use static data or functions within a class. BG> What I want to know is, is this as evil as using global data/functions? You'll probably get widely varying opinions on this, however, no matter what, I think that you should keep in mind a few things: a) they're opinions. b) if you're getting paid, you're getting paid to make it work. When evaluating an OO design (not that I've had that much experience), I generally ask simple questions. 1. Does it make sense? 2. Does the language chosen (C++, Java, Smalltalk, Ada, whatever) allow the construct? In the case of functions, I ask, on a case by case basis, more questions: 3. Does this function need to be overridden in derived classes (virtual)? 4. If no to #3, does this function require access to read the current state or to change the current state (which implies access to read) of the object, or is it merely a helper (private static) or does it just make sense (#1) to be with this type (public static)? Examples in #4... In one object, I needed to make basically the same calculation to two different variables. I wrote a private static function that took a reference to the variable to be changed plus other parameters. It could have been non-static, but since it is private, there's little difference. I assume that there _could_ be some optimizations with static, so I allow the compiler to know information that could help it do these optimizations. (There's also one fewer parameter being passed in static functions - 'this' isn't passed.) Another object I wanted to guarantee that all allocations were done on the heap, so I wrote a Construct function that returned a pointer to the object. Rather than polluting the namespace with this function, I made it static. This also gave it the added bonus of being able to access the private constructor: class foo { private: foo(...); public: static foo* Construct(...) { return new foo(...); } // ... }; One reason for this could be to put all created foo's in a special heap to keep track of how many foos are in use. Or into shared memory (special new here), or ... a miriad of reasons. And the last example, very similar results to the last, is to put a function that really belongs in a library, but doesn't need the 'this' pointer. I know I've used this idea before, but I can't recall the circumstances offhand. The idea being that you've got a class that does a lot of stuff, and this function fits in well with that class, so it goes together, but isn't necessarily a function 'on' an object of that type. Oh, here's an example: class File { //... bool delete(); static bool delete(char* filename); }; You don't need to instantiate a File object to delete the file here. Two choices here - either the static version can instantiate the File object for you and call delete, or the non-static can call the static, whichever is easiest. However this isn't always the case - you may not have a non-static version of a static function, I just can't remember the circumstance, as I said. Now, another question arose with static data. Public static data is the same thing as a standard global variable. Private static data is basically, IMO, the same as a static variable in a function. I generally will only put static variables (privately, of course) in a class when one or more of its inline functions use it, otherwise it will be a "global" (static, non-exposed) variable in the implementation file of that class. i.e.: class foo { static int num_instantiated; foo() { ++num_instantiated; } ~foo() { --num_instantiated; } }; In foo.cc: int foo::num_instantiated; However, if nothing inline uses it, I'll make it static to foo.cc rather than class foo instead. Hope this gives you one way of looking at it... --- * Origin: Tanktalus' Tower BBS (1:250/102) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: F5G00009 Date: 04/12/98 From: PAUL ROBINSON Time: 09:02am \/To: DAVID NOON (Read 3 times) Subj: Re: Compiler DN> In this echo? ROFL! DN> DN> The adjective "simple" does not associate very readily with the noun DN> "C++ compiler", I'm afraid. DN> DN> Since you are a beginner, I suggest you start by obtaining the cheap DN> compiler you can get that has a good reputation for robustness. The DN> compilers fill that role admirably, especially as they are free for DN> download. DN> DN> Which platform do you use? DOS/Windows? OS/2? NT? UNIX? Linux? DN> Is use a DOS platform.... i know theres heaps of free ones, its just i cant seem to find ANY if you have a small freeware/shareware compiler would you mind sending it to me? cya --- TriToss (tm) 1.03 - (Unregistered) * Origin: Hell BBS - Albion Park NSW Australia * (3:624/160) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: F5G00010 Date: 04/10/98 From: TIM HUTZLER Time: 09:00pm \/To: MIKE LUTHER (Read 3 times) Subj: Re: Need More Memory ML>Tim... ??>TH: MH>Trying to read in nodelist.* ML>He'll have to answer for himself, but likely as in FidoNet - ML>NodeList... You know as in Zone, Net, Node and all that data. Oh,... And, *I* thought he was trying to deal with them little bitty things, ie. nodes. BTW, your post was strange, but interesting. [grin] ___ Blue Wave/QWK v2.12 --- Maximus/2 3.01 * Origin: Madman BBS * Chico, California * 530-893-8079 * (1:119/88) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: F5G00011 Date: 04/10/98 From: TIM HUTZLER Time: 09:05pm \/To: ANTHONY TIBBS (Read 3 times) Subj: Re: Need More Memory TH>Design, design, DESIGN, my friend. Always plan your attack, and TH>you'll never get caught with your pointers down. [grin] AT>Let's see you sit down and plan a Fidonet front end mailer. You'll AT>soon see that "planning" such a beast (especially when you AT>consider how useless FTS documentation is), would require a very AT>large design team. Or, a very sophisticated thinker... [grin] TH>Just what are you try'n to do? MH>Trying to read in nodelist.* TH>??? TH>How do you *read-in* a node list? Nodes are the stuff heaps are made TH>of. Are you reading a file and creating a linked list? This file TH>"nodelist"... what's in it? AT>You obviously aren't a sysop. :-) ] Sysop, SYSOP, S-Y-S-O-P!!! We don't need no stinkin' sysops!!!! [grin] AT>The "nodelist" is a list (TEXT file) of systems in Fidonet, AT>or any other Fidonet-style network. Okay. But, why would he want to read the who thing? Setting up some indexes would be simpler and less overhead. ___ Blue Wave/QWK v2.12 --- Maximus/2 3.01 * Origin: Madman BBS * Chico, California * 530-893-8079 * (1:119/88) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: F5G00012 Date: 04/13/98 From: MIKE LUTHER Time: 05:58pm \/To: TIM HUTZLER (Read 3 times) Subj: Re: Need More Memory Yeah Tim... > TH: Oh,... > TH: > TH: And, *I* thought he was trying to deal with them little bitty > TH: things, > TH: ie. nodes. > TH: > TH: BTW, your post was strange, but interesting. [grin] You can see why I'm having a fairly hard time adapting to C++. It may have class, but once you get strung out, Basic-ly, you're spoiled. Show me a programmer that says they aren't afflicted by compulsive-addictive codified behavior... BTW, there HAS to be a twelve step program... in some language.. chuckle. // However, I have decided it isn't in C++..... >@@< Functionally, it'd take at least 1200 source lines! -----ooo^^ooo---- Mike @ 117/3001 --- Opus-CBCS 1.73a * Origin: Ziplog Public Port (1:117/3001.0) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: F5G00013 Date: 04/13/98 From: MIKE LUTHER Time: 06:14pm \/To: TIM HUTZLER (Read 3 times) Subj: Re: Need More Memory Sorry I posted the reply to your next before I posted this one, but,.. > TH: Okay. But, why would he want to read the who thing? Setting up > TH: some indexes would be simpler and less overhead. Maybe even disk access isn't fast enough assumimg cache sizes are even respectably limited! Consider the problem of having a ten position Field Day contest operation where-in all ten positions have to have access to not only the NodeList, but some 1,750,000 records in yet a bigger list. The object is to instantly, in less than one second, recover all the data associated with two records, the one you are attempting to contact in the contest, and the closest FidoNet SysOp, geographicly, to that place. The difference between you getting the station you decide to call and someone else is often measured in quarters of a second in real-time. Thus ALL the information, as to previous contacts, needed contacts, related sites for FidoNet drop-off of the emergency 'message' that is produced by the contact; all must be done in real-time. That means sub-second response hour after hour... Worse, it has to be done for up to as many as at 23 different workstations on the LAN, perhaps all in the same exact second! Until you've done this job and tried it all, you really don't know what is really needed in network response times, either, friend.. All together guys and gals (yes gals can be REAL good at this!), hit the key at the same time and see who misses that new one! NOBODY better have to wait! Top operations people can produce actual contact records of over 120-150 complete transactions per hour during peak periods of 30-90 minutes straight. More than one such 'run' can be going on at half a dozen positions in the network at once! I can do that myself on CW at the same time I'm running the program - with it doing all the comm port I/O to control the station equipment as well.... sending CW part by hand with a paddle keyer, part on the keyboard from auto-sent text, talk to someone over my shoulder and spurt type log data at the same time in-between it all, as can MANY good operators who like contests! Plus listen to at least two or three telegraph threads in the background laying up the 'mental que' as to who comes next! You are correct about the index part, but even the index(s) required are way over what one usually thinks about committing to memory. Incidentally, add to that, an administrative output overlay display for the whole site in graphics. In real-time, the 'war' board world map displays each contact, the vectors from the site - world-wide - to the remote contact, and also to the nearest FidoNet SysOp.. plus the totals for the crew that update each time every position makes a new entry! The approach was procedural in Basic, however Basic DOES have similar code to the class approach in C++, if you approach Basic in what I think is a correct manner. Most folks don't, I think. More important, it is obvious to me, even as a woefully immature and fledgling C++ aspirant, that the OO aspects of C++ are going to be the only way to meld the horribly complex work that was done before, into a graphically oriented adaptation of it, regardless of how much memory... groan ... it may take. The real purpose of this is even more subtle. The tools, required here, are exactly the tools needed to manage a full disaster relief communications operation, when merged into full double-entry inventory accounting and a complete double entry financial statement for the operation at the same time, which we can do. Ask any Army Reserve guy what the problem is in disaster relief. What of the water, fuel, money, suplies and then where can you route and handle the messages and accounting so you can go back later and recover the shrapnel or the bodies... From experience, one terminal position can handle, at a maximum, only about 1200 refugees a DAY in such a system, thus a 23 unit C++ network would be reauired to process some 30,000 victims from a hurricane down the road, if YOUR town had to take them in over the course of just one day! After EVERY transaction, we can post a completely balanced income statement for the entire operation as well as a full double entry balance sheet, at least for the incremental on-line work, minus, of course, certain monthly closing details... grin... Each of these sub-arena's is, in fact, a perfect venue for class, as set forth in C++, brought forward into OO from structured Basic work already done and tested for years in clinic and hospital records management venues. It's just that the whole thing is HUGE as to the work to convert it.. and, maybe only worth it as relative to the next step - JAVA - from which the C++ experience may be the only way to go... C++, as I see it, has a LOT to face off to in respect to Client-Server, SQL and 24X7 data mining work. It's nice to say C++, but most of the work hits a bump in the code where the 4GL OO RAD tool says... User code? yeah... User code! On thread.. on topic; what a delightful memorable experience in C++.. :) Mike @ 117/3001 --- Opus-CBCS 1.73a * Origin: Ziplog Public Port (1:117/3001.0)