Forum: PC-Programmierung Programmiersprache gesucht


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Patrick W. (pawi777)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich suche nach Vorschlägen für eine Programmiersprache, die folgende 
Voraussetzungen möglichst erfüllt:

-es sollte kostenlose oder zumindest preiswerte Compiler für Windows 
geben
-es muss möglich sein, ohne grossen aufwand GUIs zu erstellen
-eine grosse Bekanntheit wäre vorteilhaft
-möglichst direkte Kommunikation mit Hardware ist zwingend
-platformunabhängigkeit wäre schön, ist aber nicht zwingend(kratzt sich 
natürlich mit dem oberen Punkt)
-Compilierte Programme müssem auf dem Zielsystem ohne runtime 
environment laufen(Java geht folglich nicht)

Ich programmiere sonst nur AVRs in C und habe kleine erfahrungen mit 
Processing und ganz wenig BASIC. Daher wäre eine an C angelehnte SPrache 
sehr vorteilhaft, ich bin aber offen für alles.

Schöhne Festtage,

Patrick

P.S.: Bitte keinen Glaubenskrieg starten, ein Vorschlag mit kleinen 
erläuterungen reicht mir ;)

von user (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wie wäre es mit C oder C++, da gibt es den gcc-mingw Compiler. Als GUI 
kannst du gtk verwenden. http://www.gtk.org/

von Peter II (Gast)


Bewertung
0 lesenswert
nicht lesenswert
also ich würde C# empfehlen. Es ist wenn man mono mit betrachtet 
Plattformunabhängig. Es braucht zwar eine Runtime die aber schon bei 
allen aktuellen Windows-systemen vorhanden ist.
Auch wenn man C oder C++ programmiert braucht man oft eine Runtime. (z.b 
msvcrt).

Aber was meinst du mit direkter Kommunikation mit der Hardware - unter 
Windows darf man nur dafür vorgesehen Schnittstellen verwenden. Nur 
Treiber sollte auf die Hardware zugreifen.

von Patrick W. (pawi777)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Peter II schrieb:
> Aber was meinst du mit direkter Kommunikation mit der Hardware - unter
> Windows darf man nur dafür vorgesehen Schnittstellen verwenden. Nur
> Treiber sollte auf die Hardware zugreifen.

das war zugegeben etwas unklar formuliert. Natürlich sollte die 
kommunikation über Treiber stattfinden. Aber eben über schon vorhandene, 
so dass ich keine eigene schreiben muss. Die serielle Schnittstelle und 
USB zum Beispiel sollten möglichst einfach und nativ zu verwenden sein.

Frohes Fest,

Patrick

von Peter II (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Patrick W. schrieb:
> Die serielle Schnittstelle und
> USB zum Beispiel sollten möglichst einfach und nativ zu verwenden sein.

Serial ist kein Problem. USB kommt halt darauf an, was für eine USB 
gerät. USB selber kann man kaum nativ verwenden. z.b USB zu Serial 
Adapter sind kein Problem weil es wie eine normale Serielle 
Schnittstelle zu behandeln ist. FTTI bieten für ihre Chips meines 
Wissens sogar C# binding an.

von Georg A. (georga)


Bewertung
0 lesenswert
nicht lesenswert
Ich weiss ja nicht, worauf deine Ideen dann laufen sollen, aber Qt 
klingt so, als könnte es viele deiner Anforderungen erfüllen:

Kost nix.

Massenweise (gute/auf das wesentliche konzentrierte) Codebeispiele.

Sehr bekannt, man findet eigentlich zu jedem Problem ein Posting mit 
Lösung ;)

Aber sowas von plattformunabhängig (Linux[so gut wie alle CPUs]/Win/Mac, 
neuerdings auch Android+iOS). Die GUI ist dann auch automatisch immer 
sehr nah an den nativen Elementen dran.

Basis C++, das mit gnu/cygwin/ming/VisualC++ und entweder deren "nativen 
IDEs" (make.../Visualstudio) oder der Qt-IDE entwickelt werden kann. Es 
gibt aber auch eine Javascript-ähnliche Interpreter-Sprache.

Schöne und schnelle OS/HW-Abstraktion (File-IO, Sound, Netzwerk, Serial, 
...). Für USB gibts AFAIR nichts von Qt, dafür die libusb (C), die auch 
überall läuft.

Sehr hilfreiche Klassen (Strings, Container, Threads, etc). Dagegen sind 
die Standard-C++-Strings fast schon Assembler...

Laufzeitumgebung in dem Sinn brauchts nicht, halt die Libs (so ca. 
10MB). Ist eine sehr überschaubare Anzahl von Files, nicht so wie der 
Java-Moloch. Kann man aber auch statisch dazulinken.

von F. F. (foldi)


Bewertung
0 lesenswert
nicht lesenswert
Nimm C++ und Codeblocks. C kannst du ja schon.

von Fred (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Lazarus bzw. halt Delphi sollte das abdecken.

Ich guck da gerade selber hin. Wirkt so altbacken und 90er, aber es 
scheint gut zu funktionieren, ohne viel Hype, dafür mit beachtlicher 
Community.

von T.roll (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Entweder C mit GTK+ oder C++ mit Qt. Der zweite Teil jeweils fürs 
Grafische. Die Grenzen zwischen beiden sind fließend.

Von C# kann man nur abraten. Läuft nur mit dem fetten .NET-Framework. 
Davon braucht man tollerweise auch noch alle Versionen auf dem System, 
weil Programm A 3.5 braucht, Programm B 4.0 und Programm C läuft nur mit 
dem aktuellen 4.5.
Auch wenn es Mono gibt, ist die Unterstützung unter Linux noch lange 
nicht perfekt.

von Peter II (Gast)


Bewertung
0 lesenswert
nicht lesenswert
T.roll schrieb:
> Von C# kann man nur abraten. Läuft nur mit dem fetten .NET-Framework.
> Davon braucht man tollerweise auch noch alle Versionen auf dem System,
> weil Programm A 3.5 braucht, Programm B 4.0 und Programm C läuft nur mit
> dem aktuellen 4.5.

aber es ist doch schon drauf, also braucht man es nicht extra zu 
installieren. Wenn man ein Programm für 3.5 erzeugt, dann hat man 
überhaupt keine Probleme auf Windows.

Damit sind die Programm sogar viel kleiner als mit C, weil das Framework 
schon vorhanden ist.

Der Vorteil von .net ist das es auf 64bit System auch gleich als 64bit 
läuft. Man braucht also nicht 2 Versionen auszuliefern.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Peter II schrieb:
> aber es ist doch schon drauf,

Nur wenn man beim Windows up-to-date ist oder auf eine alte Version 
abzielt. Wenn aber die Kundschaft noch mit älteren Versionen rumeiert, 
vielleicht auch mit älterer Hardware, und das Prog eine neue will, dann 
kommt Freude auf. Erst bei der Installation der fehlenden Runtime, dann 
bei jedem Windows-Update, der bei DotNet unangenehm lang dauert.

: Bearbeitet durch User
von Peter II (Gast)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Nur wenn man beim Windows up-to-date ist. Wenn aber die Kundschaft noch
> mit älteren Versionen rumeiert, vielleicht auch mit älterer Hardware,
> dann kommt Freude auf.

über wie alt reden wir denn?

WinXP ist kein Problem. Und auf win2k oder noch älter laufen auch 
aktuelle C Programm nicht immer. (siehe Firefox).

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Eine C/C++/D Alternative wäre eventuell noch http://www.digitalmars.com

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Peter II schrieb:
> WinXP ist kein Problem.

Doch, nämlich wenn die benötigte Runtime nicht drauf ist. Und wenn du 
mal erlebt hast, wie lange ein Atom rumeiert, bis er 4 DotNet Updates 
verdaut hat...

von Peter II (Gast)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Doch, nämlich wenn die benötigte Runtime nicht drauf ist. Und wenn du
> mal erlebt hast, wie lange ein Atom rumeiert, bis er 4 DotNet Updates
> verdaut hat...

darum habe ich geschrieben 3.5. Es ist keine Pflicht 4.0 Programm zu 
schreiben.

von Skeptiker (Gast)


Bewertung
0 lesenswert
nicht lesenswert
A. K. (prx) schrieb:

> wenn du
> mal erlebt hast, wie lange ein Atom rumeiert, bis er 4 DotNet Updates
> verdaut hat

Liegt wohl dann am Atom.

Wenn das was du hier schreibst bereits eine Hürde darstellt will ich gar 
nicht wissen was der Arme macht, wenn er 3D-Konstruktionszeugs startet 
oder Office oder ...

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Skeptiker schrieb:
> Liegt wohl dann am Atom.

Auch. Einerseits ist ein Atom langsam. Andererseits sind Microsofts 
Updates immer langsam, egal was für Hardware drunter klebt. Bei DotNet 
kommt hinzu, das die Updates als Halbfertigware ausgeliefert und erst 
auf dem Zielsystem nativ kompiliert werden. Was die Sache auch nicht 
grad beschleunigt.

> 3D-Konstruktionszeugs

Der TO hat nicht geschrieben, um welche Maschinenklasse es geht.

: Bearbeitet durch User
von Skeptiker (Gast)


Bewertung
0 lesenswert
nicht lesenswert
A. K. (prx) schrieb:

Skeptiker schrieb:
>> Liegt wohl dann am Atom.

> Auch. Einerseits ist ein Atom langsam. Andererseits sind Microsofts
> Updates immer langsam, egal was für Hardware drunter klebt ...

Dafür hast du bei MS aber auch keine täglichen Updates und letztlich 
kann man das Updaten auf den Reboot hinausschieben, also dann wenn man 
bsp. die Kiste eh ausschaltet.

von Ganga (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Was genau war eigentlich an den Forderungen des TO nach
- Plattformunabhängigkeit und
- lauffähig ohne Runtime
nicht verständlich?

Damit ist doch C# genauso raus wie Java.
Unterm Strich wäre Java vermutlich auf Windows-Systemen noch eher 
anzutreffen, als .NET. Allein schon, weil das JRE meistens immer 
irgendwie um Dunstkreis der Webbrowser mitinstalliert wird - und das 
schon lange vor .NET.

von Borislav B. (boris_b)


Bewertung
-1 lesenswert
nicht lesenswert
Ich würde zu C# raten. Im Gegensatz zu C++/Qt ist das WIRKLICH 
Cross-Platform (eine .exe läuft ohne nochmaliges Kompilieren auf Win, 
Mac, Linux (z.B. Raspberry Pi), und sogar Windows Phone, iOS und Android 
werden unterstützt).

Außerdem ist das erstellen von GUIs damit wirklich einfach, und die 
Sprache bzw. das Framework erlaubt eine sehr effiziente Entwicklung.
Dass eine Runtime benötigt wird ist dafür (so finde ich) zu 
verschmerzen.

von Ganga (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Boris B. schrieb:
> Dass eine Runtime benötigt wird ist dafür (so finde ich) zu
> verschmerzen.
Die Forderung war aber, dass es ohne Runtime läuft.

M.M.n. kommen da ernsthaft noch C/++ und Lazarus/Pascal in Frage.

von Peter II (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ganga schrieb:
> Die Forderung war aber, dass es ohne Runtime läuft.
> M.M.n. kommen da ernsthaft noch C/++ und Lazarus/Pascal in Frage.

und das braucht keine Runtime? Also überhaupt keine Abhängigkeiten zu 
msvcrt8 oder einer andere System lib?

Viele C / C++ Programm braucht auch eine Rumtime die teilweise erst 
installiert werden muss.

http://www.microsoft.com/de-de/download/details.aspx?id=30679

Patrick W will vermutlich keine extra runtime installieren, und diese 
Forderung ist bei C# erfüllt.

von Ganga (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Peter II schrieb:
> und das braucht keine Runtime? Also überhaupt keine Abhängigkeiten zu
> msvcrt8 oder einer andere System lib?
Ein C/++-Programm braucht i.d.R. seine Standardbibliothek, das ist 
richtig. Das wäre die MSVCRT. Die gehört aber schon zu einer 
standardkonformen hosted-C-Umgebung dazu. Und die wird auch vom CLR des 
.NET benötigt.

Peter II schrieb:
> Patrick W will vermutlich keine extra runtime installieren, und diese
> Forderung ist bei C# erfüllt.
Da sich Patrick über das Zielsystem ausschweigt, ist diese Forderung bei 
C# überhaupt nicht erfüllt.

Man kann jetzt natürlich die eigentlich recht simple Fragestellung von 
Patrick solange umdiskutieren, bis u.A. C# die bestmögliche Lösung dafür 
ist. Am besten reduzieren wir das jetzt darauf, dass zumindest ein 
Prozessor benötigt wird - dann passt auf einmal jede Programmiersprache 
wieder...

von Peter II (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ganga schrieb:
> Das wäre die MSVCRT. Die gehört aber schon zu einer
> standardkonformen hosted-C-Umgebung dazu.

nein ebend nicht, zumindest nicht jeder Version. Aus dem Grund gibt es 
sie ja als extra Installation.

von Ganga (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Peter II schrieb:
> nein ebend nicht, zumindest nicht jeder Version. Aus dem Grund gibt es
> sie ja als extra Installation.

MSVCRT und MSVCPP sind die Standardbibliotheken für C und C++. Und die 
gehören zu einer standardkonformen, 'hosted' C- bzw. C++-Umgebung dazu. 
Und sie ist bei jeder Windows-Installation dabei.

Dass man sie nachinstallieren kann und/oder muss, liegt daran, dass 
Microsoft bis heute keine Versionierung von Bibliotheken hinbekommt 
('DLL hell').

von Peter II (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ganga schrieb:
> Dass man sie nachinstallieren kann und/oder muss, liegt daran, dass
> Microsoft bis heute keine Versionierung von Bibliotheken hinbekommt
> ('DLL hell').

nein. An der msvrt steht hinten eine Versionnummer dran. Und die 
aktuellen (10er) ist auf einen XP nicht vorhanden muss also 
nachinstalliert werden.

von Ganga (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Peter II schrieb:
> nein. An der msvrt steht hinten eine Versionnummer dran. Und die
> aktuellen (10er) ist auf einen XP nicht vorhanden muss also
> nachinstalliert werden.
Es zwingt dich ja niemand, dein Programm gegen die aktuellste zu linken.

Mingw zum Beispiel linkt gegen MSVCRT.DLL, die ist seit 1998 bei Windows 
dabei.


Ungeachtet dessen ist das aber immer noch Sache der C/++-Umgebung. 
Plattformunabhängigkeit bedeutet ja nicht, dass man einen Binärfile 1:1 
übertragen kann. Genau dann nämlich hast du das Problem, dass die 
falsche Version der VCRT installiert ist.
Wenn man eine C-Umgebung auf dem Zielsystem hat und das Programm auf dem 
Zielsystem (oder für das Zielsystem) kompiliert, dann wird ja quasi 
zwangsläufig gegen die auf dem Zielsystem vorhandene Bibliothek gelinkt 
und gut ist.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Wenn man Programme statisch linkt, gibt es auch keine Abhängigkeiten 
von irgendwelchen MSVCRT.DLL o.ä.

Zumindest die Compiler von Microsoft unterstützen das schon immer.

von Sven P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. Firefly schrieb:
> Wenn man Programme statisch linkt, gibt es auch keine Abhängigkeiten
> von irgendwelchen MSVCRT.DLL o.ä.
>
> Zumindest die Compiler von Microsoft unterstützen das schon immer.
Der GCC kanns auch.

Aber dann krachts vermutlich im ABI...
Die Standardbibliothek ist ja auch nur eine (abstrakte) Schicht 
zwischen Betriebssystem und Anwendung, die ihrerseits wieder 
Abhängigkeiten zu anderen Bibliotheken usw. hat. Wenn man die statisch 
in die Anwendung hineinlinkt, kommt als nächstes der Kernel oder was 
auch immer. Dann müsste man schon das ganze Betriebssystem statisch 
dazulinken...

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> Dann müsste man schon das ganze Betriebssystem statisch
> dazulinken...

Wenn man das Betriebssystem im Sinne des Fragesteller als Runtime 
Environment betrachtet, dann ist die Forderung tatsächlich nur völlig 
ohne ein Solches zu erfüllen. Da wir und hier in einem Forum für 
Microcontroller befinden, bei denen das ja meistens so ist, sollte das 
jedoch kein Problem darstellen. ;-)

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> Aber dann krachts vermutlich im ABI...

Interessant wird es, wenn man DLLs verwendet, die ihrerseits eine 
dynamische Runtime nutzen, und die gleichen Funktionen sowohl von dieser 
Runtime als auch vom eigenen Programm verwendet werden. Beispielsweise 
die stdio FILE Pointer. Die gibts dann zweimal, was in die Hose geht, 
wenn so ein Pointer gemeinsam genutzt werden soll.

von Trollinger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Vermutlich wollte Patrik nur die Zeit bis zur Bescherung amüsant 
überbrücken. Jetzt hat er seine Eisenbahn ausgepackt und hat was zum 
Spielen. OS???-ABI's sind jetzt uninteressant ;-)

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> Aber dann krachts vermutlich im ABI...

Nö. Das funktioniert ohne Probleme. Ist ja auch nicht so, daß das eine 
hochgradig spezielle Frickelei ist, den Compiler dazu zu bringen, die 
statische Version zu verwenden.

Dazu liefert MS verschiedene Varianten der Runtime-Library aus:

msvcrt.lib                          /MD
   dynamisch, multithread, nutzt msvcr100*.dll

msvcrtd.lib                         /MDd
   dynamisch, multithread, debug, nutzt msvcr100d*.dll

libc.lib**                          /ML
   statisch, singlethread

libcd.lib**                         /MLd
   statisch, singlethread, debug

libcmt.lib                          /MT
   statisch, multithread

libcmtd.lib                         /MTd
   statisch, multithread, debug

Welche davon verwendet wird, ist allerdings keine Linkereinstellung, 
sondern eine Compilereinstellung, die jede einzelne Objektdatei 
betrifft.
Der Compiler erzeugt in der Objektdatei einen Eintrag, der auf die 
jeweilige zu verwendende Library hinweist.

Ein Mischen von Objektdateien, die mit unterschiedlichen Einstellungen 
übersetzt wurden --das schließt auch andere Libraries mit ein-- führt zu 
Linkerfehlermeldungen, die loszuwerden vielen Leuten schon viele graue 
Haare eingebracht hat.

Mit dumpbin und dem Kommandozeilenargument /directives kann angezeigt 
werden, welche Libraries als Default für eine Objektdatei verwendet 
werden sollen.


*) Die Dateinamen hängen von der verwendeten Compilerversion ab:

VS6.0  msvcrt(d).dll
VS2005 msvcr80(d).dll
VS2008 msvcr90(d).dll
VS2010 msvcr100(d).dll
VS2012 msvcr110(d).dll
VS2013 msvcr110(d).dll (kein Tippfehler, wie VS2012)

**) Die single-Thread-Varianten gibt es nur bei VS6.0

von Sven P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. Firefly schrieb:
> Nö. Das funktioniert ohne Probleme.

Sicher? Für Funktionalität, die gänzlich in der Bibliothek steckt 
(Strings, ...) kann ich mir das ja vorstellen.

Aber was ist denn mit Funktionen, die weiter in Richtung Kernel linken? 
Spätestens beim Syscall sollte die Bibliothek schon irgendwie zum Kern 
passen, denke ich...

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> Spätestens beim Syscall sollte die Bibliothek schon irgendwie zum Kern
> passen, denke ich...

Das geschieht natürlich durch dynamisches Linken mit den 
Betriebssystem-DLLs. Aber deren ABI ist weitestgehend konstant, so daß 
hier kein Änderungsbedarf besteht.

Inkompatibilitäten der verschiedenen Varianten der Win32-API betreffen 
nicht die von der C-Runtime-Library abgedeckte Funktionalität.

von Reinhard Kern (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Sven P. schrieb:
> Aber was ist denn mit Funktionen, die weiter in Richtung Kernel linken?
> Spätestens beim Syscall sollte die Bibliothek schon irgendwie zum Kern
> passen, denke ich...

Das ist unter Windows etwas anders als unter Linux: API-Aufrufe bleiben 
unverändert oder bekommen allenfalls neue Parameter, die Aufrufe nach 
alter Art funktionieren aber weiter. Bei neuen Funktionen werden eher 
neue Aufrufe vorgesehen in der Art FunktionXY_Ex. Wer also nicht gerade 
bewusst Funktionen verwendet, die erst mit W7 oder W8 eingeführt wurden, 
muss sich keine Gedanken machen, dass sein Programm auch auf einem 
uralten Windows läuft. Erste Ausnahmen: Windows 3.11-Programme laufen 
unter 64bit-Windows nicht mehr - nach rund 30 Jahren!

Selbst Terminal-Programme für WfW3.11 mit der unsäglichen 
16bit-COM-Schnittstellen-API laufen noch (unter 32bit), obwohl es längst 
komplett neue APIs dafür gibt.

Gruss Reinhard

von kopfkratzer (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Patrick W. schrieb:
> Hallo,
>
> ich suche nach Vorschlägen für eine Programmiersprache, die folgende
> Voraussetzungen möglichst erfüllt:
>
> -es sollte kostenlose oder zumindest preiswerte Compiler für Windows
> geben

GCC oder Microsoft VisualStudio

> -es muss möglich sein, ohne grossen aufwand GUIs zu erstellen

Platformunabhängig Qt oder MS VisualStudio nur für Windows

> -eine grosse Bekanntheit wäre vorteilhaft
> -möglichst direkte Kommunikation mit Hardware ist zwingend

Also für Treiber unter Windows braucht es das DDK und damit dürfte GCC 
erstmal schwieriger werden als VisualStudio

> -platformunabhängigkeit wäre schön, ist aber nicht zwingend(kratzt sich
> natürlich mit dem oberen Punkt)

Ja was nun, es gibt keine plattformunabhängige Treiberentwicklung ???

> -Compilierte Programme müssem auf dem Zielsystem ohne runtime
> environment laufen(Java geht folglich nicht)
>

Dann sag mal an welche "Zielsysteme" bedient werden sollen und welche 
davon Treiber benötigen ???
Wie schon erwähnt kann man statisch linken dann wird das Programm zwar 
größer braucht aber keine Version XYZ vom Zielbetriebssystem.
Also werde mal konkret um was es eigentlich geht, wenn Windows 
XP/VISTA/7/8 das aktuelle VisualStudio nehmen und dazu passende DDK.
doppelkopfkratz
VISTA Treiber laufen unter Win7, XP Treiber nicht oder ?
Was ist mit Win8, gehen da auch die VISTA/Win7 Treiber ?
Ist zu lang her :-P

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Reinhard Kern schrieb:
> Wer also nicht gerade bewusst Funktionen verwendet, die erst mit W7 oder
> W8 eingeführt wurden, muss sich keine Gedanken machen, dass sein
> Programm auch auf einem uralten Windows läuft.

Und wer sie unbewusst benutzt?  Weil er in seiner Testumgebung gar
nicht merkt, dass er damit eine Inkompatibilität erzeugt?

Wenn man sein aktuelles System nicht für den Test auf die reduzierte
API eines früheren "eindampfen" kann, kann man sowas zumindest nicht
verlässlich als "läuft auch unter XYZ" verkaufen.

Mein Lieblings-Binary hier ist übrigens:
1
% ls -l /usr/local/bin/utree
2
-rwxr-xr-x  1 bin  bin  179639 Apr 30  1992 /usr/local/bin/utree

Läuft immer noch. ;-)  (Zugegebenermaßen allerdings nur noch mit den
passenden CompatXY-Optionen im Kernel.)  Das wurde compiliert unter
386BSD 0.0 (Version 0.1 kam im Juni 1992 heraus).

Boris B. schrieb:
> Ich würde zu C# raten. Im Gegensatz zu C++/Qt ist das WIRKLICH
> Cross-Platform

Aber nur aus dem eingeschränkten Blickwinkel eines eingefleischten
Windowsianers.  (Dass es der Forderung des TE, ohne Runtime
auszukommen, widerspricht, wurde ja schon erwähnt.)  .NET gibt es halt
autoritativ nur für Windows.  Damit steht es schlechter da als Java.
Mono hinkt der jeweiligen .NET-Umgebung von Microsoft immer noch
ausreichend hinterher (was von Microsoft sicher gewollt ist), und
benimmt sich deutlich schwerfälliger (was sicher ebenfalls gewollt ist).

Mein Votum wäre auch für Qt: echte Multiplattformfähigkeit, die
Abstraktion der jeweiligen Plattform geht weit über die für die
GUI-Programmierung notwendigen Dinge hinaus (Verzeichnis-/Dateinamen,
Threads), die Dokumentation ist gut, und man bekommt es entweder
frei für Opensource-Projekte, oder gegen einen Obulus für kommerzielle
Dinge.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Und wer sie unbewusst benutzt?

Dann hat er nicht in die Dokumentation gesehen.

Aber das passiert nur mit API-Funktionen, nicht --und ich wiederhole: 
Nicht-- mit Funktionen, die von der C-Laufzeitumgebung aufgerufen 
werden.

Solange man nicht direkte Aufrufe der Win32-API veranstaltet, besteht 
also überhaupt keine wie auch immer geartete "Gefahr".

Erst wenn man irgendeine der zum Win32-SDK gehörenden Headerdateien 
einbindet und darin deklarierte Funktionen aufruft, erst dann sollte 
man in der Dokumentation nachsehen, welche OS-Version Voraussetzung ist.

Aber auch das ist kein unentwirrbares Problem; da die Win32-API-Aufrufe 
durch die Verwendung von Importlibraries der entsprechenden DLLs 
abgewickelt werden, gibt es beim Verwenden solcher Funktionen auf einer 
diese nicht zur Verfügung stellenden OS-Version ein ganz klar 
definiertes Fehlerverhalten -- der Programmlader stellt fest, daß er 
einen "Prozedureinsprungspunkt" nicht finden kann und gibt das als 
Fehlermeldung aus, das Programm selbst wird gar nicht erst gestartet.

Das sieht dann z.B. so aus:

"Prozedureinsprungspunkt LogonAsUserW in Kernel32.dll nicht gefunden".

> Wenn man sein aktuelles System nicht für den Test auf die reduzierte
> API eines früheren "eindampfen" kann, kann man sowas zumindest nicht
> verlässlich als "läuft auch unter XYZ" verkaufen.

Das ist natürlich immer ein Problem. Nur, welchen Windows-Programmierer 
interessiert ernsthaft noch die Entwicklung von Programmen, die auf 
musealen Windows-Versionen laufen? Da gibt es erst recht die geplante 
Obsoleszenz ...

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. Firefly schrieb:
> Aber das passiert nur mit API-Funktionen, nicht --und ich wiederhole:
> Nicht-- mit Funktionen, die von der C-Laufzeitumgebung aufgerufen
> werden.

Hmm, worauf setzt denn dann die C-Laufzeitumgebung aber auf, wenn
nicht auf dem OS-API?  Klar, fast alles, was zum Standard-Sprachumfang
von C89 gehört (C99 ist ja zumindest bei Microsoft sowieso ein
Fremdwort), braucht kaum was vom OS-API.  system() wäre da noch die
berühmte Ausnahme.  Aber mit dem bisschen kann man auch nicht viel
machen.  Einen Compiler schreiben vielleicht :), der muss nur Dateien
lesen und schreiben, das ist ausreichend im Standard genormt.

Aber für jede reale Applikation kommt man doch über kurz oder lang in
Bereiche, in denen man mehr vom OS braucht, als Standard-C hergibt.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Hmm, worauf setzt denn dann die C-Laufzeitumgebung aber auf, wenn
> nicht auf dem OS-API?

Auf den Teilen, die sich seit Jahrzehnten nicht geändert haben. Die 
API-Definitionen, die MS 1993 mit der ersten NT-Version herausgegeben 
hat, sind für die Laufzeitumgebung ausreichend.

> Aber für jede reale Applikation kommt man doch über kurz oder lang in
> Bereiche, in denen man mehr vom OS braucht, als Standard-C hergibt.

Ja. Und da muss man sich sowieso die API-Dokumentation durchlesen.

Kein Grund aber, auf den Komfort statisch gelinkter Anwendungen zu 
verzichten.

von Peter II (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. Firefly schrieb:
> Kein Grund aber, auf den Komfort statisch gelinkter Anwendungen zu
> verzichten.

es gibt aber auch Nachteile! die C-Runtime kann auch Sicherheitslücken 
enthalten diese werden, hoffentlich, durch MS behoben. Aber in statisch 
gelinkten Anwendungen sind sie dann immer noch enthalten.

von Sven P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Peter II schrieb:
> es gibt aber auch Nachteile!

Es bläst die Größe des Executables auch 'ein wenig' auf...

von Reinhard Kern (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Und wer sie unbewusst benutzt?  Weil er in seiner Testumgebung gar
> nicht merkt, dass er damit eine Inkompatibilität erzeugt?

Das kann es eigentlich nicht geben: wer halbwegs ernsthaft verkaufbare 
Software programmiert, muss natürlich alles an Testumgebung haben, was 
er als zulässige Umgebung garantieren will. Das ist ja heute auch kein 
Problem mehr, ich habe z.B. virtuelle Maschinen von DOS6.22 bis 
Windows8.1 (und natürlich Linuxe, Solaris, Berkeley...). Und wer noch 
tiefer einsteigen will, enthält von MS auch Betriebssysteme in allen 
Sprachen, einschliesslich Chinesisch usw.

Bei den API-Funktionen steht im übrigen dabei, ab welcher BS-Version sie 
verfügbar sind, lesen hilft also auch hier weiter. Wenn ich meine 
Software nicht unter Windows2000 teste, kann ich natürlich nicht dafür 
garantieren, dass sie dort auch läuft, aber erfreulicherweise ist das 
fast immer so.

Unter Linux gibt es das anscheinend so nicht, mein VMWare Player muss 
nach jedem Kernelupdate neu compiliert oder gelinkt werden, manchmal 
geht es auch erst nach neuem Download. Da wird Kompatibilität also von 
vornherein überhaupt nicht angestrebt.

Gruss Reinhard

von Rolf Magnus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Mein Votum wäre auch für Qt: echte Multiplattformfähigkeit, die
> Abstraktion der jeweiligen Plattform geht weit über die für die
> GUI-Programmierung notwendigen Dinge hinaus (Verzeichnis-/Dateinamen,
> Threads), die Dokumentation ist gut, und man bekommt es entweder
> frei für Opensource-Projekte, oder gegen einen Obulus für kommerzielle
> Dinge.

Qt kann man auch mit Closed-Source-Software nutzen, seit es unter der 
LGPL steht, was soweit ich mich erinnere seit Version 4 so ist. Einzige 
Einschränkung: Man muß dynamisch linken, um die Lizenzbedingungen zu 
erfüllen.

von Rolf Magnus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Zusatz: Mit "Qt" meinte ich hier die freie Version von Qt.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Reinhard Kern schrieb:

> Und wer noch
> tiefer einsteigen will, enthält von MS auch Betriebssysteme in allen
> Sprachen, einschliesslich Chinesisch usw.

Braucht man auch nur dort.  Alle anderen Systeme müssen für diesen
Zweck nur die jeweiligen Sprachmodule nachinstallieren. ;-)  Nur bei
MS muss man dann gleich das ganze OS neu installieren ...

> Unter Linux gibt es das anscheinend so nicht, mein VMWare Player muss
> nach jedem Kernelupdate neu compiliert oder gelinkt werden, ...

VMware greift sehr tief ins System ein, und benötigt die aktive
Mithilfe eines Kerneltreibers.  Nur dieser wird jedesmal neu compiliert
und gelinkt, damit er auch exakt zum Kernel passt.

Mit einem normalen API (welches auf dem OS aufsetzt) hat das rein gar
nichts zu tun.

von Sven P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Reinhard Kern schrieb:
> Unter Linux gibt es das anscheinend so nicht, mein VMWare Player muss
> nach jedem Kernelupdate neu compiliert oder gelinkt werden, manchmal
> geht es auch erst nach neuem Download. Da wird Kompatibilität also von
> vornherein überhaupt nicht angestrebt.
Ist aber nur die halbe Wahrheit.

Unter Linux strebt man i.d.R. (der geneigte Leser mag die Grenze selbst 
ziehen...) nicht Binärkompatibilität an, sondern Quellenkompatibilität. 
Dass es meistens dann doch auch noch binärkompatibel ist, ist ein 
schöner Seiteneffekt.

Dafür kann man dann auch öfter mal die Schnittstellen aufräumen, ohne 
Jahrzehnte lang alten Ballast mitschleppen zu müssen. Aber gerade für 
Kernelschnittstellen gibts DKMS.

von Falk S. (falkschilling)


Bewertung
0 lesenswert
nicht lesenswert
Hi,

zunächst zu den Fragen des Threaderöffners:
aufgrund seiner Vorkenntnisse würde ich an dieser Stelle eher zu einem 
dezenten Mix raten.

Wenn eine Oberfläche zu schreiben ist: nimm C#, Java oder einen in C/C++ 
eingebetteten Webserver. Und letzteres wirklich nur dann, wenn C# oder 
Java nicht gehen.

Wenn hardwarenah zu schreiben ist: nimm C oder C++. Und damit meine ich 
nicht das Lesen und Schreiben von COM-Ports oder ähnlichen Schnulli, 
sondern Sachen mit hohen Datenraten, z.B. Frames von 'ner Kamera oder 
so.

Wenn du minimale Dependencies willst: statisch gelinkte C/C++-Binaries 
sind da das Non-Plus-Ultra.

Sei dir bitte im Klaren, dass dein beschriebener Kenntnisstand keine 
klare Empfehlung einer Programmiersprache zulässt. Wenn du noch nie 'ne 
UI mit C/C++ gebaut hast, wird das Erlernen von C/C++ kurz- bis 
mittelfristig teurer für dich sein. Denn die Dottie- bzw. 
Kaffeebohnen-Programmierer mit ihren Frameworks sind damit um Welten 
schneller fertig, als du mit C/C++ je sein wirst, weil sie getestete und 
simpel zu verwendende Komponenten haben.

Selbst wenn du QT, wxWidgets, MFC oder welches UI-Framework auch immer 
nutzt: um Daten zu visualisieren oder anzuzeigen, komplexe Webabfragen, 
usw. usf. da biste mit .NET oder Java viel schneller fertsch.

Fazit: schreib 'ne DLL oder 'ne shared library wo's hardwarenah wird und 
nutze für UIs Programmiersprachen, deren Design dir den UI-Entwurf 
einfach macht, sprich: erstell dir ein Portfolio an Programmiersprachen 
für die jeweiligen Zwecke.
C/C++ wäre für den Einstieg eine gute Brücke zwischen hardwarenah und 
UI, es gibt viele fertige Libs und DLLs - aber ohne diese Zusätze bist 
du auch aufgeschmissen und erfindest das Rad neu.
So wie du deinen Post geschrieben hast, implizieren deine Anforderungen 
fast C/C++.

-- zur Diskussion --

Bei Windows [XP] wird es nur durch die GDI32.dll, Kernel32.dll und 
User32.dll systemnah. Kommt man daher und schreibt mit dem MASM Code 
dagegen mit x86-ASM per Hand, kann man über diese Dll-Importe direkt 
systemnah Grafikfunktionen aufrufen. Diese Stabilität der API ist echt 
ein Riesen-Plus bei Microsoft. Dabei sind Spracheinstellungen halt feste 
Constraints des Systems. Ist halt eher ein Top-Down-Design mit bewussten 
Einschränkungen.

In der Linux-Welt funktioniert der dezentrale Entwicklungsansatz sehr 
gut, mit der Einschränkung, dass sich ABI's ändern können und man sich 
auch schnell mal das System zerschiessen kann. Der Kernel selber ist da 
freilich ein Musterbeispiel für Abwärtskompatibilität, das ist schon 
klar. Und da das System auf vielen kleinen Applikationen aufsetzt, 
verteilt sich die Komplexität aber eben auf das Gesamtsystem - und nicht 
wie bei Windows - nur auf die Applikationen. Im Endeffekt isses wurscht: 
baust du dir so ein Windows Embedded zusammen und lässt Funktionen weg, 
die deine Software braucht, hast du das gleiche Problem wie bei einem 
selbstgebauten Linux  (z.B. ELDK oder OpenEmbedded) auch: du kannst die 
Software nicht ausführen.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Braucht man auch nur dort.  Alle anderen Systeme müssen für diesen
> Zweck nur die jeweiligen Sprachmodule nachinstallieren. ;-)  Nur bei
> MS muss man dann gleich das ganze OS neu installieren ...

Das muss man auch bei MS nicht unbedingt müssen; die 
Windows-7-Enterprise-Variante, die mit dem MSDN-Paket ausgeliefert 
wurde, ist eine englischsprachige, der mit verschiedenen Languagepacks 
nachgeholfen wird. Da kann man dann auch, wie es sich gehört, mit 
verschiedenen Benutzerkonten in verschiedenen Sprachen gleichzeitig 
arbeiten.

Können tun sie es also schon, die Microsofts, nur standardmäßig machen 
sie es aus irgendwelchen Gründen nicht.

von Kai S. (kai1986)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

du kannst dir mal PureBasic anschauen.
http://www.purebasic.com/german/index.php
Ist zwar nicht kostenlos (kostet 79€), lässt sich aber auf Windows, 
Linux und Mac kompilieren, ist sehr schnell in der Programmausführung, 
benötigt außer des ausführbaren Datein nichts und hat auch eine gute 
Commuinty, wenn auch nicht so groß wie die von C/C++. Zudem ist es 
hervorragend dokumentiert. Zum GUI erstellen ist ein Tool dabei, mit dem 
das ganze per Drag & Drop sehr intuitiv und schnell geht.

Gruß Kai

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.