As I said a while ago, Visual Studio 2015 appears to have lots of pretty serious bugs.
One that probably bites me more than many people is this Save As bug. If you have a project and you select a file in that project and do a “Save As” such that the target file is also in the project then the VS2015 IDE crashes.
I tweeted about this a while back, and the Visual Studio Program Manager, Cathy Sullivan, wanted me to create a new project and see if the problem happened with it… Not quite sure why she couldn’t do this herself, but anyway, here’s a zip of a project created with VS2015 where there’s a file called SaveMeAsTargetver.
As usual I have used VMs to play with the CTP releases for the new version of Visual Studio and fixed up new warnings and build failures in my source so that I’m not too surprised when the RTM comes along.
Unfortunately as soon as I put VS2015 RTM on my build server and started running it as part of my CI system I started noticing strange things…
The first is that it seems to be possible to get VS2015 into a state where it will refuse to load C++ projects.
Today I discovered that C++ scoped static initialisation (function level) in Visual Studio is not done in a thread safe manner. It’s the kind of thing that I should have already known but I guess I assumed that since namespace level static initialisation was safe so was function level static initialisation. Unfortunately it’s not. If you read the MSDN documentation in a particular way you could decide that the docs say that it’s not; but it’s imprecise and unclear and I doubt that I did read the MSDN documentation anyway.
I’ve been pretty happy with moving to Windows 8. I’ve got used to the “new” UI, it was a pretty painless transition once I learned the new shortcut keys and I actually think that the new “start menu” is better, you don’t have to worry about complicated trees of folders, it’s all flat and you just start typing the name of what you want… So for me, a developer with two monitors and no touch interface using the desktop pretty much as I always have done, Windows 8 works well.
There’s a gnarly networking question on stack overflow that I’ve since reposted on various Microsoft forums and so far I’ve had absolutely no useful response. Not even an “I don’t know, but I’ll look into it”.
I can understand that, perhaps, the issue may be a little bit technical for a support person who isn’t steeped in networking API knowledge; but where are the MVPs? Why isn’t there a Winsock MVP who can tell me that the bug has already been raised somewhere and might get fixed, or that it’s a known and desirable breaking change?
As I mentioned here, the WebSockets protocol is, at this point, a bit of a mess due to the evolution of the protocol and the fact that it’s being pulled in various directions by various interested parties. I’m just ranting about some of the things that I find annoying…
The WebSockets protocol includes a way for the endpoints to shut down the connection.
If an endpoint receives a Close frame and that endpoint did not previously send a Close frame, the endpoint MUST send a Close frame in response.
As I mentioned here, the WebSockets protocol is, at this point, a bit of a mess due to the evolution of the protocol and the fact that it’s being pulled in various directions by various interested parties. I’m just ranting about some of the things that I find annoying…
The WebSockets protocol is designed to be extended, which is all well and good. Extensions can, at present, be formally specified by RFCs or be “private use” extensions with names that are prefixed with an “x-”.
As I mentioned here, the WebSockets protocol is, at this point, a bit of a mess due to the evolution of the protocol and the fact that it’s being pulled in various directions by various interested parties. I’m just ranting about some of the things that I find annoying…
The client MUST mask all frames sent to the server. A server MUST close the connection upon receiving a frame with the MASK bit set to 0.
As I mentioned here, the WebSockets protocol is, at this point, a bit of a mess due to the evolution of the protocol and the fact that it’s being pulled in various directions by various interested parties. I’m just ranting about some of the things that I find annoying…
Back when binary frames were mentioned in the WebSocket protocol specification as a slightly hand wavy “something for the future” and only text frames were actually possible to send and receive using the clients at the time then there MAY (in the strictest RFC meaning of the word) have been a need to differentiate between text and binary frames.
As I mentioned here, the WebSockets protocol is, at this point, a bit of a mess due to the evolution of the protocol and the fact that it’s being pulled in various directions by various interested parties. I’m just ranting about some of the things that I find annoying…
The first thing to realise about the WebSockets protocol is that it isn’t really message based at all despite what the RFC claims.
