Hello,

I was porting to Linux some Windows code which uses critical sections API, and got 'Identifier not found' error on InitializeCriticalSection and DeleteCriticalSection symbols. After searching through RTL code, I discovered that abovementioned functions are named InitCriticalSection and DoneCriticalSection. At the same time, the EnterCriticalSection and LeaveCriticalSection are not renamed, so code using them compiles without errors. Why this inconsistency? Should I supply a patch that adds Initialize/DeleteCriticalSection as aliases for Init/DoneCriticalSection?

Regards,
Sergei

Sergei Gorelkin wrote

I was porting to Linux some Windows code which uses critical sections API, and got 'Identifier not found' error on InitializeCriticalSection and DeleteCriticalSection symbols.

If I had to guess, I'd say this is probably because those identifiers come from the Windows unit.

Because one is the RTL abstraction on the different OSes, the other one is the direct Windows-API-Call.

Should I supply a patch that adds Initialize/DeleteCriticalSection as aliases for Init/DoneCriticalSection?

No, I'd suggest to fix your code.

Regards,

Vinzent.

VH> Because one is the RTL abstraction on the different OSes, the other one VH> is the direct Windows-API-Call.

But EnterCriticalSection/LeaveCriticalSection also exist in Windows API. And they are implemented in System unit without changing names. Therefore, to make my code cross-platform, I have only to remove Windows from uses clause - then cross-platform versions from System unit will be used. This is fine.

Contrary, InitlalizeCriticalSection and DeleteCriticalSection are renamed. This makes me wonder. All four functions belong to a single logical group and are being affected by whatever cross-platform issues in the same way. One would expect that either all four
are renamed, or all four left with original names - this is the reason for my question.

Sergei Gorelkin wrote

But EnterCriticalSection/LeaveCriticalSection also exist in Windows API. And they are implemented in System unit without changing names. Therefore, to

They shouldn't be exposed publicly in the system unit.

Micha

No. If you want to be cross-platform just do not use the "Windows" unit at all. Rather only use the functionality provided by the system unit, regardless of the compilation target.

The "Windows" unit should generally only included if you write platform specific code and such code should be separated in its own include file or even unit anyway.

Vinzent.

Why's that? At least it's documented that way. And I don't see any harm in doing so.

Vinzent.

Wednesday, April 04, 2007, 5:13:43 PM, Vinzent wrote:

VH> No. If you want to be cross-platform just do not use the "Windows" unit VH> at all. Rather only use the functionality provided by the system unit, VH> regardless of the compilation target.

VH> The "Windows" unit should generally only included if you write platform VH> specific code and such code should be separated in its own include file VH> or even unit anyway.

That is exactly what I'm speaking about. Removing 'Windows' from uses clause is essentially stopping using it :) And if the code continues to compile and work after that, it is just fine.

The code I was compiling was already cross-platform (Delphi/Kylix), and 'uses Windows' was wrapped by {$IFDEF MSWINDOWS}. In Kylix, InitializeCriticalSection and DeleteCriticalSection are implemented in SysUtils unit, so any code using these functions continue to work under Linux. It was surprise for me that this code could not compile with FPC.

En/na Sergei Gorelkin ha escrit:

Any reason why not to use syncobjs? (I'm just curious, since that's the unit I used when I needed critical sections).

Bye

Sergei Gorelkin wrote

That is exactly what I'm speaking about. Removing 'Windows' from uses clause is essentially stopping using it :) And if the code continues to compile and work after that, it is just fine.

Sorry, I always forget that most people are not like me and just use subroutine names without caring where they come from, while I'm used to always prefix the unit names to the subroutines and thus simply removing "Windows" from the use clause would not work, because the routines suddenly come from a different place.

Well, my opinion and my experience say you should know which routines you are actually using. I know that since the days I used DisposeStr and the FPC compiled code horribly crashed, because it was the wrong one.

I won't judge if FPC is correct here (it's supposed to be Delphi-, not Kylix-compatible), but if Borland decided to move those routines, they didn't do it right neither. ;)

Well, I'd still suggest to either stick to "System.InitCriticalSection" etc. regardless if the Windows unit is included or not (yes, this actually *requires* you to prefix it), or just use the SyncObjs unit like everyone else out there.

Vinzent.

I reimplemented whole threading- and sync code in fpc RTL, including Threadvars. My patch is very very big and need to be discussed in core first. But all your problems will be solved.

I hope I can start the discussion on core soon, but I know it will be endless. The user side of the RTL will 99% compatible to the old version, but there's a complete reimplementation required for the platfrom dependant code.

Just stay on...

-Ivo Steinmann

Thursday, April 05, 2007, 11:45:34 AM, Vinzent wrote:

VH> Sorry, I always forget that most people are not like me and just use VH> subroutine names without caring where they come from, while I'm used to VH> always prefix the unit names to the subroutines and thus simply VH> removing "Windows" from the use clause would not work, because the VH> routines suddenly come from a different place.

VH> Well, my opinion and my experience say you should know which routines VH> you are actually using. I know that since the days I used DisposeStr VH> and the FPC compiled code horribly crashed, because it was the wrong VH> one.

It appears that my way of thinking has been severely affected by using IDEs. When putting mouse over identifier shows where it comes from, prefixing seems redundant :)

VH> I won't judge if FPC is correct here (it's supposed to be Delphi-, not VH> Kylix-compatible), but if Borland decided to move those routines, they VH> didn't do it right neither. ;)

They did not move routines - they just had to implement Linux versions somehow. And they did it in a way that was not breaking existing code.

VH> Well, I'd still suggest to either stick to "System.InitCriticalSection" VH> etc. regardless if the Windows unit is included or not (yes, this VH> actually *requires* you to prefix it), or just use the SyncObjs unit VH> like everyone else out there.

In this particular case I wanted to avoid FCL dependence via using SyncObjs.
Ok, for now I have it fixed. Since Ivo has a large patch pending, I shall stay on...

Sergei Gorelkin wrote

It appears that my way of thinking has been severely affected by using IDEs. When putting mouse over identifier shows where it comes from, prefixing seems redundant :)

Prefixing *is* redundant, that's the whole point of it, but it also takes you to the safe side. I never liked Pascal's solution of calling subroutines with the same name depending on the order of the use clauses, when those use clauses are so far away from the actual code. Change the clause, you (may) change the code.
Not mentioning this awful "reuse" clause here, that's the worst. But I'm getting carried away... stop.

Well, so doing the mouseover to look at where it's from already has a bad taste of suspecting some surprise.

And well, an IDE can't help you on the printout. Clicking on the headlines in a newspaper doesn't take you to the article, neither. ;)

So they should have implemented the "Windows" unit, simple as that. Or add a "Linux" unit as replacement.

In this particular case I wanted to avoid FCL dependence via using SyncObjs.

Fair enough. It's a reason after all.

Vinzent.