DLL Compiling Question [FPC] 
Author Message
 DLL Compiling Question [FPC]


Quote:


> >Borland is notorious for ignoring standards.

> ISO committees and followers  are notorious for ignoring Borland, and its
> quite large crowd of followers :-)

ISO was there before Borland.  The standards committee drafts were
loooong before.  ISO is self-consistent.  All Borland had to do
was meet the standards - they were still free to add their own
extensions.  There are and were test suites to check compliance -
I was using them in 1980 or earlier.

Borland has done serious harm to the easiest language to use and
learn.  And Pascal is still intrinsically the most portable
language, although it hasn't been ported everywhere.  It can run
on machines which the ISO C standard forbids using for C.

I have also cross-posted this reply.

--

http://www.*-*-*.com/
   (Remove "NOSPAM." from reply address. my-deja works unmodified)



Mon, 07 Jul 2003 18:29:22 GMT  
 DLL Compiling Question [FPC]

Quote:

> > >Borland is notorious for ignoring standards.

> > ISO committees and followers  are notorious for ignoring Borland, and its
> > quite large crowd of followers :-)

> Hear Hear!

Also added to cross-posting.

I use Turbo, but with restraint.  The basic problem is entirely
different semantics, and Turbos are not self-consistent and
general.  They omit fundamentals.

You can find an example of adapting Turbo to real standards on my
web-page below.  The result is quite portable code.  Using that
TXTFILES unit I ported a complete ISO compliant Pascal compiler to
Turbo in about 2 days a few years ago.  Without it I would have
given up.

--

http://www.qwikpages.com/backstreets/cbfalconer
   (Remove "NOSPAM." from reply address. my-deja works unmodified)



Mon, 07 Jul 2003 18:29:23 GMT  
 DLL Compiling Question [FPC]

Quote:

> > I see no cross posting here!

> I also posted in c.l.p.misc. ;)

No, you must have multi-posted, which is not the same thing.  A
cross post produces only one message which appears on multiple
groups, and answers do likewise.  I have added
comp.lang.pascal.misc to this message (which I don't read) so
further things in this particular chain will appear on both
groups.

Quote:

> > By definition, Pascal is case insensitive.  Thus I would conclude
> > that FPC has it right, and the others are wrong.  The cure is
> > simple - from a case sensitive language call the routines with
> > upper case names.

> Unfortunately, you are partly correct and partly incorrect.

> Straight-Pascal is Case insensitive. If you were to write a program in TP,
> T.Vision, PasComp, or just about any other compiler the language itself is
> not case sensitive. Neither is Delphi's coding style.

> What is case sensitive is Win32 Dlls. It is known that they are case
> sensitive and, when you use C/Delphi/C++/Ada/Lisp/etc. if you type 1
> character uppercase which should be lowercase, you are unable to use the DLL
> function. (The mysterious "A device attached to the system is not
> functioning" message)

> > I believe that under Win32 you can also call DLL routines by index
> > numbers.

> Yes, but that does not help when you dynamically arrange functions. To use
> Dynamic linking (as opposed to static linking using the External directive)
> you have to get the procedure's address (using the GetProcAddress WinAPI
> function) using the Procedure's name. Case does matter. Unfortunately, I
> wish we could, but we can't use index ordinals for dynamic functions. :(

> > Borland is notorious for ignoring standards.

> Actually, FPC in this case is wrong and, as Marco said in the post over in
> c.l.p.misc, they have already fixed this for the next version.

I disagree.  Making the linker name follow original case means you
have no idea what appears in the linker, so the Pascal source can
be modified to change some name character cases, and suddenly
everything crashes and burns even though the coding is absolutely
correct.

PROBRAM bar(output)

    PROCEDURE foo;
       BEGIN writeln('foo'); END;

    BEGIN
    FOO;   Foo;  fOO;
    END.

is absolutely legal Pascal.

What is wrong with simply making all your DLL procedures upper
case? C can handle that, as can any case sensitive system.

--

http://www.qwikpages.com/backstreets/cbfalconer
   (Remove "NOSPAM." from reply address. my-deja works unmodified)



Mon, 07 Jul 2003 18:29:20 GMT  
 DLL Compiling Question [FPC]

Quote:


>> >Borland is notorious for ignoring standards.

>> ISO committees and followers  are notorious for ignoring Borland, and its
>> quite large crowd of followers :-)

>ISO was there before Borland.

Probably yes. So?

Quote:
> The standards committee drafts were loooong before.

Nice. But Drafs are only drafts.

Quote:
> ISO is self-consistent.  All Borland had to do was meet the standards -
>they were still free to add their own extensions.

That is actually the point. They didn't have to do anything, and if I heard
it correctly, ISO was quite unresponsive, and nearly dormant at the time.

Quote:
>Borland has done serious harm to the easiest language to use and
>learn.

In your view. IMHO it saved it.

Quote:
> And Pascal is still intrinsically the most portable language, although it
>hasn't been ported everywhere.  It can run on machines which the ISO C
>standard forbids using for C.

I don't want portability at any price, I want to be able to create
applications without much limitations on the one hand, but reasonable
safety, performance and ease on the other.

And personally I think this difference also cause the break from Borland
with the standards.



Mon, 07 Jul 2003 21:17:56 GMT  
 DLL Compiling Question [FPC]

Quote:
> I disagree.  Making the linker name follow original case means you
> have no idea what appears in the linker, so the Pascal source can
> be modified to change some name character cases, and suddenly
> everything crashes and burns even though the coding is absolutely
> correct.

We are talking about Name-Mangling, not the inherent code possibilities.

Quote:
> PROBRAM bar(output)

>     PROCEDURE foo;
>        BEGIN writeln('foo'); END;

>     BEGIN
>     FOO;   Foo;  fOO;
>     END.

> is absolutely legal Pascal.

Of course it is. That is the way Pascal was designed.
The problem is, the name mangling should not be the way it is. In the dll,
the procedures SHOULD BE case sensitive. That's the way EVERY Win32 DLL does
it (because Win32 is CASE SENSITIVE to dll procedures) and that's the way
FPC Should output it.

The point really is moot seeing as in the 1.0.5 version, FPC fixes it (and
it works quite nicely)

Quote:
> What is wrong with simply making all your DLL procedures upper
> case? C can handle that, as can any case sensitive system.

Aesthetics. :) And I hate holding the SHIFT key to type in procedure names
in all the other languages, not to mention the fact that it is poor coding
style and my customers will hate me.

-Luke



Mon, 07 Jul 2003 23:40:58 GMT  
 DLL Compiling Question [FPC]

Quote:



>> >Borland is notorious for ignoring standards.

>> ISO committees and followers  are notorious for ignoring Borland, and its
>> quite large crowd of followers :-)

>ISO was there before Borland.  

Probably, yes, but I don't see what that has to do with it.

Quote:
>The standards committee drafts were
>loooong before.  ISO is self-consistent.  All Borland had to do
>was meet the standards - they were still free to add their own
>extensions.  

Borland had to do nothing :-)

Quote:
>There are and were test suites to check compliance -
>I was using them in 1980 or earlier.

Probably yes.

Quote:
>Borland has done serious harm to the easiest language to use and
>learn.  And Pascal is still intrinsically the most portable
>language, although it hasn't been ported everywhere.  It can run
>on machines which the ISO C standard forbids using for C.

Now we are getting to the point. Borland wasn't interested in portability
(and specially to really large amounts of platforms), but in creating
efficient applications. And so am I.

Portability is interesting, but no "sacrifice everything" Holy Grail for me.



Tue, 08 Jul 2003 02:26:13 GMT  
 DLL Compiling Question [FPC]

Quote:

> The point really is moot seeing as in the 1.0.5 version, FPC fixes it (and
> it works quite nicely)

> > What is wrong with simply making all your DLL procedures upper
> > case? C can handle that, as can any case sensitive system.

> Aesthetics. :) And I hate holding the SHIFT key to type in procedure names
> in all the other languages, not to mention the fact that it is poor coding
> style and my customers will hate me.

Then I suggest writing the C code as follows:

#define foo FOO
....
    foo(whatever);

and put the #define in the appropriate .h prototype file for foo.

I don't agree that case conversion is name-mangling.  I restrict
the mangling concept to adding a description of parameters.
Unfortunately rules for this vary.  For case insensitive languages
uppercasing is a perfectly reasonable way of ensuring that the
other systems know just how to reference things and is
traditional.

--

http://www.qwikpages.com/backstreets/cbfalconer
   (Remove "NOSPAM." from reply address. my-deja works unmodified)



Tue, 08 Jul 2003 03:37:48 GMT  
 DLL Compiling Question [FPC]

Quote:


>> The point really is moot seeing as in the 1.0.5 version, FPC fixes it (and

>and put the #define in the appropriate .h prototype file for foo.

>I don't agree that case conversion is name-mangling.  I restrict
>the mangling concept to adding a description of parameters.

And  Foo(Iso: Integer); and another Foo(Iso:integer) in a different unit
then?

And in case of .DLL's or shared libraries, or linking to foreign languages
 (where mangling is dictated by the target?)



Tue, 08 Jul 2003 04:13:56 GMT  
 DLL Compiling Question [FPC]

Quote:
> > The point really is moot seeing as in the 1.0.5 version, FPC fixes it
(and

> I don't agree that case conversion is name-mangling.

I have to ask, have you ever programmed on the Win32 platform? If so, have
you ever used a dll?
If so, try this. Try setting an external reference (which you know is
correct) and change the case of 1 (One) letter in your external reference

Quote:
> > The point really is moot seeing as in the 1.0.5 version, FPC fixes it

(and

procedure Foo(Num :Integer); external 'Bob.dll'
changes to
procedure foo(Num :Integer); external 'Bob.dll'

Just a single letter changed with the procedure declaration. Now it will not
work anymore and you will get a "Not Functioning" error.
Case Matters! the Win32 filesystem may not care about case, but procedures
(and functions) inside of DLLs are CASE SENSITIVE!! Like it or not..
Besides:

Quote:
> > The point really is moot seeing as in the 1.0.5 version, FPC fixes it

(and

Quote:
> Unfortunately rules for this vary.  For case insensitive languages
> uppercasing is a perfectly reasonable way of ensuring that the
> other systems know just how to reference things and is
> traditional.

It is not reasonable, and nowhere near traditional. Exactly where is the
tradition of uppercasing procedure names?

Have you ever looked at the Win32 DLLs with QuickView? (or TDump, or
whatever you use to view the structure).

Notice that every single procedure has different casing. If you try to link
incorrectly to those procedures (some of which were written a LOOOOOONG time
ago in C) it will not work if you have different casing.

Whether you agree or not, it is of no consequence to debate on this. Simply
stated, Win32 Needs Case Sensitivity. The Programmer is in control of Case.
And at any rate:

Quote:
> > The point really is moot seeing as in the 1.0.5 version, FPC fixes

it!!!!

That's the end of it. I had a problem. FPC's creators acknowledged the
problem. They fixed it.

Now, if you wish to continue debating with fruitless arguments, I would like
you to show me 2 compilers (aside from FPC) which Capitalise their
procedures when writing dlls. This will reinforce the fact that there is a
"tradition" and "perfectly acceptable" way to keep/lose case-sensitivity in
DLLs.

-Luke Croteau



Tue, 08 Jul 2003 05:35:31 GMT  
 DLL Compiling Question [FPC]

Quote:

> > > The point really is moot seeing as in the 1.0.5 version, FPC fixes it
> (and

> > I don't agree that case conversion is name-mangling.

> I have to ask, have you ever programmed on the Win32 platform? If so, have
> you ever used a dll?
> If so, try this. Try setting an external reference (which you know is
> correct) and change the case of 1 (One) letter in your external reference

> > > The point really is moot seeing as in the 1.0.5 version, FPC fixes it
> (and

> procedure Foo(Num :Integer); external 'Bob.dll'
> changes to
> procedure foo(Num :Integer); external 'Bob.dll'

> Just a single letter changed with the procedure declaration. Now it will not
> work anymore and you will get a "Not Functioning" error.
> Case Matters! the Win32 filesystem may not care about case, but procedures
> (and functions) inside of DLLs are CASE SENSITIVE!! Like it or not..
> Besides:
> > > The point really is moot seeing as in the 1.0.5 version, FPC fixes it
> (and

> > Unfortunately rules for this vary.  For case insensitive languages
> > uppercasing is a perfectly reasonable way of ensuring that the
> > other systems know just how to reference things and is
> > traditional.

> It is not reasonable, and nowhere near traditional. Exactly where is the
> tradition of uppercasing procedure names?

> Have you ever looked at the Win32 DLLs with QuickView? (or TDump, or
> whatever you use to view the structure).

> Notice that every single procedure has different casing. If you try to link
> incorrectly to those procedures (some of which were written a LOOOOOONG time
> ago in C) it will not work if you have different casing.

> Whether you agree or not, it is of no consequence to debate on this. Simply
> stated, Win32 Needs Case Sensitivity. The Programmer is in control of Case.
> And at any rate:
> > > The point really is moot seeing as in the 1.0.5 version, FPC fixes
> it!!!!

> That's the end of it. I had a problem. FPC's creators acknowledged the
> problem. They fixed it.

> Now, if you wish to continue debating with fruitless arguments, I would like
> you to show me 2 compilers (aside from FPC) which Capitalise their
> procedures when writing dlls. This will reinforce the fact that there is a
> "tradition" and "perfectly acceptable" way to keep/lose case-sensitivity in
> DLLs.

My point is that if you allow all this, it will bite later.  You
have code written as:

   PROCEDURE foobar;

and it all works.  Later on someone decides it looks more readable
as "FooBar". He has no reason to modify anything else (he knows
Pascal), so he compiles it.  No errors, but at some point,
probably run-time for Valued Customer Who Must Not Be Annoyed,
everything blows up.  Then it may take a long time to fix, after
all other changes were made,all of which are now suspect.  System
error messages are not renowned for their clarity.

Why do you want to let youself in for this, when simply
uppercasing the C, and possibly controlling it with a #define,
will prevent such problems forever?   Control case in case
sensitve modules seems simple to me.

Of course you can ignore my advice.  But I have been doing these
things for a long time, and it pays to do them right if you can
think of the right way.

Pascal linkages are in uc because there were, and are, machines,
printers, etc. that don't have lc. Maybe you don't care, but
others do, and locking them out smacks of evil discrimination to
me.

BTW, if you have legacy DLLs not under your control, you can
easily write a set of C thunks to pass control.  If nothing else
they draw the attention of future maintainers to the case problem,
as do the #defines in your owc C source.

Traditions are more often worthwhile than not.  I believe you are
French.  Would you look kindly on replacing La Marseillese with
Hinky Dinky Parlez Vous?  Champagne with NewYorkStateBubbly?
Ignoring Napoleons contribution to laws?  Referring to Voltaire,
Verne, Bizet, Debussy as hacks.  That fanatic Pascal?  That dauber
deGas.  I'll skip deGaulle, that might be super sensitive.  I
don't think you would approve of all this.

Similarly I disapprove of bastardizing the output of FPC when
clean workarounds exist.

--

http://www.qwikpages.com/backstreets/cbfalconer
   (Remove "NOSPAM." from reply address. my-deja works unmodified)



Wed, 09 Jul 2003 07:18:33 GMT  
 DLL Compiling Question [FPC]

Quote:


>> It is not reasonable, and nowhere near traditional. Exactly where is the
>> tradition of uppercasing procedure names?

Basic? :-)

Quote:

>> Now, if you wish to continue debating with fruitless arguments, I would like
>> you to show me 2 compilers (aside from FPC) which Capitalise their
>> procedures when writing dlls. This will reinforce the fact that there is a
>> "tradition" and "perfectly acceptable" way to keep/lose case-sensitivity in
>> DLLs.

>My point is that if you allow all this, it will bite later.  You
>have code written as:

>   PROCEDURE foobar;

>and it all works.  Later on someone decides it looks more readable
>as "FooBar". He has no reason to modify anything else (he knows
>Pascal), so he compiles it.

Yup, no problem.;

Quote:
> No errors, but at some point,
>probably run-time for Valued Customer Who Must Not Be Annoyed,
>everything blows up.

No, because it won't compile. And if it has to do with namemangling(so the
dll case, this won't save you either, since there is no direct relation
between case in the source and in the DLL.

Quote:
>Then it may take a long time to fix, after
>all other changes were made,all of which are now suspect.  System
>error messages are not renowned for their clarity.

In this specific case (and all others are not comparable), there are a
zillion tools that list the exports of DLLs, and can detect the error.

Quote:
>Why do you want to let youself in for this, when simply
>uppercasing the C, and possibly controlling it with a #define,
>will prevent such problems forever?   Control case in case
>sensitve modules seems simple to me.

There is no C code related to this, and even if it was so, you would need
Windows source code for this. This is an ABI specification. (language
independant interface)

Quote:
>Of course you can ignore my advice.  But I have been doing these
>things for a long time, and it pays to do them right if you can
>think of the right way.

To be honest, I'm not impressed this time. You don't even seem to understand
what this was about.

Quote:
>Pascal linkages are in uc because there were, and are, machines,
>printers, etc. that don't have lc. Maybe you don't care, but
>others do, and locking them out smacks of evil discrimination to
>me.

No. Why would I work with unreadable sources, while the chance of
encountering such system is nearly zero.

Quote:
>BTW, if you have legacy DLLs not under your control, you can
>easily write a set of C thunks to pass control.  If nothing else
>they draw the attention of future maintainers to the case problem,
>as do the #defines in your owc C source.

*ALL* dll's have this. It is part of the specification of DLLs.

Quote:
>Similarly I disapprove of bastardizing the output of FPC when
>clean workarounds exist.

There is no workaround.


Wed, 09 Jul 2003 18:59:51 GMT  
 DLL Compiling Question [FPC]

Quote:
> > Now, if you wish to continue debating with fruitless arguments, I would
like
> > you to show me 2 compilers (aside from FPC) which Capitalise their
> > procedures when writing dlls. This will reinforce the fact that there is
a
> > "tradition" and "perfectly acceptable" way to keep/lose case-sensitivity
in
> > DLLs.

> My point is that if you allow all this, it will bite later.  You
> have code written as:

My point is this.
Win32 is Case Sensitive when it comes to DLL procedure names!

Try it yourself! Compile something with Case-Sensitive compilers and try to
change the case of the DLL. It will not work. I can provide you with
examples in a few different languages.

On the other hand, again you mention

Quote:
> Traditions are more often worthwhile than not.

But you have not shown me compilers where this is tradition!
I have been programming for 9 years. Granted, that is not a long time by
computer standards, it is long enough to have gone through quite a few
operating systems. In all of the systems which used DLLs (Or
Modules/Standard librarys in the case of the *NIXs), ALL of them are case
sensitive, including Win2.0, Win3.0, Win3.1, Win3.11, NT (All flavors),
Win95, Win98, Win2k, Whistler, Linux (only not-tested kernel is Slackware),
Unix, FreeBSD.

I'm not saying it to impress you. I'm saying it to show, the tradition in
99.99999 of operating systems is that the Modules/Libraries MUST BE CASE
SENSITIVE!

On the whole, your point is invalid. It will not bite me later. It is biting
me right now. Windows was built with the filesystem to be case-insensitive,
but the DLLs are case sensitive. I now have to contend with that.

End of story.

Quote:
> Of course you can ignore my advice.  But I have been doing these
> things for a long time, and it pays to do them right if you can
> think of the right way.

I will ignore your advice simply because it is incorrect. When the
"tradition" of operating systems and Case Sensitivity exist, there is no
reason I need to work around a problem which isn't a problem. (How's that
for spaghetti logic.)

Quote:
> I believe you are French.

Actually, I'm American with Canadian ancestors. Close enough though.

Quote:
> Would you look kindly on replacing La Marseillese with
> Hinky Dinky Parlez Vous?  Champagne with NewYorkStateBubbly?
> Ignoring Napoleons contribution to laws?  Referring to Voltaire,
> Verne, Bizet, Debussy as hacks.  That fanatic Pascal?  That dauber
> deGas.  I'll skip deGaulle, that might be super sensitive.  I
> don't think you would approve of all this.

> Similarly I disapprove of bastardizing the output of FPC when
> clean workarounds exist.

As a case in point, the examples you have provided have no relation, even
metaphorical, to the discussion at hand. The discussion is about
case-sensitivity within DLLs cooperating between multiple compilers and
operating systems. The discussion is not about simple naming and convention
problems.

And, we are not bastardizing the output of FPC. We are making it compatible
with the operating systems with which it must run.

I suggest before you launch another diatribe against us, you find {*filter*}
proof of these "traditions" which you believe exist, and how the many
compilers in the world are wrong.

-Luke Croteau



Thu, 10 Jul 2003 02:11:18 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. DLL Compiling Question [FPC}

2. compile to .dll ?

3. I need to compile a 16 bit dll

4. DLL ACCESS WORKS IN IDE NOT COMPILED

5. Can I use FPC to compile and debug windows dlls?

6. FPC - linux question

7. Question about FPC under linux

8. fpc question

9. fpc question

10. FPC charset (linux) question

11. FPC: ^longint type, curious question

12. FPC (linux) question

 

 
Powered by phpBB® Forum Software