From: muta...@gmail.com   
      
   On Sunday, August 29, 2021 at 1:20:22 PM UTC+8, muta...@gmail.com wrote:   
   > On Sunday, August 29, 2021 at 9:26:50 AM UTC+10, Tavis Ormandy wrote:    
   > > On 2021-08-28, muta...@gmail.com wrote:    
   > > > But the DLL being produced is very small and doesn't    
   > > > contain the functions I want, and that is confirmed    
   > > > by the link map.    
   >    
   > > You need to mark the symbols you want exported, or the compiler will    
   > > assume it's dead code and remove them - they're not visible outside of    
   > > the current compilation unit, and you never called them...so why keep    
   > > them!    
   > >    
   > > The easy solution is to just add __declspec(dllexport) to the functions    
   > > you want exported. Alternatively, you can make a def file to tell the    
   > > linker precisely what you wanted.   
   > Hi Tavis. Thanks for your reply.    
   >    
   > That solved the problem!    
   >    
   > My next problem is that my functions appear to have an    
   > underscore in front of them (from kernel32.map):    
   >    
   > 0001:00000040 _WriteFile@20 10001040 f kernel32.obj    
   >    
   > What will Microsoft be doing to suppress that?    
   >    
   > Here is how each function I define looks like:    
   >    
   > #define WINAPI __declspec(dllexport) __stdcall    
   >    
   > I'm guessing that Microsoft has done something special    
   > to avoid namespace pollution. Any idea what?    
      
   I had another crack at this.   
      
   I spent a lot of effort, writing programs to generate assembler   
   code and generate aliases.   
      
   In the end it was near the end of this that nailed it:   
      
   https://stackoverflow.com/questions/2804893/c-dll-export-decorat   
   d-mangled-names/2805560#2805560   
      
   Use a simple:   
      
   EXPORTS   
     SetCallback   
      
   and it removes the decoration automatically.   
      
   So I can now use Visual Studio 2005 to create kernel32.dll,   
   kernel32.lib, msvcrt.dll and msvcrt.lib (my own versions of   
   all of those) and both the DLLs and programs linked with   
   them work on both PDOS/386 and Windows. (Although I   
   didn't specifically attempt to replace the Windows DLLs   
   on Windows).   
      
   I think it is good to have the option of professionally   
   supported tools like Visual Studio.   
      
   I also have the option of the gnu toolchain.   
      
   And I almost have the option of public domain replacements   
   for everything.   
      
   Oh - I have a little bit (400 lines) of assembler that is AT&T syntax   
   so I am using binutils to assemble that. I'm not yet in a position   
   to switch to using masm syntax.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)