Maybe, this way could be productive:
1) implement FAR16 calling conventions support;
2) translate OS2 API header to units;
3) genreate win32 PE executables/DLLs using ldw;
4) convert PE to LX using PE2LX from Odin

Sorry if my message is false (now I have only patched compiler 1.1 based on yesterday's). But it seems to have a new bug. It's not able to compile this sample:

type
 t1=procedure;pascal;
begin
end.

If I use {$calling pascal} without pascal keyword after "procedure" I reproduce the same problem.
If I replace pascal to stdcall or cdecl, all is OK. If I use pascal keyword not in type definition but immediately in function header, all is also OK. Check please...

Date sent: Wed, 27 Mar 2002 14:54:12 +0000
From: "Pavel V. Ozerski"
Organization: IEPhB RAS
To:
Subject: [fpc-devel]An idea how to unbind OS/2 port from EMX

Maybe, this way could be productive: 1) implement FAR16 calling conventions support;

This would be definitely nice (and useful), but it isn't absolutely necessary (we can still use one of the available DLL wrappers, and be independent of EMX). The main problem for me is I won't probably be able to implement this (I have some information about this topic, but calling conventions aren't quite my domain, ;-) and embedding it into the compiler would need deeper understanding of compiler internals on my side :-( ). However, if you'd be able to add it, be my guest - I'm willing to help you any possible way.

2) translate OS2 API header to units;

The OS/2 API is very extensive, of course, but the most important parts needed for us are already available (see units OS2Def, DosCalls, KbdCalls, VioCalls, MouCalls, MonCalls, PMWin, PMGPI and DIVE). The PM units aren't as good as the text ones probably (regarding compatibility with other compilers, etc.). Among more important parts, which are still missing, there's definitely the interface for TCP/IP. Another thing is replacing all EMX calls throughout the current RTL with the native API calls. This is needs some work, of course. :-(

3) genreate win32 PE executables/DLLs using ldw; 4) convert PE to LX using PE2LX from Odin

It's definitely an interesting idea. I see some possible problems here, however:
1) I'm not sure, whether the created binaries wouldn't need ODIN DLLs for some helpers (read: "they would most probably, IMHO").
2) We'd probably loose any debugging possibility this way. I can imagine we might introduce support for a different format of debug information to use some other debugger instead of GDB in the future, but I doubt PE2LX could ever transform GNU debugging information into something useable.
3) I don't know, whether text mode applications would still work correctly - all Win32 applications run in graphic mode under Odin (a special GUI window emulating the console is opened for text tools).

Given all of this, it might still be better to try to implement our own linker in the future, and use something like NASM / LINK386 combination in between.

Tomas

Hello Pavel,

Wednesday, March 27, 2002, 6:53:51 PM, you wrote:

PVO> Sorry if my message is false (now I have only patched compiler 1.1 PVO> based on yesterday's). But it seems to have a new bug. PVO> It's not able to compile this sample:

PVO> type
PVO> t1=procedure;pascal;
PVO> begin
PVO> end.

PVO> If I use {$calling pascal} without pascal keyword after "procedure" I PVO> reproduce the same problem.
PVO> If I replace pascal to stdcall or cdecl, all is OK. PVO> If I use pascal keyword not in type definition but immediately in PVO> function header, all is also OK. Check please...

The problem seems to be fixed!
Solution:
unit pdecsub.pas, procedure handle_calling_convention, inside large CASE operator:

case def.proccalloption of
.....
          pocall_pascal :
            begin
              include(def.procoptions,po_leftright);
              st:=tparasymtable.create;
              parast:=tprocdef(def).parast;
              lastps:=nil;
              if parastnil then //<<<<<<<<<<<<<<<<<<<
              while assigned(parast.symindex.first) and (lastpstsym(parast.symindex.first)) do

PVO> The problem seems to be fixed!
PVO> Solution:
PVO> unit pdecsub.pas, procedure handle_calling_convention, inside large PVO> CASE operator:

PVO> case def.proccalloption of
PVO> ....
PVO>           pocall_pascal :
PVO>             begin
PVO>               include(def.procoptions,po_leftright);
PVO>               st:=tparasymtable.create;
PVO>               parast:=tprocdef(def).parast;
PVO>               lastps:=nil;
PVO>               if parastnil then //<<<<<<<<<<<<<<<<<<<
PVO>               while assigned(parast.symindex.first) and (lastpstsym(parast.symindex.first)) do

Unfortunatelly, that was only partial solution: at compiling of bigger programs this bug occured sometimes again. The situation seems to be more complex. I think, temporary replacing of actprocsym whith new-created object causes generation of AktProcDef.parast with random value which can be also not nil but be pointing to random address. I could to fix this circumstance also:
unit pdecsub.pas, end of procedure parse_var_proc_directives:

        inc(lexlevel);
        AktProcDef.parast:=nil;//<<<<<<<<<<<<<<<<<<<<<<<
        parse_proc_directives(pdflags);
        dec(lexlevel);
        aktprocsym.free;
        aktprocsym:=oldsym;
        aktprocdef:=olddef;
      end;

This change seems to be a solution of this problem but I'm not sure that it is always not wrong and cannot cause lose of data (although compiler seems to worki correctly now).

Please be patient.

Most of us have daytime jobs as well, so we cannot always immediatly apply bug fixes.

If you send a diff, then I will apply the patch as soon as I have it.

Michael.

Hello FPC Team,
Yesterday I found a bug, reported about it, made two-step bugfix (maybe, preliminary but effective) - and all is ignored?!!! Why, this bug is real not only in my WDOSX-supporting patch but also in today's 1.1 compiler!

This one is correct. I applied it. You can check it out from CVS.

Michael.

Hello Michael,

Friday, March 29, 2002, 9:05:30 AM, you wrote:

MVC> If you send a diff, then I will apply the patch as soon as I have it.

Unfortunatelly, I never used GNU diff utility, therefore this will be my first attempt...
Original file named pdecsub.pas, after patches (temporarely, for comparing only) named pdecsub.new.

command:

diff -a pdecsub.pas pdecsub.new
output:

1622a1623

if parastnil then

1757a1759

AktProcDef.parast:=nil;

command:

diff -a pdecsub.new pdecsub.pas
output:

1623d1622
<               if parastnil then
1759d1757
<         AktProcDef.parast:=nil;

What of these 2 results is necessary to ADD 2 new lines, I don't know, sorry, but I hope that one of 2 must be correct.

Hello,
I would also remind a already known but not fixed bug: calling stdcall constructors causes Runtime error 216. If I did not forget something, cause of this problem was found. Now Ivan Shikhalev wrote me about a similar problem in interfaces. Please at least inform us where is located possible bug cause in compiler source, then we could try to fix it.

I'm sorry to say it, but the patch was not correct. You didn't test it using the 'make cycle' command in the compiler dir. This cycle is a check if the compiler can at least compile itself successful.

The problem with the patch is that aktprocdef is a tprocdef, but when parsing a procvar it is loaded with a tprocvardef. So you can only access fields of tabstractprocdef without checking. And parast is a field of tprocdef only so a check if deftype=procdef is required.

It is now fixed in CVS.

Please regard this message as a hint. We appreciate patches more than bug reports. Because thanks to your patch the real problem was found much quicker.

Peter

Now Ivan Shikhalev wrote me about a similar problem in interfaces. Please at least inform us where is located possible bug cause in compiler source, then we could try to fix it.

I want to add:

When we use a multiple interfaces in one class, a calling any interface functions
like QueryInterface, _AddRef and _Release generates an error "Access Violation".
This error is occured because the compiler write code, which do not initialize
the ESI register before it calls another methods, and push this register as Self.
Now I use own build of RTL with "asm end ['ESI'];" in beginning of QueryInterface,
_AddRef and _Release.

--------------------
Ivan Shikhalev

http://fpc.by.ru/
http://iws.by.ru/

Because that is not coded :)

Hello All,
A question about rules of name mangling in FPC. If we use CDECL or CPPDECL calling conventions, the compiler uses C or C++ rules of name mangling, and it's true because this solution simplifies using C/C++ libraries. But why STDCALL uses FPC internal name mangling style instead C standard (_<name>@<params_size_in_bytes>?

And what is this supposed to do ?

This is supported for classes and must be compiled with -S2 or -Sd.

Michael.

On Wed, 3 Apr 2002, Michael Van Canneyt wrote:

}> type
}> t1=object
}> procedure proc(var m);virtual $20;
}
}And what is this supposed to do ?

This is to be dynamic method, accessed via DMT instead of VMT. I personally think it's not worth of effort to support this but this is indeed incompatibility. Probably best way would be ignoring any constant after 'virtual' - it would work fine in most cases (although Object Windows really needs dynamic methods to be dynamic).

regards,
Ingmar Tulva

Hello,
I tried to compile some parts of Borlad's OW with FPC and found that FPC 1.1 does not support some TP syntax constructions. Example (has been compiled with BP7 (real-mode target) successfully):

type
 t1=object
  procedure proc(var m);virtual $20;
  constructor init;
 end;
var
 p1:t1;
procedure t1.proc(var m);
 begin
 end;
constructor t1.init;
 begin
 end;
var
 x:integer;
begin
 p1.init;
 p1.proc(x);
end.

FPC does not recognize used here analog of
procedure XXXX(var m); message YYY;
which is used also in OW:"Fatal: Syntax error, ";" expected but "ordinal const" found". Using -So compiler switch does not help.

> t1=object > procedure proc(var m);virtual $20; This is supported for classes and must be compiled with -S2 or -Sd.

It's true, but I wrote not about CLASSES but about old-style objects. Syntax is also different: 'virtual' instead 'message' is used. This feature missing does not allow to recompile OW without it's cardinal rewriting (classes instead objects!).

Pavel

If you really need it, I guess you can make a patch, Pavel :) !

I meant a compiler patch to support dynamic methods with virtual <ord. value>;

Yes, FPC doesn't distinguis between dynamic and virtual because the data segment isn't limited to 64kB.

virtual XXX; doesn't mean necessarily that the method uses the dynamic calling conventions! From the semantic point of view it means only that the method can be identified by a ordinal number. The dynamic calling convention isn't necessary to compile the OWL, it saves only space in data segment which was important in 16 Bit times.

Look at the following log entry in hcgdata.pas (at least 1.0.x branch)

Revision 1.24 2000/01/28 23:17:53 florian
* virtual XXXX; support for objects, only if -dWITHDMT is defined

I don't know if -dWITHDMT still works, but it's worth a try :)

Of course, you've to rewrite the dispatcher in the OWL, but this shouldn't be a problem.

Btw, is using of ONLY INTERFACE PARTS of OW units a disturbance of Borland's (C)?

At least not in Europe.

Hello Florian and all,
FK> If you really need it, I guess you can make a patch, Pavel :) ! Of cource, I can could solve my problem (rewriting Object Windows) without compiler patching but I think not only about my problems but also about compiler. Now I generated some asm-files hoping to find differences between internal realization of virtual and dynamic methods at least in new-style classes. At least now I see no differences and think that in FPC, unlike Delphi, 'dynamic' and 'virtual' methods in classes are the same. Therefore I don't understand how to implement indexes here without big modifications of methods handling (writing full support of dynamic metods like in Delphi). It's true?

Btw, is using of ONLY INTERFACE PARTS of OW units a disturbance of Borland's (C)?