This is a document of the XTDLIB/FPK package COPYRIGHT (C) 1993..1998 by Marco van de Voort, All Rights Reserved Free for non-commercial use. See license.txt. E-Mail : Marcov@stack.nl (download page: www.stack.nl/~marcov/xtdlib.htm) Version 0.06 <- This is the most reliable versionnumber but one of this package, the most important one is the file name of the archive. Copying/colofon ------- XTDLIB is free for non-commercial use, but otherwise copyrighted. Commercial users (Selling applications with XTDLIB-code in it and/or distributing modyfied copies of this source) can contact mee on above E-mail address for more information. The unmodified source can be distributed without other restrictions then those mentioned in de GNU License Agreement. Donations will encourage me to develop this package further. The FPK package is rather small now. No wonder, because I only program a few weeks in FPK now (but many,many years I ago I programmed in TurboPascal). FileList ---------- The only files in this package are now : - This document. - EDate.pas Date handling(Unix dates etc) - EStrings.pas PChar handling (in addition to strings.pas, not replacing strings.pas) - EPasStr.pas String handling. - EDirTree.pas Directory/file searching. A base module which allows you to allow complex wildcards and recursion for your commandline util, while the details of the filesearching are almost entirly hidden and handled by EDirTree. - Dirtest.pas demo of EDirTree, which builds a directory tree(with files) in memory - EWindow.pas, start of advanced textwindows on top of Crt. See below. - Windtest.pas Test module for Window. See also below. - ELib.pas Misc routines. Used to be a module which contained diverse DOS-int-call procedures, but I haven't ported those. - DFree.pas Standalone demo. Unix DF command with colors. Read header about FPK problems. - Some untested files History/Philosophy behind XTDLIB. --------- The original, Modula2 Xtdlib was meant as a kind of SWAG for Modula2. The only difference was that it wouldn't be a bunch of loose messages, but a standarized, coherent library, a kind of secondary RTL on top of the normal RTL. Since feedback was nearly zero (except for the TopSpeed buglist which was also maintained in the archive), and cause it remained a 'Me, Myself and I' project I changed the package to shareware. When I started playing with FPK, I ported some small routines to FPK. While that went fast and easy, I decided to translate all mostused routines to a FPK version. The new philosophy is the same as the old one. Standarize the not entirely standard, but often used routines. The standard libraries aren't very adequate. The FPK runtime library team decided to keep the routines as close to the original TP routines as possible. I see their point, but why not throw the excess routines (you can't convince me they never use something like LTrim/FileExists) in separate units, and if you have to, only conditionally install those (for the purists) ? There must be enough Pascal-junkies out there to maintain both a BP version, and a FPK native version, with some extra's for the diverse platforms. Compability kept, and full speed on both platforms. The RTL-runtime even put the compability issues through that far, that Linux.pp has unix-date routines, which dos hasn't. Dos however has the filetime procedures for its own filesystem, but Linux doesn't. The routines exist, are OS-independant allthough Dos-filetime is not that handy, but aren't shared. Installing ----------- Make sure the main units are in your unit path, and compile :-) Except for DFree, Dfree requires -Rintel switch All other units need -Rdirect. This is switch is default, so if you don't use -Ratt or -Rintel in your ppc386.cfg, you don't have to specify it. Procedure names --------------- I got a remark that the string routines have weird names. This is not entirely true. De Pchar routine-names originally came from C, not from Pascal, and have Cish names. Since this is Pascal, I dare to choose names with Pascal/Modula2 conventions. I don't know C enough to supply the names for the corresponding C routines, and named them the way I did it in Xtdlib for easier porting years ago. Those names are partially own fantasy, partially derived from things like swag. If somebody has a coherent proposal for the names, I will change them, maybe with aliases to the old names (if possible). Keep in mind that I come from the Modula2 platform, and don't like all lower case names :-) Assembler, and my coding style. -------------------------------- A lot of people (specially academic programmers) avoid assembler as long as they can. I don't. I can get away with it, cause I am an hobby-programmer. I heard the reasons for killing asm a dozen time, and though I don't fully agree, I can understand professional programmers point about assembler. I like assembler simply because I think small often used routines (like a rtl) should be done in assembler. I often keep highlevel versions(often not optimized) in a separate archive to avoid portability problems. If you dive into public code(like swag), you'll find numerous units which are Pascalled assembler (loading System.registers and Intr calls is the only thing which is done). Personally I think that is bad programming. The dos-interrupts (and the bios interrupts even more) were designed to be called in assembler. My own style isn't that great. It was fair with 16-bit code, but know it's a bit old fashioned. It took me 12 days to discover that I could use a imul in immediate mode on a 386+, and yesterday I replaced 16 test ecx,ecx je $label by jecxz $label :-) Ppc386 assembler programming is easier than what I'm used to. - Stack calling conventions (opposed to register-) are simpler, more regs free - No worries about segment for normal routines. A register is an address. - No worries about what is 286+, 386+ or not. Just program 386 code. (I almost used a 486+ instruction in EDATE however, but commented it out, see notes unixdates) FEEDBACK. --------- My E-mail address is at the top of this document, feel free to mail. Also I have some questions for YOU! - What should I do with the manual. I thought about converting it to HTML, but I'm not entirely sure. Please don't propose Latex. To long learning time, too big, and my Linux PC is also server and only has a monochrome display. UNITS descriptions. ------ EWINDOW ------ THIS UNIT IS STILL EXPERIMENTAL One of the most interesting standard units of Modula2 (also a Wirth language like Pascal) is module Window. It implements multithreaded textwindowing. So this module does NOT exist in the modula2 version of XTDLIB, it was written from scratch while peeking at the several Modula2 implementations. This module emulates the Modula2 counterpart A BIT. The module is still under development, but the raw core stands, the rest is changing window colors, implementing shades etc, moving etc. Problems, points of critics, differences with the M2 version. The problems marked with x are somewhat fundamental, and won't be implemented soon I think. -x No Multithreading, and/or support for writes to hidden/background windows. This is a result of EWindow being based on Crt's Window procedure, and Pascal not (default) supporting multithreading. Also the M2 Window manages it's own Crt. (Crt doesn't exist in Modula2, Window with only the FullScreen window used is the M2-equivalent) As a result Use puts the window on Top.(makes it visible), so that Crt can write in it. This will be the main problem in the future I think. The rest can be changed, but this can't without integrating Crt into EWindow, and making Crt and EWindow mutually exclusive (like the Crt in the Modula-2 version of Xtdlib but the otherway around) -x No wordwrap. Also a result of Crt handling the writes. - "Huge" consumption of memory. All windows are kept in memory including the "fullscreen" Due to my inexperience with aligned arrays, my allocation is probably to 4-2 times too big, and my system dumb. Will be improved in future versions I hope. (Not really a problem with an extender anyway, heap comsumption maximal 40k or so when normally used. 40k equals 5 fullscreen windows) - Some of the lower functions are not implemented yet (colorchanges of frame, dumping (reading a window, maybe via Crt) etc etc. However the difficult parts (except the specific RedrawScreen) stand I believe. -x Portability issues. EWindow is now based on writing to $b800 with a DosMemPut. Not really portable. To be portable Linux should be able to read the screen, and write it, and both at a very high speed. Maybe Linux' Crt internal virtual screen can help here. The number of dos-dependant calls is about 20, and mostly located in 2-3 procedures. -x PROCEDURE RedrawScreen now redraws entire screen, should be limited to portion actually to redraw. Specially interesting for a Linux version. Less(Even none!) complete redraws of the screen. - Way too less checking on several important parameters (closing NIL windows, Creating Windows with X2