@kas ob:
ehmm... with
self, I mean
not the Delphi keyword in Context of Classes/Records.
with self, I mean the internal working Design of Microsoft Windows.
Like himitsu said - it could be for "self" managed Code (
COM+).
I am lost here, i don't understand this point or how it is relevant to raising an
exception.
Notice that,
exception are raised by an interrupt instruction, meaning it have standard way to raise, this doesn't have anything to do the
OS (Windows/Linux...) it is standard by hardware, were the
OS Kernel should have installed its debugger to capture/receive these hardware generated interrupt.
That was one, and second is notice how Delphi raise the
Exception, we create a class then we pass the class to specific procedure to raise it, we don't call any element of that class.
Code:
type
TMyException = class(
Exception)
end;
var
MyExcept: TMyException;
begin
MyExcept.Create('Error Message');
// we do
raise MyExcept;
// and there is no way to raise it from within like
MyExcept.raise;
end.
If we could do MyExcept.Raise then we should pass the except as self here, but we do raise MyExcept, which take a parameter to the System._RaiseExcept which has hidden way (aka compiler magic) to fill the parameter with the
exception class, meaning it is declared as such
Code:
procedure RaiseExcept(Obj: TObject);
The fact we pass the created
exception as parameter is merely a coincidence.
And I can bet, that Microsoft have a secret Layer'ed File with Numbers (I pointed: 2 ^64 = 18 Trillion GiBytes dataflow. So, each managed Type becomes a (
GUID) Number, and as such, all the Component(s) are different and can directly accessed. Instead to use String like in Delphi, and C++ Builder Debug Symbols.
In older Window's, the
DLL Functions could be called by Value, and Name.
Also don't understand this,
GUID for
COM literally stored in specific Windows format standardized with specific
VMT, so we have what we can call a class but it is a bunch of linked look-up tables each have its own
GUID stored in central table for that created class, so no secret
DB for them, just a service belongs to the
OS have the control over the registration for these
COM/
DCOM, and fill the data in the registry, in readable way.
Also these strings in Delphi are the same in other languages (eg. C#..), in all cases these
GUID strings will be translated into bytes from their hex values, into the specific structure to be read then looked up.
So if you use a hex editor/viewer on an application, you will not find any string like these
GUID in an interface, but you will find the HEX values for them.