Seeing that cmake is being used, its not too hard. When I compile on mingw64, the WIN32 micro is already set. Not om Cygwin, bit that's not a typical use case. By not too hard I mean about 1 hoir implementation, mostly reading. I can support if you want
Sent from my Windows 10 phone From: Joseph Southwell<mailto:[email protected]> Sent: Tuesday 30 May 2017 21:16 To: [email protected]<mailto:[email protected]> Subject: Re: Support external recv and send callbacks So, according to http://mono-list.ximian.narkive.com/lfOw5Ldl/mono-net-delegate-incompatibility MONO and .NET have different requirements on windows (one requires cdecl callbacks and the other requires stdcall). If that is still the case there isn’t really right answer without adding build options and that gets a little out of the area I am being paid to put effort into. > On May 28, 2017, at 3:19 PM, Jason Curl <[email protected]> > wrote: > > > On 25/05/2017 16:25, Joseph Southwell wrote: >> I found a flaw in this and will be resubmitting it. > If you're going to make callbacks public, any way to prefix them with > __stdcall? That would allow .NET to use the callbacks also [1], [2], with the > only solution I've seen in [3] that is not practical. > > It would mean having to add something like WINAPI to the header file for the > typedefs and if we're compiling on Windows then set it to __stdcall (note for > 64-bit this is ignored anyway and everything is __fastcall). > > e.g. > #if defined(WIN32) > #define WINAPI __stdcall > #else > #define WINAPI > #endif > > Note, you can't do that for the existing APIs, because that would cause > breakage. > > I haven't tested on Linux with Mono/dotnet, but I assume here one doesnt need > to worry. >> >>> On May 25, 2017, at 9:44 AM, Joseph Southwell <[email protected]> >>> wrote: >>> >>> This patch allows you to replace the calls to send and recv with alternate >>> callbacks. I am using this because I am running an event driven network >>> stack with stackfull coroutines in c++. This makes the whole thing appear >>> blocking to libssh while still sharing threads efficiently. Socket closure >>> is non blocking so I did not add a callback for that but if somebody wanted >>> to extend this to work with something that isn’t really sockets they would >>> need to add a close callback as well since ssh_disconnect calls close on >>> the socket fd. >>> <0001-got-external-io-working-in-libssh-client.patch> >> > [1] https://msdn.microsoft.com/en-us/library/aa288468(v=vs.71).aspx > [2] https://msdn.microsoft.com/en-us/library/ektebyzx.aspx > [3] > https://www.codeproject.com/Articles/12512/Using-the-CDECL-calling-convention-in-C-changing >
