From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) by hurricane.the-brannons.com (Postfix) with ESMTPS id B665877DC1 for ; Fri, 1 Jan 2016 11:31:13 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id b14so114005165wmb.1 for ; Fri, 01 Jan 2016 11:31:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=DJPnspAxsS2chqdrP4gZ1OmbqbRFh8nrTVWzpQZxTH8=; b=QvvxVkkihxRNvxuNpS+E6oBxz4AyOGGubD8NYEtB+XOHDx8R3IccaseFs0UnjamvKk hVpoCg9nEmVhqDbgwrdy9T2pSEmRbSf0XBzsVVxLVH9F44pbAVkeeyB/Vu0hy1U6/KnK LFJdzhhYLAOIZZzs6oQ4EObSvaY14Wfq7beix5UAQCSwH5FTDLNePKhXBWCqgwIAJha7 Qwlr/1kYx/uxuhXQAzQaMEpJgg7dgZ+ctd7T2UmR20+Az1XVow6U3OMkrluYtm71EO9s BHUjTucUYiurZXmVcONM8M8CmZiq/2GSJbG09N0BaYNlrXaffwrEG9xfZFMCJJW3zRhV Ud6w== X-Received: by 10.194.179.162 with SMTP id dh2mr83184511wjc.17.1451676703551; Fri, 01 Jan 2016 11:31:43 -0800 (PST) Received: from 122oven.adamthompson.me.uk (c.2.2.f.4.7.e.f.f.f.d.1.4.2.2.0.2.4.0.9.2.4.1.1.0.b.8.0.1.0.0.2.ip6.arpa. [2001:8b0:1142:9042:224:1dff:fe74:f22c]) by smtp.gmail.com with ESMTPSA id w4sm74657668wje.49.2016.01.01.11.31.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jan 2016 11:31:42 -0800 (PST) Date: Fri, 1 Jan 2016 19:31:41 +0000 From: Adam Thompson To: Geoff McLane Cc: Karl Dahlke , Edbrowse-dev@lists.the-brannons.com Message-ID: <20160101193141.GE12402@122oven.adamthompson.me.uk> References: <20151130125742.eklhad@comcast.net> <20160101142238.GB24842@122oven.adamthompson.me.uk> <20160001100135.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="19uQFt6ulqmgNgg1" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Subject: Re: [Edbrowse-dev] Ports X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2016 19:31:14 -0000 --19uQFt6ulqmgNgg1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 01, 2016 at 08:09:10PM +0100, Geoff McLane wrote: > Hi Karl, Adam, >=20 > Well I think pipes and sockets seem certainly the most > practical cross-platform IPC mechanisms... I agree with that and if we were doing a traditional client server I'd go d= own that route for sure. > Pipes seems to have less difference in that only perhaps > a few #ifdef WIN32 are required, if any, in a cross-compile... But multiple processes can't monitor a pipe as far as I know. > Sockets definitely does require a number of #ifdef WIN32, > but not really excessive... many can be handled as MACROS... > and the cross-porting has been done MANY times... in lots > and lots of libraries, apps, utilities, so is sort of very > mature... getting easy even... I wonder if what we actually should be doing is looking for a cross-platfor= m IPC lib? > But reading up a little on MSDN, and remembering, the > following IPC mechanisms are available in Windows, but > for sure some are **WINDOWS ONLY**! >=20 > 1. Clipboard/DDE - can agree a format then do copy/paste Yuck, is that really done within apps? > 2. COM - OLE manage compound document interface =2E.. ouch! That's gonna be ifdef hell. > 3. Data Copy - Using Windows messaging - WM_COPYDATA Don't know about this, sounds potentially interesting though. > 4. RPC - have only ever used it over sockets... Yeah, usually a socket technology as far as I know. > 5. File Mapping or shared memory mapping - just put data Unix has this via mmap, never used it for IPC but I've used it for other th= ings. There'll be sync issues this way, lots of 'em. I know apps do IPC this way, and successfully though. > 6. Pipes and Sockets - are cross-platform... Yep. > Not sure which of these would fit "domain sockets", but maybe > I missed something else available... having coded and used > most of them, in various apps, at various time, I am not sure > which I would choose as the most 'generic' to Windows... How about named pipes? I just looked them up on msdn and it looks like we c= ould may be do that. I'm not sure if it's directly equivalent to unix domain soc= kets or may be the unix equivalent is more like a fifo, but either way that'd wo= rk. Actually fifos would work quite nicely. Edbrowse-curl, per user, monitors an input fifo, then creates output fifos for each connected edbrowse instance. That way we can have $tmpdir/edbrowse/$user/edbrowse-curl/input and then numbered output fifos. > I am sure unix has some form of shared memory mapping (5)... just > copy a data block using a simple memory pointer would probably be > the fastest... but requires that the partner be monitoring that > space, polling... and what about thread safety? and maybe needs > some/many #ifdef to account for the differences... Yeah as I said above, certainly possible but the synchronisation issues wil= l be awkward, and there're probably differences as well as you point out. > But as Karl mentions he has already shown 6. Pipes and Sockets > both work... with no porting issues that I know of... Agreed. > Concerning sockets, over the years I have collected some tcp, > udp samples, and this is where I added and tested Karl's > socket.c - and pushed them all to my 'new' tcp-tests repo - >=20 > https://github.com/geoffmcl/tcp-tests >=20 > See src/ebsocket.c... compiles without even a warning both > in WIN32 and UNIX... still to do a WIN64 compile... and > maybe a MinGW compile... sockets are fun ;=3D)) and really > now quite an old technology that has not been replaced... Ok, not to forget cygwin... and the 32 and 64 bit versions of those, though I should imagine that we should be fine as long as we don't try runn= ing 64 bit libs on 32 bit Windows. =2E.. fun as you say. Cheers, Adam. PS: has any of this altered with Windows 10? --19uQFt6ulqmgNgg1 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWhtQdAAoJELZ22lNQBzHOmKQH/RBdpWYORmjn2X2rP0vzS0cn QuVQH7j1O50WjdoXD4dCYNRH+tA3GOilGGyT26gjSs2Ia5OXD2QA6UpMln6WSdZJ HnVn3dQ6JpcLKpKeLcuGrqOT42n/wln/36ztmg5CwjfyhJ6+5vd35Ujdvr9wsZkq M+YGDi5pXdkbqwFyoVhlsofKUvVPDqNPH087Ug8ZX+RxgCs96t9zHF2tgXDoHN9o M8ujfKF1/PY3GVwvmjtyKGttZWCBFns1VRUrJZSKaDxvYLLjtrcxVUk6OvA2SLoa RtAhL1pCZYZ3zB/bAsIDDt9XSqIGjfRNxirh2wWPMQHdT5CZfvxj4UoyfT3wAhU= =ZBQY -----END PGP SIGNATURE----- --19uQFt6ulqmgNgg1--