Earlier quoted context omitted.
Earlier in my life I did a lot of Windows system-level programming, including some minor driver development, and now I'm practically exclusively on the #nix bunch, sometimes doing similar stuff. I can't say that there is a disparity. If anything, the parts that are documented are usually better documented in the Windows world, and there are very good books about most components. (To be fair I never read a book on any…
I've never done kernel work on Windows but on Linux at least you can dig into the source code to figure out how stuff works when the documentation is lacking. I suppose that's what the parent was talking about.
Microsoft open-sources Graph Engine
31–40 of 192 posts
Re: Microsoft open-sources Graph Engine
#32Am I the only one getting SSL cert authority invalid error
*Edit: checking the site on my phone now and it seems to load, pretty poorly designed site though IMO, unbalanced layout but at least it loads now.
Re: Microsoft open-sources Graph Engine
#33Am I the only one getting SSL cert authority invalid error
Re: Microsoft open-sources Graph Engine
#34Seems to be just a marketing page with no link to source code or even mention of open source? Here is the github page: https://github.com/Microsoft/GraphEngine
Re: Microsoft open-sources Graph Engine
#35Re: Microsoft open-sources Graph Engine
#36At this rate, are we going to see Windows open-sourced? MS is on a roll. My bias since 1996 is being eroded with each OSS release they have, and multi-platform targeted support. I started using VSCode regularly as my main Rust IDE, and I feel dirty for liking it. It's seemless across macOS and Linux.
I am under the impression that MS has a lot of different parts, and that these parts have different cultures and goals. MS Research and their developer division seem really open-source-friendly, but that may or may not say anything about their OS team.
Re: Microsoft open-sources Graph Engine
#37Re: Microsoft open-sources Graph Engine
#38Re: Microsoft open-sources Graph Engine
#39Earlier quoted context omitted.
Not yet. Their next strategy is to try and use ARM (again) to shove UWP down your throat. I love Windows but I seriously will not touch UWP until they loosen up the sandbox restrictions so that I can do regular IPC with a win32 desktop app. You can't even send an HTTP request to a little node.js Web server running on your desktop right now. Fuck that. I'm not buying into it.
Care to elaborate on the HTTP part? You just need the "Internet (client)" capability in your manifest, it's even enabled by default when you create a new project Moreover, win32 desktop apps can use the AppService mechanism exposed by UWP apps (but cannot host an AppService themselves, just connect to UWP-hosted AppServices)
AppService is largely useless for IPC between UWP and Win32 since the UWP app can't initiate a request to the Win32 app.
Another thing you can't do, which is really annoying: UWP won't let your code start an external process and use standard i/o pipes to communicate with it.
The only possibility is to use files for IPC and you'd have to have your Win32 app listen for changes in the file or directory, then open it up and read the data. However UWP can't listen for changes in those same files, so it's a real PITA.
All of the options are listed here - http://stackoverflow.com/questions/12341707/communication-be...
You can also use a loopback exemption, but it requires installing a fake root certificate (no thanks!) - http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/Conf...
or
Re: Microsoft open-sources Graph Engine
#40I find that very abstract software packages like this are difficult to visualize without an example. This page does not offer one, but TFM does -- see [1]. Also note that TFM describes the fact that this is Windows-only. That makes it substantially less interesting, IMO. [1] https://www.graphengine.io/docs/manual/index.html#what-is-ge