DLL-Aufruf kontrollieren

[Heinz-Mario Frühbeis]

Hallo!

Eine DLL (C) wird mit CreateObject aufgerufen aus einer anderen DLL(B) des
Programms(A).
Ich möchte gerne verhindern, daß ein anderes Programm die DLL (C) aufruft,
bzw. nutzt.

Welche Möglichkeiten kennt ihr um festzustellen, daß C auch tatsächlich von
B (und nur von B aus <!>) aus A aufgerufen wurde?

Mit Gruß
Heinz-Mario Frühbeis

[Lothar Geyer]

Hallo,

reicht es Dir, einen "geheimen" Parameter zu übergeben?

Oder definieren ein Interface und liefere die Interface-dll nicht mit
aus. Dann weiß niemand, dass es die Schnittstelle gibt und wie sie
aussieht (AFAIK).

Lothar Geyer

[Heinz-Mario Frühbeis]

"Lothar Geyer"...

> Hallo,
>
> reicht es Dir, einen "geheimen" Parameter zu übergeben?

Das ist eben die Sache; es soll nicht geheim sein.
Bsp.:
ProgA
DLL_A (quasi die Base)
DLL_B (z. Bsp. für Sektionen, oder Areale)
es soll/darf sogar eigene Sektionen/Areale (DLL_C) durch DLL_A mit verwaltet
werden.

Und ich suche eben nach einer eindeutigen Möglichkeit 100%ig davon ausgehen
zu können, daß auch wirklich meine_ Base (DLL_A) genutzt wird.
Bisher nutze ich ein CallBack bei der Initialisierung, aber wenn man mal die
Prozedur "raus" hat, dann kann man das bestimmt faken, da ja dafür min. eine
Klasse in DLL_A 'Public' ist.
Diesen Sicherheitspunkt möchte ich dann schon gerne auch
"Fremd"-Sektionen/Arealen anbieten.

> Oder definieren ein Interface und liefere die Interface-dll nicht mit aus.
> Dann weiß niemand, dass es die Schnittstelle gibt und wie sie aussieht
> (AFAIK).

Verstehe ich nicht ganz, aber überhaupt ... keine Verweise.

Mit Gruß
Heinz-Mario Frühbeis

[Lothar Geyer]

Guten Morgen,

Am 16.05.2012 21:53, schrieb Heinz-Mario Frühbeis:
> "Lothar Geyer"...
>> Hallo,
>>
>> reicht es Dir, einen "geheimen" Parameter zu übergeben?
>
> Das ist eben die Sache; es soll nicht geheim sein.
> Bsp.:
> ProgA
> DLL_A (quasi die Base)
> DLL_B (z. Bsp. für Sektionen, oder Areale)
> es soll/darf sogar eigene Sektionen/Areale (DLL_C) durch DLL_A mit
> verwaltet werden.
>
> Und ich suche eben nach einer eindeutigen Möglichkeit 100%ig davon
> ausgehen zu können, daß auch wirklich meine_ Base (DLL_A) genutzt wird.
> Bisher nutze ich ein CallBack bei der Initialisierung, aber wenn man mal
> die Prozedur "raus" hat, dann kann man das bestimmt faken, da ja dafür
> min. eine Klasse in DLL_A 'Public' ist.
> Diesen Sicherheitspunkt möchte ich dann schon gerne auch
> "Fremd"-Sektionen/Arealen anbieten.

Ehrlich gesagt weiß ich nicht, ob ich Dich richtig verstehe.

Warum legst Du die Objekte in DLL_A und DLL_B nicht in eine DLL?

>> Oder definieren ein Interface und liefere die Interface-dll nicht mit
>> aus. Dann weiß niemand, dass es die Schnittstelle gibt und wie sie
>> aussieht (AFAIK).
>
> Verstehe ich nicht ganz, aber überhaupt ... keine Verweise.

Du kannst für jede Klasse ein oder mehrere Interfaces definieren. Das
Interface kommt in eine eigene DLL. Diese DLL muss nicht ausgeliefert
werden. Damit weiß niemand etwas von diesem Interface und den sich darin
befindlichen Properties und Methoden - außer Dir.

Beispiel:

DLL_1/Klasse_1
--------------
Public Property Set tmStandort(tmStandort As clsStandort)
End Property

Public Property Set tmComputer(tmComputer As clsComputer)
End Property


DLL_2:Klasse_2
--------------
Implements Klasse_1

Public Property Set Klasse1_tmStandort(tmStandort As clsStandort)
Set m_Standort = tmStandort
End Property

Public Property Set Klasse1_tmComputer(tmComputer As clsComputer)
Set m_Computer = tmComputer
End Property

Public Property Set tmPlattform(tmPlattform As clsPlattform)
Set m_Plattform = tmPlattform
End Property

Die DLL_1 lieferst Du nicht aus, nur die DLL_2. Dann weiß niemand etwas
von den Properties tmStandort und tmComputer. Sie scheinen als Verweise
nicht auf, wohl aber die tmPlattform, da diese zum Standard-Interface
gehört. Auf Deinem Rechner ist die DLL_1 vorhanden und Deine IDE kann
darauf zugreifen. Auf einem anderen Rechner weiß die IDE nichts davon
und die beiden Properties tmStandort und tmComputer werden bei den
Verweisen nicht angezeigt, wohl aber tmPlattform.

Ich verwende so etwas für meine Lizenz-Routinen.

Lothar Geyer

[Heinz-Mario Frühbeis]

"Lothar Geyer"...

> Guten Morgen,
>
> Am 16.05.2012 21:53, schrieb Heinz-Mario Frühbeis:
>> "Lothar Geyer"...
>>> Hallo,
>>>
>>> reicht es Dir, einen "geheimen" Parameter zu übergeben?
>>
>> Das ist eben die Sache; es soll nicht geheim sein.
>> Bsp.:
>> ProgA
>> DLL_A (quasi die Base)
>> DLL_B (z. Bsp. für Sektionen, oder Areale)
>> es soll/darf sogar eigene Sektionen/Areale (DLL_C) durch DLL_A mit
>> verwaltet werden.
>>
>> Und ich suche eben nach einer eindeutigen Möglichkeit 100%ig davon
>> ausgehen zu können, daß auch wirklich meine_ Base (DLL_A) genutzt wird.
>> Bisher nutze ich ein CallBack bei der Initialisierung, aber wenn man mal
>> die Prozedur "raus" hat, dann kann man das bestimmt faken, da ja dafür
>> min. eine Klasse in DLL_A 'Public' ist.
>> Diesen Sicherheitspunkt möchte ich dann schon gerne auch
>> "Fremd"-Sektionen/Arealen anbieten.
>
> Ehrlich gesagt weiß ich nicht, ob ich Dich richtig verstehe.
>
> Warum legst Du die Objekte in DLL_A und DLL_B nicht in eine DLL?

DLL_A ist in diesem Bsp. die Base, die Verwaltung.
Ab DLL_B wäre eine Sektion.

Davon mal abgesehen:
DLL_A hat immo (ca.) 10 Module, 15 Klassen ... und dann den ganzen "Rest"
auch noch mit rein, nee?!
Weil das für eine DLL vllt. zu viel wird?
In einer DLL ist z. Bsp. die Sektion; in zwei anderen sind jeweils Areale
für die Sektion.
Bei meinem Listview-Areal kommt alleine schon einiges zusammen.

Mittlerweile glaube ich aber, daß es nicht geht, wie ich es mir vorstelle.
Der Beginn müßte Statisch sein ... das ist er aber nicht ... sondern Public.
Ich versuche es zur Laufzeit auszuklabüsern.
Vllt. ginge es, wenn auf der HD (oder sonst wo) ein Prog-ROM wäre .. was
100%ig nur vom Prog.hersteller geflasht werden kann, oder es könnte auch
eine Datei sein, die 100%ig nur vom Prog.hersteller geöffnet werden kann.

Aber dabei ist man schon wieder bei 100%, die vllt. nie 100% sind.
Ich versuche es zur Laufzeit auszuklabüsern.

Und ich verwende keine Verweise ...

Mit Gruß
Heinz-Mario Frühbeis

[Lothar Geyer]

Hi,

Am 17.05.2012 10:41, schrieb Heinz-Mario Frühbeis:
> ...

> DLL_A ist in diesem Bsp. die Base, die Verwaltung.
> Ab DLL_B wäre eine Sektion.

Vielleicht kann ich mir mehr vorstellen, wenn Du mal schreiben würdest,
was verwaltet wird bzw. was eine Sektion, ein Areal usw. ist. Und
welcher Zugriff für wen nicht möglich sein soll.

> Davon mal abgesehen:
> DLL_A hat immo (ca.) 10 Module, 15 Klassen ... und dann den ganzen
> "Rest" auch noch mit rein, nee?!

Was spricht dagegen?

> Weil das für eine DLL vllt. zu viel wird?
> In einer DLL ist z. Bsp. die Sektion; in zwei anderen sind jeweils
> Areale für die Sektion.
> Bei meinem Listview-Areal kommt alleine schon einiges zusammen.

Mir ist nicht bewusst, dass es irgendeine Beschränkung bei den DLLs gäbe.

Lothar Geyer

[Heinz-Mario Frühbeis]

Hallo!

"Lothar Geyer"...

> Hi,
>
> Am 17.05.2012 10:41, schrieb Heinz-Mario Frühbeis:
>> ...
>> DLL_A ist in diesem Bsp. die Base, die Verwaltung.
>> Ab DLL_B wäre eine Sektion.
>
> Vielleicht kann ich mir mehr vorstellen, wenn Du mal schreiben würdest,
> was verwaltet wird bzw. was eine Sektion, ein Areal usw. ist. Und welcher
> Zugriff für wen nicht möglich sein soll.

Eine Sektion ist dem Desktop untergeordnet und einem Areal übergeordnet.

>> Davon mal abgesehen:
>> DLL_A hat immo (ca.) 10 Module, 15 Klassen ... und dann den ganzen
>> "Rest" auch noch mit rein, nee?!
>
> Was spricht dagegen?

A) Nee <schüttel>, das ist total und voll unübersichtlich.
B) Es soll ja die Möglichkeit bestehen eigene DLL's (z. Bsp. für Sektionen
und Areale) mit einbinden zu können.

>> Weil das für eine DLL vllt. zu viel wird?
>> In einer DLL ist z. Bsp. die Sektion; in zwei anderen sind jeweils
>> Areale für die Sektion.
>> Bei meinem Listview-Areal kommt alleine schon einiges zusammen.
>
> Mir ist nicht bewusst, dass es irgendeine Beschränkung bei den DLLs gäbe.

Hauptsächlich geht es ja um B) ... und das wird durch die "DLL_A" eben
verwaltet (Init, Laden, Speichern, Öffnen, Schließen, Editieren,
Terminieren, etc. ... eben die Kommunikation zwischen den einzelnen
Programmteilen).
In DLL_A ist dafür eine "offene" Klasse, die eine Prozedur hat, die mit zwei
privaten Idents angesprochen wird (Sender, Empfänger).

Anbei:
Bei mir habe ich den einzelnen Programmteilen immer eine "Public Not
Creatable-Klasse", die als Schnittstelle "reingereicht" wird ... damit
brauche ich keine Verweise.
Der Casus Knacktus ist eben das "absolut beginning" und da kriegt man wohl
zunächst keine eindeutige, salopp gesagt, "Freund/Feind-Erkennung" hin, das
muss wohl mit dem Programmablauf wachsen.

Mit Gruß
Heinz-Mario Frühbeis

[Schmidt]

Am 17.05.2012 10:59, schrieb Lothar Geyer:

> Am 17.05.2012 10:41, schrieb Heinz-Mario Frühbeis:
>> ...
>> DLL_A ist in diesem Bsp. die Base, die Verwaltung.
>> Ab DLL_B wäre eine Sektion.
>
> Vielleicht kann ich mir mehr vorstellen, wenn Du mal schreiben würdest,
> was verwaltet wird bzw. was eine Sektion, ein Areal usw. ist. Und
> welcher Zugriff für wen nicht möglich sein soll.

Wie ich es verstehe, schreibt Heinz-Mario an einem
(streng geheimen) "Full-Screen-Ersatz für den Windows-Desktop"...
In seiner Terminologie ist das "ein Betriebssystem".

Er benutzt dazu eine "Base"(-Dll), welche die grundlegenden
Erfordernisse von Fenstern *auf* dieser "FullScreen-Desktop-
Base" abdeckt... Diese auf seiner "Base"-Desktop-Fläche
verschiebbaren "TopLevel-Rechtecke" sind in seiner
Hierarchie-Terminologie "Sektionen" (also vergleichbar
mit normalen, übergeordneten Applikations-Parent-Fenstern).

"Areale" sind dann Controls bzw. Widgets *in* bzw. auf
diesen "übergeordneten Parent-Sektionen".


Also im Prinzip:
"Base" (-Fullscreen-Desktop)
"Sektionen" (App-ähnliche Fenster auf Desktop)
"Areale" (Controls/Widgets auf Sektions-Fenstern)

Da die ganze "Desktop-Simulation" nun aber eigentlich
in nur einem (singlethreaded) Prozess abläuft...
(kleiner HostProzess lädt Base-Dll und zeigt den
leeren Desktop)
und dennoch ein "Betriebssystem" sein will ...
(mit vom User beisteuerbaren Applikations-Binaries) -
sollen diese "User-Apps" in Dlls - und nicht als
in unabhängigen Prozessen aufstartbare *.exe - vorliegen.

Seine DLL_A ist also die den Desktop bereitstellende "Base".
Die "User-Apps" wären dann also seine DLL_C-Varianten.
Das "Betriebssystem" kommt aber auch mit eingebauten
"Applikationen" - gekapselt in seinen eigenen DLL_B Varianten.

Dass der ganze Ansatz irgendwie fraglich und "wackelig"
scheint (crash in einer User-Dll_C-App reisst den ganzen
Desktop mit) - kein Task- bzw. Thread-switching zwischen
unabhängigen, parallel laufenden Prozessen usw...
sei jetzt mal dahingestellt.

Was jetzt (IMO) angestrebt wird ist, dass seine *eigenen*
Applikationen (gekapselt im DLL_B-Typ) *ausschließlich*
im Kontext *seines* Desktops (bereitgestellt von DLL_A)
laufen... und nicht etwa ("missbraucht" als Control)
im Kontext anderer Applikationen (anderer Prozesse).

Also so in etwa stell ich mir das Ganze vor...


@Hein-Mario
Bitte um Korrektur, wenn ich da oben irgendwas falsch
interpretiert haben sollte.

Zwecks Sicherstellung Deines Wunsches (zumindest die eigenen
Dll_B-Varianten laufen ausschließlich im Kontext von
Base-Dll_A) ... da gäbe es unterschiedlichste Varianten -
die Einfachste wäre wahrscheinlich die Implementierung
eines CRAM-Mechanismus (Challenge-Response-Verfahren):
http://de.wikipedia.org/wiki/CRAM-MD5

Das hieße, die DLL_B- und DLL_C- Varianten müssten
sich bei DLL_A (Deinem "Server") im Zuge des Aufstartens
zunächst anmelden.

Wer sich nicht anmeldet, liefe dann entweder gar nicht,
oder nur in einem "reduzierten Modus".

Das erfolgreiche Aufstarten einer COM-Dll-Klasse lässt
sich ja in jedem Falle unterbinden, wenn man in der
entsprechenden Klasse im Class_Initialize einen
nichtbehandelten Fehler auslöst, z.B. prinzipiell so:

Private Sub Class_Initialize() 'in DLL_B/DLL_C Classes

If Not CreateObject("DLL_A.cAuth").CRAMMD5(...) Then
Err.Raise vbObjectError, , "Auth failed"
End If

End Sub

Olaf

[Heinz-Mario Frühbeis]

"Schmidt"...

> Da die ganze "Desktop-Simulation" nun aber eigentlich

Man lernt halt dazu ...

> in nur einem (singlethreaded) Prozess abläuft...
> (kleiner HostProzess lädt Base-Dll und zeigt den
> leeren Desktop)
> und dennoch ein "Betriebssystem" sein will ...

Wer hat behauptet, daß das_ schon ein BS ist?
Nicht unverschämt werden ...; du mit deinen Fähigkeiten und "_deinem_"
'Cairo' könntest schon mehr erreicht haben.

> (mit vom User beisteuerbaren Applikations-Binaries) -
> sollen diese "User-Apps" in Dlls - und nicht als
> in unabhängigen Prozessen aufstartbare *.exe - vorliegen.

Einzelne Programmteile könnten rein theoretisch auch als Exe vorhanden sein
und wäre mir vom Prinzip echt schnuppe.
Nur ... wenn ich mal fertig bin mit einem BS, dann wird es wohl gar keine
Installationen (jedenfalls im klassischen Sinne) mehr brauchen, sondern
lediglich ein 'Init'. Selbst tiefste, systemrelevante Veränderungen zur
Laufzeit sollten damit möglich sein.
Wie das im Einzelnen mit Multithreading funktioniert, weiß ich noch nicht;
wenn ich soweit bin wird man es bestimmt erfahren ...

> Dass der ganze Ansatz irgendwie fraglich und "wackelig"
> scheint (crash in einer User-Dll_C-App reisst den ganzen
> Desktop mit) - kein Task- bzw. Thread-switching zwischen
> unabhängigen, parallel laufenden Prozessen usw...
> sei jetzt mal dahingestellt.

W3, als Bs, hat auch mal so angefangen, oder nicht?

> @Hein-Mario
> Bitte um Korrektur, wenn ich da oben irgendwas falsch
> interpretiert haben sollte.

Im Prinzip ...

> Zwecks Sicherstellung Deines Wunsches (zumindest die eigenen
> Dll_B-Varianten laufen ausschließlich im Kontext von
> Base-Dll_A) ... da gäbe es unterschiedlichste Varianten -
> die Einfachste wäre wahrscheinlich die Implementierung
> eines CRAM-Mechanismus (Challenge-Response-Verfahren):
> http://de.wikipedia.org/wiki/CRAM-MD5

Kann ich mir durch den Kopf gehen lassen.
Im Grunde mache ich mit dem eigenen CallBack auch nichts anderes (und findet
auch bei 'Class_Initialize' statt), wobei das wohl noch einen Schritt
weitergeht ...; ich schau' ma'.

Mit Gruß
Heinz-Mario Frühbeis

[Schmidt]

Am 17.05.2012 19:42, schrieb Heinz-Mario Frühbeis:
> "Schmidt"...
>> Da die ganze "Desktop-Simulation" nun aber eigentlich
>
> Man lernt halt dazu ...
>
>> in nur einem (singlethreaded) Prozess abläuft...
>> (kleiner HostProzess lädt Base-Dll und zeigt den
>> leeren Desktop)
>> und dennoch ein "Betriebssystem" sein will ...
>
> Wer hat behauptet, daß das_ schon ein BS ist?

Ok, ich korrigiere:
"...und dennoch später mal ein BS *werden* will"

> Nicht unverschämt werden ...;
Das lag nicht in meiner Absicht, ich wollte
eigentlich nur erklären, was es mit Deinen
DLL_B und DLL_C Typen eigentlich auf sich hat -
und das selbige (derzeit) als Ersatz für richtige
Executables herhalten.

> du mit deinen Fähigkeiten und "_deinem_"
> 'Cairo' könntest schon mehr erreicht haben.

Nein, könnte ich nicht - meine freie Zeit die ich
da reinstecke ist leider begrenzt.

Und was ich mit meinen Libs versuche abzubilden, ist
nur ein alternatives GUI-Framework, adaptiert auf die
Belange von VB6 und dessen COM-Support. RC4 ist nur
ein COM-Wrapper ... cairo ist eine OpenSource-lib,
die ich nicht geschrieben habe, sie exisitert jedoch
plattform-unabhängig da in C implementiert - und hält
so den Weg offen für eine spätere, einfachere Portierung
der RC4-libs auf andere Betriebssysteme, da sich die
derzeitigen Berührungspunkte mit dem Windows-OS-API
(was die Grafik und die WidgetControls betrifft) im
Prinzip nur auf das Abgreifen von Maus u. KeyEvents,
sowie ein Blt-API beschränken.

Ein Betriebssystem will ich also (Gott bewahre)
nicht entwickeln - vor allem weil es bereits
genügend klasse funktionierende (OpenSource)-BS
gibt auf diesem Planeten.

Hast Du überhaupt eine Ahnung, was derzeit in z.B.
Linux für Mannjahre an Aufwand stecken?
Aus dieser relativ frischen Meldung:

>
http://www.heise.de/open/meldung/Millennium-Technology-Prize-fuer-Linus-Torvalds-1543593.html

...lässt sich entnehmen, dass es sich in dem Fall um inzwischen
73.000 Mannjahre handelt, geleistet in Summe von einer
Community - und (logischerweise) nicht von einer Einzelperson.

Und die Sourcen des Linux-Projekts decken nur den Kernel
ab (also die grundlegenden IO- und Scheduling-Routinen,
die alles zusammenhalten + die Driver-Schnittstellen +
die Driver-Implementierungen).

D.h. in diesen 73.000 Mannjahren ist noch nicht mal
ein GUI eingerechnet (diverse Window-Manager-Projekte +
diverse GUI-Frameworks wie GTK+ oder QT) und ebenfalls
nicht die grundlegenden Basis-Applikationen (wie z.B.
die diversen Browser, File-Manager und was weiss ich alles).

Das heisst im Klartext, dass Du Dein Ziel im Alleingang
nie und nimmer erreichen *kannst*.

Zumal Du völlig falsch angefangen hast IMO - Du kannst
ein Betriebssystem nicht vom GUI her aufzäumen, schon
gar nicht dann, wenn dieses GUI zu 90% vom HighLevel-
User-API eines bereits exisitierenden OS abhängt, dessen
Sourcen nicht offenliegen.

D.h. wenn Du irgendwann mal den Punkt erreichen solltest,
wo Du von Deiner derzeitigen Win-API Grundlage abkoppeln
möchtest, müsstest Du Alternativen für all die WinAPIs
*schreiben*, die Du derzeit benutzt.

Aber auch dafür gibt es bereits ein Projekt (Wine) -
und ich bin sicher, auch da sind in Summe bereits hunderte
von Mannjahren reingeflossen.

Aber wie gesagt, selbst wenn Du es schaffen solltest
"mal eben" (in vielleicht nur 10 Jahren) einigermaßen
funktionierende Alternativen zu all den verwendeten
WinAPI-Implementierungen zu schreiben, bleiben immer
noch die rund 70.000 Mannjahre für einen ordentlichen
Kernel und all die Treiber-Implementierungen für
Grafikkarten, USB, Storage-Devices, Netzwerk-Karten,
WLAN usw.
Ganz zu schweigen von einem ordentlichen Compiler
(denn Du willst doch die Nutzer bzw. Entwickler für
Dein BS nicht dazu zwingen, sich ein Windows zu
installieren und eine VB6-Lizenz zu "besorgen")?

> Einzelne Programmteile könnten rein theoretisch auch
> als Exe vorhanden sein und wäre mir vom Prinzip echt schnuppe.

Theoretisch geht halt vieles - aber das ist doch die
Krux eines Betriebssystems - die Möglichkeit ein
Binary (heutzutage üblicherweise im Windows-eigenen
PE-Format bzw. im Unix-eigenen ELF-Format) zu parsen
und dann als (Scheduler-verwalteten) Prozess aufzustarten
bzw. extern liegende Zusatz-Bibliotheken dort hinein
nachzuladen.

Das heisst, Du müsstest bald mal damit anfangen,
zumindest Deine eigene Alternative zu ShellExecute
(zum Aufstarten von Prozessen) bzw. LoadLibrary
(zum Laden von Dlls) zu schreiben.

Das alleine ist schon komplex genug - macht jedoch
nur schätzungsweise ein 5.000-dstel des von Dir
sonst noch zu erbringenden Aufwands aus.

Lass mich mal rechnen - mal angenommen Du gibst Dir
noch 20 Jahre für Dein BS - das wären dann 7300 Tage.

Das heisst, um im Zeitplan zu bleiben, müsstest Du uns
schon morgen! zumindest mit einer selbstgeschriebenen
Alternative zu LoadLibrary/GetProcAddress usw.
versorgen können...
Kannst Du das?
Hast Du überhaupt eine Ahnung, was in diesen Calls
unter der Haube so alles abgeht?

> Nur ... wenn ich mal fertig bin mit einem BS,

Das wird definitiv nicht eintreten.
(da Du "ich" schreibst und nicht in der Mehrzahl,
ist das vom zu erbringenden Arbeitsaufwand her
einfach nicht zu schaffen).

>> Dass der ganze Ansatz irgendwie fraglich und "wackelig"
>> scheint (crash in einer User-Dll_C-App reisst den ganzen
>> Desktop mit) - kein Task- bzw. Thread-switching zwischen
>> unabhängigen, parallel laufenden Prozessen usw...
>> sei jetzt mal dahingestellt.
>
> W3, als Bs, hat auch mal so angefangen, oder nicht?

Ja, klar - aber ein BS auf "DOS-Level" willst Du doch
sicher nicht anbieten wollen - zumal auch dafür
zunächst ein Compiler, ein Filesystem, Treiber usw. geschrieben
sein wollen (die dann mit den *heutigen* modernen CPUs,
USB-Devices, Harddisks, Grafikkarten usw. zusammenspielen).

Aber selbst wenn das nur für eigene "experimentelle Zwecke"
geschrieben werden soll, *musst* Du Dich demnächst
mal mit Assembler oder zumindest C bechäftigen,
um überhaupt gegen ein aktuelles Motherboard-BIOS
einen erfolgreichen Bootvorgang, hinein in eine simple
Text-Konsole hinzubekommen.

Wenn Du schon daran scheitern solltest (an einem
einfachen blinkenden Prompt, der z.B. zunächst nix
anderes versteht, als eine einfache Aufforderung
zum listen von Dateien), dann kannst Du die Versuche
gleich ganz abbrechen, falls Du dazu länger brauchst
als - sagen wir mal - 1 Jahr.

Olaf

[Heinz-Mario Frühbeis]

"Schmidt"...

> Am 17.05.2012 19:42, schrieb Heinz-Mario Frühbeis:
>> "Schmidt"...

>> du mit deinen Fähigkeiten und "_deinem_"
>> 'Cairo' könntest schon mehr erreicht haben.
>
> Nein, könnte ich nicht - meine freie Zeit die ich
> da reinstecke ist leider begrenzt.

Könntest du wohl ...

[schnipp]

Ich habe nie behauptet, daß ich das heute* alleine schaffe; dafür ist die
Struktur (wie u. a. auch schon von dir umschrieben) viel zu weit
fortgeschritten.
Zu Linux kann ich (leider) nicht viel sagen, da ich es nur seltenst mal
gesehen, geschweige denn damit gearbeitet habe.
Zu meiner Schande führe ich dazu sogar an, daß ich mich damals verleiten
ließ durch die Einfachheit von VB, lindernd jedoch kann ich auch anführen,
daß vor Jahren auch einfach niemand da war der mir erklären konnte, daß es
besser sein kann (zumin. u. a.) auch C zu können. (Wobei die Welt damals mMn
auch noch eine ganz andere war.)

Was mir an Windows aufstößt ist, daß es ungenügend 'Privat' ist.
Bei Linux vermute ich das Gleiche.
M. E. besteht bei beiden Systemen die Möglichkeit durch einen kleinen_
illegalen Zugriff das gesamte System zu korrumpieren.
Bei dem System, wie ich es mir vorstelle, gäbe es z. Bsp. für einen
Stammbereich (wenn man so will eine Art Registry) keinen öffentlichen
Zugriff (oder eben zumindest bestmöglich gesichert).
Dieser Stammbereich wird auch nur intern in der Base und 'Privat' verwaltet
(u. a. als Kopie des Originals).
Ein Zugriff kann nur_ erfolgen, wenn Sender und Empfänger identifiziert
werden konnten. Sender und Empfänger sind absolut 'Privat'. Das kann sogar
soweit führen, daß Nachrichten quasi zurück erfragt werden.
Bei Fehlzugriff wird u. a. eine Meldung an einen Owner gesendet, die der
Owner dann 'Privat' verwalten kann (was mMn bis zu einem Shutdown führen
kann (wobei das Original zur Laufzeit wieder eingesetzt werden kann).
Es kann auch "nur" einzelne Bereiche betreffen (bis "hinunter" zum Areal),
da dort auch schon bei jedem Laden ein neuer 'Privater' Ident vergeben wird
und sollte einck zur Laufzeit zur Normalität zurückführen können.
Ein Hacken kann also mMn einzig durch generieren und testen von Idents
erfolgen, was von der Base realisiert und (als Info zum Owner) weitergegeben
wird.
Einzelne Programmteile können nur vom jeweiligen Owner (des Projektes) in
Kommunikation treten, ist aber möglich und funktioniert sogar im
Drag&Drop-Verfahren.
Es ist sogar möglich eigene Areale vollkommen 'Privat' zu implementieren.
Es könnten auch theoretisch "offene" Projekte erstellt werden, was aber mMn
nicht anzuraten ist.
Etc.

"Mehr" versuche ich im Grunde derzeit gar nicht zu erreichen.
Der ganze Schnickschnack drum herum (wie z. Bsp. ein ListView schreiben) ist
immo einfach nur "beiläufig", ein gutes Training und bringt auch Wissen.

Mit Gruß
Heinz-Mario Frühbeis