"Jonathan M Davis via Digitalmars-d"  wrote in message news:mailman.5880.1423039515.9932.digitalmars-d@puremagic.com...

> No, on further reflection, that can't be it, because it shows up in snn.lib,
> not just io.h. So, it's actually in the compiled library. So, it probably is
> a problem with the D declaration itself - be it the calling convention or
> something else.

Yes, it's the calling convention. 

On Wed, 04 Feb 2015 00:33:48 -0800, Jonathan M Davis via Digitalmars-d wrote:

> On Wednesday, February 04, 2015 08:18:46 Kagamin via Digitalmars-d wrote:
>> You got it declared with stdcall convention, should change to cdecl.
> 
> Well, I have it as extern(Windows) like everything else in core.sys.windows.windows - it has extern(Windows): at the top. Should that be something else in this case? I'm not at all familiar with the Windows calling conventions.

for the most time `extern(Windows)` is using only for winapi calls. and `wsopen` is a library call, so it's likely an `extern(C)`.

On Wed, 04 Feb 2015 00:29:58 -0800, Jonathan M Davis via Digitalmars-d wrote:

> Oh, wait. Looking over io.h, whereas _wsopen is declared, I see two problems. One, MS declared it as
> 
> int _wsopen(const wchar* filename, int oflag, int shflag, int pmode);
> 
> whereas dmc seems to have
> 
> int __CLIB _wsopen(const wchar_t *, int, int, ...);
> 
> So, for some reason, dmc made it variadic.

`pmode` argument is optional (it depends on flags in `oflag`), and passing it each time is somewhat annoying. but there is no way to do optional args in C, so DMC made function variadic. take the first declaration, it's ok.

>  Error 42: Symbol Undefined __wsopen@12

and yes, it must be `extern(C)`, not `extern(Windows)`, as Daniel told you in another post.

On Wednesday, February 04, 2015 09:02:01 ketmar via Digitalmars-d wrote:
> On Wed, 04 Feb 2015 00:33:48 -0800, Jonathan M Davis via Digitalmars-d wrote:
>
> > On Wednesday, February 04, 2015 08:18:46 Kagamin via Digitalmars-d wrote:
> >> You got it declared with stdcall convention, should change to cdecl.
> >
> > Well, I have it as extern(Windows) like everything else in core.sys.windows.windows - it has extern(Windows): at the top. Should that be something else in this case? I'm not at all familiar with the Windows calling conventions.
>
> for the most time `extern(Windows)` is using only for winapi calls. and
> `wsopen` is a library call, so it's likely an `extern(C)`.

Well, unfortunately, a C function is a C function to me. I know that different calling conventions exist in Windows, but I have no idea why, what the difference is, or what they affect. AFAIK, it's not an issue that exists on POSIX systems. I really should study up on it.

- Jonathan M Davis

On Wed, 04 Feb 2015 01:13:18 -0800, Jonathan M Davis via Digitalmars-d wrote:

>> for the most time `extern(Windows)` is using only for winapi calls. and
>> `wsopen` is a library call, so it's likely an `extern(C)`.
> 
> Well, unfortunately, a C function is a C function to me. I know that different calling conventions exist in Windows, but I have no idea why, what the difference is, or what they affect. AFAIK, it's not an issue that exists on POSIX systems. I really should study up on it.

it's mostly historical artifacts. and it's too late to change that. most of the time it's used to make your program crash in most unexpected ways.

first windows was written in pascal, so it has pascal calling convention (left-to-right order, callee cleans the stack). i don't know why, but when they go to 32-bit version, they start using stdcall calling convention (right-to-left order, yet callee still cleans the stack). that is what `extern(Windows)` in D means. and most of other libraries written in C, and they using cdecl convetion (right-to-left order, caller cleans the stack). lovely things, aren't they?

so you have to triple-check your declarations when using windows. 'cause besides name mangling, you can accidentally mark some stdcall function as cdecl, and your program will work... for some time. but with bad stack pointer, which will lead to some mystical bugs later.

On Wednesday, February 04, 2015 19:51:38 Daniel Murphy via Digitalmars-d wrote:
> "Jonathan M Davis via Digitalmars-d"  wrote in message news:mailman.5879.1423038837.9932.digitalmars-d@puremagic.com...
>
> > Well, I have it as extern(Windows) like everything else in core.sys.windows.windows - it has extern(Windows): at the top. Should that be something else in this case? I'm not at all familiar with the Windows calling conventions.
>
> Try extern(C) and see if it works.  If it's a C function, it will most likely be using C mangling instead of system mangling.

Yes. extern(C) does seem to do the trick. Thanks for guys' help. I've had the code sitting around incomplete for quite some time now, and it's long past time for it to become a PR.

https://github.com/D-Programming-Language/phobos/pull/2956

- Jonathan M Davis

On Wednesday, February 04, 2015 09:33:22 ketmar via Digitalmars-d wrote:
> On Wed, 04 Feb 2015 01:13:18 -0800, Jonathan M Davis via Digitalmars-d wrote:
>
> >> for the most time `extern(Windows)` is using only for winapi calls. and
> >> `wsopen` is a library call, so it's likely an `extern(C)`.
> >
> > Well, unfortunately, a C function is a C function to me. I know that different calling conventions exist in Windows, but I have no idea why, what the difference is, or what they affect. AFAIK, it's not an issue that exists on POSIX systems. I really should study up on it.
>
> it's mostly historical artifacts. and it's too late to change that. most of the time it's used to make your program crash in most unexpected ways.
>
> first windows was written in pascal, so it has pascal calling convention (left-to-right order, callee cleans the stack). i don't know why, but when they go to 32-bit version, they start using stdcall calling convention (right-to-left order, yet callee still cleans the stack). that is what `extern(Windows)` in D means. and most of other libraries written in C, and they using cdecl convetion (right-to-left order, caller cleans the stack). lovely things, aren't they?
>
> so you have to triple-check your declarations when using windows. 'cause besides name mangling, you can accidentally mark some stdcall function as cdecl, and your program will work... for some time. but with bad stack pointer, which will lead to some mystical bugs later.

Just one more reason to hate Windows, I guess.

- Jonathan M Davis

On Wednesday, 4 February 2015 at 08:33:57 UTC, Jonathan M Davis wrote:
> On Wednesday, February 04, 2015 08:18:46 Kagamin via Digitalmars-d wrote:
>> You got it declared with stdcall convention, should change to
>> cdecl.
>
> Well, I have it as extern(Windows) like everything else in
> core.sys.windows.windows - it has extern(Windows): at the top. Should that
> be something else in this case? I'm not at all familiar with the Windows
> calling conventions.
>
> - Jonathan M Davis

Functions in <io.h> are low-level I/O API, providing POSIX-style wrappers for winapi functions: https://msdn.microsoft.com/en-us/library/40bbyw78.aspx - you can see them documented as part of C runtime library. The declarations should be somewhere core.sys.windows.io, see for example core.sys.windows.stat.
Everything in C runtime library uses C calling convention, because that's a library special for C, which makes it working. C is C, Windows is Windows, that's the difference. There can be Ada runtime library, which will use whatever calling (and naming) convention native to Ada, there can be Pascal runtime library, which will use whatever calling convention native to Pascal, there can be Haskell runtime library, which will use whatever calling convention native to Haskell, and so on. C has runtime library too.