Is the trick by skeeto applicable in Adept?

[ghost]

Lazy Load a DLL in Go doesn't need a function pointer prototype.

Hmm, I suppose if you wanted similar semantics you could do this:

typedef uintptr_t Syscall(...);

Go treats Win32 functions like system calls, passing everything as uintptr because the interfacing is really that dumb (in a good way). So you can do basically the same in C. I'd even use a helper like this to pass full-width "empty" parameters:

#define nil ((uintptr_t)0)

Then maybe:

typedef struct {
    Syscall *ExitProcess;
    Syscall *GetCommandLineW;
    Syscall *GetProcAddress;
    Syscall *GetStdHandle;
    Syscall *LoadLibraryA;
    Syscall *WriteConsoleW;
} Kernel32;


typedef struct {
    Syscall *CommandLineToArgvW;
} Shell32;

And then:

static Kernel32 new_kernel32()
{
    Syscall LoadLibraryA, GetProcAddress;  // bootstrap
    uintptr_t h = LoadLibraryA("kernel32");
    return (Kernel32){
        .ExitProcess     = (Syscall *)GetProcAddress(h, "ExitProcess"),
        .GetCommandLineW = (Syscall *)GetProcAddress(h, "GetCommandLineW"),
        .GetProcAddress  = (Syscall *)GetProcAddress(h, "GetProcAddress"),
        .GetStdHandle    = (Syscall *)GetProcAddress(h, "GetStdHandle"),
        .LoadLibraryA    = (Syscall *)GetProcAddress(h, "LoadLibraryA"),
        .WriteConsoleW   = (Syscall *)GetProcAddress(h, "WriteConsoleW"),
    };
}

static Shell32 new_shell32(Kernel32 kernel32)
{
    uintptr_t h = kernel32.LoadLibraryA("shell32");
    return (Shell32){
        .CommandLineToArgvW =
            (Syscall *)kernel32.GetProcAddress(h, "CommandLineToArgvW"),
    };
}

No type safety at the call sites of course, though likely those call sites are already wrappers presenting a higher level interface. Usage example:

static ptrdiff_t char16len(char16_t *s)
{
    ptrdiff_t len = 0;
    for (; s[len]; len++) {}
    return len;
}

void mainCRTStartup()
{
    Kernel32 kernel32 = new_kernel32();
    Shell32  shell32  = new_shell32(kernel32);
    char16_t  *cmd  = (char16_t *)kernel32.GetCommandLineW();
    int        argc = {};
    char16_t **argv = (char16_t **)shell32.CommandLineToArgvW(cmd, &argc);
    uintptr_t  out  = kernel32.GetStdHandle(-11);
    for (int i = 1; i < argc; i++) {
        kernel32.WriteConsoleW(out, u"hello, ", 7, nil, nil);
        kernel32.WriteConsoleW(out, argv[i], char16len(argv[i]), nil, nil);
        kernel32.WriteConsoleW(out, u"\n", 1, nil, nil);
    }
    kernel32.ExitProcess(0);
}

Then:

$ cc -nostartfiles -o hello.exe hello.c
$ ./hello world skeeto
hello, world
hello, skeeto
$ peports hello.exe
KERNEL32.dll
	0	GetProcAddress
	0	LoadLibraryA

Though this technique does not work on x86 because stdcall is incompatible with these variadic calls, and you'd need to dispatch through custom assembly. Looks like the libraries you linked struggle with this, too.

Original thread: skeeto/w64devkit#340

[IsaacShelton]

Yes the same technique should work from Adept, but you would have to be careful to call it with the right types since the integer promotion rules are not the same as in C. Usually it is easier to just cast to the correct function pointer type instead.

[ghost]

integer promotion rules

Could you please elaborate further? Thank you.

[IsaacShelton]

The default integer type in Adept is long (64-bits), but in C it is int (usually 32-bits), so in Adept the argument must be explicitly given the 32-bit signed integer type int (if not already an int). Also when you pass integers in C that are smaller than 32 bits to functions, they are promoted to 32 bits by the ABI (although this is not an issue I believe since this promotion of variadic arguments <32 bits is already handled by LLVM). The main one to be careful of, is that the type of the argument in Adept must have the same number of integer bits and sign as the counterpart in C.

Now that I think about this more, I think this trick might actually be undefined behavior in general (disregarding Adept). This trick looks to be more of a coincidence in how variadic arguments are implemented on some platforms than actual intended behavior. But not 100% sure, I'd have to check the C spec.

Somewhat related: https://stackoverflow.com/questions/46073295/implicit-type-promotion-rules
The integer promotions this talks about are not exactly the same as the argument promotions I'm talking about, but are the same idea except are for operators in C instead of arguments.

Also, for any complicated types, how they are passed (including promotion/ABI rules for large integers and vectors) can differ per platform and C compiler. But this is not really an issue normally for simple types such as integers and pointers.