Re: Pirates of Silicon Valley

[Mike <moose@rocknet.net.au>]

Mike Pike wrote:

> Steve:
>
> all I can say is.... "Wow, you know you're shit!" :)
>
> someone who knows the inner-workings of the Win32 API as you do, and even
> posts example code has credibility in my book... hats off to ya...
>
> Glad to see someone here has some real knowledge and doesn't spout stuff
> off of the top of their head such as Mike O'Malley...

Well, Mike Pike, I was actually responding to rediculous and wildly inaccurate
rubbish that you spouted.

Yet, you continue to try and twist things around - you must be on some really
powerful drugs or something.  Amazing !

I can substantiate everything I have said.  And I don't need biased or prejudiced PC
or MAC links to do it.  Links to Cringeley's Triumph of the Nerds TV show transcript
prove everything I have said about Apple stealing the GUI.  The relevant transcript
section comes straight from video quotes shown of Steve Jobs.  And this is all
straight from a person who is a MAC-o-phile.

Check it out :
http://www.pbs.org/nerds/

Mike O'Malley

>
> Mike
>
> Steve Mentzer (!smentzer@ecom.net) wrote:
> : >
> : >        The Mac OS has lagged behind on >technicalities<, it actually works
> : >much better than Windows does with its many "features" most of the time.
> : >Even this is gap is being filled quickly, though, as the Mac OS leaps
> : >forward into the future and leaves Windows FAR, FAR behind (Memory
> : >Protection: http://www.MacKiDo.com/Myths/memoryprotection.html,
> : >Multitasking: http://www.MacKiDo.com/Myths/mt.html)
> : >
> :
> : I am so glad about you posting those links. I sent them to a couple of unix and
> : NT programmers in my department. They are still reading them, but all of them
> : said <in one way or another> "Where did you find this crap?"
> :
> : I will just highlight one section of the document...
> :
> :   "Much of windows messaging (like COM and OLE) just pass around pointers to
> :   each others memory. So they are protected, except where they share - and they
> :   have to share quite a bit"
> :
> : This is a load of crap. The writer obviously has NO knowledge of Win32
> : architecture, especially COM.
> :
> : If you have a program which calls a COM component (ActiveX/OLE run on COM), the
> : only way you can cause GPF's in the COM components address space is if that
> : component runs INPROC (which means it runs in the same process, hence the same
> : memory map/address space), and the only way to do that would be to know exactly
> : what address space the member data resides at. COM objects do not expose member
> : data. You can only access it via an interface method or property.
> :
> : If the component is a Local or Remote server, it runs in it's own process
> : (hence it gets it's own address space). When accessing methods on the
> : component, a proxy-stub interface is called, which marshalls the data across
> : the network (wire, cross-process).
> :
> : It has never and will never be acceptance to pass pointers to non-standard type
> : data across COM boundaries. And if you have non-standard data that you want
> : to pass across a COM call, then you can write a custom marshalling routine
> : to handle it for you...
> :
> : Take this example (a property on a component)
> :
> : STDAPI        CSampleObj::put_TestString(/*[in]*/ BSTR bstrVal)
> : {
> :       if (bstrVal)
> :       {
> :               m_bstrTestString = SysAllocString(bstrVal);
> :               return S_OK;
> :       }
> :       else
> :               return E_INVALIDARG;
> :
> : };
> :
> : STDAPI CSampleObj::get_TestString(/*[in,out]*/ BSTR *bstrVal)
> : {
> :       *bstrVal = SysAllocString(m_bstrTestString);
> :       return S_OK;
> : }
> :
> :
> : This code example simply allows you to put and get the value for the property
> : "TestString" on a ActiveX/COM component.
> :
> : If this component was running INPROC (in the creators process), you would be
> : passing standard pointers of type (unsigned int*) to the method call (BSTR is
> : of type unsigned int*). But since you are running INPROC, it doesn't matter,
> : because it all shares the same address space..
> :
> : If the component was running OUT OF PROC (in it's own process either on the
> : local computer, or the remote computer), the proxy interface (which is created
> : for you automatically by the SCM) would do the following.
> :
> :       1 - Marshall all standard type data (BSTR) into a stream.
> :       2 - Pass that stream across an RPC to the remote object.
> :       3 - The remote object would then decode the stream and call the
> :           method locally.
> :
> : You see, for an OUT OF PROC component, there is NO way to directly access or
> : corrupt memory in it's address space. This is the beauty of COM.
> :
> : Creating an object remotely (runs in a remote machine process), or locally
> : inproc or locally outofproc) requires a simple change in calling sequence (and
> : some additional keys in the registry when you register the component)...
> :
> : To create this component in VB as a remote server requires no code changes,
> : only registry changes...
> :
> :       Dim objTest as Sample::SampleObj
> :       set objTest = new Sample::SampleObj
> :       msgbox Sample.TestString
> :       set objTest = nothing
> :
> : A simple registry tweak will change the context of its run....
> :
> : I know this was a long diatribe, but the author of that document doesn't have a
> : clue...
> :
> : smentzer@pacbell.net
> :
> :
> :
> :
> :
> :
> :
> :
> :
> :
> :