_stdcall dlls

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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)







[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux