Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: GEOS-InfoBase-Forum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1

Montag, 19. November 2018, 17:07

Neues SDK

Sehe ich das richtig, dass im neuen SDK kein Bin-Verzeichnis enthalten ist?

2

Montag, 19. November 2018, 18:07

Huch, wie ist denn das passiert... danke Wilfried für den Hinweis!! Das ist natürlich so nicht gedacht, ein bin-Ordner muß es aus jeden Fall geben.
Ich prüfe das, korrigiere es und lade eine neue Version hoch. Ich gebe dann hier bescheid.

Viele Grüße,
Falk

3

Dienstag, 20. November 2018, 09:00

Was kann das neue SDK, was das alte noch nicht konnte?

4

Dienstag, 20. November 2018, 15:44

Hallo Falk,

ich habe mal alle mir bekannten Fehler korrigiert (wo noch nötig) und jede Menge Requests erstellt. ;)

Wo ich mir nicht ganz sicher bin, sind meine Aufzeichnungen bzgl. "WINC.GOH", da die Datei anders aussieht als beim allerersten Dos-SDK...
Das hätte man tun sollen:

@importMessage MetaWindowMessages, void MSG_META_RAW_UNIV_ENTER();
@importMessage MetaWindowMessages, void MSG_META_RAW_UNIV_LEAVE();

should read

@importMessage MetaWindowMessages,
void MSG_META_RAW_UNIV_ENTER(optr inputObj=cx:dx, WindowHandle ptrWin=bp);
@importMessage MetaWindowMessages,
void MSG_META_RAW_UNIV_LEAVE(optr inputObj=cx:dx, WindowHandle ptrWin=bp);

Instead of altering the header file you can also use an alias definition in your own header file:
@alias (MSG_META_RAW_UNIV_ENTER) void MSG_RAW_UNIV_ENTER
(optr inputObj = cx:dx, WindowHandle ptrWin = bp);
@alias (MSG_META_RAW_UNIV_LEAVE) void MSG_RAW_UNIV_LEAVE
(optr inputObj = cx:dx, WindowHandle ptrWin = bp);


Gruß
Jörg
d[ 0_O ]b

5

Dienstag, 20. November 2018, 15:52

Was kann das neue SDK, was das alte noch nicht konnte?


Nichts - siehe Falks Vortrag ( https://www.kwirandt.de/geoswelt/geostreffen/videos/ )
d[ 0_O ]b

6

Mittwoch, 21. November 2018, 07:54

Nichts - siehe Falks Vortrag

Die Unabhängigkeit von kommerzieller Software (Borland C++) würde ich nicht nichts nennen ;-)
Gruß
Rainer
Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

7

Mittwoch, 21. November 2018, 08:19

Das SDK was jetzt online ist, ist noch vom Borland Compiler abhängig. Das "New SDK" von dem Falk sprach, ist noch in der Entwicklung... :whistling:
Nichts - siehe Falks Vortrag

Die Unabhängigkeit von kommerzieller Software (Borland C++) würde ich nicht nichts nennen ;-)
Bye,
MeyerK

8

Mittwoch, 21. November 2018, 17:44

Ja, so dehnbar ist der Begriff "neues" SDK :-)
Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

9

Donnerstag, 22. November 2018, 11:14

Ich habe einen Account bei Blueways angelegt und mir die Downloads angeschaut. Mit Enttäuschung musste ich feststellen, dass das neue Geos SDK für Win32, nicht mehr für DOS ist. Heißt das dass nun DOS mit neuen Entwicklungen für GEOS engültig leer ausgeht?

Es gibt übrigend genug Aboandonware Seiten im Netz, die auch alte PC-GEOS Versionen vorhalten UND NICHT ABGEMAHNT WERDEN.

Internetforen sind da mit ihrem ekligen vorauseilenden Gehorsam pingeliger als unbedingt nötig.

@Rainer:
Die Unabhängigkeit von kommerzieller Software (Borland C++) würde ich nicht nichts nennen ;-)

Ist das jetzt der Preis dafür dass eine neues Geos SDK nur noch für Windows verfügbar ist?

Heutige Rechner, auch Uralt DOS Rechner sind mit genug RAM ausgestattet, um richtige GUI zu können. Das alte Textmodezeug bleibt doch auch verfügbar und da gab es ebenso viel kommerzielle Anwendungen, nur wird da nicht so dogmatisch hingeschaut wie im Fall von GUI. AUch DOS kann die hohen VESA Auflösungen 800x600, 1024x768, 1280x1024. Der Ram steht heute auch in uralten DOS Rechnern zur Verfügung. Im Zweifelsfall geht auch die Minimalauflösung von 640x480.

Wird wohl dann doch bei Windows und KDE, XFCE, LXDE ... bleiben. AUch Kommandoziele oder Texmode gehe ich nicht zurück, heutige Rechner können GUI und da gibt es bereits sehr gute mit Windows und den verschiedenen Linux Desktops.

Oder ich bleibe halt auf immer und ewig bei der letzten oder den unmittelbaren Vorgängerversionen von Geos, das noch mit DOS zusammen funktioniert.


Ich hätte ja nix dagegen, für GEOS unter Windows mit einer modernen Windows IDE zu entwickeln und das Ergebnis dann in der Final-Version erst für DOS zu übersetzen, aber ich glaube einfach nicht, dass das je vorgesehen sein wird. Dann schon lieber ein SDK das nur unter Geos verwendbar ist und innerhalb einer RBasic IDE von GEOS aus ansprechbar ist. DA weiß ich dann wenigstens wirklich dass das Compilat auch mit GEOS für DOS läuft!

10

Donnerstag, 22. November 2018, 11:47

So pessimistisch würde ich das alles gar nicht sehen - was Falk im Moment vorbereitet hat, ist erst mal noch eine Bestandsaufnahme des letzten Zustands der Quelltexte und Tools bei Breadbox, und noch nicht unbedingt eine Aussicht auf darauf, was sich daraus machen lässt.
Ich hätte ja nix dagegen, für GEOS unter Windows mit einer modernen Windows IDE zu entwickeln und das Ergebnis dann in der Final-Version erst für DOS zu übersetzen, aber ich glaube einfach nicht, dass das je vorgesehen sein wird. Dann schon lieber ein SDK das nur unter Geos verwendbar ist und innerhalb einer RBasic IDE von GEOS aus ansprechbar ist. DA weiß ich dann wenigstens wirklich dass das Compilat auch mit GEOS für DOS läuft!

Ich würde persönlich dieses Szeario sogar für das wahrscheinlichste halten: das GEOS SDK dürfte erst mal nur für 32-bit-Systeme wie Windows und Linux verfügbar sein (und die Frage ist, ob eine DOS-Version der Tools wirklich sinnvoll wäre, angesichts der wenigen Leute, die sich vermutlich um die Pflege des Codes kümmern können).
Allerdings spricht für mich nichts dagegen, dass das damit gebaute System auch auf nacktem DOS läuft - andernfalls würde meiner Meinung nach sogar viel vom Charakter von GEOS verloren gehen, wenn es ausschließlich in einer VM laufen könnte. RBasic wäre dann tatsächlich die IDE der Wahl, wenn man unter nacktem DOS entwickeln will.
Für etwas fraglich halte ich, was man mit der "NTVDM-Version" von GEOS macht, die ja im eigenen DOS-Emulator von Windows läuft und dann mit speziellen Treibern ein Desktop-Fenster aufmacht. Da es diesen Emulator in neueren Windows-Versionen gar nicht mehr gibt, dürfte ein quelloffener DOS-Emulator als Basis erst mal für die meisten Nutzer interessanter sein (zunächst DOSBox, wegen der weiteren Verbreitung, und dann evtl. DOSEMU, wenn sich dafür jemand findet, um es zu pflegen).
Würde das so Sinn ergeben?

11

Donnerstag, 22. November 2018, 12:23

Stellt mich nicht wirklich zufrieden, ich will GEOS für richtiges DOS.

Dort also sollten die Programmierer, die das alles in ihrer Freizeit machen, anfangen. Windows und DOSBox kann danach unterstützt werden.

Zitat von »"mgroeber"«


Allerdings spricht für mich nichts dagegen, dass das damit gebaute System auch auf nacktem DOS läuft - andernfalls würde meiner Meinung nach sogar viel vom Charakter von GEOS verloren gehen, wenn es ausschließlich in einer VM laufen könnte.


100% Zustimmung!


Zitat von »"mgroeber"«


RBasic wäre dann tatsächlich die IDE der Wahl, wenn man unter nacktem DOS entwickeln will.


RBasic ist dann die IDE der Wahl. Richtig!

Zitat von »"mgroeber"«


Ich würde persönlich dieses Szeario sogar für das wahrscheinlichste halten: das GEOS SDK dürfte erst mal nur für 32-bit-Systeme wie Windows und Linux verfügbar sein (und die Frage ist, ob eine DOS-Version der Tools wirklich sinnvoll wäre, angesichts der wenigen Leute, die sich vermutlich um die Pflege des Codes kümmern können).


Gerade weil so wenige Leute sich um den Code kümmern können, sollte das Hauptaugenmerk auf DOS bleiben. Denn wenn die paar Leute, noch dazu in ihrer mehr als knappen Freizeit den Code bearbeiten und dann aber mit Windows anfangen, kann ich wohl bis zum St,. Nimmerleistag warten, bis die Neuentwicklungen auch auf DOS verfügbar werden. Deshalb sollten dies Programmierer erst mal für DOS entwickeln und wenn da alles funktioniert was da geplant ist, können die das gerne auch auf Windows, in die DOSBox, die VEMM ... portieren.

Windows ist mitnichten einfacher bei der Programmierung, wenn ich mir da das Windows API so anschaue oder auch Delphi oder Lazarus aus der Pascal Welt, bzw. den Boralnd C++ Builder und deren Komponenten, deren Code man dort wunderbar einsehen kann. Nichts ist da unter Windows einfacher, wenn man richtig tief in die Programmierung von all dem Zeug einsteigt.

12

Donnerstag, 22. November 2018, 12:59

Zitat

Heißt das dass nun DOS mit neuen Entwicklungen für GEOS engültig leer ausgeht?

Nein, das heißt nur, dass das SDK nie wieder unter DOS laufen wird...

Zitat

...sollte das Hauptaugenmerk auf DOS bleiben.

Diese Behauptung würde dann Sinn machen, wenn es ein aktuelles SDK für DOS gäbe. Aber die Geos-SDKs setzen schon seit mindestens 1998 ein Windows NT voraus... Die Tools etc. wieder auf DOS zurückzuportieren wäre viel zu aufwendig, würde voraussetzen, dass man zum Swatten wieder zwei PCs mit COM-Ports benötigen würde, ... .
d[ 0_O ]b

Ähnliche Themen

Thema bewerten