Ready.
GFS History
GFS goes on. It is ready for even further eloquence, now in FIX, instead of C. This page documents the historical existence of GFS - including links to its source code. To read more, and to discuss about GFS, please visit The GFS home.
Through these pages (gfs.hst.htm, gfs.c.htm, gfs.cpp.htm), I publish the GFS document(s) and source code, for the record.. The appendices contain the material:
I have plans for building on GFS, too, but those are not on this page. You may follow the related developments, through The GFS home.
A Few Historical Bits, about GFS
1990: The foreword ...
I had designed, and implemented GFS, as a computer-programming final-project, in 1990. A few sections (e.g: foreword, conclusion, references) do not exist in the demo-time document, but in proj280.txt. Those sections were written, (shortly) later, to comply, when submitting the bound-document.
A TypeA-personality, and the "I" versus "we"
The strange thing about those (newer) sections, is that I use the "I" instead of "we" language, although GFS was submitted as a two-persons project. Here, the document shows a two-kind "we"/"I" words. (Or, did we correct this, before publishing/submitting?) In fact, the copyight notice at the first line of the source code, GFS.c, was only for myself, too, but this was all right.
The truth was my insistence that we should code in C. If we had programmed in Pascal, after system-analysis of a real-estate agency (whether imaginary, or real), this could be a two-persons project. In fact, I keep in my folders a few pages that my project partner had brought as the print-outs of data-entry screens for various cases.
In other sorts of project-management, you may even refer to this as, competing project teams, pursuing different paths, but submitting/selling a single project. That was not the intention in our case, but practically, the result.
I was a C thinker, so I was supposed to program in C. (Descartes had expressed it a bit differently.:-)= ) In other words, to exercise my expressive powers, I wanted C, and we settled for it. But by the end of the term, we were not in synchrony, yet. He was yet to become proficient. So, I designed, and implemented everything in the program source code, myself - including the copyright notice.
1990: Very polite
This was all very polite (and friendly). In fact, the only argument we had was after all this, because of "overpoliteness." When he told me about a few lines he added, to the submitted document (after proj280.txt), before bound, to "acknowledge" the help of the instructor, I was surprised. What help?!?
- Was there any help with the not-found bitmap file formats?
This was the "major issue" and at the end, we had to make do with what Turbo C already provided. No external bitmap files. i.e: Both the designated project advisor, and I, separately, attempted to find the PCX, or some other popular bitmap file format, but we both failed. Therefore, at best, it should be termed an "attempt," or a "promise" for help, not really a rendered help.
- Should we thank for the lowest-grade among all projects?
A BB (80 to 84, out of 100) is not such a low grade, but GFS was technically superior - except the awful bitmaps. Even from the same advisor, a Hypercard-based project got the same, or probably better grade. As a result, as in all disagreements, a statement/evaluation you make/post (as with a grade), declares that you do not find any real value with the project. But in fact, if there is value there, then it tells (adversely) about the evaluator, too.
- Should we thank for his awful suggestion that "ideas on paper would arrive nowhere?"
That denies specification. He was wrong, with me, any way. I cannot tell whether he was telling out of his own projects (although he had a Ph.D. in computer engineering), or out of his experience with other students, who may dump whatever first comes to their mind. But in my case, as a thorough-thinker, as a high-techie, I thought about feasibility, too.
As a result, I guess, we were not pleased of each other's styles/preferences. A friend had told me that, that lecturer/advisor programmed cartoons in assembly language, and this would fit me, too. But I guess, we diverge thereafter. Some people have to work "on screen." But I tend to favor concepts, and paper, even for interface-oriented software, and I had been successful, too. i.e.: GFS was saved by not minding his suggestions (but I cannot tell whether the grade was hit adversely).
Then, my project partner told me that, the advisor told us how to revise the demo-time-documentation, before publishing, and this could count as a help. I responded that, the grades had been assigned already, by then, with whatever we had presented at demo-time. Even my formatting the source-code page-by-page was extra. (Not such an extra, because a tiny program in C, was doing it, and now, that may help when I refer to pages. I have some of the pages in print, from those days, and I may find the others, too. Better than tracking line-by-line.)
1990s: Object-oriented/based, with the GFS flavor
The GFS documentation, already referred to the similarities (polymorphism). At first, I pointed out the similarity. Next, I reflected that the GFS version, is more favorable than the DDJ example. In the 1990s, I did not build on GFS, but told people about it, and suggested it as an alternative.
2001/2002: DOVE vs. SOAP? :-))
This was a joke, but I envisioned a few ideas, too. Here, the "DOVE" stands for "Distributed Objects with Versatile Extensibility." The problem was, I guess, that could infringe a trademark, and/or a motto, because y'see, DOVE is not SOAP, although they would be relevant/rivals.
The DOVE idea/joke refreshed the ideas about GFS object'ness - along with
dynamically-allocated tables that I had suggested in the GFS documentation. I keep this idea.
If anything develops, The GFS home is there to point at it.
Appendix A: The gfs document (for demo, in 1990)
The document that I republish in this section (Appendix A), is the demo-time documentation, that I restored to the state of those printed pages I keep, from demo-time, in June 1990. The next section, Appendix B: Proj280.txt presents a file, dated June 18, 1990, that must be the final version, when bound, and submitted. But it is this demo-time documentation that contributed to a grade; the other document was later than that. And I like this better.
The document, here, is republished exactly. I do not correct even the grammatical errors, on this page. This is why this page exists. I HTML'ized it, though. This is not any difference, in content. A table is, again, a table. The text formatting lacks tabs, but now has colors, and bolds/italics/etc.
Page 0
Abstract
This's a GRAPHICAL estate query SYSTEM. The estate subject is not of central (great) importance to the project; it could be a school, or inventory query system as well. It makes a foundation for porting text based applications to non-OS-supported flat graphics. We have used many nice features of the C language, like function-type parameters, no-type parameters, enumerations, etc. We hope it will be a project to be built on, and used in many different applications. For example, our FormsManager is completely application independent, and by changing the parameters, or reallocating the array, one may even use it to emulate dynamically the dBASE's get/read operations.
Table of CONTENTS
| PART I: | Text screen emulation in graphics mode |
| PART II: | Forms Manager |
| PART III: | Menu Manager |
| PART IV: | Threaded binary tree indexing & [optional] Query ( Select ) mode & related stuff |
| Appendix A: | Compiler specifics & Environment limitations |
| Appendix B: | Hungarian notation |
Page 1
PART I: Text screen emulation in graphics mode
We have defined the screens as 25 x 80. This's the usual size of a text mode screen ( currently). Emulation is managed by high level functions, and is portable through the range of cards & modes supported ( Hercules, CGA, EGA, VGA ). There're functions for formatted text output ( like printf ), box drawing, reversing line attributes, popping menus, etc.
If new routines would like to be added, there're some global variables to ease the process. Here're the list of those emulation related global constants & variables :
| Variable Name | What it means... |
|---|---|
| GRCOLAMOUNT | maximum col (constant) |
| GRROWAMOUNT | maximum row (constant) |
| giMax_xmaximum | pixel width-1 of the screen |
| giMax_ymaximum | pixel heighth - 1 of the screen |
| gcCol_pixels | pixel width of a character box |
| gcRow_pixels | pixel heighth of a character box |
| *gcXor_buffer | 80 column wide white screen ( getimage()d ) |
Page 2
PART II: Forms Manager
We have built a something-oriented FormsManager. It requires each form to point to its associated headers, optional paint function, and field parameters.
Each field parameter consists of, in turn,
{
starting column,
starting row,
field's width ( length as a string ),
data type
}
The 'data type' parameter is an enumerated constant which is used to refer to the data type manipulation functions enumeration. The data type manipulation functions are...
| name | job |
|---|---|
| From | converts the data from internal representation to
string type |
| Display | displays the 'string'ized data in a form preferred
by the data type. e.g: numeric types should better
be put flush-right, while original strings are
flush-left, and 'emlak tipi' types ( a type that
we have designed ) is better to show a full word,
say 'Villa', instead of just 'V'. |
| Validate | checks if the string passed to this function
conforms to the standards of the data type. |
| To | converts a string to the internal representation
of the data type. |
Recently there was a pretty surprise ( which we met long after the form manager was in charge of its department ); In May '90 issue of Doctor Dobbs' Journal, there's an OBJECT ORIENTED PROGRAMMING EXAMPLE ( not in source code ) demonstrating POLYMORPHISM, and looks very much like FormsManager. In fact the fact that one can already design object oriented in C has been already with us for some time, but we were still surprised to discover that, this fact has already found roots in our deeper brains.
To define new data types is easy. Just write the manipulation routines for the new type. Then append the enumerations ( bind those functions to the data type, in other words), and you are done ! From then on, you can start having FormsManager take charge of the fields of that type, too.
And finally, why we didn't use some inherently dynamic structure (such as linked-lists) to keep the fields parameters, headers, etc. ? Yes, this would make it more flexible, and by no means is hard to implement from the manager's point of view. But then, one would lose the ability to initialize the parameters as static arrays. This's too much an inconvenience, to just be fit to some extreme applications ( like dBASE's get/read ). And also, if you so badly need such a mechanism, there are two ways : either modify the source code for the FormsManager, or use dynamic allocation ( and reallocation ) routines of C (, and optionally, such a scheme as master indexes - indexes to the sorted order of the parameters ).
Page 3
PART III: The Menu Manager
The MenuManager, in fact, was an older idea than the FormManager. It has the same philosophy of FormManager, and is as much like the FormManager as you may decide a form & menu looks like eachother.
It has been successfully used in several text-based projects, but in graphics-mode most of the small ( though nice ) features had to be excluded, either for speed and/or memory space considerations, or for the graphics interface we are using ( BGI ) does not support it.
Still, IT DOES THE JOB. We use it at two places; one for the query operations menu, and the other for options menu.
Page 4
PART IV: Threaded binary tree indexing
& [optional] Query ( Select ) mode
& related stuff
The indexing mechanism used in this program is a THREADED BINARY TREE.
The next(), previous(), include() ( --> add() ), exclude() ( --> delete() ), update() functions are used to manipulate the data in file ( and, of course, the indexes ). Those functions have a dual nature; they both operate in the 'Show All' mode, and the 'Select' (the optional query) mode.
In 'Select' mode, those functions also manipulate the active list ( the list of the records that conform to the current selection criteria ).
Frequently used query criteria can be saved in a query file. When a query is loaded, or has been just designed, the 'Select' mode is automatically turned on, and the active list is formed.
Here is a diagram that shows some sample data and the related index, and active list formations ( those 'kod no's with a check are those which conform to the current criteria ):
Page 5
Appendix A: Compiler specifics & environment limitations
Though we reserve almost half the screen for the picture to be displayed, BGI ( Borland Graphics Interface) 's putimage is short of accomplishing the task in most modes. This ( we think ) is due to the segmented architecture of the 80x86; enough memory to load a screen wide, say VGA, image exceeds the size of a segment by far, and even the half size mostly won't be possible to allocate. But there are also problems in the huge model malloc(). The compiler promises that one would be able to allocate memory of more than 64K in huge model, thanks to the normalization of the pointers. But, though we have switched to huge model, we were still unable to allocate the needed size ( even e.g. 45K ).
We have also tried to manipulate PCX files for a long time. It's better than BGI-images in many ways. First, it's designed to be saved in a file ground up, second it's widely used and to find sample data would be very easy, and third it is of interest to many programmers, and we thought we had got an article that describes it enough (that enough should be dropped, now ), and the last for here, as PCX is file-based, and is so widely used, the inter-programm portability is almost guaranteed, while no one knows if Borland will change its image format at any time.
As an aside, not all formats used by BGI are so ambiguous. For example the graphic drivers ( *.bgi ), and font files ( *.chr ) have their standard interfaces (version numbers, size, etc., etc. ) explained.
If someone ever tries to build on this project, we suggest him/her to ( try to ) use PCX, or much better, TIFF (because it's portable through several ENVIRONMENTS - PC to Mac to nExt cube ).
We have not forgot the optimizer, and have tried to do best of us to enable it to do its job best. We have arranged repeated codes ( in functions ) in a way that optimizer can best see & optimize it. In fact, that much brain has been among our assets, too, but letting the optimizer do the job, instead of our using 'goto's makes the source more readable ( though no easier to prepare ). Of course, our knowledge of the behavior of the optimizer is fully gained as we were examining the object code, and debugging the program.
Page 6
Appendix B: Hungarian notation
For those who would like to examine the code ( source ), here we explain the meaning of those prefixes found pre-almost-every-variable.
It's called 'Hungarian notation'. It's devised by Charles Simonyi - Manager of Advanced Languages at Microsoft. The notation requires a lower case prefix that describes the data type, followed by a variable name whose first letter is capitalized. Some prefix examples are:
b - boolean ( variable expects 0 or 1, usually an int ) c - character dw - double word ( type not defined, usually unsigned long ) f - flag ( used for bit-field variables ) i - int variable l - long lp - long pointer n - short int p - pointer variable s - string sz - '\x0' terminated string u - unsigned w - word ( type not defined, usually unsigned )
For example, iHeapStatus ( or iHeap_status as we would use it ) is an integer variable whose name is HeapStatus ( or Heap_status ). This convention is used widely by MS-Windows and OS/2 programmers.
Some programmers have extended the prefix notation and have a prefix-to-the-prefix, representing the class of the variable, using these conventions:
a - automatic and parameter passed ( we just used for auto ) g - global variable ( as our gupENdx ) m - semi-global, static but visible throughout the module r - register variable s - static but visible in a block only
In our program, we did not use 'a' prefixes for parameters, because we take it as the default. Globals, and autos are shown.
For further examples, either see the program, or the article in C Users' Journal October '89 (p.p.105+).
Appendix B: The Proj280.txt (June 18, 1990)
The document/file that I republish here, is: PROJ280.TXT (June 18,1990, 17:57, with 23161 bytes). The original document that must have accompanied the bound/published GFS - as my project partner bound, and submitted the final document to the department.
cover (trimmed)
|
GRAPHICS FILE SYSTEM v1.0 ISTANBUL JUNE, '90 ( 19' ) |
The names of the jury members, and the surname of my project partner is not here. Upon permission/request, I may include any of these, too.
The content pages
The document, here, is republished exactly - except the cover page, as I explained. I do not correct even the grammatical errors, on this page. This is why this page exists. I HTML'ized it, though. This is not any difference, in content. A table is, again, a table. The text formatting lacks tabs, but now has colors, and bolds/italics/etc.
Foreword
This's June 18, 1990. Dear Stranger, the project you're holding is ( was ) this is a nice C program, that demonstrates some of the C language features, and some of what I have learned so far about graphics, graphics formats, indexing, assembly programming ( though no single line of assembly code is included here, when you go through the source code, I hope you'll feel the way C is used here - as a structured assembly language ), etc.
I hope you enjoy it reading it as much as I had enjoyed as writing, and benefit as much...
Abstract
This's a GRAPHICAL estate query SYSTEM. The estate subject is not of great importance to the project; it could be a school, or inventory query system as well.
It makes a foundation for porting text based applications to non-OS-supported flat graphics. Many nice features of the C language have been used, like function-type parameters, no-type parameters, enumerations, etc. Carries many application independent routines.
Beyond any words, one should read the source code to get the real benefit of it. I hope that this will be a rewarding process.
Turkish Abstract
Bu bir grafik tabanli emlak sorgu sistemidir. Emlak konusunun programin kurulusu uzerinde buyuk bir etkisi yoktur. Ayni program kucuk degisikliklerle bir okul, ya da stok sorgu sistemine de donusturulebilir.
Text ekran icin yazilmis olan programlara, sadece bir-iki fonksiyonun ismini degistirerek ( mesela printf()'leri grwritexy() yaparak, vs. ) onlari grafik tabanli yapabilmek icin temel olusturulmustur. C dilinin pek cok sirin ozelligi kullanilmistir (mesela fonksiyon tipi degiskenler, tipsiz degiskenler, siralama sabitleri, vs.). Pek cok, program yapisindan bagimsiz (yani genel amacli) fonksiyon icermektedir.
Kelimelerin otesinde, bu projeden yararlanmak istiyorsaniz, programi okumalisiniz. Odullendirici bir surec olacagini umuyorum.
Table of CONTENTS
PART I: Text screen emulation in graphics mode
The screens have been defined as 25 x 80. This's the usual size of a text mode screen ( currently). Emulation is managed by high level functions, and is portable through the range of cards & modes supported ( Hercules, CGA, EGA, VGA ). There're functions for formatted text output ( like printf ), box drawing, reversing line attributes, popping menus, etc.
If new routines would like to be added, there're some global variables to ease the process. Here're the list of those emulation related global constants & variables :
| Variable Name | What it means... |
|---|---|
| GRCOLAMOUNT | maximum col (constant) |
| GRROWAMOUNT | maximum row (constant) |
| giMax_xmaximum | pixel width-1 of the screen |
| giMax_ymaximum | pixel heighth - 1 of the screen |
| gcCol_pixels | pixel width of a character box |
| gcRow_pixels | pixel heighth of a character box |
| *gcXor_buffer | 80 column wide white screen ( getimage()d ) |
PART II: Forms Manager
There's an object-oriented-like FormsManager. It requires each form to point to its optional paint function, and field parameters.
Each field parameter consists of, in turn,
{
starting column,
starting row,
field's width ( length as a string ),
data type
}
The 'data type' parameter is an enumerated constant which is used to refer to the data type manipulation functions enumeration. The data type manipulation functions are...
| name | job |
|---|---|
| From | converts the data from internal representation to string type |
| Display | displays the 'string'ized data in a form
preferred by the data type. e.g: numeric types
should better be put flush-right, while
original strings are flush-left, and 'emlak
tipi' types ( a new type designed just for this
project ) is better to show a full word, say
'Villa', instead of just 'V'. |
| Validate | checks if the string passed to this function
conforms to the standards of the data type. |
| To | converts a string to the internal representation of the data type. |
Recently there was a pretty surprise ( which is met long after the form manager was in charge of its department ); In May '90 issue of Doctor Dobbs' Journal, there's an OBJECT ORIENTED PROGRAMMING EXAMPLE ( not in source code ) demonstrating POLYMORPHISM, and looks very much like FormsManager. In fact the fact that one can already design object oriented in C has been known to me for some time, but it was still a surprise to discover that, this fact has already found roots in deeper parts of the brain.
To define new data types is easy. Just write the manipulation routines for the new type. Then d the enumerations ( bind those functions to the data type, in other words), and you are done ! From then on, you can start having FormsManager take charge of the fields of that type, too.
And finally, why some inherently dynamic structure was not used (such as linked-lists) to keep the fields parameters, headers, etc. ? Yes, this would make it more flexible, and by no means is hard to implement from the manager's point of view. But then, one would lose the ability to initialize the parameters as static arrays. This's too much an inconvenience, to just be fit to some extreme applications ( like dBASE's get/read ). And also, if you so badly need such a mechanism, there are two ways : either modify the source code for the FormsManager, or use dynamic allocation (and reallocation ( to expand or shrink the parameters array ) ) routines of C.
PART III: The Menu Manager
The MenuManager, in fact, was an older idea than the FormManager. It has the same philosophy of FormManager, and is as much like the FormManager as you may decide a form & menu looks like eachother.
It has been successfully used in several text-based projects, but in graphics-mode most of the small ( though nice ) features had to be excluded, either for speed and/or memory space considerations, or for the graphics interface used ( BGI ) does not support it.
Still, IT DOES THE JOB. It is used at two places; one for the query operations menu, and the other for options menu.
PART IV: Threaded binary tree indexing
& [optional] Query ( Select ) mode
& related stuff
The indexing mechanism used in this program is a THREADED BINARY TREE.
The next(), previous(), include() ( --> add() ), exclude() ( --> delete() ), update() functions are used to manipulate the data in file ( and, of course, the indexes ). Those functions have a dual nature; they both operate in the 'Show All' mode, and the 'Select' (the optional query) mode.
In 'Select' mode, those functions also manipulate the active list (the list of the records that conform to the current selection criteria).
Frequently used query criteria can be saved in a query file. When a query is loaded, or has been just designed, the 'Select' mode is automatically turned on, and the active list is formed.
Here is a diagram (see next page) that shows some sample data and the related index, and active list formations (those 'kod no's with a check are those which conform to the current criteria):
CONCLUSION
The project is over now. It has come along a long way. The process was instructive. All that could be said ( I hope ), have been said in the previous sections, and here there's not much to say as a conclusion.
References
- Turbo C 2.0 User's Guide; Borland International; 1988
- Turbo C 2.0 Reference Guide; Borland International; 1988
- Ezzell, Ben, Graphics Programming In Turbo C 2.0; Addison-Wesley; 1989
- Adams, Lee, SuperCharged Graphics; TAB BOOKS; 1988
- Graef, Gerald L., Graphics Formats; BYTE; September 1989
- Quirk, Kent, Translating PCX Files; Dr. Dobb's Journal; August 1989
- Meadow, Anthony, & Offner, Rocky & Rudiansky, Michael, Handling Image Files with TIFF ; Dr. Dobb's Journal ; May 1988
- White, Eric, Object-Oriented Programming As A Programming Style; C Users Journal ; February 1990
- Duntemann, Jeff, Grinding the Speckled Axe; Dr. Dobb's Journal; May 1990
- Farah, Avraham, Debugging Heap Problems; C Users Journal; October 1989
- Norton, Peter & Wilton, Richard, New Peter Norton Programmer's Guide to IBM PC & PS/2; Microsoft Press ; 1988
- Horowitz, Ellis, & Sahni, Sartaj; Fundamentals of Data Structures in Pascal; Computer Science Press Inc.; 1984
- Miller, Nancy E., File Structures Using Pascal; Benjamin/Cummings; 1987
Appendix A: Software users' and recompilers' guide
Sotware & hardware requirements : to run the compiled version, you need either an IBM PC, XT, AT or PS/2 or compatible equipped with a CGA, Hercules, EGA, VGA, and at least with 128K free memory. To compile the source code, Turbo C 2.0, and 640K main memory are recommended ( Turbo C has got some clones in BGI compatibility recently).
To use the compiled version, change to the directory were the data and picture files reside, and type GFS (assuming that the executable is also in the same directory).
If the "emlak.280" file was found in the current directory, the software will start to use it, else you will be given a message that the file is not found, and will be asked if you would like to initialize one. If you really did not have such a file, and want to initialize one, type 'y', else if it is just because of wrong directories, or something like that, type 'n', quit the program, make necessary corrections, and restart the process.
In the main screen ( view mode ), there're headers that show several items defining an Emlak. If the file carries at least one record, the corresponding data portion will show one of these, if the field also has a corresponding picture ( a picture file that has a '.pct' extension to the record's code no, and resides on the current disk\directory ), the picture is also shown.
The last line in the main screen is, the available operations. Here are brief discussions:
| Operation | What it does... |
|---|---|
| <--- | If there are any records with code no's less than this one, goes back to reach the one before. In 'Select' mode, this means both less, and that conforms to the current selection criteria. |
| ---> | If there are any records with code no's greater than this one, advances to reach the one greater one. In 'Select' mode, this means both greater, and that conforms to the current selection criteria. |
| Add | Inserts a new record to the file. When you press 'A' ( or 'a' ), a form with no data is shown, and you're expected to fill it. When you press 'Esc', the input process is over. If the code is 0, or a record with this code already exists, insertion is rejected, else it's inserted in sorted order, and if there's an a corresponding picture, it is also shown. These were in 'Show all' mode. In 'Select' mode, the record is also checked for conformance to the current selection criteria; If it does, it is displayed, else the screen is restored to its previous look. |
| Delete | The current record is to be deleted when you press 'D'. If you also confirm the deletion with replying with a 'y' to the message, the record is deleted. If any record is available to be shown, it is shown. |
| Update | The current record is updated. You can edit it till you press 'Esc'. In select mode, if the new form does not conform, another one ( if available ) will be visible. |
| Query | This is a pop-up-menu entry. You can save some frequently referred queries for convenience, save them, or design them. When designing, string fields are optional. If you leave them empty, they're defaulted to ALL ( beware : space is not nothing ). For numeric fields, you nust specify the maxima. The initial defaults for all field are designed to include every possible record in file. |
| Options | This is also a pop-up-menu entry. Controls the sound during entry validation ( beep ), for more serious errors ( siren ), and swaps the query status between 'Select' & 'Show all'. |
| eXit | s the program, saves files, restores the screen to text mode. |
Those who would like to recompile the source should know just one thing extra to compiling an ordinary C program : the object forms of the BGI drivers & small font are included to the software. For this to be possible, first you must convert the files...
herc.BGI CGA.BGI EGAVGA.BGI litt.CHR
to .obj with the bgiobj utility supplied with Turbo C package, and then include those object file in your graphics.lib with the tlib utility.
tlib graphics.lib + herc cga egavga litt tcc gfs graphics.lib
Have fun !
Appendix B: Compiler specifics & environment limitations
Though we reserve almost half the whole screen for the picture to be displayed, BGI ( Borland Graphics Interface ) 's putimage is short of accomplishing the task in most modes. This ( we think ) is due to the segmented architecture of the 80x86; enough memory to load a screen wide, say VGA, image exceeds the size of a segment by far, and even the half size mostly won't be possible to allocate. But there are also problems in the huge model malloc(). The compiler promises that one would be able to allocate memory of more than 64K in huge model, thanks to the normalization of the pointers. But, though we have switched to huge model, we were still unable to allocate the needed size ( even e.g. 45K ).
We have also tried to manipulate PCX files for a long time. It's better than BGI-images in many ways. First, it's designed to be saved in a file ground up, second it's widely used and to find sample data would be very easy, and third it is of interest to many programmers, and we thought we had got an article that describes it enough ( that enough should be dropped, now ), and the last for here, as PCX is file-based, and is so widely used, the inter-program portability is almost guaranteed, while no one knows if Borland will change its image format at any time.
As an aside, not all formats used by BGI are so ambiguous. For example the graphics drivers (*.bgi), and font files (*.chr) have their standard interfaces (version numbers, size, etc., etc.) explained.
If someone ever tries to build on this project, we suggest him/her to ( try to ) use PCX, or much better, TIFF ( because it's portable through several ENVIRONMENTS - PC to Mac to nExt cube ).
The usage of optimizer had been tried to be optimized. It can see repeated codes in functions. In fact it is limited, but it was best to try to make maximum use of it for readibility. Stepping through the code with the debugger shows the result.
Appendix C: Hungarian notation
For those who would like to examine the code ( source ), here is explained the meaning of those prefixes found pre-almost-every-variable.
It's called 'Hungarian notation'. It's devised by Charles Simonyi - Manager of Advanced Languages at Microsoft. The notation requires a lower case prefix that describes the data type, followed by a variable name whose first letter is capitalized. Some prefix examples are:
b - boolean ( variable expects 0 or 1, usually an int ) c - character dw - double word ( type not defined, usually unsigned long ) f - flag ( used for bit-field variables ) i - int variable l - long lp - long pointer n - short int p - pointer variable s - string sz - '\x0' terminated string u - unsigned w - word ( type not defined, usually unsigned )
For example, iHeapStatus ( or iHeap_status ) is an integer variable whose name is HeapStatus ( or Heap_status ). This convention is used widely by MS-Windows and OS/2 programmers.
Some programmers have extended the prefix notation and have a prefix-to-the-prefix, representing the class of the variable, using these conventions:
a - automatic and parameter passed g - global variable ( as gupENdx in GFS.c) m - semi-global, static but visible throughout the module r - register variable s - static but visible in a block only
In the program, 'a' prefixes are not used for parameters, because they are taken as the default. Globals, and autos are shown.
For further examples, either see the program (GFS.c), or the article in C Users' Journal October '89 (p.p.105+).
Appendix C: Source Code Availability
I had designed, and implemented GFS, as a computer-programming final-project, in 1990. So far as I remember, I never modified gfs.c, and gfs.cpp, since that first submitted gfs.c. That gfs.c was self-contained, whereas gfs.cpp refers to a few custom includes/libraries of mine, for the i/o. This is minor difference, if, at all. And it is not a development, but abridgment, any way. This is fine, for our purposes.
gfs.cpp is available through the page gfs.cpp (alone) - without the related include/library files.
I publish gfs.cpp, for the reason that, now, on my computer's harddisk, and in 3.5" floppy diskettes, I have gfs.cpp, as the oldest version (Sept.11,1991, 21:47, with 59033 bytes). Next, there is a gfs.c (July 21, 1993, 14:15, with 62172 bytes) I may, later, find the submitted version (June 1990), in a 5.25" floppy, or at the department/friends, somewhere. Or, I may reconstruct/verify it from pages that I had printed. I have found a few of those printed old pages, already.
In a later project, I noticed that the threaded-binary-tree algorithm, as I had implemented, contains an error, but this is not the main importance of GFS, here. Therefore, this little warning suffices [now].
LastUpdated: May 19, 2004
Page-version: 0
Written by: Ahmed Ferzen/Ferzan R Midyat-Zilan (or, Earth)
Copyright (c) 1990, 2003, 2004 Ferzan Midyat. All rights reserved.
Wherever applicable, GFS, zElQarneyn's FIX, zFIX, and also FIX, are trademarks of Ferzan Midyat.