02:46 <triangle345> hey all i'm having some trouble running FFI on simple windows commands such as: @ShellExecute[U32](U32(0), "open".cstring(), "cmd.exe".cstring(), "/C ipconfig > out.txt".cstring(), U32(0), U32(0))

02:47 <triangle345> keeps giving me error LNK2019: unresolved external symbol ShellExecute referenced in function Main_Dispatch

02:47 <triangle345> does anyone know if I have to manually include a windows header or something somewhere?

02:53 <doublec> triangle345: you probably need to link against a windows library somehow

02:53 <doublec> triangle345: do you have a: use "lib:somelibraryname" in your program?

02:54 <doublec> (which is what handles the linking)

02:56 <doublec> triangle345: possible: use "lib:shell32"

03:15 <triangle345> thanks i will give that a try

03:18 <doublec> np

03:27 <triangle345> hmm still having same issue

03:27 <triangle345> do i need to the have dll in the current path?

03:30 <triangle345> no that didnt work either

03:32 <doublec> odd

03:33 <doublec> hmm, I wonder if there's some name mangling thing going on

03:33 <doublec> istr that win32 functions use pascal linkage or something like that

03:35 <doublec> Yes, they use stdcall

03:37 <doublec> I don't know if there's a way to specify that, hopefully a pony dev can help

03:38 <triangle345> right, well thanks for the help

03:38 <doublec> triangle345: you might be able to use @system though on win32

03:39 <triangle345> i will probably be able to use system but it is a lot slower and i was looking to do something more complex to eventually being able to do a createprocess

10:20 <allplayersdd> how much test coverage does ponylang have?

10:47 <triangle345> hey are any devs on right now to help answer a ffi question?

10:55 <allplayersdd> yes go ahead

11:03 <triangle345> im trying to do something liek this under windows:

11:03 <triangle345> @ShellExecute[U32](NULL, "open".cstring(), "cmd.exe".cstring(), "/C ipconfig > out.txt".cstring(), "".cstring(), U32(0))

11:04 <triangle345> but keep getting unresolved lnk reference errors

11:04 <triangle345> i use at the top: use "lib:shell32"

11:05 <triangle345> i also tried replacing the args with primitives i made, thats why you see the "NULL" in there

11:06 <triangle345> error LNK2019: unresolved external symbol ShellExecute referenced in function Main_Dispatch

11:06 <triangle345> thats the specific line - sorry it was unresolved symbol?

11:13 <allplayersdd> im not actually a dev but its better to just ask

11:17 <triangle345> i asked my question above yours

11:18 <triangle345> is it visible?

11:20 <CcxCZ> triangle345: It is. allplayersdd just joined after that.

11:20 <CcxCZ> I kinda wish I could help. But on the other hand, for my own sanity, I don't desire deep understanding of Win32 internals. :P

11:21 <triangle345> haha yea its a necessary evil :)

11:21 <triangle345> allplayersdd: just in case you missed it:

11:22 <triangle345> i'm trying to run ffi @ShellExecute[U32](NULL, "open".cstring(), "cmd.exe".cstring(), "/C ipconfig > out.txt".cstring(), "".cstring(), U32(0)) but keep getting unresolved symbol errors and i'm definitely useing the use "lib:shell32" line

11:22 <CcxCZ> Wasn't ShellExecute more of a COM object rather than simple library call? I forgot the details. I remember needing to use that COM thingy (from FoxPro, don't ask) to avoid nasty mess of winapi calls to have popen() equivalent.

11:26 <triangle345> yea but i get the same error on other functions such as CreateProcess

11:28 <allplayersdd> what symbol errors do you get?

11:29 <allplayersdd> should be googleable what .dlls you have to include

11:29 <triangle345> error LNK2019: unresolved external symbol ShellExecute referenced in function Main_Dispatch

11:29 <triangle345> msdn says shellexecute uses shell32.lib

11:32 <triangle345> i put the dll in the current path but that had no effect

11:34 <CcxCZ> There's some depend.exe or dependency.exe tool to introspect dynlinking and determine what is where.

11:35 <triangle345> but msdn says exactly where it is:

11:35 <triangle345> Library Shell32.lib DLL Shell32.dll (version 3.51 or later)

20:36 <M-Ingo> Hello, I just found ponylang and may check it out, so I just joined here to see what's happening.

20:38 <TwoNotes> Praetonus, so your fix to single store is in master now?

20:40 <Praetonus> TwoNotes: Yes. I think it should fix the problem. I'm also doing an audit of atomics in the codebase so it may help spot other potential problems

20:41 <jemc_> M-Ingo: welcome! let us know if you have any questions :)

20:51 <TwoNotes> Ok, pulling it now, and I will test it on ARM

21:59 <triangle345> hey guys any devs on here.. i have an ffi issue for windows

22:01 <triangle345> trying to run @ShellExecute[U32](NULL, "open".cstring(), "cmd.exe".cstring(), "/C ipconfig > out.txt".cstring(), "".cstring(), U32(0))

22:01 <triangle345> and keep getting this error: error LNK2019: unresolved external symbol ShellExecute referenced in function Main_Dispatch

22:02 <doublec> I suspect ShellExecute is exported with a different name

22:02 <triangle345> however; i do have using "lib:shell32" at the top of my file

22:03 <triangle345> how do you know its exported under a different name?

22:04 <doublec> triangle345: can you try with more verbosity. eg. ponyc --verbose=3

22:04 <doublec> triangle345: that prints the actual commands as they are run

22:05 <triangle345> sure

22:05 <doublec> triangle345: also, can you run dumpbin /exports shell32.dll

22:05 <doublec> triangle345: and see the exports

22:06 <triangle345> cmd /C ""C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\link.exe" /DEBUG /NOLOGO /MACHINE:X64 /OUT:.\ponycod e.exe .\ponycode.obj /LIBPATH:"C:\Program Files (x86)\Windows Kits\10\Lib\10.0.14393.0\ucrt\x64" /LIBPATH:"C:\Program Fi les (x86)\Windows Kits\10\Lib\10.0.14393.0\um\x64" /LIBPATH:"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\ amd64" /LIBPATH:"C:\ponyc\ponyc\bin" /LIBPATH:"C:\ponyc\ponyc\bin\..

22:06 <triangle345> looks like some of it got cut off

22:07 <doublec> can you pastebin it?

22:08 <triangle345> http://pastebin.com/mr55nehv

22:08 <triangle345> can you see that

22:08 <triangle345> wierd thing is it put shell32 in qoute

22:08 <triangle345> qoutes

22:08 <doublec> hmm, is there a shell32.lib anyway?

22:09 <triangle345> so if i mistype that like do "she32" it gives me a different error

22:09 <triangle345> so it must be finding it

22:10 <Praetonus> triangle345: To find the real symbol name, you can create a C program wich uses the function and look at the assembly code generated

22:10 <doublec> triangle345: try calling the function: ShellExecuteA

22:10 <doublec> triangle345: Windows has a A and W version of the functions IIRC

22:10 <doublec> (for ascii and wide strings)

22:11 <triangle345> ohh

22:11 <triangle345> that worked

22:11 <triangle345> thanks!

22:11 <triangle345> how did you find that name out?

22:11 <doublec> triangle345: see the bottom of https://msdn.microsoft.com/en-us/library/windows/desktop/bb762153%28v=vs.85%29.aspx

22:12 <doublec> triangle345: where the table has "Unicode and ascii names"

22:12 <doublec> And I recall vaguely dealing with it when I used win32 years ago

22:13 <doublec> The win32 headers makes ShellExecute a C #define that goes to the A or W version depending on various things

22:13 <triangle345> ah i see

22:16 <jemc> ah, preprocessor macros as public API - the bane of FFI development

22:16 <CcxCZ> triangle345: That's why I suggested using introspection tool. :P

22:17 <jemc> its worst when the function or struct behind the macro isn't supposed to be a part of the public API, so you can't depend on it being stable >_<

22:17 <doublec> Or when it replaces some other usage that happens to clash with the macro name but would have been fine if it was just a function

22:23 <jemc> it's getting better, at least though - in the age of a billion languages many modern C libraries have chosen to make their APIs more friendly for FFI usage

22:23 <jemc> things like functions to look up the meaning of C constants, or lookup string error messages, etc

22:25 <Praetonus> Maybe we could expand ponyc to parse C headers with libClang or something, and make the C declarations available to FFI

22:25 <doublec> That'd be neat!

22:32 <triangle345> thanks for the help guys! btw, that is a good idea with the clang lookup