Windows-CLI-Programme (EXE) entwickeln - wie anfangen?

Schlangenmensch

@EinNutzer0 Es gibt halt einfach keinen Grund wenn man für Windows Systeme entwickelt bei einem Windows Dev System über eine VM unter Linux zu arbeiten. Das ist einfach wirr und bringt nur unnötige Komplexität.

Und, weil du gefragt hast: Ich entwickel aktuell mit Visual Studio Professional.

Wenn ich privat was mache, bin ich aktuell von VSCode mit entsprechenden Plugins ganz angetan, unabhängig vom Betriebssystem.

EinNutzer0

@Schlangenmensch sagte in Windows-CLI-Programme (EXE) entwickeln - wie anfangen?:

Es gibt halt einfach keinen Grund [...]

Aber es läuft (erstmal) : Bild 1

Quiche Lorraine

@EinNutzer0 sagte in Windows-CLI-Programme (EXE) entwickeln - wie anfangen?:

Oder... vielleicht mal etwas anders gefragt... womit entwickelt ihr?

× Visual Studio Professional
× Visual Studio Code
× Atmel Studio
× Segger Studio
× Android Studio

Privat:
× Visual Studio Code
× Spyder
× Qt Creator

EinNutzer0

Danke. Mit CodeLite bin ich bisher ganz zufrieden, auch wenn ich noch nicht weiß, wie Auto-Completion geht... Das wäre für mich ein K.-o.-Kriterium...

Kann VSC das? (auf Linux)

vscode kann so ziemlich alles was vs auch kann, nur eben nicht native, sondern mit der hilfe von first- und thirdparty plugins/extensions.

EinNutzer0

Oki...

Welche plugins/extensions würdet ihr mir für VSC empfehlen?

https://code.visualstudio.com/docs/languages/cpp

EinNutzer0

@Cardiac Das ist nicht gerade hilfreich... Einfach sparen beim nächsten Mal.

> Fragt nach empfohlenen extensions
> Bekommt eine extension empfohlen
> "Ist nicht gerade hilfreich, bitte keine empfehlungen mehr"

Alles klar, ich werde deine threads kuenftig ignorieren
muppet...

EinNutzer0

@Cardiac sagte in Windows-CLI-Programme (EXE) entwickeln - wie anfangen?:

"Ist nicht gerade hilfreich, bitte keine empfehlungen mehr"

Ich meinte damit, einfach ein Link ohne weitere Erklärung ist nicht hilfreich.

EinNutzer0

Meine Idee, mit x86_64-w64-mingw32-g++ für Windows zu übersetzen, war eher Sch***... a) Viele Libs und Abhängigkeiten werden nicht gefunden, b) die für Windows kompilierte .exe-Datei wird sofort als Virus eingestuft.

Führt wohl kein Weg an Cygwin bzw. MinGW vorbei, wenn man das VS vermeiden möchte und Programme für Windows übersetzen möchte.

Quiche Lorraine

@EinNutzer0 sagte in Windows-CLI-Programme (EXE) entwickeln - wie anfangen?:

Kann VSC das?

Kann ich nicht exakt beantworten da ich VSC nur für Web (PHP), Python und Dokumentation (Markdown + Mermaid) nutze.

Für Python gibt es hierzu das Python und PyLance Plugin. Das PyLance Plugin sorgt für das Auto Completion. Und ehrlich gesagt funktioniert dieses sehr gut, man bekommt zu jeder Funktion automatisch die Foku angezeigt,...

Unter Linux scheint das PyLance in das Python Plugin gewandert zu sein.

Leon0402

@EinNutzer0 sagte in Windows-CLI-Programme (EXE) entwickeln - wie anfangen?:

Danke. Mit CodeLite bin ich bisher ganz zufrieden, auch wenn ich noch nicht weiß, wie Auto-Completion geht... Das wäre für mich ein K.-o.-Kriterium...

Kann VSC das? (auf Linux)

Klar, mit extension. Die Extension https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools wird standardmäßig empfohlen (weil sie auch von Microsoft ist) und kann alles mögliche: Syntax Highlighting, Auto-Completion, Code Formatting, Built in docs, Navgiations Features etc.

Persönlich nutze ich die trotzdem nicht gerne, weil offiziell nur für das MS Vs Code verfügbar etc. Stattdessen nutze ich lieber https://marketplace.visualstudio.com/items?itemName=llvm-vs-code-extensions.vscode-clangd. Dafür braucht man eine compilation database, welche von verschiedenen Tools generiert werden kann. CMake kann diese generieren, wenn man Make oder Ninja verwendet. Funktioniert recht gut unter Linux, unter Windows hatte ich da glaube ich immer meine Probleme.
Ansonsten sind die Features relativ ähnlich.

Tyrdal

@EinNutzer0 sagte in Windows-CLI-Programme (EXE) entwickeln - wie anfangen?:

Danke. Mit CodeLite bin ich bisher ganz zufrieden, auch wenn ich noch nicht weiß, wie Auto-Completion geht... Das wäre für mich ein K.-o.-Kriterium...

Kann VSC das? (auf Linux)

Klar, genau dafür wurde ja das Language Server Protocol erfunden. Also einfach immer nur die passenden LSP Server installieren.

EinNutzer0

@Tyrdal sagte in Windows-CLI-Programme (EXE) entwickeln - wie anfangen?:

Klar, genau dafür wurde ja das Language Server Protocol erfunden. Also einfach immer nur die passenden LSP Server installieren.

Hää?

Tyrdal

@EinNutzer0 sagte in Windows-CLI-Programme (EXE) entwickeln - wie anfangen?:

@Tyrdal sagte in Windows-CLI-Programme (EXE) entwickeln - wie anfangen?:

Klar, genau dafür wurde ja das Language Server Protocol erfunden. Also einfach immer nur die passenden LSP Server installieren.

Hää?

Google!

Finnegan

@EinNutzer0 sagte in Windows-CLI-Programme (EXE) entwickeln - wie anfangen?:

Führt wohl kein Weg an Cygwin bzw. MinGW vorbei, wenn man das VS vermeiden möchte und Programme für Windows übersetzen möchte.

Nur zur Info "MinGW" bzw. das auf jeden Fall zu bevorzugende "MinGW-W64" ist mehr oder weniger nur die Implementierung der C-Standardbibliothek (und Header/Import-Libs um auf die Windows-API zuzugreifen). Mit dieser lässt sich dann der reguläre GCC bauen (diverse MinGW-spezifische Patches mal aussen vor gelassen).

Das was du vermutlich unter "MinGW" verstehst, sind mit dieser C-Standardbibliothek gebaute GCC+Binutils-Tools und Bibliotheken (Compiler, Linker, libstdc++, die C++-Standardbibliothek, etc) und eben die C/Win-Bibliotheken selbst. Bei denen ist keine Installation erforderlich. Die kann man einfach so in einen Ordner packen und rumkopieren (USB-Stick auf Rechner, etc). Wenn die Bibliotheken und Utilities alle die richtigen relativen Pfade zu den Compiler/Linker-Executables haben, dann findet GCC die auch. Z.B. bin/ für die .exe-Dateien, lib/, include/ für Bibliotheken und Header oder auch <target-triple>/lib/, <target-triple>/include/ für zielsystem-spezifische Files, wenn GCC nicht als nativer (gcc.exe/g++.exe) sondern als Cross-Compiler gebaut wurde (<target-triple>-g++.exe wie z.B. x86_64-w64-mingw32-g++.exe oder arm-linux-gnueabi-g++.exe). Diese relativen Pfade sind in den GCC-Tools hartcodiert und ermöglichen es relativ einfach, mal eben eine völlig andere GCC-Toolchain zu verwenden (Clang kennt diese Pfade übrigens auch, wenn es im GCC-kompatiblen Modus und nicht im MSVC-Modus läuft, so kann man z.B. auch mit Clang+MinGW kompilieren).

Cygwin ist damit nicht direkt vergleichbar, weil es ein völlig anderes Konzept verfolgt. Statt Funktionen der Windows-API auf die minimial benötigten Funktionen der C-Standardbibliothek abzubilden, versucht Cygwin eine möglichst vollständige Unix-API in einer Emulationsschicht zu implementieren - das ist das, was man sich mit der benötigten cygwin1.dll reinzieht. Cygwin ist daher mehr wie eine "Unix-Emulation", während man mit MinGW tatsächlich native Windows-Programme erstellt.

Ich weiss nicht genau, was du mit "weitestgehend unberührt" für den Entwicklungsrechner meinst, aber viel weniger als einen portablen Ordner mit den MinGW und den GCC-Tools ist denke ich kaum machbar. Wenn ich da Installations-Programm von MinGW-w64 stört (das macht nicht viel mehr, als Dateien an die richtige Stelle auszupacken und evtl. Pfade zu setzen), dann mach die MinGW-w64-Installation auf deinem Privatrechner und kopier dann einfach den MinGW-Ordner. Das sollte alles auch ohne Installation laufen. Dazu empfehle ich noch MSYS2 zu installieren, damit hast du dann auch noch eine Bash-Shell mit den entsprechenden Unix-Tools. Damit ist es dann auch möglich mit deutlich weniger Stress z.B. Autotools-basierte Projekte zu bauen (configure/make). Nicht alle interessanten Bibliotheken lassen sich nämlich so einfach auf Windows bauen - auch wenn der Code selbst relativ portabel ist und keine bis wenig Anpassungen erfordert - für Autotools-Projekte kommt man um eine Unix-Shell nicht herum. Alternativ geht da auch WSL(2) - damit hsat du eine relativ vollwertige Linux-Umgebung, die auch Windows-.exe-Dateien ausführen kann. Damit kann man die GCC-Tools für Windows auch ausführen, sofern die Pfade richtig gesetzt sind.

Eine weitere Alternative wäre auch GCC+MigGW für Linux in WSL2 zu installieren. Das sind dann Linux-Executables und die lassen ich recht einfach mit dem Paketanager der verwendeten Distribution installieren. Diese erzeugen dann (als Cross-Compiler) .exe-Dateien für Windows. Die Performance dürfte da auch etwas beser sein, erfahrungsgemäss lahmt Windows schonmal gerne, wenn viele Prozesse gestartet werden und auf vielen kleinen Dateien hantiert wird - selbst wenn der Echtzeit-Virenschutz ausgeschaltet ist (massive Bremse beim kompilieren grösserer Projekte - z.B. so einen kompletten GCC zu bauen kann da auf Windows und mit Echtzeit-Schutz schonmal ne ganze Größenordnung länger dauern (!)).

Was die IDE angeht finde ich VSCode gar nicht mal so schlecht. VSCode lässt sich auch portabel installieren, so dass an den Ordner nach belieben hin- und herkopieren kann (recherchier mal im Netz). Damit kannste dir auch nen USB-Stick zusammenbauen, von dem du direkt arbeiten kannst, ohne überhaupt irgendwelche Dateien auf deinen Arbeitrechner kopieren zu müssen - Performance mal aussen vor gelassen - große Projekte zu kompilieren ist schon ziemlich IO-lastig.