On 6/27/2012 6:23 PM, Björn Felten -> Scott Street wrote:   
    BF>     WOW! A totally clean compile!   
      
   Hmm. That is a feat!  Cross compatibility is a nightmare.   
      
    BF>     Well, I downloaded the latest smapi package from sourceforge and   
    BF> installed it in a subdir -- smapi -- under src. Compiled it with the mgw   
    BF> makefile and got a libsmapimgw.a file. In Makefile.win32 in src I   
    BF> changed line 21 to:   
      
    BF>     $(CC) -o jamnntpd$(EXESUFFIX) $(OBJS) smapi/libsmapimgw.a -lwsock32   
      
   You should see the size of the Win32 Binary with SMAPI linked in and TLS in   
   DLLs .. it is HUGE in comparison.  It has inspired me to take another look at   
   the 'regular' version of JamNNTPd.  I also have uncovered a memory leak in   
   using somewhere between SMAPI and JamNNTPd.   
      
   I was running my test scripts against the new Win32 build - and after some   
   time, SMAPI starts to go nuts about being unable to close some random   
   pointer...  I've just pulled the win32 zip off the website until I can track   
   down the issue.   
      
   Look for a new version, perhaps tomorrow.   
      
    BF>     And whaddaya know? It compiled! But then I once again have all the   
    BF> warnings. I don't think I will go for the SMAPI version -- the resulting   
    BF> EXE file is twice as big as the Stenberg version.   
      
   I should point out that for the size, it does gain some options for message   
   bases.  That version will support JAM, .MSG, and Squish all at the same time.   
   (just prefix the group filename with a '$' for Squid, a '#' for .MSG, and   
   optionally, a '!' for Jam, which is the default anyway)   
      
   ---   
    * Origin: -=[ SSAlpha da'Point/win32 ]=- (1:266/420.1)