In Asm-Prozedur eine Exception auslösen

[Kas Ob.]

Zitat von paule32.jk:

@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.

Zitat von paule32.jk:

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.