David GravereauxDonal K. Fellows$Revision: 1.21 $

This TIP proposes a change to how the EXTERN macro in tcl.h works to support a wider range of compiler specific attributes.

With working on Borland support recently, I found that luckily the newest "free commandline tools" [] does support Microsoft's __declspec(dllexport) attribute. But at the same time, the older way with __export is still valid, but can't be used due to the order within the prototype declaration of the EXTERN macro. What's this with the MS compiler: CV9fZGVjbHNwZWMoZGxsZXhwb3J0KSBfX2NkZWNsIGludCBmdW5jIChpbnQgYSwgaW50IGIpOw== will have to be this with Borland: CWludCBfX2V4cG9ydCBfX2NkZWNsIGZ1bmMgKGludCBhLCBpbnQgYik7 The order of the attribute needs to be after the return type. Even though __declspec is supported in the Microsoft style with version 5.5+ of the Borland compiler, if EXTERN could swap around the order a hair, old Turbo C v5.0 has a better chance to make a DOS library. Should someone feel the need. Let's leave the existing EXTERN macro as-is and just make a new one called TCL_EXTERN to support the new behavior. Karl Lembuaer (sp?) did a presentation @ OSCON regarding his recent tinytcl project %TODO: add link here% about his DOS port of Tcl 6.7 for use in a hand-held device. Stepping backward for DOS support, may actually be a leap forward in an off-beat manner...

I saw something like this in a very old DDE extension that someone at Sun wrote. It was used as an example windows extension for years. In example.h is this: I2lmIGRlZmluZWQoX19XSU4zMl9fKQ==IyAgIGlmIGRlZmluZWQoX01TQ19WRVIpIwlkZWZpbmUgRVhQT1JUKGEsYikgX19kZWNsc3BlYyhkbGxleHBvcnQpIGEgYg==IyAgIGVsc2U=IwlpZiBkZWZpbmVkKF9fQk9STEFORENfXyk=IwkgICAgZGVmaW5lIEVYUE9SVChhLGIpIGEgX2V4cG9ydCBiIwllbHNlIwkgICAgZGVmaW5lIEVYUE9SVChhLGIpIGEgYg==IwllbmRpZg==IyAgIGVuZGlmI2Vsc2U=IyAgIGRlZmluZSBFWFBPUlQoYSxiKSBhIGI=I2VuZGlmRVhURVJOIEVYUE9SVChpbnQsRXhhbXBsZV9Jbml0KSBfQU5TSV9BUkdTXygoVGNsX0ludGVycCAqaW50ZXJwKSk7 That work is doing the same job, but I prefer the method that I'm proposing. It is also mentioned on and feel it is rather out-of-date and the order issue with __export should be brought into the core with this patch and be fix for good. Is> CUVYVEVSTiBpbnQgRm9vYmFyX0luaXQgKFRjbF9JbnRlcnAgKmludGVycCk7 Proposed> CVRDTF9FWFRFUk4oaW50KSBGb29iYXJfSW5pdCAoVGNsX0ludGVycCAqaW50ZXJwKTs=

Is: RVhURVJOIGludA==Rm9vYmFyX0luaXQgKFRjbF9JbnRlcnAgKmludGVycCk=ew==I2lmZGVmIFVTRV9UQ0xfU1RVQlM=ICAgIGlmIChUY2xfSW5pdFN0dWJzKGludGVycCwgIjguMSIsIDApID09IE5VTEwpIHs=ICAgICAgICByZXR1cm4gVENMX0VSUk9SOw==ICAgIH0=I2VuZGlmICAgIFRjbF9DcmVhdGVPYmpDb21tYW5kKGludGVycCwgImZvb2JhciIsIEZvb0JhciwgTlVMTCwgTlVMTCk7ICAgIHJldHVybiBUQ0xfT0s7fTs= Proposed: VENMX0VYVEVSTihpbnQpRm9vYmFyX0luaXQgKFRjbF9JbnRlcnAgKmludGVycCk=ew==I2lmZGVmIFVTRV9UQ0xfU1RVQlM=ICAgIGlmIChUY2xfSW5pdFN0dWJzKGludGVycCwgIjguMSIsIDApID09IE5VTEwpIHs=ICAgICAgICByZXR1cm4gVENMX0VSUk9SOw==ICAgIH0=I2VuZGlmICAgIFRjbF9DcmVhdGVPYmpDb21tYW5kKGludGVycCwgImZvb2JhciIsIEZvb0JhciwgTlVMTCwgTlVMTCk7ICAgIHJldHVybiBUQ0xfT0s7fTs= Preprocessor output is the following: Borland: LyogZm9vYmFyLmMgMTQ6ICovZXh0ZXJuICBpbnQgX19leHBvcnQ=LyogZm9vYmFyLmMgMTU6ICovRm9vYmFyX0luaXQgKFRjbF9JbnRlcnAgKmludGVycCk=LyogZm9vYmFyLmMgMTY6ICovew==LyogZm9vYmFyLmMgMTc6ICovLyogZm9vYmFyLmMgMTg6ICovaWYgKFRjbF9Jbml0U3R1YnMoaW50ZXJwLCAiOC4xIiwgMCkgPT0gMCkgew==LyogZm9vYmFyLmMgMTk6ICovcmV0dXJuIDE7LyogZm9vYmFyLmMgMjA6ICovfQ==LyogZm9vYmFyLmMgMjE6ICovLyogZm9vYmFyLmMgMjI6ICovKHRjbFN0dWJzUHRyLT50Y2xfQ3JlYXRlT2JqQ29tbWFuZCkoaW50ZXJwLCAiZm9vYmFyIiwgRm9vQmFyLCAwLCAwKTs=LyogZm9vYmFyLmMgMjM6ICovcmV0dXJuIDA7LyogZm9vYmFyLmMgMjQ6ICovfTs= VC++: ZXh0ZXJuICBfX2RlY2xzcGVjKGRsbGV4cG9ydCkgaW50Rm9vYmFyX0luaXQgKFRjbF9JbnRlcnAgKmludGVycCk=ew==ICAgIGlmIChUY2xfSW5pdFN0dWJzKGludGVycCwgIjguMSIsIDApID09ICgodm9pZCAqKTApKSB7ICAgICAgICByZXR1cm4gMTs=ICAgIH0=I2xpbmUgMjIgImZvb2Jhci5jIg==ICAgICh0Y2xTdHVic1B0ci0+dGNsX0NyZWF0ZU9iakNvbW1hbmQpKGludGVycCwgImZvb2JhciIsIEZvb0JhciwgKCh2b2lkICopMCksICgodm9pZCAqKTApKTs=ICAgIHJldHVybiAwOw==fTs= MinGW (native gcc on win): ZXh0ZXJuICAgICAgIGludA==Rm9vYmFyX0luaXQgKFRjbF9JbnRlcnAgKmludGVycCk=ew==ICAgIGlmIChUY2xfSW5pdFN0dWJzKGludGVycCwgIjguMSIsIDApID09ICgodm9pZCAqKTApICkgew==ICAgICAgICByZXR1cm4gMSA7ICAgIH0=ICAgICh0Y2xTdHVic1B0ci0+dGNsX0NyZWF0ZU9iakNvbW1hbmQpIChpbnRlcnAsICJmb29iYXIiLCBGb29CYXIsICgodm9pZCAqKTApICwgKCh2b2lkICopMCkgKTs=ICAgIHJldHVybiAwIDs=fTs=

In tclInt.h starting around line 1916, are prototypes for the internal cmdprocs. I can't think of any reason why they should be exported. Also note the comment about line:1673, as it states: Lyo=ICotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICogUHJvY2VkdXJlcyBzaGFyZWQgYW1vbmcgVGNsIG1vZHVsZXMgYnV0IG5vdCB1c2VkIGJ5IHRoZSBvdXRzaWRlICogd29ybGQ6ICotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICov As the current EXTERN macro places ""everything"" exportable, the use of EXTERN following this comment in tclInt.h is contradictory. In place of EXTERN for this purpose I used the new TCL_EXTRNC in the reference implementation.

This document has been placed in the public domain.