<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 10.02.2013 13:52, Igor Stasenko
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAEYrNzA8qG0x+1=iHc_5HS-XkFD6RiVRLm+aHNZ=uHE1J17DsA@mail.gmail.com"
      type="cite">
      <pre wrap=""> </pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">On 10 February 2013 01:51, Eliot Miranda <a class="moz-txt-link-rfc2396E" href="mailto:eliot.miranda@gmail.com">&lt;eliot.miranda@gmail.com&gt;</a> wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">


On Sat, Feb 9, 2013 at 3:18 PM, Igor Stasenko <a class="moz-txt-link-rfc2396E" href="mailto:siguctua@gmail.com">&lt;siguctua@gmail.com&gt;</a> wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">

Hi, Eliot

i thought about it, and i don't like it.
I am in favor of exporting stuff explicitly, rather than implicitly by
compiler..
because with implicit exports, you never know whether given symbol
will be visible or not..
and you have to guess and hope instead of being confident.

It would be nice if we could have a way to export all functions and variables
which has &lt;api&gt; pragma.. because exporting everything , first is not
needed, second
it will expose some symbols which are really private to VM which is
not very good from design perspective.
</pre>
        </blockquote>
        <pre wrap="">

I agree. All you need to do on WIndows is to collect all the functions that are either marked as api, export: true or in requiredMethodNames and write a .def file.  The syntax of the def file is easy enough (just a list of names IIRC) that a Makefile could munge it to produce a set of flags for a linker (but it's a *lot* of flags :) ).  You might look at where the CodeGenerator produces cointerp.h and cogit.h and add the generation there.

</pre>
      </blockquote>
      <pre wrap="">
There's already support for that in codebase
all we need is to use  __declspec( dllexport )  as recommended in [1].

(btw, it is already used by EXPORT() macro,
but this macro suitable only for declarations with known return type
(btw why?), so i took a freedom to add a new)..

- added VM_EXPORT macro
  in sq.h:

#define VM_EXPORT  /*nothing*/

  in win32/vm/sqPlatformSpecific.h:

#undef VM_EXPORT
#define VM_EXPORT __declspec( dllexport )

(in both cases right under EXPORT() macro definition)

- changed 3 methods in VMMaker, mainly to emit corresponding macros in
.headers (see attached)

i wonder, if it is syntactically correct to use
EXPORT() macro e.g. without parameter.. then VM_EXPORT not needed since
will be expanded into
EXPORT(/*nothing*/) =&gt;  __declspec( dllexport ) /*nothing*/


And now running in windoze, i  can do:

 NativeBoost loadSymbol: #CFramePointer fromModule: NativeBoost VMModule
         @ 16r5A5710

or:
 NativeBoost loadSymbol: #suppressHeartbeatFlag fromModule: NativeBoost VMModule
         @ 16r5A56EC
        

voila!


[1] <a class="moz-txt-link-freetext" href="https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/4/html/Using_ld_the_GNU_Linker/win32.html">https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/4/html/Using_ld_the_GNU_Linker/win32.html</a>


</pre>
    </blockquote>
    There's also an equivalent in GCC &gt;= 4, in a dll I wrote some
    time ago I used:<br>
    <br>
    #if defined _WIN32 || defined __CYGWIN__<br>
      #define API __declspec(dllexport)<br>
      #define PRIVATE  //Methods not visible by default when compiling
    using CYGWIN or MSVC<br>
    #else<br>
      #if __GNUC__ &gt;= 4<br>
        <br>
        #define API __attribute__ ((visibility("default")))<br>
        #define PRIVATE __attribute__ ((visibility("hidden")))<br>
    <br>
    Used gcc on OSX though, so not sure what the same would be for
    clang.<br>
    <br>
    Cheers,<br>
    Henry<br>
    <br>
  </body>
</html>