In the meantime I downloaded the Abbrevia package from SourceForge, and came across several unpleasent constructs. Please let me introduce my preferred programming model for portable code.

1) Target Dependencies
I don't accept any OS or machine specific conditional compilation in code, except in dedicated units. In Abbrevia the same fixes occur in various places in the code, instead of in a dedicated OS specific procedure. Such a procedure exists, but unfortunately only in the unpatched form :-(
Also compiler specific conditionals should be used only where absolutely necessary (local options, syntax differences...).

2) Code Checks
It should be possible to check code for compilation on other platforms. This requires that target specific code can be compiled on any host, somehow. Consequently it must be possible to override the compiler generated symbols that describe the environment.

3) Standard Units
Portable code shall use standard procedures and units for target specific actions. This requires the definition, implementation, and consequential use of one or more standard units for:
- Machine specific data types and procedures (endianness...)
- OS specific data types and procedures
- C and POSIX specific data types (for code ported from GNU/C) Then it should be clear which portable data types and procedures should be taken from which unit. It also should be easier to determine which procedures need special considerations in portable code, from the defined data types and procedures in these units.

It's not necessary that everybody follows these principles, but I will do so in my own published portable code. Otherwise I can continue to write my code for Delphi, and let it to somebody else to port that code to e.g. FPC.

In the simplest case these units will have an unconditional interface part, the target specific data type declarations and the implementation part can be included conditionally from the appropriate locations. For testing purposes fake units or code sections can contain the OS specific procedure declarations, with empty bodies. This way I could verify that my changes to the main stream code would not break the code for other environments, due to the use of not yet ported constants or data types etc.

This model has one disadvantage, in so far as complex procedures with small embedded platform specific code could no more be checked, because it often was impossible to determine the impact of changes to local variables etc. in the conditionally excluded code. It also was and is impossible to automatically verify that the conditional sections really are implemented for every target!

In another implementation of a target independent library I defined portable classes with standardized methods. These virtual methods were almost abstract in the base class, so that they had to be overridden in every derived class. In the initialization section of the unit the appropriate class was created and assigned to the according variable, based on the actual or desired target environment. Of course this approach has the disadvantage of increasing runtime (how much?), due to the virtual method calls. Nonetheless I think that in many cases the difference from the traditional method will not be noticeable, due to the (unknown, long?) runtime spent in the embedded OS calls.

The best compromise might be a mix of both methods. The interface can be fully procedural, and objects with virtual methods are used only in the implementation part, and only when this approach makes sense. Perhaps somebody finds another way to achieve the same goal, with less disadvantages?

I'm willing to demonstrate my ideas in a redesign and extension of Abbrevia, so that we have a concreter base for further discussions. But before starting with that work I would like to hear some encouraging <g> opinions or suggestions.

DoDi

Agreed 100%.
In general, a component suite should have all os-dependent code in a single unit, presenting the rest of the suite with a uniform API.

Why, you can simply cross-compile ?

Compiler defines the endianness.
System unit has 'guaranteed' types.

- OS specific data types and procedures

? This is not portable.

I don't think you should worry about virtuals. For archiving purposes, it's the compression/decompression algorithms that will take most time, and tha actual reading/writing from stream.

I think you can do this. I will be pleased to help where I can. But send a proposal before you start, I wouldn't want to you end up rewriting half your code after a discussion. ;-)

Michael.

Fine :-)
But how should that code be implemented? For various target platforms?

> 2) Code Checks Why, you can simply cross-compile ?

No, I can't, neither in Delphi nor (AFAIK) in the Windows version of fpc.

> 3) Standard Units Compiler defines the endianness.

Correct, but this definition must be evaluated to produce the appropriate code. E.g. RPM defines a function htonl, read: HostToNetworkLong, that then is used to convert Long values in Network byte order (big endian?) into the Host byte order. Such a function should reside in a common unit, where the according implementation depends on the endianness of the host machine. It also should have an handy name, so that it's almost obvious how to replace htonl in the ported code.

System unit has 'guaranteed' types.

Fine, but these names often are not very descriptive, like ShortInt and SmallInt. Names like cUInt16 make it more obvious that this type has a fixed size and is unsigned. More standard C names have to be mapped to the predefined types. E.g. in Abbrevia the file size type (IMO) initially has been Integer, later was conditionally extended to LongInt and then to Int64, depending on the capabilities of the compiler and platform. Here it can be seen that a replacement of some type by the currently appropriate System standard name is not a good idea. A distinct data type like off_t (standard C) would make all related adaptations much simpler, with exactly one definition of that data type.

> - OS specific data types and procedures ? This is not portable.

When porting code, that was written for a specific platform, the names of the procedures and related data types should not be changed. Instead these procedures should be declared in a general unit, together with the according implementations for other platforms. Please note the different handling of OS functions and types, where the names should not be changed, in contrast to the htonl function mentioned above, that should be renamed to the according (to be defined) common procedure name.

I don't worry at all, but many people (assembler freaks...) will. That's why I want to collect opinions before proceeding.

For archiving purposes, it's the compression/decompression algorithms that will take most time, and tha actual reading/writing from stream.

This is an rather obvious case, but there exist other cases...

After a closer look at Abbrevia I'm not sure whether it's a good example for porting code. The recent Kylix extension is crap, and also the preceding conversions into Windows specific procedures and Pascal standard types must be reverted to the original definitions. That's why I'd prefer to use the better ported and portable code from e.g. zlib and bzip2, instead of again porting the according miserable code from Abbrevia. More to follow...

DoDi

Here some comments and questions about the Abbrevia port.

1) Conditionals
I've redesigned the AbDefine.inc file, with two important changes:

In the first place a DEBUG symbol allows to replace everything else by another AbDebug.inc file. This switch will allow (me) to define the OS etc. at will, for debugging purposes. Defining this symbol and the file contents is entirely up to the user, the file will not occur in CVS or any distribution.

In the next place the FPC symbol is used to replace the Borland specific part by an AbFpc.inc file. This file, with an appropriate name, can be contributed by some FPC user, I don't care for this conditional branch for now.

Question: Rename all files? All lowercase...?

The LINUX symbol can clash with the according FPC symbol. It should be renamed e.g. into KYLIX - does somebody know what Kylix defines for itself?

Question: How to use the FPC provided target symbols? I'm not happy with the UNIX keyword, I'd used POSIX instead. But that's only my opinion, I don't want to introduce another symbol. I'm also not familiar with the differences between the Unix/POSIX systems. Currently I make no according differences myself, I only separate the existing code into conditional MSWINDOWS and UNIX parts.

2) File Restructuring
I've separated the spaghetti code in AbUtils.pas into distinct MSWINDOWS and UNIX sections, each containing complete procedures. These sections could be moved into dedicated OS specific include files - what's the preferred way?

It may be desireable to use another dedicated unit for strictly platform dependent procedures, apart from AbUtils?

According to my first impression of the Abbrevia coding conventions I'd prefer to use the existing and better ported and portable code in the already existing paszlib and bzip2 libraries, instead of porting the according Abbrevia implementations. Perhaps the whole de/compressor part of Abbrevia could be reduced to the base classes, from which inherit the new wrappers for the FPC ports.

Question: What's preferrable, a direct port of the Abbrevia library, or a new and better portable design instead, that interfaces with the not otherwise available worker classes as implemented in Abbrevia?

A direct port IMO requires more work than a redesign. In a redesign also much Windows/Delphi/Kylix specific stuff could be removed or replaced by more portable procedures. The entire file handling stuff in Abbrevia IMO is too Windows-centric, the Linux/Kylix extensions only are patchwork that tries to map the Windows file handling to the very different POSIX file handling, what can result in loss of file attributes on POSIX platforms.

3) Data Types
"off_t" now replaces the Integer/LongInt/Int64 mess, for all file size related values. I took this name from the C standard, but perhaps it should be replaced by some Pascal name?
IMO this type also should be used in the TStream classes, replacing the current conditional distinction (seek64bit) between 32 and 64 bit methods. Why write two implementations, when the compiler can use the actual type definition immediately?

"DWORD" will be replaced by cUInt32 (or equivalent - what?), as far as this type is used outside dedicated MSWINDOWS code.

The 16 bit "word" datatype IMO should not be used in 32 bit code, unless where required in datastructures with a fixed layout.

Similar considerations and decisions will be required during porting, I only presented these examples as a concrete base for a general discussion.

4) Exceptions, Error Codes etc.
IMO it would be sufficient to use one general exception class for the de/compression errors. An application cannot draw any advantage from many specialized exception classes, and exception handlers inside a specific class can use the class specific error code in the exception object.

For the same reasons I think that public error codes only should be specified for those error conditions that can or must be handled in some specific way. These common codes then should be used by all de/compressor classes.

DoDi

This seems good.

That would be preferable.

The LINUX symbol can clash with the according FPC symbol. It should be renamed e.g. into KYLIX - does somebody know what Kylix defines for itself?

Nothing other than 'verX' (replace x with 14,15 or 16) and Linux...

Question: How to use the FPC provided target symbols? I'm not happy with the UNIX keyword, I'd used POSIX instead.

The FPC units are not POSIX, hence, UNIX.
(long threads have already been spent on that, and it is a done deal)

This is good.

{$ifndef unix}
{$i abiuwin.inc} // more to follow later: e.g. Mac OS, Netware etc.
{$else}
{$i abiulin.inc}
{$endif}

It may be desireable to use another dedicated unit for strictly platform dependent procedures, apart from AbUtils?

If there are a lot: yes, otherwise, I think they could

Second option.

Agreed.

I think the best way - for now - is to define a set of basic types in some base unit:
- TFileHandle
- TSeekOffset
- ...
Which should be used consistently throughout the system. These base types can then be mapped on a per-os basis to whatever fits best.

(or to basic FPC types, when (not if!) FPC introduces them.

IMO this type also should be used in the TStream classes, replacing the current conditional distinction (seek64bit) between 32 and 64 bit methods. Why write two implementations, when the compiler can use the actual type definition immediately?

The current implementation is done for compatibility with Delphi, and for optimization.

"DWORD" will be replaced by cUInt32 (or equivalent - what?), as far as this type is used outside dedicated MSWINDOWS code.

The native pascal type is 'Cardinal'. But see the remark about basic types.

The 16 bit "word" datatype IMO should not be used in 32 bit code, unless where required in datastructures with a fixed layout.

Agreed.

Yes and no. You can use exceptions perfectly for aborting code. It is a common misconception to think that an exception always signals an error condition. Of course, the code must then know which exceptions are error conditions and which not.

But normally, I agree that you don't need too many exception classes. 1 or 2 with an error code field (if needed at all) should be enough.

Agreed.

Michael.

I suggest the thread be continued in your other mail.

Michael.

On Sun, 2 Jan 2005 23:35:10 +0100 (Romance Standard Time), Michael Van Canneyt wrote

On Sun, 2 Jan 2005, DrDiettrich wrote: > Michael Van Canneyt wrote:

.
.

There's at least one (IMHO not worse at least) alternative to that (already used in FPC itself among others) - keep the include file name the same, place it in separate directories for different targets (like UNIX, WIN32, etc.) and provide the right paths using a Makefile (see e.g. fcl/Makefile.fpc + Makefile in our source tree). The advantage of this approach is that you don't need any ifdefs at all (especially when there are more targets supported it could get somewhat messy).

Tomas

You might also want to have a look at

http://www.stack.nl/~marcov/porting.pdf

and

http://www.stack.nl/~marcov/unixrtl.pdf

A combination of ver<x> and linux, as Michael said.

There are 4 cases for Unix:

1 Kylix
2 FPC/Linux/x86 reusing Kylix libc code.
3 FPC/Linux/x86 using general FPC unix code
4 Other FPC Unix targets using general FPC unix code

Since 1->2 is an easy port often, so I think in general FPC/Linux/x86 should remain switchable between "libc" and "FPC-UNIX" mode.

Question: How to use the FPC provided target symbols?

See the "porting" guide. I try to adhere to it, and so does JEDI.

I'm not happy with the UNIX keyword, I'd used POSIX instead. But that's only my opinion, I don't want to introduce another symbol.

As Michael said, that was already discussed.

I'm also not familiar with the differences between the Unix/POSIX systems.

Unix is supposed to be a superset. However one of the main reasons is to avoid standards picking.

I (and FPC in general) prefer that. Jedi prefers to ifdef ad infinitum, they are (used to be is a better word) afraid of include files.

Since the answer varies wildly with the amount of work the implementor wants to invest, I guess my answer would be "that is up to the implementor".

To me, a clean interface with zlib that is switchable between shared lib and paszlib is a pre. I always liked that in the old situation. Partially also because paszlib is still slower.

3) Data Types "off_t" now replaces the Integer/LongInt/Int64 mess, for all file size related values. I took this name from the C standard, but perhaps it should be replaced by some Pascal name?

FPC still got to acquire a native form of 64-bit filesupport. I think using an identifier that is not likely to clash with existing types is preferable. So that rules out off_t (which is used by Unix internally).

Later when FPC has a system for 64-bit fs, we can assign the type to an invariant that has the right size for FPC's filesystem. (64-bit on new systems, 32-bit on legacy)

IMO this type also should be used in the TStream classes, replacing the current conditional distinction (seek64bit) between 32 and 64 bit methods. Why write two implementations, when the compiler can use the actual type definition immediately?

I'm in favour of simply making the whole FPC file implementation 64-bit, regardless of 64-bit OS support or not.

"DWORD" will be replaced by cUInt32 (or equivalent - what?), as far as this type is used outside dedicated MSWINDOWS code.

On *nix, the unixtype unit defines these.

The 16 bit "word" datatype IMO should not be used in 32 bit code, unless where required in datastructures with a fixed layout.

True.

I think it would wise to not use exceptions too deep in the code. Compression is one of those things where OOP and exception overhead still count.

This is definitely an option.

Michael.

The reason is very simple: They are all Delphi programmers, and the Delphi IDE has NO understanding of include files. Codetools don't work at all if you use include files. That said: $ifdefs confuse it as well...

Michael.

That is one, the another is that they simply have support less targets. A ifdef that is not bad with two possibilities, becomes annoying with 20.

I guess you mean "Code Insight (R)" don't work at all .. . ;)

Mattias

-----Original Message----- From: Behalf Of Marco van de

erstanding of include files. Codetools don't work at

Apart from win32 almost all operating systems that are used by anyone are unix like enough to be considered the same. At least in normal code (things like the rtl of course are a very different matter).

On Mon, 3 Jan 2005 14:56:07 -0000, peter green wrote

You don't want a flamewar here, do you? Let's put it mildly - I don't agree with your statement about "all operating systems used by anyone", as I know quite a few distinct operating systems (different from Unix and Win32) which are still used by quite a few people in total (even if you don't care at all).

If you want to discuss this particular question further, please, use my private e-mail for responding.

Tomas

Not everything is a matter of OS. It could be also a matter of toolkit, database, word size of the cpu or whatever. Further smaller files are usually easier to handle:
- cvs works much better with small files
- easier navigation in editors
- last but not least: work with small units as much as possible
- easier overview what has been modified when checking logs: which log entry is better:
rtl/system.pp: fixed writeln
rtl/morphos/ossysc.inc: fixed writeln
?

Michael Van Canneyt wrote

The FPC units are not POSIX, hence, UNIX. (long threads have already been spent on that, and it is a done deal)

I don't want to resurrect a discussion, but can somebody give me an idea how UNIX and POSIX are different, with regards to FPC?

I have already started with a revival of my TXStream classes, now with hopefully better portability. One problem are required changes and extensions to the TStream base class. The new stream classes will be either input or output streams, and will have I/O buffers used for crypting and compression. What's the recommended base class herefore? THandleStream?

That's why I choose the well defined C names for now, like size_t, off_t.
off_t could be replaced by TFileSize, what's the reason for moving from 32 to 64 bit for huge files, whereas TSeekOffset also indicates that this type must be signed for moves in both directions. size_t must not necessarily become a new type. I used it for the amount of data in Read and Write, where (signed) 32 bits are sufficient on 32 bit machines, with regards to buffer size in memory.

These base types can then be mapped on a per-os basis to whatever fits best. (or to basic FPC types, when (not if!) FPC introduces them.

The best base unit IMO is where the low level I/O procedures are defined, which wrap the OS I/O calls (FileRead...).

The current implementation is done for compatibility with Delphi, and for optimization.

Hmm, compatibility with which Delphi version? ;-)

Apropos optimization, in many FPC units I found constructs like: if x = 0 then f(0) else f(x)
In these cases the IF is superfluous.

> "DWORD" will be replaced by cUInt32 (or equivalent - what?), as far as > this type is used outside dedicated MSWINDOWS code. The native pascal type is 'Cardinal'. But see the remark about basic types.

DWORD often is used for exactly 32 bits, so that Cardinal is not an appropriate replacement.

Perhaps we should discuss the (new and old) data types explicitly, for a precise description of the intended use, naming, and general properties (signedness, fixed or minimum bit size...).

DoDi

Here's my general idea of an Abbrevia compatible redesign:

The working name for this new project is Directories+DirectoryItems, with a "di" prefix for the unit names etc. The project unifies the handling of archives, compressed and encrypted files.

The basic objects are Directories and DirectoryItems. This should allow to cover the file systems of all platforms, as well as archive files, networks etc.

Directories are DirectoryItems themselves (subdirectories), in general containers for DirectoryItems, with according management functions. One method allows to enumerate all contained DirectoryItems. A callback function can process the items and signal abort (when the file is found) or recurse (into a subdirectory). This IMO is a better replacement for the FindFirst/FindNext/FindClose crap, applicable also to the contents of archive files.

Other DirectoryItems are files and links.
Links transparently wrap the linked file for file related operations, and have additional methods for managing the links themselves (redirect...).
File items can be opened and closed, open files have an according Stream object/property.
Archive files must be mappable into Directories, somehow. A Mount method might return the appropriate Directory object for the files inside an archive.

Question:
On Posix (Unix?) file systems the ownership (UID, GID) as well as specific file (executable...) and directory (sticky...) attributes are important, when extracting files from archives. Does FPC already provide according portable access and management procedures?

DoDi

A good idea - at least for FPC ;-)
For Delphi it does no harm to implement just the Windows specific part, in a dedicated directory.

I only don't know how to implement or check the other branches - is the Windows version of FPC equipped for crosscompilation?

DoDi

Ah, thanks :-)

How important is Kylix at all? Isn't it almost dead now?

I think it would wise to not use exceptions too deep in the code. Compression is one of those things where OOP and exception overhead still count.

I'd use exceptions only for fatal errors, which can be caught in the application code. The cost for raising such exceptions is neglectable, and catching outside the compressor does not affect the efficiency of the worker code. The worker code can become simpler this way, because error checks in every level then are superfluous. OTOH all local resources then must be protected by try-finally blocks...

DoDi

Florian Klaempfl wrote

Not everything is a matter of OS. It could be also a matter of toolkit, database, word size of the cpu or whatever. Further smaller files are usually easier to handle: - cvs works much better with small files

Hmm...

- easier navigation in editors

Definitely NO, with regards to include files! (May miss your point?)
1) Navigation inside one file is more powerful (search, replace..)
2) How to determine all related files, e.g. for other targets?
3) How many windows are required for one unit?
4) Long search pathes require accordingly featured tools (target switching...)
5) How to produce diffs for multiple versions (targets) of one unit?

- last but not least: work with small units as much as possible

Hmmm...
I think that I prefer compact projects, with few units and no include files.
At least I don't like units consisting effectively only of includes. That's near C, with it's sea of header files and unrelated implementation modules, and the effectively compiled text becomes visible only after running the preprocessor :-(
BTW, I already wrote an preprocessor to produce single files from the FPC units. Now I have to extend it, for multiple targets...

- easier overview what has been modified when checking logs: which log entry is better: rtl/system.pp: fixed writeln rtl/morphos/ossysc.inc: fixed writeln

I'm not sure about the logging conventions. Precise logs require to save almost every single change, with an appropriate comment. After half an hour with multiple related corrections it's hard to find a really descriptive common subject.

DoDi

Probably yes, you can easily open two editor windows viewing e.g. declaration and splitted view is always a mess
and requires mouse usage.

1) Navigation inside one file is more powerful (search, replace..)

grep/sed is more powerfull than any search/replae of an editor :) Even more if grep is integrated into the editor :)

2) How to determine all related files, e.g. for other targets? 3) How many windows are required for one unit?

I don't know, but usually two are enough when modifying e.g. a class: definition and declaration.

4) Long search pathes require accordingly featured tools (target switching...)

Well, this might be sometimes a problem, usually it isn't anymore.

5) How to produce diffs for multiple versions (targets) of one unit?

Modify it; do a
cvs diff fcl > fcl.diff

Having nested ifdefs with matching endifs or elsifs several hundred lines further _is_ a hell if you didn't write the code.

At least I don't like units consisting effectively only of includes. That's near C, with it's sea of header files and unrelated implementation modules, and the effectively compiled text becomes visible only after running the preprocessor :-(

If you have projects were a _team_ works on, having multiple include files is definitively better.

When fixing bug by bug in 10min you don't think about better log messages :)

On the condition that you also implement by default also a method returning a TList or TStringList with TDirectoryItems. Not everyone is comfortable with callbacks. The TList/TStringlist method should work fine for not-too-large lists.

This seems all pretty much OK.

No.
We have stuck to the lowest common denominator, i.e. Windows, mainly for compatibility reasons.

I think that if we're going to be having a new implementation, we should go for the maximum, and provide sensible defaults for the 'lesser' OS-es.

Michael.

FPC and POSIX are totally unrelated.
Unix is a superset of POSIX. Most Unices out there are POSIX compliant.

POSIX says nothing about pascal, it's basically a C interface.

The FPC baseunix/unix units mimic more or less the POSIX standard, so
1. It would be easy to write Pascal code, based on C examples.
2. It can be mapped on Libc for porting purposes. If you port to a new platform, and it has a Posix-confirming C library, you will have little work to do.

No. TStream. An archive stream does not have a handle.

1. They are not "well-defined", but this is another story :-)
2. I absolutely HATE underscores in types/variables/whatever for documentation purposes it is a horror (I use TeX)

Sysutils, then.

5 at least.

Apropos optimization, in many FPC units I found constructs like: if x = 0 then f(0) else f(x) In these cases the IF is superfluous.

You can send a list of such things to any core member.

Cardinal = 32 bits _always_. Also on 64 bit.

Perhaps we should discuss the (new and old) data types explicitly, for a precise description of the intended use, naming, and general properties (signedness, fixed or minimum bit size...).

The old are not subject to discussion.
You can introduce new ones in any way you see fit.

Rule number 1 when creating a new (big) Delphi project: "Subclass ALL classes you will be needing."
Saves a lot of trouble afterwards.

Same rule applies here.

Michael.

grep/sed is more powerfull than any search/replae of an editor :) Even more if grep is integrated into the editor :)

Two advantages of using an editor search tool is:

* Interactive replace, because often not all of the possible replacements should actually be replaced.

* Batch search where the result set is browseable.

Also not everybody is fully comfortable with grep/sed :)

Olle

On Tue, 04 Jan 2005 02:14:33 +0100, DrDiettrich wrote .
.

I only don't know how to implement or check the other branches - is the Windows version of FPC equipped for crosscompilation?

The compiler itself can compile for all platforms listed in help pages (those running on the same CPU). However, you need GNU tools (as & ld at least) for every target - some of them are pre-built for you and can be downloaded from ftp://ftp.freepascal.org/pub/fpc/contrib/cross/. Alternatively, you can compile with "-s" parameter, which gives you the generated assembler code for your source files and scripts necessary to assemble&link somewhere where the right tools are available (like the target platform itself).

Tomas

crosscompilation from windows to unix using libraries is also not that easy.

I did it already for arm/linux: simply copy the *.a files to win32 and pass the path with -Fl to the compiler.

I did it for small programs in sept-okt 2003 (mkxmlrpc specially). Didn't manage with textmode ide though. It always segfaulted on startup.

Hi,

I've found that the definition of some constants like RT_RCDATA or IDI_EXCLAMATION from the latest RC1 is a little bit strange. These "constants" are defined as functions, which return a value using the function MakeIntResource, which in turn does a type casting from integer to LPTSTR. So all this only does returning a fixed integer value as LPTSTR.

Why do this? Even if inline functions would remove most of the overhead, it seems odd. The compiler perfectly understands a type cast in a constant definition like

const TestConst = LPTSTR(5);

At least in Delphi mode this compiles fine. I didn't check the other modes, though.

Another side effect of this function approach is that these "constants" can never be used as values for default parameters. The following function does not compile in FPC 1.9.6, but works fine in Delphi:

function GetResource(
  lpszName : PChar;
  szType   : PChar = RT_RCDATA;
  hInst    : HINST = 0) : Pointer;

Bye,

Frank

How do you "open two editor windows"?
In Lazarus I didn't find such a function yet, and using separate instances of an IDE for work on the same project is not recommended (concurrent save?)

---
I don't want to inititate an flame war about mouse usage and toolism, but you should know:

It was in 1986 when I got my first Atari ST, because it had a GUI. Then I found that I can work better with a GUI than with a command prompt.

I also prefer integrated tools, instead of an sea of tools for specific tasks, coming with private and cryptic commands and arguments. In an IDE the various components and commands must fit together, whereas separate tools have nothing in common, by nature.

Some people use emacs as their IDE, but I cannot remember the many keystrokes that are required to perform various tasks in such an environment.

I accept that editing files should be possible without a mouse, but sometimes it's easier to use a mouse for navigation and other tasks, instead of the keyboard.

So much about my personal preferences.
---

> 1) Navigation inside one file is more powerful (search, replace..) grep/sed is more powerfull than any search/replae of an editor :) Even more if grep is integrated into the editor :)

As is the case with Delphi :-)

Grepping the FPC source tree doesn't distinguish between target specific directories. This behaviour may be unwanted sometimes...

For porting purposes various dedicated versions of the same procedures or definitions (FPC/Delphi, Windows/Linux, C/Pascal...) must be accessible concurrently. I also can configure in Delphi that I can jump to a definition in an different file, that is displayed in a different Window, so that the definition remains visible when I jump back to the original location.

Hmm, if I understand you right then this command will produce a diff of all files in the fcl tree?

What I wanted is a diff of e.g. classes.pp for Win32 vs. for Linux. Similar to a diff of classes.pp (FPC) vs. classes.pas (D4).

Having nested ifdefs with matching endifs or elsifs several hundred lines further _is_ a hell if you didn't write the code.

It's a hell even if you wrote such code yourself :-(

If you have projects were a _team_ works on, having multiple include files is definitively better.

I'm not sure. The organization has nothing to do with contents. A version control system always has to handle concurrent updates of the same pieces of text, regardless of the size and number of the related files. It were most important to me to find related changes, in all affected places, based on a single change notice. Yes, I know that I can grep all possibly affected files for a common change notice, but that is not what I need and want to have.

I agree that include files help to keep distinct contents in distinct places. But development means to fit things together, so that dependencies and relationships must be recognizable in the first place.

When fixing bug by bug in 10min you don't think about better log messages :)

I don't remember the exact procedures, isn't it required to connect to the server for such updates? For me that would mean to boot a different OS, connect to the server, synchronize with cvs, shut down and reboot my working OS again. Even without a reboot such a sync (update?) breaks the workflow, and I started to use an batch file with the messages and the related units. AFAIR not a pleasant procedure at all, and a sync usually took more than 10 minutes :-(

Bug fixing is not the primary goal of development. Even if I agree that bug fixing is inevitable, I suspect that the relationship between bug prevention and bug production is tightly related to the used development tools and methods. But that's another story...

DoDi

Michael Van Canneyt wrote

> method allows to enumerate all contained DirectoryItems.

...

On the condition that you also implement by default also a method returning a TList or TStringList with TDirectoryItems. Not everyone is comfortable with callbacks. The TList/TStringlist method should work fine for not-too-large lists.

It's not a matter of the lists, it's a matter of the required processing. When it takes the same time to build the list than to extract or decrypt all files, then one may prefer *not* to wait for the list before simply extracting all files.

Of course it's always possible to build a file list, with a simple procedure that wraps the enumeration procedure.

Could you imagine a procedure that gets an record with file attributes, as found in an archive, and then does the best with regards to the actual host system? I could write such a procedure for both Windows and e.g. Linux, provided the required OS calls are available. Would that mean that I had to use libc for the Unix part?

DoDi

Michael Van Canneyt wrote

POSIX says nothing about pascal, it's basically a C interface.

To me POSIX means primarily the very different file handling, with regards to devices, path separators, owner/group/world access rights etc. This is what bites not only me when porting GNU software to Windows.

The FPC baseunix/unix units mimic more or less the POSIX standard

As already mentioned, I couldn't find these units :-(

No. TStream. An archive stream does not have a handle.

It was so in my first approach. But you are right, an archive or decompressor stream should use an input stream, as provided by the calling application.

> That's why I choose the well defined C names for now, like size_t, > off_t. 1. They are not "well-defined", but this is another story :-)

Hmm, I refer to the GNU libc documentation, so I thought that some types and procedures are well specified there.

2. I absolutely HATE underscores in types/variables/whatever for documentation purposes it is a horror (I use TeX)

I also don't like underscores, but for porting IMO it's a *must* to retain these names. How else should somebody know which Pascal names to use for these types?

Okay.

> DWORD often is used for exactly 32 bits, so that Cardinal is not an > appropriate replacement. Cardinal = 32 bits _always_. Also on 64 bit.

As I understand the Delphi documentation, Integer and Cardinal have an unspecified size. In a 16 bit environment they have 16 bits, in 32 bit environment 32 bits. Of course one could say that even on a 64 bit machine the most frequently used numbers will have 32 bits as well...

It would make life easier, with regards to 64 bit machines, 64 bit file sizes etc. I definitely see no problems when the file-size types (off_t) would be retyped from LongInt into e.g. TFileSize in the TStream class(es). This is one of the rare cases where one can learn from Windows and C ;-)

DoDi

Tomas Hajny wrote

> I only don't know how to implement or check the other branches - is the > Windows version of FPC equipped for crosscompilation? The compiler itself can compile for all platforms listed in help pages

The problem is that the installed FPC doesn't show any help - no files installed. There's something wrong with that FPC version :-( I only could install an older verion, but AFAIR that one cannot cross new version is out of reach to me, unless I get it on a CD.

Alternatively, you can compile with "-s" parameter, which gives you the >generated assembler code for your source files and scripts necessary to >assemble&link somewhere

That would be sufficient, I mainly need an syntax check. Best in Lazarus, so that I can browse through the related source files...

DoDi

Marco van de Voort wrote

You might also want to have a look at http://www.stack.nl/~marcov/porting.pdf

A very fine document, I'll have to study it in detail :-)

At the first glance I found some more or less important errors in this document. Do you want an according list? How to refer to the text passages? pdf line numbers, page and paragraph...?

DoDi

This is what I had in mind.

Using Unix/Baseunix, yes, this would be fine.
Note that not all attributes can be set.

Michael.

Best is section name and then count paragraphs, or the phrase the paragraph starts with (It's in LyX and rendered output and format in LyX don't correspond in pg nr etc)

But pretty much anything is ok, the document is not that big.

DrDiettrich wrote

> The FPC baseunix/unix units mimic more or less the POSIX standard As already mentioned, I couldn't find these units :-(

They only exist for unix-like OS'es. They are not generic units which you can use to port software from *nix to Dos/Windows (although in theory they should compile on Windows with a POSIX-compliant libc installed, if some small include files with type definitions are made).

Jonas

Why? There are cvs clients for pretty much any OS out there. Or does your working OS not have a network connection?

Good IDE's have cvs syncing integrated ;)

Jonas

Jonas Maebe wrote

Why? There are cvs clients for pretty much any OS out there. Or does your working OS not have a network connection?

I have a network connection, that I use rarely when I need to access some device built into my old computer. Everything else goes over the phone line.

But perhaps I missed some important features of the local CVS client?

Good IDE's have cvs syncing integrated ;)

Lazarus?

DoDi

In a port from C to Pascal it's required to implement the OS specific procedures for all targets, as far as possible. This requires knowledge of the available target specific procedures, that can be used on the various platforms. In most cases the C code is written for Unix/POSIX, so that only a connection to e.g. Windows must be implemented, somehow. In other cases, like Abbrevia, the Unix connection must be implemented, and that's when I need detailed information about the available FPC libraries, even if I'm working on Windows.

In my discussion with Linux people, about the distribution of FSF/GNU/open source... code, I had an idea for a more practical system for writing and distributing portable code. My ideas were not understood by the C people, perhaps I'll find a less biased audience here?

Most readers will know the procedures used to install portable C code on e.g. Linux, from a *.src.tar.gz or like that. The most critical step is ./configure, where the package tries to find out all required information about the host and target system. IMO it's not a good idea to leave it to every single package to implement these tests. In the case of C code it would be much simpler to support an set of common header files, containing all ported data types and procedure prototypes. These header files map the portable functions to the functions available on the actual target, provide defines for the available functionality (memory mapped files just come into mind). These header files can be distinct from the header files of the platform and compiler, they only have to provide the appropriate mapping to the available procedures. The difference from the actual automake... procedure is the simplified maintenance of these header files, required exactly once for every target OS. Then not much is left what configure or the author can or should makefiles can use platform specific macros for e.g. producing shared libraries, making libtool superfluous.

The only decisions, left to the author of portable software, are about the workarounds when a feature, like MM files, is not available on a platform. In the simple case a Make will fail with unresolved external symbols, in the more elaborated case the code will check for the availability of a feature, and use standard procedures on less comfortably equipped platforms instead.

Even if the exact procedures are somewhat different for C and Pascal, e.g. the standard header files correspond to Pascal units, the idea IMO already is part of FPC. What remains to do is the creation and maintenance of further portable units, in addition to (or extending) the already existing portable System, Classes, SysUtils etc. units.

Wouldn't it be great to demonstrate to the C world how easy it can be to write portable software, based on the FPC philosophy? Not that I want to convince anybody to use Pascal instead of C, but I dream of open source code that compiles and runs on every (supported) platform, without autobloat and all that can of worms :-)

I even would accept that Windows is not an official supported platform, because then I would maintain the portable units for that target myself. That wouldn't be really hard to do, it only were required to check the changes to the portable header files or units (interface sections), and to implement the new or changed funcionality as appropriate for Windows. Nothing more would be required, to turn Windows or any other best-hated <g> OS into a supported platform for really portable code ;-)

DoDi

On Thu, 06 Jan 2005 22:29:45 +0100, DrDiettrich wrote

I'm not sure what exactly you mean. If you mean that you can't get beyond the installer successfuly (i.e. no installation proceeds), then it probably isn't that important which platforms it can compile for anyway. <g> If FPC gets installed at all (even if you just unpack base*.zip), the help pages which I meant are displayed by fpc.exe (or ppc*.exe) when started without any parameters (from command line).

Tomas