gibt es Analog zu _vscprintf(..)
-
Hallo an alle,
ich benutze in meinem Programm (unter Windows!) das Funktion
int _vscprintf(const char *, va_list)Das Programm wird problemloß kompiliert, aber beim linken bekomme ich folgende Meldung:
test.obj error LNK2001: unresolved external symbol __imp___vscprintfWeißt jemand vielleicht, ob es in Windows-API das gleiche Funktion gibt,
wie _vscprintf(..)?
Es muss unbedingt ein Funktion von Windows-API sein,
da mein Programm auf jedem Windows-Rechner laufen soll. Dafür habe ich versucht
nur C-Sprache und nicht C++ zu benutzen. Grund: Wie ich weiß, wurde WindowsBetriebsSystem in C-Sprache geschrieben.Vielen Dank im Vorauß
-
Wie ich sehe hast du keine Ahnung, Grund:
goldslawik schrieb:
da mein Programm auf jedem Windows-Rechner laufen soll. Dafür habe ich versucht
nur C-Sprache und nicht C++ zu benutzen. Grund: Wie ich weiß, wurde WindowsBetriebsSystem in C-Sprache geschrieben.Achja, ich brauche dringend Ersatzreifen aus Japan, Grund: Mein Auto wurde da gebaut.
-
Hallo Entenwickler,
Sehr witzig!
Wenn ich ein C++Programm (mit Klassen, virtuelle Methoden, ....) schreibe, kompiliere u.s.w, dann
will ich z.B., dass irgendjemand mein Programm auf seinem Windows_Rechner ausführt
und auf diesem Rechner ist kein VisualStudioC++ installiert!Was passiert dann?!
-
Dann läuft das (abgesehen von Problemen mit fehlenden Debug-DLLs, die du aber bei einem C-Programm genauso hast) problemlos - C++ wird genauso wie C in Maschinencode übersetzt, der von jedem Rechner (mit der passenden Architektur) verarbeitet werden kann.
(und im Allgemeinen mußt du dich erst (und nur) bei den Teilen auf C-Niveau runterbegeben, die direkt mit der WinAPI kommunizieren wollen)
-
Hallo CStoll,
ich habe gehört, dass UNIX/LINUX genau so wie WINDOWS mit C-Sprache geschrieben wurde. Wofür schreibt man dann manchmal im Quellcode folgende Zeilen:
#ifdef _WIN32
...
#else // für LINUX
...Sieht stdlib.h in Windows anderes als in LINUX?
Kannst du mir vielleicht kurz erklären?
-
Die Funktionen des ANSI Standards (sowohl für C als auch für C++) werden in Windows und Unix auch identisch umgesetzt - solche
#ifdef _WIN32Konstrukte benötigst du nur, wenn du die Welt des Standards verlässt (z.B. gibt es für die meisten WinAPI-Funktionen kein direktes Äquivalent in Linux - so daß du sie mit Linux-Bordmitteln nachbilden mußt (und umgekehrt)).
-
goldslawik schrieb:
Sieht stdlib.h in Windows anderes als in LINUX?
Kannst du mir vielleicht kurz erklären?Total irrelevant wie die aussieht. Wichtig ist nur dass sie das macht was im Standard definiert ist. Jede Implementierung sieht da anderst aus, und es gibt viele (auch auf gleichen Platformen).
-
Ergänzend zu CStolls Aussage:
goldslawik schrieb:
...
ich habe gehört, dass UNIX/LINUX genau so wie WINDOWS mit C-Sprache geschrieben wurde.
Wofür schreibt man dann manchmal im Quellcode folgende Zeilen:...Das Eine hat mit dem Anderen nichts zu tun. Erstes interessierte die Betriebssystem-Entwickler von Windows/Linux.
Das Andere sind "Schalter einer Entwicklungsumgebung" ... mal als Extrembeispiel:Für ein in Assembler entwickeltes Betriebssystem könnte ich trotzdem eine eigene Sprache "Rutzifutz" einführen und verwenden - und zwar so, dass sie auf jeder Maschine läuft !
... und wenn ich einen "plattformunabhängigen Kern" von Rutzifutz entworfen habe, habe ich bestimmt auch einen Schalter _WIN32 für die Verwendung von Win32-spezifischen Teilen.Gruß,
Simon2.
-
Vielen Dank an beiden für Ihre Hilfe
Jetzt ist mir klar geworden.Es bleibt mir eine Frage noch offen:
Wenn ich im LINUX #include <windows.h> benutzen will, heißt dann windows.h im LINUX anders?
-
Meinst du in einem Raumschiff findest du eine Handbremse wie in deinem Auto?
-
goldslawik schrieb:
...
Wenn ich im LINUX #include <windows.h> benutzen will, heißt dann windows.h im LINUX anders?Japp.
Da ist man tief in den "plattformspezifischen Innereien" .... und naturgemäß lässt sich der Standard nicht darüber aus, welche Funktionalitäten da zu bieten sind.
Dieses include "heißt" auch nicht nur anders, sondern es ist sehr wahrscheinlich, dass es unter Linux (oder jedem anderem Betriebssystem) gar kein include gibt, das dieselben Funktionalitäten (sogar noch unter denselben Namen) liefert wie in der windows.h ....Wenn es also plattformunabhängig sein soll: Am Besten auf den Einsatz von windows.h verzichten und wenn das nicht geht: JEDES daraus verwendete Element überprüfen, ob und wie es unter Linux unterstützt wird und geeignet "mappen".....
Ein Totalverzicht dürfte allerdings deutlich einfacher sein.
Gleich vorab: Wenn eine GUI plattformübergreifend programmiert werden soll, muß man sich seeeehr viele Gedanken (und Zugeständnisse) machen. Da bietet es sich eher an, einen plattformunabhängigen (GUI-freien) Kern zu entwickeln und dann für jede Plattform eine eigene GUI zu entwickeln, die diesen Kern steuert.
Gruß,
Simon2.
P.S.: (nur zur Klarstellung) "Plattform" bedeutet hier z.B. "Betriebssystem"; 2 unterschiedliche Windows-Rechner fallen also unter "dieselbe Plattform".