Fun fact about BSTR, it uses memory before the string pointer to store the length.
From the CComBSTR documentation from microsoft: "The CComBSTR class is a wrapper for BSTRs, which are length-prefixed strings. The length is stored as an integer at the memory location preceding the data in the string.
A BSTR is null-terminated after the last counted character but may also contain null characters embedded within the string. The string length is determined by the character count, not the first null character." https://learn.microsoft.com/en-us/cpp/atl/reference/ccombstr...
From the book ATL internals that I read about 24 years ago.
"Minor Rant on BSTRs, Embedded NUL Characters in Strings, and Life in General
From the book ATL internals that i read about 24 years ago.
The compiler considers the types BSTR and OLECHAR* to be synonymous. In fact, the BSTR symbol is simply a typedef for OLECHAR. For example, from wtypes.h:
typedef / [wire_marshal] / OLECHAR __RPC_FAR BSTR;
This is more than somewhat brain damaged. An arbitrary BSTR is not an OLECHAR, and an arbitrary OLECHAR is not a BSTR. One is often misled on this regard because frequently a BSTR works just fine as an OLECHAR *.
STDMETHODIMP SomeClass::put_Name (LPCOLESTR pName) ; BSTR bstrInput = ... pObj->put_Name (bstrInput) ; // This works just fine... usually SysFreeString (bstrInput) ;
In the previous example, because the bstrInput argument is defined to be a BSTR, it can contain embedded NUL characters within the string. The put_Name method, which expects a LPCOLESTR (a NUL-character-terminated string), will probably save only the characters preceding the first embedded NUL character. In other words, it will cut the string short."
I wont link to the pirated edition which is never than the one I read.
So if there is code in outlook that relies on the preceding bytes being the string length it can be the cause of the memory corruption. It would require a sesssion in the debugger to figure it out.
Because he showed the action fps was possible on limited hardware. Also he has had some good ideas in the software- design and architecture of Wolfenstein, Doom and Quake, that where apparent when he open sourced their engines.
I'm dumbstruck that Crowstrike exists with George Kurtz still at the helm. There is no accountability at all. Kurtz was CTO of McAfee when their update caused back in 2010. Why does these things keep following him?
I've turned off my history on all logged in profiles, to get YouTube not giving me recommendations! I had a constant humm of YouTube content in my background during work. So when I was offered due to the EU to turn off my recommendations by turning off history I grabbed the offer. It is just enough for me to make my YouTube consumption intentional and avoid it. I've experimented with having a non-logged in browser with recommendations but occasionally it manages to find my poison, so after I nuke the cookies it is back to intentional usage of YouTube there too. Because the worst part of the YouTube, it gives you useful stuff that improves your life, but it also just sucks you into a black hole of content.
Also it is true that these things with procrastination and addictive behaviors are very much emotional issues and so on... and in my case whenever I notice that I'm avoiding dealing with my emotions and the hard stuff with YouTube content black holes I do the resets.
I'm old as dirt but I recall one of the arguments for TPM was shoved down our throats was the ability to tie documents to machines and organizations. Something something... industrial espionage. Now we know that is a lie. They just wanted to fill landfills with old working computers.
A crypto library is "essential complexity" and running a node.js runtime inside a container in kubernetes node in a virtual machine on a server owned by a hyperscalar cloudprovider is "accidental complexity". I'll take the crypto library any day of the week but if I get to decide how to host a webapplication I'll stay away from that fragile tower of abstractions. As it happens I currently make a living from that "accidental complexity" so it is not a matter of skill, I just see it as unnecessary.
When skimming through the report I got to think of the oscillation problem in RIP routing protocol. Although it isn't the same thing, but it shows the complexity of the problem to anyone who thinks there is a single solution to it.
I've harped on this before: the problem is that the ads if they are fraudulent or harmful in other ways and the companies making money when presenting deserve get their shit blocked. Especially if they can target ads to vulnerable people. These are huge profitable companies that moderate the content they profit of but as soon as someone pays them they turn the blind eye.
Yep, it's a straight up safety issue with all the scam ads. I pay for YouTube premium but sometimes my parents and grandparents don't log in, accidentally sign out, watch it on the browsers, etc that it's safer to block them all. It only takes one to get through and gen AI is not helping.
From the CComBSTR documentation from microsoft: "The CComBSTR class is a wrapper for BSTRs, which are length-prefixed strings. The length is stored as an integer at the memory location preceding the data in the string. A BSTR is null-terminated after the last counted character but may also contain null characters embedded within the string. The string length is determined by the character count, not the first null character." https://learn.microsoft.com/en-us/cpp/atl/reference/ccombstr...
From the book ATL internals that I read about 24 years ago.
"Minor Rant on BSTRs, Embedded NUL Characters in Strings, and Life in General From the book ATL internals that i read about 24 years ago.
The compiler considers the types BSTR and OLECHAR* to be synonymous. In fact, the BSTR symbol is simply a typedef for OLECHAR. For example, from wtypes.h: typedef / [wire_marshal] / OLECHAR __RPC_FAR BSTR;
This is more than somewhat brain damaged. An arbitrary BSTR is not an OLECHAR, and an arbitrary OLECHAR is not a BSTR. One is often misled on this regard because frequently a BSTR works just fine as an OLECHAR *.
STDMETHODIMP SomeClass::put_Name (LPCOLESTR pName) ; BSTR bstrInput = ... pObj->put_Name (bstrInput) ; // This works just fine... usually SysFreeString (bstrInput) ;
In the previous example, because the bstrInput argument is defined to be a BSTR, it can contain embedded NUL characters within the string. The put_Name method, which expects a LPCOLESTR (a NUL-character-terminated string), will probably save only the characters preceding the first embedded NUL character. In other words, it will cut the string short."
I wont link to the pirated edition which is never than the one I read.
So if there is code in outlook that relies on the preceding bytes being the string length it can be the cause of the memory corruption. It would require a sesssion in the debugger to figure it out.