Comment Re:The most important concept in WinSxS (Score 1) 433
I ended up creating a blog for this: Everything you Never Wanted to Know about WinSxS. It's too long for stackoverflow, but the docforge suggestion sounds interesting...
I ended up creating a blog for this: Everything you Never Wanted to Know about WinSxS. It's too long for stackoverflow, but the docforge suggestion sounds interesting...
Perfect. It should be there later today.
Hands up anyone who knows what an "activation context" is! If you don't you have no idea what WinSxS does, how it does it or how to diagnose it when it goes wrong.
In my opinion, WinSxS is a good mechanism, or at least as good as Microsoft could have made it while working within the constraints of history. However, WinSxS cannot be used in the real world without properly understanding it, and achieving that understanding is very painful indeed. The MSDN documentation is piecemeal, appears incomplete and inaccurate in a few places and lacks a proper overview. I think the only reason I properly twigged what activation contexts are about is that I had recently written a mechanism that operated on similar principles (a thread-local stack of context-related information).
I wrote a Wiki page at work describing what (I think) WinSxS's motivation is, how it works and some of the problems it suffers from. I'd like to put it somewhere on the public internet - any suggestions? It should ideally be somewhere wiki-like where people can correct its inevitable inaccuracies without me having to maintain it, but I'm not sure it's appropriate for wikipedia.
I'm assuming this was due to a typo on the first line (and presumably no code reviews). With memcpy_s and the same development practices, this would most likely become:
char *buffer = malloc(200);
memcpy(buffer,2000,message,2000);
send_message(buffer);
free(buffer);
, which would behave exactly the same and illustrate the point many people here are making about this really not fixing the supposed insecurity. The reason the code you show crashed is not that memcpy takes no destination size parameter. The reason is that the code contained an obvious typo that nobody noticed because there were no formal code reviews.
I don't know about you, but if I evacuate without instruction from management, it counts against my vacation time.
That's rough, man. I get to go to the toilet whenever I please.
The article is very difficult to read, due to poor English (no offense meant - I don't speak a word of Portuguese!) However, having waded through it, it is clear the parent is correct, and the summary is completely wrong.
The article's author is resigning from the ABNT, specifically because it is not appealing. It is only "protesting", whatever that means. The article claims the failure to appeal is due to Microsoft supporters claiming they did not have enough time to weigh the arguments, which sounds a bit rich in the circumstances.
"No matter where you go, there you are..." -- Buckaroo Banzai