Wo findet man Programmierer?

[Martin Klaiber]

Bernhard Walle <bernhard.walle@gmx.de> wrote:

:

Es gibt noch Kylix. Ich nutze es auf SuSE-Linux 9.0 ohne probleme.

Man beschränkt sich halt auf Linux/x86 und zudem hat Kylix meiner
Meinung nach eine ungewisse Zukunft, da es sich nicht richtig etablieren
konnte.

Wer eine leistungsfähige, portable Sprache mit pascalähnlicher Syntax
sucht, kann sich auch mal Ada anschauen. Die Sprache wurde immerhin
für solche Zwecke entworfen (Programmierung von Satelliten, u.ä.),
ist echtzeitfähig, standardisiert, unterstützt tasks, OO-fähig, usw.

Mit GNAT <http://www.libre.act-europe.fr/GNAT> existiert auch ein
OpenSource-Compiler auf Basis des gcc, der bei jedem Linux dabei
sein sollte (gibt's aber auch für Windows), es gibt aber natürlich
auch kommerzielle Compiler von verschiedenen Anbietern.

Martin

 

[Olaf Kaluza]

Michael Schneider <none@none.com> wrote:

Wir haben schon unterschiedliche Projekte mit VB realisiert

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

 

[Oliver Bartels]

On Sat, 5 Feb 2005 14:01:16 -0500, Olaf Kaluza <olaf@criseis.ruhr.de>
wrote:

Oder anders ausgedrueckt, ist damit zu rechnen das Programme in Delphi
unter Windows BSE nicht mehr laufen werden?
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

 

[Jan Bruns]

"Olaf Kaluza":

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

Ich will das jetzt nicht bewerten da ich selbst ueberzeugter C
Programmierer bin, aber die Anwendungen sind halt schon da und laufen
auch.

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.

Vielleicht ist auch freepascal.org eine Alternative?

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

Dafür erhält man aber auch einen zu TP sowie weitreichend auch zu Delphi
kompatiblen Compiler, der sowohl DOS (32Bit), WIN32, als auch diverse
UNIX-derivate als Zielsystem unterstützt. Stark OS-spezifische Funktionen
kann der allerdings ebensowenig wie gängige C-Compiler vereinheitlichen,
und hat natürlich den im Vgl. zu C den Nachteil, daß die Konvertierung
der API-Header (welche ja meist in C formuliert sind) teilw. recht aufwendig
ist (die wichtigsten DirectX9-Header haben mich z.B. einige Wochen gekostet,
hätte man auch schneller haben können, aber ich wollt's "native-like" haben).

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

Gruss

Jan Bruns

 

[Martin Laabs]

Oliver Bartels <spamtrap@bartels.de> wrote:

Hör mir bitte mit Informatik und dem Deutschen_Ingenieur auf, wir
kennen das Drama aus dem EDA Bereich nur zu gut.

[...]

Insofern muss ich hier mal ganz klar eine Lanze für die
Informatiker brechen:
- Die sind im allgemeinen *deutlich* flexibler.

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.

Ciao Oliver

 

[Frank-Christian Kruegel]

On Sat, 5 Feb 2005 14:01:16 -0500, Olaf Kaluza <olaf@criseis.ruhr.de> wrote:

Oder anders ausgedrueckt, ist damit zu rechnen das Programme in Delphi
unter Windows BSE nicht mehr laufen werden?

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

 

[Jan Bruns]

"Olaf Kaluza":

Suchst du für eine langfristige Beschäftigung oder eher flexibel?

Bis zur Rente.

Also unflexibel? Aussichtslos. Vermute ich.

Worum geht's eigentlich?

Eher Richtung Treiberentwicklung? Dann sucht ihr möglicherweise eher
überhaupt nicht nach Pascal-Leuten, sondern eher nach einem vollständigen
Treiberentwickungspaket (ca. 2000$).

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

Gruss

Jan Bruns

 

[MaWin]

"Matthias Weingart" <mwnews@pentax.boerde.de> 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 ?

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.

 

[Matthias Weingart]

Olaf Kaluza <olaf@criseis.ruhr.de> wrote in
news:s553uc.hs3.ln@criseis.ruhr.de:

Matthias Weingart <mwnews@pentax.boerde.de> wrote:

Mhh, Delphi ist so lange verfügbar, wie Windows die WIN32-Api
unterstützt. Auch heute kann man noch Programme für Windows 3.1
schreiben (oder für Dos). Die Software verfällt ja nicht.

Kann du mir das nochmal erklaeren? Ich dachte bisher Delphi waere
ein Pascal fuer Windows mit grafischer Oberflaeche zum Fenster
zusammenklicken. Und solange es Windows gibt sollte es darauf
laufen. Unterliege ich da einem Irrtum?

Oder anders ausgedrueckt, ist damit zu rechnen das Programme in
Delphi unter Windows BSE nicht mehr laufen werden?

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.

 

[MaWin]

"Rainer Buchty" <buchty@atbode100.lrr.in.tum.de> schrieb im Newsbeitrag
news:cu2qei$39ira$1@sunsystem5.informatik.tu-muenchen.de...

Aus deinen Worten spricht die wahre Unkenntnis.

p2c

Jemals ausprobiert mit einem ernsthaften Programm ?
Eindeutig nicht.

Nö, das kam im Consumer-Markt erst mit DOS/Windows.

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.

sinnvolles Sicherheitskonzept

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.

Was die GUI-Problematik anbelangt, so habe ich den Windows-Wahn
sowieso nie verstanden,

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.

 

[Matthias Weingart]

Oliver Bartels <spamtrap@bartels.de> wrote in
news:4hj901tn08ht7q09p86bukohrmsc1unhr6@4ax.com:

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.

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

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

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 Pascal<->C
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.

 

[Matthias Weingart]

Oliver Bartels <spamtrap@bartels.de> wrote in
news:6t0901lp2e3tncmt1plgjvn0sqttk2ct7e@4ax.com:

Hör mir bitte mit Informatik und dem Deutschen_Ingenieur auf, wir
kennen das Drama aus dem EDA Bereich nur zu gut.

mode=lernunwilliger_Busfahrer
Der Lichtschalter war immer rechts oben und ein Schiebeschalter.
/mode

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.

 

[Rainer Buchty]

In article <Xns95F4A957B802AlwLookOnTBrightSide@212.21.75.70>,
Matthias Weingart <mwnews@pentax.boerde.de> 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

 

[Jan Bruns]

"MaWin":

"Matthias Weingart"

Die Politik von M$ war bisher immer die Kompatibilität zu alter
Software zu erhalten.

Haeh ? Lebst du in einer Parallelwelt ?

Muss wohl.
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äzise.

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 ?

Da sprichst Du aber die andersrumme Kompatiblität an.

Daß ein für XP geschriebenes Programm auch unter DOS laufen soll,
wär' doch irgendwie etwas viel verlangt.

Andererseits dürften allerdings diese Dinger auch mal automatisch
die niedrigste wählbare Formatversion ohne Datenverlust wählen,
sehe ich ein.

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 ?

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

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

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

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.

*grummel*
Allerdings.

In diesem Licht könnte man fast meinen, nur MS könne gute
Compiler entwickeln. Alle anderen müssen schliesslich erstmal die
API-buggies reverse injezieren.

Und all diese Inkompatibilitaeten sind UNNOETIG gewesen.
(Ja, ich kann's beweisen.)
Ich kenne keine Firma, die so extrem rueckwaertsinkompatibel
ist, wie M$.

Na ja, besonders doll durchdacht ist all das (ausser in marktstrategischer
Hinsicht) nicht, sehe ich ein.
Andererseits bin ich auch nicht wirklich davon überzeugt, daß der Rest der
Welt all dies einheitlicher gestaltet hätte, wenn also nicht FirmaX
irgendwelche APIs für Heimanwender zurechtgetüftelt hätte.

Du lebst in einer Parallelwelt.

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

Gruss

Jan Bruns

 

[Rainer Buchty]

In article <36k81cF529ghfU1@individual.net>,
"MaWin" <me@private.net> writes:
|> "Matthias Weingart" <mwnews@pentax.boerde.de> 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

 

[Jan Bruns]

"Rainer Buchty":

"MaWin":

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

Am Commodore128 standen noch die Worte "Personal Computer".

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

Ich bin vielleicht etwas später. Trotzdem. Der C128 war vollständig
C64-kompatibel. Selbst das Diskettenlaufwerk dazu hatte einen
Kompatiblitätsmodus. Sowohl C128, als auch das zugehörige Diskettenlaufwerk
hatten zusätzlich auch noch einen CP/M Kompatiblitätsmodus, der allerdings
leider mit Fernseh-Anzeigegeräten inkompatibel war.
Letzlich hatte das Gerät (+ die Floppy) weiters einen nativen C128-Modus,
in dem die 6502-kompatiblen CPUs (C128+Floppy) mit 2Mhz betrieben werden
konnten, wofür nicht nur ein vergleichsweise üppig ausgestatter
BASIC-Interpreter, sondern gleichzeitig sogar ein Maschinencode-Debugger
zur Verfügung stand (auch für C64-Programmierung interessant:
MONITOR,..,GO64,SYS49152,reset,MONITIOR,..,GO64,SYS49152).

Ok, soll wohl eine Ausnahme gewesen sein, das Gerät.

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

Ja, und das sind denn auch die Fälle, bei denen oft tatsächich:

Für Office, Spiele, Mediaplayer, usw. hingegen macht das UI den
Hauptanteil der Programme aus.

Du kannst doch auch deiner Nachbarin nicht ernsthaft das Auswendiglernen
von Kommandozeilenaufrufparametern zumuten wollen. Natürlich kann man
denn noch die UI einfach bundlen, nur wo liegt da dann der Unterschied
zum fertig gelinkten binary? In der Freiheit, etwa sowas wie
"CALL Shell, TYPE Start" zu betreiben. Ausser Skript-Kiddies hat da
niemand was von, und selbst die können ersatzweise besser
"#include" tippen.

Gruss

Jan Bruns

 

[Rainer Buchty]

In article <36k9npF53egcjU1@individual.net>,
"MaWin" <me@private.net> 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

 

[Oliver Bartels]

On Sat, 5 Feb 2005 17:24:06 +0000 (UTC),
buchty@atbode100.lrr.in.tum.de (Rainer Buchty) wrote:

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

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

 

[Bernhard Walle]

* Jan Bruns [05.02.2005 19:24]:

Für Office, Spiele, Mediaplayer, usw. hingegen macht das UI den
Hauptanteil der Programme aus.

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.

Du kannst doch auch deiner Nachbarin nicht ernsthaft das Auswendiglernen
von Kommandozeilenaufrufparametern zumuten wollen. Natürlich kann man
denn noch die UI einfach bundlen, nur wo liegt da dann der Unterschied
zum fertig gelinkten binary? In der Freiheit, etwa sowas wie
"CALL Shell, TYPE Start" zu betreiben. Ausser Skript-Kiddies hat da
niemand was von, und selbst die können ersatzweise besser
"#include" tippen.

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

 

[Oliver Bartels]

On Sat, 5 Feb 2005 15:18:54 +0000 (UTC), Matthias Weingart
<mwnews@pentax.boerde.de> wrote:

Ich wuerde sagen in dem Fall wäre eher das neue Betriebssystem tot.
Ach täusch Dich da mal nicht ...

Im großen PC-Spiel ist Delphi eine Randerscheinung.

Bislang war es immer so, das neue Betriebssysteme, auf denen alte
Software nicht mehr lief, nicht vom Anwender akzeptiert wurden.
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 ...

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

(Ich rede hier nur von den
alten Delphi Versionen. Das neue Delphi8 ist ja eher ein NET-Clone).
Eben. Und wenn das Volk auf Net geeicht ist, was kommt dann ;-)

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.
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 ;-)

Die Aussage oben trifft eigentlich nur auf komplexe Algorithmen zu, die
nicht auf die Benutzeroberfläche zurückgreifen (z.B.
Signalverarbeitungen, FFT usw).
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 ...

Für so etwas ist ein Pascal<->C
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
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