Winlean definition issues

[euantorano]

The winlean module has a couple type definitions that don't quite match up to Microsoft's documentation:

• DWORD: defined as int32, Microsoft documents it as typedef unsigned long DWORD;:

A 32-bit unsigned integer. The range is 0 through 4294967295 decimal.
This type is declared in IntSafe.h as follows:

• HANDLE: defined as int, Microsoft documents it as typedef PVOID HANDLE;:

A handle to an object.

There may well be others, but these are the two I've noticed so far. This is causing issues in my serial package.

It seems the DWORD issue was already reported as #9848

The HANDLE definition also means that the INVALID_HANDLE_VALUE constant doesn't work as this is defined as -1 by Microsoft, which isn't a valid int.

Changing these may break things, but for the sake of correctness (and fixing my library 😉) I think it's worth investigating.

[ringabout]

Edited:
It seems to be consistent with posix definitions. I don't know whether it is right?

# posix.nim
SockLen* {.importc: "socklen_t", header: "<sys/socket.h>".} = cuint

winlean defines SockLen = cuint but it should be cint.

https://nim-lang.org/docs/winlean.html#SockLen

proc accept(s: SocketHandle; a: ptr SockAddr; addrlen: ptr SockLen): SocketHandle {.
    stdcall, importc: "accept", dynlib: ws2dll.} 

In MSDN:
https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-accept

SOCKET WSAAPI accept(
  SOCKET   s,
  sockaddr *addr,
  int      *addrlen
);

Another thing which can be improved, but it's ok for me.
It also uses pointer instead of ptr char or cstring to stand for char * in c.

proc getsockopt(s: SocketHandle; level, optname: cint; optval: pointer;
               optlen: ptr SockLen): cint {.stdcall, importc: "getsockopt",
                                        dynlib: ws2dll.}

[timotheecour]

note regarding WINBOOL:

WINBOOL is currently WINBOOL* = int32; this is wrong on 2 levels:

• according to https://docs.microsoft.com/en-us/windows/win32/winprog/windows-data-types WINBOOL is:
  BOOLEAN = BYTE = unsigned char (and is explicitly mentioned as being 8 bits, unlike int32) = cuchar in nim
• furthermore, since windows uses opposite convention as posix (0 means FALSE aka error on windows APIs usually, whereas 0 means success on posix), we should use distinct cuchar and introduce an auxiliary template proc isSuccess(a): bool to work cross platform and be self descriptive in code; would avoid the current guesswork when reading this:

proc closeHandleCheck(handle: Handle) {.inline.} =
    if handle.closeHandle() == 0:
      raiseOSError(osLastError())

links

• reference https://docs.microsoft.com/en-us/windows/win32/winprog/windows-data-types which contains all the windows API types
• see also typesafe windows API, eg: WINBOOL should be distinct cuchar timotheecour/Nim#470

[ringabout]

# winlean
type
  LONG* = int32
  ULONG* = int32
  PULONG* = ptr int

this is not correct too! It should be

type
  LONG* = int32
  ULONG* = cuint
  PULONG* = ptr ULONG

[euantorano]

I’m going to try get tome this weekend to at least take a first pass at this and see how much would break.

[HugoGranstrom]

I'll chime in and add that AsyncHttpClient which uses AsyncFile uses DWORD for its offset:

Nim/lib/pure/asyncfile.nim

Line 150 in 8ccde68

ol.offset = DWORD(f.offset and 0xffffffff)

This means it's limited to roughly 2GB files because DWORD = int32 in winlean:

Nim/lib/windows/winlean.nim

Line 38 in 8ccde68

DWORD* = int32

But DOWRD = uint32 here:

Nim/tools/urldownloader.nim

Line 82 in 8ccde68

DWORD = uint32

So using HttpClient you can download files up to 4GB. This inconsistency alone has bugged me recently.