_stdcall dlls

[Peter Sylvester]

Hi youngsters and elders,

I would kike to share an experience:experiment.

Around 25 years ago, in the EU-IST project CHRONIC, a work item was a "secure" communication 
protocol for health monitoring to reduce hospitalization.

The client part demo was done in Visual Basic by a spanish partner. I proposed to add SSL uSing 
openssl.

To minimize the work on openssl  (0.9.6b), I decided to compile the stuff with the global stdcall 
switch. That went rather well:

- a bit of RTFM

- The MAIN applications in apps need an explicit _cdecl.  ==> ok, no big deal

- Some routines are in assembler, ==> -no-asm (too lazy)

- One quicksort was missing. ==> got the one from microsoft. Nice code avoiding recursion (and 
possible stack problems).

- The big tIme consuming part was a pentium II WNT 4.0 to compile. Hours :-)

There was another idea which I didn't follow:

there are already macros to declare external functions so that no DLL spec (compiled by an almost 
unreadable perl) is required. The perl was buggy at some point btw.

But these macros are/were not used. Maybe some one time perl could change the prototypes etc. since 
he existing perl to detect them exists.

This would avoid using a global compiler switch (a -Dxxx would be sufficient) -no-asm could avoided 
for internal functions ....

      Would others like such a version of the dlls?

      I know about 64 bits. So maybe there is no need anymore.

I could have sent this message as a suggestion to the github and I might do so. But since this list 
is for users, I think there could feedback from non-developers.

Good idea? Bad idea? Suggestions?

Best

Peter Sylvester --- otherwise happily retired (or almost)