Wo findet man Programmierer?

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?

Genau, vielleicht kann man es ja irgendwann einfuehren das du einfach alle zwei Jahre dein Geld nach Redmund ueberweisen darfst ohne eine neue Version eines Betriebssystems zu installieren. Das waere schonmal eine kleine Verbesserung. :-/

Olaf

Das ueberlasse ich mal lieber meinem Chef. :-)

Bis zur Rente. :-)

Olaf

"Bernhard Walle":

=20

aufsetzen.

Ist unter win =E4hnlich. Da ist dann die lib Teil des OS. Entsprechend verbleibt also auch beim Media-Player nur noch UI. =20

Auswendiglernen=20

man

Unterschied=20

=20

Also wirklich h=E4ufig wird auch das nicht sein. Wie auch. Die GUI klicken sich doch viele in einem Editor zusammen, der ja zumeist eher nicht von sich aus "richtig gro=DFe Anwendungen" = erzeugt.

In v=F6llig anderen Bereichen ist es sogar einfach besser, "engine + grafik-engine" eng zu verkn=FCpfen. Z.B. h=E4tten viele=20 Direct3D verwendende Spiele durchaus auch so programmiert werden = k=F6nnen, da=DF es einem wrapper =FCberlassen wird, ob nun D3D oder OpenGL = verwendet wird. Damit h=E4tte man ein vergleichsweise leicht portierbares, daf=FCr aber optisch suboptimales Produkt (da featurelimitiert und langsamer). In diesem Sektor wird teilw. nicht nur Schnittstellenspezifisch, sondern gar f=FCr konkrete Hardware/Treiber-Konfiguration optimiert geschrieben. Geht halt nicht wirklich anders.

Aus dieser Richtung betrachtet sieht es schon irgendwie etwas = kleinn=FCdelig aus, wenn pl=F6tzlich z.B. die GUI-Konvertierung f=FCr ein Brennprogramm = mehr als etwas Aufwand bedeuten soll.

gibt

mir

=20 Sehe ich noch nicht so ganz. Nahmen wir als Beispiel mal ACAD. Davon mag es in den letzten 10 Jahren vielleicht 7 releases gegeben = haben. Eine davon wegen Umstellung des UI von DOS auf WIN32. Der Rest d=FCrfte auf "Codeverbesserungen" wie "K=F6rperschnitte", = Ger=E4tetreiber, bessere Algos, CPU-spezifische Optimierungen, und wei=DF der Geier was = nicht sonst=20 noch alles entfallen. Sicherlich h=E4tte es ACAD nie bis zur Marktreife geschafft, wenn die=20 Programmierer einzelne Programmodule nicht sorgf=E4ltig separiert = h=E4tten, das aber doch nicht ernsthaft, weil wom=F6glich irgendwann mal die=20 GUI-Anpassung mehr oder minder aufwendig gewesen sein mag.

Gruss

Jan Bruns

In article , "Jan Bruns" writes: |> Am Commodore128 standen noch die Worte "Personal Computer".=20

Das stand auch am 1981 PC.

Namen sind Schall und Rauch.

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

Das mußt Du mir nicht erzählen, C64 war "meine" Zeit. Allerdings war der C128 diesbezüglich auch die einsame Ausnahme und vor allem auch nie wirklich erfolgreich -- mit der CP/M-Kompatibilität kam er ein paar Jahre zu spät. Da hätte er eher Erfolg gehabt, wenn er nen 8088 als Zusatzprozessor besessen hätte und mit MSDOS gekonnt hätte.

Wäre er nicht C64-kompatibel gewesen, wäre er vermutlich so gut wie gar nicht verkauft worden -- vgl. auch die "Profi"-Geräte der CBM600/700 Serie.

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

Jup, und die dem C128 auch noch zu einem 62Hz-PAL-Modus verhelfen, wie erst vor wenigen Jahren herausgefunden wurde.

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

Man hat's ja auch nochmal mit dem C65 probiert.

Aber grundsätzlich war es eine Ausnahme... Bei den Sinclairs war keiner zu den anderen kompatibel (wenn man mal von den Spectrums unter sich bzw. ZX80/81 absieht), genauso war's bei den Commodores (abgesehen vom C128) und den Apples (abgesehen vom Apple IIGS, der eine ähnliche Totgeburt wie der C128 war).

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

Sicher, hier sehe ich das Problem auch nicht. Es wäre sinnlos, z.B. einen Shell-MP3-Player laufen zu lassen, der dann per popen() z.B. die Aussteuerungsanzeige an die GUI zurückschickt.

|> Du kannst doch auch deiner Nachbarin nicht ernsthaft das Auswendiglernen = |> von Kommandozeilenaufrufparametern zumuten wollen.

Doch... Sie kann beim Auto ja auch erlernen, wie man selbiges betankt, startet und den Reifendruck bzw. Ölstand überprüft. Der Ölmeßstab ist bei jedem Fabrikat/Hersteller an einer anderen stelle, auch der Tankeinlaß ist mal links, mal rechts, bei den Amis sogar auch mal hinter dem Nummernschild.

Komischerweise akzeptiert man beim Auto durchaus, wenn das Licht beim einen Fabrikat als Drehschalter, beim anderen als Dreh-Hebel zu bedienen ist. Beim Computer hingegen ist diese Varianz geradezu unerträglich, es hat immer alles so zu sein, wie man es mal (meist unter Windows) gelernt hat.

Beim Computer hingegen ist man komischerweiser der Ansicht, daß das Ding so wie ein Toaster zu bedienen sein muß. Immer gleich, ein Hebel, ein Stellrad.

Eben wie in dem von Oliver beschrieben Szenario.

Rainer

In article , Bernhard Walle writes: |> 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.

Nunja. Bei Media-Playern kann ich es zumindest verstehen, wenn man Monolithen bäckt, denn hier ist eine starke Interaktion zwischen dem nackten Algorithmus und der Wiedergabe (respektive dem System) gegeben.

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

Danke. Dies war der Punkt, auf den ich raus wollte.

Rainer

Rainer Buchty schrieb:

An der Ähnlichkeit zum Toaster wird gearbeitet, zunächst mal im Bezug auf die Heizleistung. Der Rest kommt später.

Gruß Dieter

Also an dieser Stelle haettest du unbedingt das A20-Gate erwaehnen muessen. :-)

Bekomme ich Rabatt wenn ich Frage wie das Programm heisst? :-]

Olaf

Oliver Bartels schrieb:

Ob da in Prozent bei den Fahrern ausgedrückt immer noch so ganz viele sind...

Gerald

Olaf Kaluza schrieb:

Da würde ich nicht all zu viel erwarten... das Arbeitsamt mag noch als Kontaktadressenverteiler funktionieren, aber wenn die Anfangen selber zuzuordnen wer auf welchen Arbeitsplatz passen könnte und Bäckermeister zu einer Firma schickt die Autoradios entwickeln...

Gerald

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

Als der PC erfunden wurde, egal ob nun Altair, Apple oder IBM-PC, freute sich die Welt, das es endlich brauchbare Rechenknechte gab, die man als Einzelperson verstehen und bedienen konnte, und mit denen man sinnvolle Sachen machen konnte (Spiele... :-) ohne das man ein ganzes Heer von Systemadministratoren brauchte, jahrelange Schulung, und einem dutzende Hindernisse in den Weg gelegt wurden, wie es auf Grossrechnern ueblich war.

Die Zeit ist lange vorbei, jeder PC heute laesst ehemalige Big Irons locker hinter sich, was Komplexitaet, Unbedienbarkeit und Unzuverlaessigkeit anlangt. Selbst ein Heer von 'Fachleuten' ist heute oft nicht mehr in der Lage, herauszufinden, WARUM auf einem PC etwas nicht funktioniert. Dokumentiert ist der ganze Verhau sowieso schon lange nicht mehr (Linux mal aussen vor).

Die gesteigerte Komplexitaet war dummerweise im wesentlichen Selbstzweck, d.h. es gibt aus Anwendersicht KEINEN Grund fuer die ca. 100000 Dateien auf beispielsweise meinem Rechner. Die sind im wesentlichen da wegen konzeptioneller Fehler von M$. Aus Anwendersicht tut es (vereinfacht gesagt) SYSTEM.EXE, BROWSER.EXE, DRUCKER.DRV, TCPIP.DRV und ein paar Font und Konfigurationsdateien.

Ich habe damals verstanden, warum meine Eltern den Videorecorder nicht bedienen konnten, ich verstehe heute Leute, die vor dem Computer verzweifeln, und frage mich, welches kranke Hirn meine Handysoftware entworfen hat.

Ebenso, wie ein Redakteur kaum glauben kann, das viele seiner Leser klueger sind als er, oder ein Stiftung-Warentest-Mensch nicht begreift, das viele Kunden mehr Ahnung von der getesteten Materie haben als er, ignorieren viele Softwareentwickler, das der Mensch, der vor dem Computer ueber sie schimpft, RECHT hat.

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

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

Von allen GUIs (X, Mac, GEM, AmigaOS, NeXT, BeOS, ....) ist Windows mit Abstand am programmiererfreundlichsten. Mit grossem Abstand.

Das Win3.1 API (weitestgehend identisch mit Win 1.0) ist ein Lehrmeisterstueck fuer eine sinnvolle und tragfaehige Funktionensammlung.

Eine Applikation teilt sich normalerweise NICHT in eine Oberflaeche und einen Rechenkern, sondern in 3 Dinge: Oberflaeche Datenstruktur Rechenkern und die Datenstruktur hat natuerlich ebenfalls viele Funktionen (Daten laden/speichern).

Trennt man Oberflaeche von Datenstruktur durch ein zu loses Interface, wird die Performance schlecht und man sieht es der Applikation auch meist an, weil die Oberflaeche zu wenig Interaktion bietet.

Trennt man Datenstruktur und Rechenkern, sinkt auch die Performance und wird ein Programm meist aufwaendig und damit unuebersichtlich programmiert und fehlerhaft.

Man muss vor der Programmerstellung keine kuenstliche Trennung zwischen Rechenkern und Oberflaeche machen. Man muss nur logisch nach realen Gegebenheiten programmieren. Denn wenn in der Realitaet das Rechnen ohne Benutzerinteraktion erfolgt, kann man zu jeder Zeit Rechenkern von Oberflaeche trennen. Falls das Programm nicht durch kranke Hirne sondern durch logisch denkende Menschen mit geringstem Aufwand programmiert wurde, spiegelt es naemlich die Realitaet wider, haben also Oberflaeche und Rechenkern keine programmtechnischen Abhaengigkeiten. Beide sind aber direkt abhaenigig von der Datenstruktur.

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

Nein, X ist deutlich konsistenter und leichter erlernbar. Ausserdem hat das Wissen über X eine größere Transferierbarkeit.

Ist OO an Dir vorbeigegangen? Die Datenstruktur gehört heute mit zur Logik/Verarbeitung, weil sie Bestandteil der verwendeten Objekte ist. Das gilt bis hin zur Persistenzschicht.

Genau deswegen ist OO von Vorteil, es trennt nicht Daten von der Verarbeitung und bietet effiziente und wohldefinierte Schnittstellen zu den Objekten.

Gruß, Kurt

--
Kurt Harders
MBTronik - PiN - Präsenz im Netz GITmbH
mailto:news@kurt-harders.de
http://www.mbtronik.de

Die lassen halt jetzt die Meute los all derer die sich bewerben müssen um als arbeitswillig gelten zu dürfen. Aus dem Grund sind Stellenanzeigen in Zeitungen auch keine gute Alternative mehr: allgemeiner Ansturm. Also schalten Firmen "Personaldienstleister" vor. Die zeichnen sich durch völlige Ahnungslosigkeit bezüglich der Gegebenheiten in der Firma des Auftraggebers und bezüglich tatsächlicher fachlicher Eignung des Bewerbers aus. Reduziert sich dann auf das Abhaken ob Begriffe die in der Anzeige standen auch im Bewerbungsschreiben wieder zu finden sind. Einzige Ausnahme könnten Vermittler sein die auf E-Technik spezialisiert sind, vgl. die die öfter in M&T auftauchen. Und dann gibts noch die oberschlauen Firmen die den Ansturm mildern wollen indem sie einfach das Anforderungsprofil beliebig auf Typ Supermann aufblähen. Die kriegen dann die Bewerbungschreiben die genauso schief optimiert wurden und sind dann passend bedient.

MfG JRD

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

Delphi braucht nur dann Spezial-DLL's, wenn es so eingestellt ist. Man kann das aber auch "statisch linken", so dass zwar die Exe um

300kBytes groesser wird, aber _keine_ zusätzlichen Dll's usw. im System benötigt werden. (ein grosser Vorteil gegenüber z.B. VisualBasic).

M.

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

"Kurt Harders" schrieb im Newsbeitrag news: snipped-for-privacy@individual.net...

Es gleitet zu sehr ins Programmieren ab, daher egal was du antwortest meine letze Mail zum Thema.

Ein klares Nein. Bedenke, das es fuer X nicht mal allgemein akzeptierte Dialoggadgets gibt (Motif, KDE, ...) Und selbst wenn WinAPI den Eindruck erweckt, das anzeigender Rechner und rechnender Recher dieselbe Maschine sein muessen: Nein, auch das WinAPI ist so gestrickt, das eine Trennung zwischen Displayrechner und anwendungsausfuehrendem Rechner bedacht worden war (erkennbar z.B. an HBITMAP-Funktionen).

Von Unix zu Unix zu Unix ? Wow. Das Windows-API ist *sogar* unter Unix verfuegbar, DAS nenne ich portabel, Wines sei Dank. Sogar GEM war von TOS zu DOS bis zu Unix und Helios verfuegbar, also viel weiter transferierbares Wissen.

Ein Fehler vieler heutige Programme. Nach dieser Strukturierung ergibt sich ein kein vertikal teilbares Programm

+------+-----+------+ | | | | |Ober- |Daten|Rechen| |fläche| |-kern | | | | | +------+-----+------+

sondern das Programm ist ein unteilbarer monolithischer Block, der bloederweise nur horizontal teilbar ist

+-----------------------------------+ | vermengtes Durcheinander | +-----------------------------------+ |spezialisierte Sonderkonstruktionen| +-----------------------------------+ | simple Elementfunktionen | +-----------------------------------+

das ist durchaus das inzwischen bekannte Drama der OO-Technologie. Denn eine auf beide Arten teilbare Programmstruktur

+------+-----+------+ | Zusammenfassendes | +------+-----+------+ |Ober- |Daten|Rechen|anwendungsgerechtes |fläche| |-kern |API +------+-----+------+ | | | |simple | | | |Elementfunktionen +------+-----+------+

uebersteigt erwiesenermassen die Planungsfaehigkeit realer Programmierer.

Viele OO Buecher beginnen mit der Bemerkung, das OO die Realitaet abbildet. In der Realitaet sind Objekte(Gegenstaende) aber von der sie bearbeitenden Werkstatt(Verarbeitung) getrennt. Ein Radio schleppt die R%F-Werkstatt NICHT mit sich herum, daher kann eine R&F-Werkstatt auch Fernseher reparieren, sogar Computerbildschirme. Auch weiss ein Radio NICHT, wie es sich in ein Regal stellt, es passt in viele Regale, sogar in welche, die zur Zeit des Radios noch nicht erfunden waren. Ein kleiner Blick auf die Realitaet zeigt, was derzeit an vielen OO-Programmen falsch ist. Das Problem ist aber inzwischen bekannt. Ich habe Smalltalk bereits 1986 wegen Unbrauchbarkeit zur Applikationsprogrammierung bei Seite gelegt.

Die Realitaet trennt Daten und Verarbeitung, sie arbeitet eben nicht dokumentenzentrisch (wenn ich ein Papier habe, stehen mir eben nicht saemtliche Werkzeuge zum Schreiben, Bemalung, Zerschneiden automatisch zur Verfuegung, wie jeder weiss dem mal eine Offsetdruckmaschine fehlte), sondern liefert Werkzeuge (Anwendungsprogramme) zur Bearbeitung, ist also Applikationsorientiert. Sorry, so ist die Realitaet, egal was in OO-Buechern an modernen Maerchen drin steht.

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

Hallo,

• Rainer Buchty [06.02.2005 00:36]:

Dafür gibt es Shared Libraries. Es findet auch eine sehr starke Interaktion zwischen der C-Library und dem Programm statt, deshalb linkt man auch nicht bei jedem Programm die C-Library statisch hinzu.

Natürlich macht ein extra Kommandozeilenprogramm, das man aufruft und mit den Daten füttert, hier keinen Sinn.

Gruß, Bernhard

Es gibt keine ernsthaften P Programme. Zumindest keine, die man portieren wöllte. Bzw. wo man nicht schon vorher weiß, daß die Portierung fehlschlagen *muß*. GUI-Krempel halt.

OK, erste C-Versionen von TeX wurden wohl per p2c portiert. Später hat man dann 'web' auf 'web2c' aufgebohrt und das funktioniert auch.

Die Entscheidung, ob eine Resource frei ist, trifft in richtigen Betriebssystemen der Betriebssystemkern. Deswegen ist es eine ausgesprochen blöde Idee, eben diesen Kern zu umgehen.

XL

In article , "MaWin" writes: |> Die gesteigerte Komplexitaet war dummerweise im wesentlichen Selbstzweck, |> d.h. es gibt aus Anwendersicht KEINEN Grund fuer die ca. 100000 |> Dateien auf beispielsweise meinem Rechner.

Mmhm, ich kenne das 50%-Mirakel... Egal, wie groß die Festplatte ist, direkt nach Installation derselben ist sie quasi unmittelbar zu 50% gefüllt.

|> Ich habe damals verstanden, warum meine Eltern den Videorecorder nicht |> bedienen konnten

Nein, hier muß ich widersprechen.

Es gab auf dem Kassettenrekorder das |> Play-Symbol, es gab auf dem CD-Player das |> Play-Symbol und es gab auf dem Videorekorder das |> Play- Symbol.

Trotzdem wurde man für jedes Gerät wieder aufs neue gefragt, wie man denn hier nun die Abspielfunktion aktiviert.

Programmieren, ja, das war -- abgesehen von Grundig mit Textprogramming -- immer eine Wissenschaft für sich.

|> Ebenso [...] ignorieren viele Softwareentwickler, das der Mensch, der |> vor dem Computer ueber sie schimpft, RECHT hat.

Sicherlich ist das Programmieren kein Selbstzweck (so wie früher, als die Lösung im Vordergrund stand), aber andererseits ist dem Anwender IMO durchaus zuzumuten, sich von Zeit zu Zeit an eine veränderte Bedienung zu gewöhnen.

Die schluckt er aber nur, wenn sie aus Redmond kommt. In allen anderen Fällen wäre die Lernkurve unzumutbar steil.

Rainer

In article , Bernhard Walle writes: |> Dafür gibt es Shared Libraries. Es findet auch eine sehr starke |> Interaktion zwischen der C-Library und dem Programm statt, deshalb linkt |> man auch nicht bei jedem Programm die C-Library statisch hinzu.

Mit "Monolith" meinte ich nicht eine statisch gelinkte Version, sondern die komplette Verzahnung von GUI und Anwendung in einem Programm.

|> Natürlich macht ein extra Kommandozeilenprogramm, das man aufruft und |> mit den Daten füttert, hier keinen Sinn.

Eben, das war der Knackpunkt.

Rainer