Wo findet man Programmierer?

Meine Firma sucht keine andere Firma sondern jemanden der 40h/Woche bei ihr arbeitet. Und Delphi muss er koennen weil seit anbeginn der Zeit alles darin programmiert wurde und davor in TurboPascal. Letzeres laeuft noch auf auf Einplatinencomputer mit V20/30. Ich will das jetzt nicht bewerten da ich selbst ueberzeugter C Programmierer bin, aber die Anwendungen sind halt schon da und laufen auch. Ausserdem hat meine Firma ein sehr guten Ruf was Kundenfreundlichkeit angeht. Selbst Leute mit einem 15Jahre alten Messgeraet wo die Steuersoftware noch unter Win3.11 laeuft, bekommen immer noch Hilfe wenn sie ein Problem haben.

Was uebrigens Kylix angeht, ich weiss davon. Ich wuerde auch lieber heute als morgen auf Linux umsteigen da ich selber Linux seit fast der ersten Stunde benutze. (1991 umgestiegen als es noch auf vier Disketten gepasst hat) Aber man kann soetwas Anwendern nicht zumuten. Es ist oftmals erschreckend wie wenig Wissen bei Anwendern die immerhin alle eine technische Ausbildung haben, vorhanden ist und die mittlerweile auch fast alle mit Computern aufgewachsen sein muessten. Und von Servicetechnikern die dann immerhin in kurzer Zeit von null auf den Level guter Unixanwender kommen muessten will ich garnicht erst anfangen.

Naja, ich werd die bisher erhaltenen Tips sicherlich beruecksichtigen, aber ich bin auch gespannt was das Arbeitsamt vorbeischickt. :-]

Olaf

Delphi ist eine nicht standardisiertes Sprachsystem genau eines Anbieters aus den USA, welches u.a. Elemente von Pascal verwendet. System deshalb, weil es von ganz vielen "Standard" Komponenten lebt.

Bereits "Original" Pascal war stets ein Hort von Compiler- spezifischen Erweiterungen, weil das orischinale Pascal ursprünglich als *Lehrsprache* für Studenten konzipiert war und daher viele Dinge aus Gründen der Einfachheit weggelassen wurden. Die für den professionellen Einsatz gedachte Wirth-Sprache Modula-2 kam hingegen zu spät und hat sich nie wirklich durchgesetzt.

Wenn die Borland Software Corp. z.B. einem bösen Raider zum Opfer fallern würde oder ein Wettbewerber sie aufkaufen würde um sie vom Markt zu nehmen oder deren Management "keinen Bock" mehr auf das Produkt hätte, dann wäre Delphi schlagartig tot. Wird die Windows API so geändert, dass es massive Kompatibilitätsprobleme mit den "Standard" Komponenten gibt, dann hat Delphi ebenfalls ein Problem.

Hingegen ist C oder C++ nachweislich portierbar, es gibt Normdokumente und es ist nachweislich möglich, Software so zu schreiben, dass sie mit dem Austausch weniger Dateien auf so unterschiedlichen Betriebssystemen wie Windows oder Linux einwandfrei innerhalb einer grafischen Oberfläche läuft. Und selbst Fortran oder Cobol Programme laufen immer noch damals wie heute.

Deshalb halte ich es für ziemlich gefährlich, bei großen Software- Projekten - die über Jahre bis Jahrzehnte gepflegt werden sollen - bei Kernkomponenten auf firmenspezifische Sprachen zu setzen, auch wenn die Bunti-Bildi Entwicklungsumgebung natürlich sehr verlockend wirkt.

Gruß Oliver

--
Oliver Bartels + Erding, Germany + obartels@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10

"Olaf Kaluza":

Hat doch alles recht wenig mit Elektronik zu tun, oder? Ich setzte mal 'n fup nach de.comp.misc

Vielleicht ist auch freepascal.org eine Alternative?

Die Entwickler kann man wegen Compilerbugs nicht verklagen, und die Doku ist auch eher sparsam als vollst=E4ndig.

Daf=FCr erh=E4lt man aber auch einen zu TP sowie weitreichend auch zu = Delphi kompatiblen Compiler, der sowohl DOS (32Bit), WIN32, als auch diverse=20 UNIX-derivate als Zielsystem unterst=FCtzt. Stark OS-spezifische = Funktionen kann der allerdings ebensowenig wie g=E4ngige C-Compiler = vereinheitlichen, und hat nat=FCrlich den im Vgl. zu C den Nachteil, da=DF die = Konvertierung der API-Header (welche ja meist in C formuliert sind) teilw. recht = aufwendig=20 ist (die wichtigsten DirectX9-Header haben mich z.B. einige Wochen = gekostet, h=E4tte man auch schneller haben k=F6nnen, aber ich wollt's = "native-like" haben).

Ich benutze fpc seit Jahren unter Linux (bash) und Win32, habe dabei = auch=20 schonmal einen bug gefunden (bspw.: cjqj9j$cv8$ snipped-for-privacy@online.de ), und kann = das=20 Ding bedenkenlos weiterempfehlen (Achtung: StdUnits zumeist nicht = Thread-Safe).

Gruss

Jan Bruns

Olaf Kaluza wrote in news: snipped-for-privacy@criseis.ruhr.de:

Die Politik von M$ war bisher immer die Kompatibilität zu alter Software zu erhalten. Vermutlich waren sie auch deshalb am erfolgreichsten. Da die älteren Delphi-Versionen (bzw. die VCL) nur auf der Win-32 API Funktionalität aufsetzen, werden damit geschriebene Programme höchstwahrscheinlich auch noch auf neueren Windowsversionen laufen. (Genaus wie mit VC5 geschriebene Programme).

M.

--
Bitte auf mwnews2@pentax.boerde.de antworten.

[...]

Liegt das evt. auch an dem alter bzw. der Zeit in der sie aufgewachsen sind? Die klassischen Ingenieursstudiengänge sind ja um einiges älter als Informatik. Ich glaub nicht das ein junger Ingenieur diesbezüglich unflexiebler als ein Informatiker ist.

Tschüss Martin L.

Es könnte sein, daß später einmal die 16 Bit Box (die Microsoft ja von Insignia, Hersteller von PC-Emulatoren für Mac, eingekauft hat und nicht selber entwickelt hat) rausfliegt. Auf Itanium-Systemen laufen schon keine

16 Bit Programme mehr.

Ich weiß ja nicht, wie alt Eure Delphi-Versionen sind.

Das gilt insbesondere auch für Setup-Programme, die oftmals auch 16 Bit Komponenten enthalten. (Installshield 5 z.B.). Viele Programme laufen auf Itanium zwar, man kann sie aber nicht installieren, weil das Setupprogramm nicht mehr läuft.

Reine 32 Bit Geschichten, die mit dem Microsoft-Installer (msi) installiert werden, sollten prinzipiell erstmal sicher sein, sofern keine schmutzigen Tricks gemacht werden.

Mit freundlichen Grüßen

Dipl.-Ing. Frank-Christian Krügel

Oliver Bartels wrote in news: snipped-for-privacy@4ax.com:

Ich wuerde sagen in dem Fall wäre eher das neue Betriebssystem tot. Bislang war es immer so, das neue Betriebssysteme, auf denen alte Software nicht mehr lief, nicht vom Anwender akzeptiert wurden. Auch alle mit älteren Visual C geschriebene Programme würden nicht mehr funktionieren (und das sind eigentlich fast alle). Letztlich benutzte Delphi auch nur die gleichen Schnittstellen. (Ich rede hier nur von den alten Delphi Versionen. Das neue Delphi8 ist ja eher ein NET-Clone).

So ist das aber meistens nicht. Eigentlich ist die Portierbarkeit gar keine Frage des dahinterliegenden Compilers (oder der Programmiersprache) sondern im wesentlichen der verwendeten Bibliotheken. Ein mit Borland C++ Builder (VCL) geschriebenes Programm ist nicht portierbar zu Visual C++ und die MFC oder gar KDE oder Gnome (alles C++-Compiler). Also eine Aussage "schreib in C++" ist völliger Nonsen. Die Aussage oben trifft eigentlich nur auf komplexe Algorithmen zu, die nicht auf die Benutzeroberfläche zurückgreifen (z.B. Signalverarbeitungen, FFT usw). Für so etwas ist ein PascalC Konverter ziemlich simpel (naja kommt drauf an wieviel vom Sprachraum man umsetzen muss). Delphi ist schliesslich auch nur ein C, so wie Pferde auch nur Menschen sind :-)

M.

--
Bitte auf mwnews2@pentax.boerde.de antworten.

Oliver Bartels wrote in news: snipped-for-privacy@4ax.com:

Hrhr, den Dialog kann ich mir gut vorstellen. Man muss aber auch mal die andere Seite der Medaille sehen (der Busfahrer hat nicht so ganz unrecht). Es soll eine CAD-Software bedienen, die eigentlich kaum die gängigen Bedienregeln, die sich bei Windows so eingebürgert haben, hat. Um beim Busfahrer zu bleiben, geht es eher darum, dass das Gaspedal mit der linken Fuss zu betätigen ist und er zum Bremsen immer den Handgriff hinter der rechten Schulter ziehen muss. :-)

M.

--
Bitte auf mwnews2@pentax.boerde.de antworten.

"Olaf Kaluza":

Also unflexibel? Aussichtslos. Vermute ich.

Worum geht's eigentlich?

Eher Richtung Treiberentwicklung? Dann sucht ihr m=F6glicherweise eher =FCberhaupt nicht nach Pascal-Leuten, sondern eher nach einem = vollst=E4ndigen Treiberentwickungspaket (ca. 2000$).

Oder eher diese Messen, Steuern, Regeln-Schiene? Wozu dann Angestellte?

Gruss

Jan Bruns

"Matthias Weingart" schrieb im Newsbeitrag news:Xns95F4A64A8573FAlwLookOnTBrightSide@212.21.75.70...

Haeh ? Lebst du in einer Parallelwelt ?

Warum kriege ich staendig irgendwelche Word oder PowerPoint oder Excel-Dateien zugeschickt, die nur das allerneueste Word, Excel oder PowerPoint lesen kann, obwohl nur plattester Inhalt drin ist, den schon Version 1.0 konnte ?

Und warum braucht der WebServer immer ein Update auf allerneueste Software und Patch-Level, wenn man irgendein abgelegenes Feature verwenden will, was angeblich schon seit Jahren funktioniert ?

Ein ueberwiegender Teil ehemals gut funktionierender Software laeuft unter meinem XP nicht mehr, ob TombRaider3, CDRWin oder meine Programmiergeraetesoftware.

M$ hat dutzende inkompatibler APIs entworfen, nach Win16 das voellig aufrufinkompatible Win32, nach Win32 das MFC-API, und OLE und OCX und wasweissichnoch und ist heute mit .NET sicher bei zehnten komplett inkompatiblem API mit der zehnten Art eine Datei zu oeffnen und ein Pixel zu setzen. Alle werden parallel installiert, damit alte Software noch benutzbar ist, aber nur so lange Microsoft diese alte Software haben will. Oft genug wurden ganze Gruppen ausgeschlossen, z.B. tausende von Geraetetreibern oder Spielen.

Und all diese Inkompatibilitaeten sind UNNOETIG gewesen. (Ja, ich kann's beweisen.)

Ich kenne keine Firma, die so extrem rueckwaertsinkompatibel ist, wie M$.

Du lebst in einer Parallelwelt.

--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

In article , Matthias Weingart writes: |> Ich wuerde sagen in dem Fall wäre eher das neue Betriebssystem tot. |> Bislang war es immer so, das neue Betriebssysteme, auf denen alte |> Software nicht mehr lief, nicht vom Anwender akzeptiert wurden.

Nö, das kam im Consumer-Markt erst mit DOS/Windows. Davor war es fast schon Usus, daß mit jeder neuen Maschine der alte Kram nicht mehr lief.

Und das war auch gut so [tm]. Was da speziell auf Wintel-Ebene für ein Aufwand getrieben wird, daß man auch noch garantiert zur Steinzeit kompatibel ist, ist nicht mehr feierlich. Führt dann auch zu so Blüten, die man auch hier öfter lesen kann, daß man dann ein durchaus sinnvolles Sicherheitskonzept durch spezielle Libraries aushebelt, so daß alte Programme auch weiterhin direkt auf die Hardware einprügeln oder jegliche Ressourcen am System vorbei an sich reißen dürfen.

Im Industriebereich kann ich nicht mitreden, aber ich gehe davon aus, daß dort ähnliche Standards wie z.B. der POSIX-Standard bei den *NIXen existieren. Bei den bekannten RTOSes ist das IIRC der Fall.

So kann die Kernfunktionalität leicht portiert werden, lediglich die Benutzerschnitstelle muß ggf. an die Besonderheiten des lokalen Systems angepaßt werden.

|> So ist das aber meistens nicht. Eigentlich ist die Portierbarkeit gar |> keine Frage des dahinterliegenden Compilers (oder der |> Programmiersprache) sondern im wesentlichen der verwendeten |> Bibliotheken. Ein mit Borland C++ Builder (VCL) geschriebenes Programm |> ist nicht portierbar zu Visual C++ und die MFC oder gar KDE oder Gnome |> (alles C++-Compiler). Also eine Aussage "schreib in C++" ist völliger |> Nonsen. |> Die Aussage oben trifft eigentlich nur auf komplexe Algorithmen zu, die |> nicht auf die Benutzeroberfläche zurückgreifen [...]

Grundsätzlich ist aber C überall übersetzbar, bei allem anderen braucht man dann p2c oder ähnliche Übersetzer.

Was die GUI-Problematik anbelangt, so habe ich den Windows-Wahn sowieso nie verstanden, Oberfläche und Nutzprogramm zu verschmelzen. Bei bestimmten Anwendungen kann man natürlich nicht trennen, aber in sehr vielen Fällen eben doch. Da einen monolithischen, an ein und nur ein OS gebundenen Brocken zu stricken, halte ich für nicht unbedingt förderlich.

Rainer

"Rainer Buchty" schrieb im Newsbeitrag news:cu2qei$39ira$ snipped-for-privacy@sunsystem5.informatik.tu-muenchen.de...

Aus deinen Worten spricht die wahre Unkenntnis.

Jemals ausprobiert mit einem ernsthaften Programm ? Eindeutig nicht.

Erstens: Falsch: Das gab es vorher unter CP/M gut 10 Jahre. Zweitens: Der Consumer-Makrt BEGANN da erst, also muesste der Satz lauten: Das gab es im Consumer-Markt von Anfang an, so wie es der kommerzielle Markt auf der IBM360 Plattform schon jahrzehntelang vorgemacht hatte.

Falsch. Es gibt KEINEN Grund, derartiger Altsoftware, wenn sie direkte Zugriffe macht, diese nicht zu erlauben, so lange die Resource frei ist. Die Diskussion gab es in d.s.e allerdings schon mal, daher will ich die Begruendung nicht wiederholen. Google.

Irgendwann wirst auch du verstehen (hoffentlich).

--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

In article , "MaWin" writes: |> "Matthias Weingart" schrieb im Newsbeitrag |> news:Xns95F4A64A8573FAlwLookOnTBrightSide@212.21.75.70... |> >

|> > Die Politik von M$ war bisher immer die Kompatibilität zu alter |> > Software zu erhalten. |> |> Haeh ? Lebst du in einer Parallelwelt ? |> |> Warum kriege ich staendig irgendwelche Word oder PowerPoint oder |> Excel-Dateien zugeschickt, die nur das allerneueste Word, Excel |> oder PowerPoint lesen kann, obwohl nur plattester Inhalt drin |> ist, den schon Version 1.0 konnte ?

Oh, so funktioniert Microsoft. Gerade weil Leute meinen, nur mit der neuesten Version von Office arbeiten zu müssen/können, werden andere mit in den Update-Zyklus gezogen, weil man auf einmal "den Standard" nicht mehr lesen kann.

Aber mit der neuesten Version kannst Du noch die Urväter (naja, zumindest wohl bis 6.0) einladen. Diese Art Kompatibilität meinte Matthias wohl.

Rainer

"MaWin":

Muss wohl.=20 Einzig das GUI-Design ist bei MS halbwegs Massenfreundlich.

Z.B. die Bewegung des Mauszeigers war bei MS-Win schon zu

16-Bit Zeiten vorbildlich bedienerfreundlich. Schnell, aber Pr=E4zise.

Da sprichst Du aber die andersrumme Kompatiblit=E4t an.

Da=DF ein f=FCr XP geschriebenes Programm auch unter DOS laufen soll, w=E4r' doch irgendwie etwas viel verlangt.

Andererseits d=FCrften allerdings diese Dinger auch mal automatisch die niedrigste w=E4hlbare Formatversion ohne Datenverlust w=E4hlen, sehe ich ein.

Ist aber mit z.B. Linux auch nicht so ganz viel anders. =20

Zum Zwecke der Verbesserung der Systemsicherheit w=E4re das vielleicht ja auch noch hinnehmbar... aber in diesem Punkt hat MS ja nun wirklich grottig versagt. =20

*grummel* Allerdings.

In diesem Licht k=F6nnte man fast meinen, nur MS k=F6nne gute Compiler entwickeln. Alle anderen m=FCssen schliesslich erstmal die API-buggies reverse injezieren.

Na ja, besonders doll durchdacht ist all das (ausser in = marktstrategischer Hinsicht) nicht, sehe ich ein. Andererseits bin ich auch nicht wirklich davon =FCberzeugt, da=DF der = Rest der=20 Welt all dies einheitlicher gestaltet h=E4tte, wenn also nicht FirmaX irgendwelche APIs f=FCr Heimanwender zurechtget=FCftelt h=E4tte.

Na ja, die Kernaussage, da=DF Win32 schon noch einige Jahre tun wird, ist doch vermutlich nicht falsch.

Gruss

Jan Bruns

In article , "MaWin" writes: |> > p2c |> |> Jemals ausprobiert mit einem ernsthaften Programm ? |> Eindeutig nicht.

Doch... Vor etwa 10 Jahren. Furchtbar. Aber ich bin mal davon ausgegangen, daß sich da ggf. noch was getan hätte und habe mich darum nicht mit einer Qualitätsanalyse aufgehalten.

|> Erstens: Falsch: Das gab es vorher unter CP/M gut 10 Jahre.

Stimmt, an CP/M hatte ich nicht gedacht. Wobei das IMO damals nicht dem "consumer"-Lager zuzuordnen war, sondern eher dem (semi-)professionellen.

Die Kisten waren im allgemeinen ja doch etwas teurer als typische Homecomputer der damaligen Zeit.

|> Zweitens: Der Consumer-Makrt BEGANN da erst, also muesste |> der Satz lauten: Das gab es im Consumer-Markt von Anfang an, |> so wie es der kommerzielle Markt auf der IBM360 Plattform |> schon jahrzehntelang vorgemacht hatte.

Der Consumer-Markt begann irgendwo zwischen Altair-8080 und Apple-II.

Den Wildwuchs im Heimcomputermarkt kennst Du sicherlich auch noch, da war niemand zueinander kompatibel (außer vielleicht MSX), nicht einmal innerhalb eines Herstellers (z.B. Commodore).

|> > Was die GUI-Problematik anbelangt, so habe ich den Windows-Wahn |> > sowieso nie verstanden, |> |> Irgendwann wirst auch du verstehen (hoffentlich).

Dann erklär mal.

In etlichen Fällen wird die GUI lediglich zur Erleichterung der Parametrisierung verwendet oder als Visualisierer. Da gibt es keinen Grund, die eigentliche Funktionalität mit in die GUI zu klatschen.

Nehmen wir doch einfach mal p2c als Beispiel: Du kannst den eigentlichen Übersetzer als reine Terminalanwendung ausgliedern und mußt ihn nicht mit in die GUI integrieren. Genau das wird aber in der Windows-Welt sehr gerne gemacht, anstatt für die Klickhuchs hier lediglich eine Bedienoberfläche bereitzustellen, die dann die Terminalanwendung aufruft.

Rainer

"Rainer Buchty":

=20

Am Commodore128 standen noch die Worte "Personal Computer".=20

war

innerhalb

Ich bin vielleicht etwas sp=E4ter. Trotzdem. Der C128 war vollst=E4ndig C64-kompatibel. Selbst das Diskettenlaufwerk dazu hatte einen Kompatiblit=E4tsmodus. Sowohl C128, als auch das zugeh=F6rige = Diskettenlaufwerk hatten zus=E4tzlich auch noch einen CP/M Kompatiblit=E4tsmodus, der = allerdings leider mit Fernseh-Anzeigeger=E4ten inkompatibel war. Letzlich hatte das Ger=E4t (+ die Floppy) weiters einen nativen = C128-Modus, in dem die 6502-kompatiblen CPUs (C128+Floppy) mit 2Mhz betrieben werden =

konnten, wof=FCr nicht nur ein vergleichsweise =FCppig ausgestatter=20 BASIC-Interpreter, sondern gleichzeitig sogar ein Maschinencode-Debugger zur Verf=FCgung stand (auch f=FCr C64-Programmierung interessant: MONITOR,..,GO64,SYS49152,reset,MONITIOR,..,GO64,SYS49152).

Ok, soll wohl eine Ausnahme gewesen sein, das Ger=E4t.

Grund,=20

Ja, und das sind denn auch die F=E4lle, bei denen oft tats=E4chich: =20

F=FCr Office, Spiele, Mediaplayer, usw. hingegen macht das UI den Hauptanteil der Programme aus.=20

Du kannst doch auch deiner Nachbarin nicht ernsthaft das Auswendiglernen =

von Kommandozeilenaufrufparametern zumuten wollen. Nat=FCrlich kann man denn noch die UI einfach bundlen, nur wo liegt da dann der Unterschied=20 zum fertig gelinkten binary? In der Freiheit, etwa sowas wie=20 "CALL Shell, TYPE Start" zu betreiben. Ausser Skript-Kiddies hat da=20 niemand was von, und selbst die k=F6nnen ersatzweise besser "#include" tippen.

Gruss

Jan Bruns

CP/M war so konstruiert, dass bewußt eine große Vielfalt an Hardware unterstützt wurde.

Insofern war der "PC" damals ein extremer Rückschritt, er hat sich IMHO nur aus Marketinggründen durchgesetzt hat ("Nobody has ever been fired for buying IBM")

Der Vorteil für den Kunden ist natürlich die Kompatibilität, sprich mehr Software für weniger Geld.

Der Nachteil ist, dass technologisch trotz der Taktratenerhöhung in vielen Bereichen wegen der Einheitsarchitektur die Zeit stehen geblieben ist. Ich rede hier nicht von Taktraten, sonden z.B. von Multiprocessing, es ist irgendwie komisch, dass eine moderne Grafikkarte deutlich paralleler arbeitet als die CPU ...

Völlig korrekt. Wer für langfristige Projekte beides vereinigt, bindet sich auf Gedeih und Verderb an einen Hersteller.

Wir haben sehr gute Umsätze im Softwarebereich damit erzielt, dass wir ein komplexes C Programm mit einer definierten Bibliotheksschnittstelle auf diversen Plattformen an Wettbewerber verkauft haben ;-)

Und es gäbe mit Sicherheit heute keinen BAE für Linux, wenn ich nicht bereits vor 15 Jahren eine interne betriebssystem-

*unabhängige* Grafikschnittstelle anstelle der direkten API Calls eingeführt hätte. Die wurde natürlich im Laufe der Zeit um Gimicks wie Pop/Pull/sostwas/Menüs/Boxen aller Art und Funktionen wie Nutzung der Online-Hilfe des Betriebsystems erweitert, die eigentliche Applikation ist aber weiterhin stark systemunabhängig ( Demzufolge gibt es sogar noch eine Sonderversion für Sun Cluster für einen bestimmten Kunden ).

Und_das_ist_gut_so (tm).

Monopole von Zulieferern sind mir nämlich immer irgendwie unsympathisch ...

Gruß Oliver

--
Oliver Bartels + Erding, Germany + obartels@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10

• Jan Bruns [05.02.2005 19:24]:

Office ja, Spiele möglicherweise, Mediaplayer mit Sicherheit nicht. Genau deshalb gibt es unter Linux z. B. die xine-lib, auf der unterschiedliche UIs (Xine-UI, Kaffeine, gXine, Xfmedia, etc.) aufsetzen.

Ja, allerdings werden oftmals Programme geschrieben, wo GUI und eigentlicher Code im Quellcode so vermengt sind, dass eine Portierung auf ein anderes GUI-System einem Rewrite der kompletten Anwendung gleichkommt, weil einfach keine Trennung vorhanden sind. Und damit geht es! GUI-Systeme ändern sich weit häufiger als Programmlogik und es gibt mehrere GUI-Systeme (was weiß ich was meine Kunden in 5 Jahren von mir haben wollen), so dass eine Trennung im Code bei einer vernünftigen Anwendung ab einer bestimmten Größe einfach essententiell ist.

Ich spreche nicht von kleineren Tools mit < 10K Codezeilen, die man sich mal eben in ein paar Tagen zusammenprogrammiert sondern von richtigen großen Anwendungen.

Gruß, Bernhard

Ach täusch Dich da mal nicht ... Im großen PC-Spiel ist Delphi eine Randerscheinung.

Bei Office-Software ist das bereits anders. Otto "Dumpfbacke" Normaluser kennt sowieso nur das Office, jede leicht modifizierte Bedienweise wie z.B. Staroffice überhitzt unweigerlich seine grauen Zellen.

Mit denen kann man als Besitzer des "Industriestandards" schon ganz nette Spielchen machen ...

Jein, das Zeug installiert tonnenweise Spezial-DLL's. Wenn die aus marktpolitischen Gründen ausgehebelt werden sollen, geht das ganz einfach. Bisher war Borland halt nur nicht in der Hauptschußlinie.

Eben. Und wenn das Volk auf Net geeicht ist, was kommt dann ;-)

Nein, alleine schon unser BAE beweist das Gegenteil ;-)

Der Kern ist C und läuft auf jeder gängigen Hardware.

Vor kurzem habe ich aus Gaudi den Autorouter auf einem TMS320C6416 Demoboard übersetzt, sozusagen als Benchmark ;-)

Das sind aber die interessanten Softwareteile. Für Software, die eigentlich nix rechnet sondern nur oberflächt(tm), gibt es beliebig viele 4GL Lösungen ...

Eher Pascal nach C++ mit ganz viel Bauchweh.

Gruß Oliver

--
Oliver Bartels + Erding, Germany + obartels@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10