Wird noch mit der WinApi programmiert?

[volkard]

WinAPI zum öffnen, schreiben, schließen von dateien, zum prozesse starten, threads stoppen, semaphoren aufmachen und pipes zu pipen, für mailsots, mutexe und iocompletun ports, für high resolution timers, zumn runterfahren des system und zum files locken, zum speicher allokieren, sperren freigeben, mmappen oder nur zu löschen. das alles wird mit feinen funktionen aus der windows.h angeboten und es gibt keinen grund, die nicht zu nehmen.

für das gui-zeugs sind natürlich nun andere überlegungen gefragt. gehts dir um gui mit winapi oder winapi selbst?

[Vertexwahn]

Ich empfehle dir .Net - oder irgendeine GUI-Lib

[coolio]

howdy alter kumpel,
ich sage es schadet nie winapi zu kennen und zu können, du verstehst besser was sich genau abspielt als wenn du nur mit einem baukasten programmierst der alles verschleiert-

mfg,
coolio

[Vertexwahn]

wenn du nur mit einem baukasten programmierst der alles verschleiert-

sagt das mal einen Java Programmierer - hey Leute das ist doch nicht euer ernst - für ein kleine Oberfläche gleich WinAPI zu benutzen - da nimm ich doch lieber .Net

[Vertexwahn]

außerdem kann man von Net aus eh das ganze WinAPI Zeugs benutzen wenn man will - per DLL Invoke:

public class WinAPI
	{
		#region DLL_Imports_WinAPI
		[DllImport("user32.dll")]
		public static extern IntPtr GetDesktopWindow();

		[DllImport("gdi32.dll")]
		public static extern bool BitBlt(
			IntPtr hdcDest, // handle to destination DC
			int nXDest, // x-coord of destination upper-left corner
			int nYDest, // y-coord of destination upper-left corner
			int nWidth, // width of destination rectangle
			int nHeight, // height of destination rectangle
			IntPtr hdcSrc, // handle to source DC
			int nXSrc, // x-coordinate of source upper-left corner
			int nYSrc, // y-coordinate of source upper-left corner
			System.Int32 dwRop // raster operation code
			);

		public const Int32 SRCCOPY = 0xCC0020;

		[DllImport("user32.dll",EntryPoint="GetSystemMetrics")]
		public static extern int GetSystemMetrics(int nIndex);

		public const Int32 SM_CXVIRTUALSCREEN = 78; // from <winuser.h>
		public const Int32 SM_CYVIRTUALSCREEN = 79;

		[DllImport("user32.dll")]
		public static extern void SetCursorPos(int x, int y);

		public const uint MOUSEEVENTF_MOVE       = 0x0001; /* mouse move */
		public const uint MOUSEEVENTF_LEFTDOWN   = 0x0002; /* left button down */
		public const uint MOUSEEVENTF_LEFTUP     = 0x0004; /* left button up */
		public const uint MOUSEEVENTF_RIGHTDOWN  = 0x0008; /* right button down */
		public const uint MOUSEEVENTF_RIGHTUP    = 0x0010; /* right button up */
		public const uint MOUSEEVENTF_MIDDLEDOWN = 0x0020; /* middle button down */
		public const uint MOUSEEVENTF_MIDDLEUP   = 0x0040; /* middle button up */
		public const uint MOUSEEVENTF_WHEEL      = 0x0800; /* wheel button rolled */
		public const uint MOUSEEVENTF_ABSOLUTE   = 0x8000; /* absolute move */

		public const uint KEYEVENTF_EXTENDEDKEY = 0x0001;
		public const uint KEYEVENTF_KEYUP       = 0x0002;

		public const uint INPUT_MOUSE    = 0;
		public const uint INPUT_KEYBOARD = 1;

		public struct MOUSE_INPUT
		{
			public uint dx;
			public uint dy;
			public uint mouseData;
			public uint dwFlags;
			public uint time;
			public uint dwExtraInfo;
		}

		public struct KEYBD_INPUT
		{
			public ushort wVk;
			public ushort wScan;
			public uint   dwFlags;
			public uint   time;
			public uint   dwExtraInfo;
		}

		[StructLayout(LayoutKind.Explicit)]
		public struct INPUT
		{
			[FieldOffset(0)]
			public uint type;

			// union
			[FieldOffset(4)]
			public MOUSE_INPUT mi;

			[FieldOffset(4)]
			public KEYBD_INPUT ki;
		}

		[DllImport("user32.dll")]
		public static extern uint SendInput(
			uint nInputs,     // count of input events
			ref INPUT input,
			int cbSize        // size of structure
			);

		[DllImport("user32.dll")]
		public static extern uint MapVirtualKey(
			uint uCode,     // virtual-key code or scan code
			uint uMapType   // translation to perform
			);

		[StructLayout(LayoutKind.Explicit)]
		public struct Rect 
		{
			[FieldOffset(0)] public int left;
			[FieldOffset(4)] public int top;
			[FieldOffset(8)] public int right;
			[FieldOffset(12)] public int bottom;
		}   

		[DllImport("gdi32")]
		public static extern int GetClipBox(System.IntPtr hDC,ref Rect r);

		#endregion
	}

[howdy]

Vertexwahn: .NET Programme laufen nicht auf Windows 95. Das ist der große Nachteil.

[geeky]

"Windows 95" ist doch selber schon nen Nachteil
Bei uns auf der Firma wird Software mit Mindestvorraussetzung Windows 2000 programmiert - Und selbst dafür hat Microsoft einen Teil des Supports schon lange eingestellt.

[RED-BARON]

genau !

Windows 3.1 wird auch nicht unterstützt, weil dort die Win32API fehlt

[:-((]

In vielen Firmen ist Windows 95 noch häufig im Einsatz!

[geeky]

Setzen die Firmen dann noch Software ein, dessen Hersteller es nicht mehr gibt ?
Oder zu geizig upzugraden ? Oder selber fast pleite ?
Nagut, kommt natürlich auch drauf an wofür der Rechner genutzt wird und was da für Anwendungen drauf laufen

[_BackBONE_]

Ich hab mal in einer Elektronik-Fertigung gearbeitet.
Da gab es auch ein paar Rechner mit Win95. Die hatten aber ausschließlich die Aufgabe die Raumtemparatur, Luftfeuchtigkeit und Stickstoffzufur zu den Lagerplätzen zu überwachen.

Damals (vor ca. vier Jahren) hatten wir noch etwas betagtere Bestückungsautomaten von Sanyo im Einsatz.
Für diese Maschinen gab es lediglich Software für DOS.
Deshalb hatten wir auch zwei 486er um Programme von den Maschinen up- bzw, downzuloaden.

Layout- und Programmerstellung, Dokumentation u.s.w. wurde auf Rechnern mit Windows NT gemacht.

Allerdings besteht hier nicht die Notwendigkeit Programme für die alten Rechner zu schreiben, und das einzige Tool das ich mal schreiben mußste war ein simpler Konverter der ein Programm der Sanyo Maschine (ASCII) in ein Program für eine Panasonic Maschine (ebenfalls ASCII) umwandelt.
Der Konverter mußste auch nur unter NT laufen.

Aber ich würd auch nicht ausschließen daß in anderen Firmen auch noch eigenschnitz für ältere Systeme praktiziert wird.

[spruch]

"never change a running system"

[Vertexwahn]

ich könnte mir vorstellen um ein großes Publikum zu erreichen auf Java bzw. Net zu verzichten damit dem (unerfahrenem) User, die Installation von Net bzw. Java erspart bleibt

ich sage ja nicht das WinAPI unwichtig ist und nicht mehr gebraucht wird, aber wer es sich aussuchen kann sollte doch lieber auf Net, Java oder ähnliches setzen - spart einfach einen haufen arbeit - schon allein die "Automtische" ausrichtung von Steuerelementen... usw...

[o_O]

Und letztendlich brauch man für .NET auch immernoch die Laufzeitumgebung...
Und fürn kleines progrämmchen gleich das Framework runterladen zu müssen is doch auch beschissen.

[Ein ehemaliger Benutzer]

Ja und? Ab Longhorn ist es dabei und früher war es ja auch nicht anders mit dem Win32s unter Windows 3.1

[wash]

Wird noch mit der WinApi programmiert?

Nein, denn ich hab linux

[Gast]

wash schrieb:

Wird noch mit der WinApi programmiert?

Nein, denn ich hab linux

Und Langeweile.
http://www.c-plusplus.net/forum/viewtopic-var-t-is-119682.html

[geldgeil]

Es gibt noch die ganze Bandbreite bei den Betriebssystemen, gerade bei PC-Systemen mit speziellen Aufgaben (Elektronik, Analytik, ...). Daher sollte ein universelles Programm von Win95 bis WinXP laufen. Im Bürobereich hat in größeren Firmen W2K die Oberhand, in kleineren Betrieben stehen auch noch Maschinen mit Win98. Oft will niemand eine Veränderung, weil ein PC-Wechsel meistens Stress und manchmal auch Daten- und Geldverlust bringt. Daher kann man noch nicht von einer .NET-Basis sprechen, auch wenn MS das gerne so hätte. An der Uni lernt man heute eher Java als C++. C# läuft nicht auf Linux. Daher passt zu C/C++ sehr gut die WinAPI oder deren Kapselung, z.B. MFC.

[geeky]

geldgeil schrieb:

C# läuft nicht auf Linux.

Stimmt so nicht: z.B.: http://www.mono-project.com
sogar die Windows-Eigenheiten wie Windows.Forms werden da derzeit lauffähig gemacht.