www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - core.sys.windows so lean?

reply Jonathan Marler <johnnymarler gmail.com> writes:
I'm writing some platform specific D code and I've found that 
what the druntime exposes for the windows platform is pretty 
lean.  I'm guessing that the purpose of the druntime version of 
the windows api is to implement the minimum required to support 
the windows platform and not meant to be a full-featured 
interface to windows.  Is this the case?

If so, is there a good library that someone has implemented to 
support the full windows API? I think I remember there was one a 
few years ago, but now I'm unable to find it.  I think I remember 
that the windows .lib files installed with dmd were missing 
symbols/functions I needed so I had to use the ones in the 
system32 directory installed with windows.  I also had to convert 
them to OMF (since optlink doesn't support COFF).  I'm just 
wondering if someone can shed some light on this, it's just been 
a while and google didn't seem to be much help so pointers in the 
right direction would be much appreciated.  Thanks.
Jun 06 2016
next sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Monday, 6 June 2016 at 16:04:30 UTC, Jonathan Marler wrote:

 I'm writing some platform specific D code and I've found that 
 what the druntime exposes for the windows platform is pretty 
 lean.  I'm guessing that the purpose of the druntime version of 
 the windows api is to implement the minimum required to support 
 the windows platform and not meant to be a full-featured 
 interface to windows.  Is this the case?


Erm, not since 2.070:

http://dlang.org/changelog/2.070.0.html#core-sys-windows


 If so, is there a good library that someone has implemented to 
 support the full windows API? I think I remember there was one 
 a few years ago, but now I'm unable to find it.  I think I 
 remember that the windows .lib files installed with dmd were 
 missing symbols/functions I needed so I had to use the ones in 
 the system32 directory installed with windows.  I also had to 
 convert them to OMF (since optlink doesn't support COFF).  I'm 
 just wondering if someone can shed some light on this, it's 
 just been a while and google didn't seem to be much help so 
 pointers in the right direction would be much appreciated.  
 Thanks.


This is the (former URL of the) library you are thinking of:

http://www.dsource.org/projects/bindings

Or you might've used my GitHub mirror:

https://github.com/CS-svnmirror/dsource-bindings
https://github.com/CS-svnmirror/dsource-bindings-win32

It has been intergrated into Druntime as the core.sys.windows 
package in 2.070.
Jun 06 2016
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Monday, 6 June 2016 at 16:13:48 UTC, Vladimir Panteleev wrote:

 On Monday, 6 June 2016 at 16:04:30 UTC, Jonathan Marler wrote:

 I'm writing some platform specific D code and I've found that 
 what the druntime exposes for the windows platform is pretty 
 lean.  I'm guessing that the purpose of the druntime version 
 of the windows api is to implement the minimum required to 
 support the windows platform and not meant to be a 
 full-featured interface to windows.  Is this the case?


 Erm, not since 2.070:


Hmmm...it seems to be missing quite alot though.  Especially the 
winsock api.  Over the weekend I was writing some code that uses 
a windows IOCompletionPort and had to add a fair amount of code 
that was missing:

   import core.sys.windows.windows;
   import core.sys.windows.winsock2;

   // NOTE: not sure if this stuff should be included in 
core.sys.windows.winsock2
   alias u_long = uint; // NOTE: not sure if uint is the best 
alias for u_long

   // The actual sockaddr_in structure in windows is 24 bytes long,
   // but the sockaddr_in defined in core.sys.windows.winsock2 is 
only 20.
   // This caused an error when calling AcceptEx that indicated 
the buffer
   // size for sockaddr_in was too small.
   union real_sockaddr_in {
     sockaddr_in addr;
     ubyte[24] padding; // make sure the sockaddr_in takes 24 bytes
   }

   struct WSABUF {
     u_long len;
     char* buf;
   }
   alias LPWSABUF = WSABUF*;

   // NOTE: WSAOVERLAPPED is supposed to be castable to and from 
OVERLAPPED.
   //       Maybe this doesn't need to be defined, maybe I could 
just always use OVERLAPPED?
   struct WSAOVERLAPPED {
     ULONG* Internal;
     ULONG* InternalHigh;
     union {
       struct {
	DWORD Offset;
	DWORD OffsetHigh;
       }
       PVOID Pointer;
     }
     HANDLE hEvent;
   }
   alias LPWSAOVERLAPPED = WSAOVERLAPPED*;
   alias LPWSAOVERLAPPED_COMPLETION_ROUTINE = void function(uint, 
uint, LPWSAOVERLAPPED, uint);

   enum : int {
     SIO_GET_EXTENSION_FUNCTION_POINTER = 0xc8000006,
   }

   enum GUID WSAID_ACCEPTEX = 
{0xb5367df1,0xcbac,0x11cf,[0x95,0xca,0x00,0x80,0x5f,0x48,0xa1,0x92]};
   alias LPFN_ACCEPTEX = extern(Windows) bool function(SOCKET 
listenSocket,
						      SOCKET acceptSocket,
						      PVOID outputBuffer,
						      DWORD receiveDataLength,
						      DWORD localAddressLength,
						      DWORD remoteAddressLength,
						      DWORD* bytesReceived,
						      OVERLAPPED* overlapped) nothrow  nogc;


   extern(Windows) int WSAIoctl(SOCKET s, uint dwIoControlCode,
			       void* lpvInBuffer, uint cbInBuffer,
			       void* lpvOutBuffer, uint cbOutBuffer,
			       uint* lpcbBytesReturned,
			       LPWSAOVERLAPPED lpOverlapped, 
LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine) nothrow 
 nogc;
   extern(Windows) int WSARecv(SOCKET s, LPWSABUF lpBuffer, DWORD 
bufferCount,
			      LPDWORD numberOfBytesReceived, LPDWORD flags,
			      LPWSAOVERLAPPED overlapped, 
LPWSAOVERLAPPED_COMPLETION_ROUTINE completionRoutine);
Jun 06 2016
next sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Monday, 6 June 2016 at 16:51:20 UTC, Jonathan Marler wrote:

 Hmmm...it seems to be missing quite alot though.


You could've mentioned you meant just the winsock modules.

They have not been brought over because they were not explicitly 
under an open-source license.
Jun 06 2016
parent Jonathan Marler <johnnymarler gmail.com> writes:
On Monday, 6 June 2016 at 17:11:44 UTC, Vladimir Panteleev wrote:

 On Monday, 6 June 2016 at 16:51:20 UTC, Jonathan Marler wrote:

 Hmmm...it seems to be missing quite alot though.


 You could've mentioned you meant just the winsock modules.

 They have not been brought over because they were not 
 explicitly under an open-source license.


:(

(Sorry I didn't realize they were all only in the winsock module)

Weird that you could include the standard windows module but not 
winsock?  Also seems odd that a language including bindings to an 
operating system api would be a licensing issue.
Jun 06 2016
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On Monday, 6 June 2016 at 16:51:20 UTC, Jonathan Marler wrote:


 Hmmm...it seems to be missing quite alot though.  Especially 
 the winsock api.  Over the weekend I was writing some code that 
 uses a windows IOCompletionPort and had to add a fair amount of 
 code that was missing:


Pull requests for anything you find missing would be great.
Jun 06 2016
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
With the newest dmds, if you use -m32mscoff you just use the 
Microsoft libraries and linkers and the core.sys.windows is 
pretty full - should be easy to use.
Jun 06 2016