As you might have noticed already, this functionality is currently missing in phobos leading people to write buggy or platform specific code.

We just fixed this in dub.
https://github.com/D-Programming-Language/dub/pull/497

Time to finally add this to phobos, what's missing is someone to implement it ;).
https://issues.dlang.org/show_bug.cgi?id=13996

On Wednesday, February 04, 2015 03:33:50 Martin Nowak via Digitalmars-d wrote:
> As you might have noticed already, this functionality is currently missing in phobos leading people to write buggy or platform specific code.
>
> We just fixed this in dub. https://github.com/D-Programming-Language/dub/pull/497
>
> Time to finally add this to phobos, what's missing is someone to
> implement it ;).
> https://issues.dlang.org/show_bug.cgi?id=13996

I have an implementation for it already, but I get linker errors for _wsopen and any of its variants on Windows, so it doesn't work on Windows. If it weren't for that, I'd have created a pull request for it quite some time ago.

Has anyone else ever used _wsopen or its variants with dmd? If so, I'd love to know how they got them to link.

- Jonathan M Davis

Looks like a relatively new function, so I guess, snn simply doesn't implement it.

Oops, no, not new.

On Wednesday, February 04, 2015 07:34:14 Kagamin via Digitalmars-d wrote:
> Looks like a relatively new function, so I guess, snn simply doesn't implement it.

No. If I grep dmc's folder, snn.lib contains _wsopen. It doesn't contain _wsopen_s, which is what MS wants folks to use, but it does have _wsopen. However, when I try and use it, I get

Error 42: Symbol Undefined __wsopen@16

As I understand it, snn.lib is already linked in for other stdio stuff, so I don't know why it can't find _wsopen. And adding pragma(lib, "snn.lib"); doesn't help. So, I don't know what to do.

- Jonathan M Davis

You got it declared with stdcall convention, should change to cdecl.

On Wednesday, February 04, 2015 00:13:21 Jonathan M Davis via Digitalmars-d wrote:
> On Wednesday, February 04, 2015 07:34:14 Kagamin via Digitalmars-d wrote:
> > Looks like a relatively new function, so I guess, snn simply doesn't implement it.
>
> No. If I grep dmc's folder, snn.lib contains _wsopen. It doesn't contain _wsopen_s, which is what MS wants folks to use, but it does have _wsopen. However, when I try and use it, I get
>
> Error 42: Symbol Undefined __wsopen@16
>
> As I understand it, snn.lib is already linked in for other stdio stuff, so I don't know why it can't find _wsopen. And adding pragma(lib, "snn.lib"); doesn't help. So, I don't know what to do.

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. And the second problem is that dmc has that block of function declarations surrounded by

#ifdef __NT__
#ifndef __STDC__
// declarations
#endif
#endif

and it's quite possible that the declarations are being skipped entirely. And since changing the D declaration for _wsopen to be variadic simply changes the error message to

 Error 42: Symbol Undefined __wsopen@12

that would imply that those declarations aren't actually enabled. And without some version of _wsopen, I don't know how to get the code working properly on Windows. Maybe the a version will work? But those are supposed to be avoided like the plague as I understand it.

All in all, this is quite annoying.

- Jonathan M Davis

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

On Wednesday, February 04, 2015 00:29:58 Jonathan M Davis via Digitalmars-d wrote:
> And the second problem is that
> dmc has that block of function declarations surrounded by
>
> #ifdef __NT__
> #ifndef __STDC__
> // declarations
> #endif
> #endif
>
> and it's quite possible that the declarations are being skipped entirely.

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.

- Jonathan M Davis

"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.