Schmerzfreie Windows-Programmierung?

COLOSSUS

Administrator
GNUltra

Registered: Dec 2000
Location: ~
Posts: 12133

18.06.2007 - 17:47

Ich "darf" wohl demnaechst eine kleine Eigenentwicklung fuer POSIX-Systeme (Darwin und GNU) auf Win32 portieren; dabei geht es hauptsaechlich um Prozesskontrolle, die ich auf den UNIXoiden Systemen urspruenglich via bash realisiert, und dann in C reimplementiert habe.

Ich kann es nicht beschwoeren, aber ich schaetze mal, dass es fork() und exec*() so unter Windows ja nicht gibt, und ich den Code deswegen wohl nicht einfach so mit mingw32 (hab ich noch nie angegriffen) auf WIndows kompilieren kann, und das dann alles wie gehabt losmarschiert - was ich nun suche ist eine Moeglichkeit, ein (graphisches) Tool das beliebige Kindprozesse starten und stoppen kann zu implementieren, und zwar so dass das Ergebnis ueber NSIS installierbar, kommerziell verwertbar und ohne irgendwelche nonstandard-Runtimes auf Zielsystemen lauffaehig ist.
Wie genau ich das anstelle ist mir eigentlich egal, ich waere auch bereit, dafuer so weit in eine neue Sprache einzusteigen, dass ich den Task at hand eben bewaeltigen kann. Viel mehr moechte ich mit der Plattform aber nicht zu tun haben.

Kann mir jemand was empfehlen?

Tia:
- colo

mat

Administrator
Legends never die

Registered: Aug 2003
Location: nö
Posts: 25520

18.06.2007 - 18:05

war lustig zu lesen, so als würdest du dich "grausen". hey, das sind betriebssysteme, also alles halb so schlimm

wenn du c++ beherrscht dann gibt es natürlich die unterste variante: win32. nicht unbedingt handlich, aber auch schon ewig alt. davon würde ich die finger lassen..

für ein kleines grafisches tool eigenet sich imo ein dialogbasierendes MFC-Programm. paar overrideables und die buttons auf den dialog stempeln und die sache ist erledigt.

für die implementierung der prozessfunktionen steht dir die msdn zur verfügung.

als letzte lösung bietet sich natürlich c# an. damit hab ich jedoch nicht viel am hut.

Prof_Albert

Little Overclocker

Registered: Aug 2004
Location: Weinviertel
Posts: 124

18.06.2007 - 18:26

Also ich weiß das jetzt nicht sicher aber:
Wurden nicht im Rahmen des Cygwin projekts, die fehlenden libs für Prozessverwaltung und Interprozesskommunikation mal nachgebaut?
Wird teilweise halt etwas graulig emuliert. Aber das wäre mit wenig aufwand lösbar denk ich.

DKCH

Administrator
...

Registered: Aug 2002
Location: #
Posts: 3299

18.06.2007 - 18:57

cygwin bietet fork und exec, jo.

COLOSSUS

Administrator
GNUltra

Registered: Dec 2000
Location: ~
Posts: 12133

18.06.2007 - 21:07

Ja, ist mir klar - nur erfuellt cygwin (zumindest meiner Ansicht nach)

Zitat
ohne irgendwelche nonstandard-Runtimes auf Zielsystemen lauffaehig

Danke an mat fuer den Input, jetzt weisz ich zumindest schon mal, wo ich in Doku herumstochern kann

DKCH

Administrator
...

Registered: Aug 2002
Location: #
Posts: 3299

18.06.2007 - 23:55

würde sich aber wohl am ehesten als schmerzlos portieren bezeichnen lassen, aber das musst du ja selber wissen

edit: wenn du aber sowieso relativ von vorn anfangen willst würd ich trotzdem C# ins auge fassen: mit dem System.Diagnostics-namespace solltest du sehr einfach zum ziel kommen. benötigt halt die .net-runtime...

gue

Addicted

Registered: Feb 2003
Location: Linz
Posts: 400

19.06.2007 - 10:28

Also wenn du planst, demnächst Microsoft noch mehr zu hassen und/oder die Woche danach in einer Klapse zu verbringen, dann kannst du die MFC oder die Win32 API verwenden.
Ansonsten kannst du noch probieren, das ganze mit pthreads zu meistern oder eben C# & .NET/Mono verwenden, was imho sehr angenehm zum Programmieren ist. Bei den neueren XPs (also mit SP2 oder so) ist iirc auch so eine .NET Runtime auch schon dabei.

Prof_Albert

Little Overclocker

Registered: Aug 2004
Location: Weinviertel
Posts: 124

19.06.2007 - 17:13

Zitat von gue
Bei den neueren XPs (also mit SP2 oder so) ist iirc auch so eine .NET Runtime auch schon dabei.

.NET-runtime ist nicht dabei (zumindest musste ich die bis jetzt immer nachinstallieren).

während es bei cygwin afaik genügt, die nötigen .dlls (cygwin.dll) im arbeitsverzeichnis zu haben

Bearbeitet von Prof_Albert am 19.06.2007, 17:16

COLOSSUS

Administrator
GNUltra

Registered: Dec 2000
Location: ~
Posts: 12133

19.06.2007 - 17:28

Zitat von Prof_Albert
während es bei cygwin afaik genügt, die nötigen .dlls (cygwin.dll) im arbeitsverzeichnis zu haben

Echt? Das waere ja genial... Muss ich heute abend checken, vielen Dank fuer den Hinweis

that

Hoffnungsloser Optimist

Registered: Mar 2000
Location: MeidLing
Posts: 11342

19.06.2007 - 22:33

Zitat von COLOSSUS
Echt? Das waere ja genial... Muss ich heute abend checken, vielen Dank fuer den Hinweis

Ja, normalerweise reicht die cygwin1.dll. Ein Problem für dich könnte nur sein, dass das GPL-Software ist.

COLOSSUS

Administrator
GNUltra

Registered: Dec 2000
Location: ~
Posts: 12133

19.06.2007 - 22:43

Ueberhaupt nicht, da auch das Gros der restlichen verwendeten Komponenten unter GPL steht. Aber damit sind sowohl der Auftraggeber als auch ich einverstanden - I love my own dogfood

COLOSSUS Administrator GNUltra Registered: Dec 2000 Location: ~ Posts: 12133	18.06.2007 - 17:47 Ich "darf" wohl demnaechst eine kleine Eigenentwicklung fuer POSIX-Systeme (Darwin und GNU) auf Win32 portieren; dabei geht es hauptsaechlich um Prozesskontrolle, die ich auf den UNIXoiden Systemen urspruenglich via bash realisiert, und dann in C reimplementiert habe. Ich kann es nicht beschwoeren, aber ich schaetze mal, dass es fork() und exec*() so unter Windows ja nicht gibt, und ich den Code deswegen wohl nicht einfach so mit mingw32 (hab ich noch nie angegriffen) auf WIndows kompilieren kann, und das dann alles wie gehabt losmarschiert - was ich nun suche ist eine Moeglichkeit, ein (graphisches) Tool das beliebige Kindprozesse starten und stoppen kann zu implementieren, und zwar so dass das Ergebnis ueber NSIS installierbar, kommerziell verwertbar und ohne irgendwelche nonstandard-Runtimes auf Zielsystemen lauffaehig ist. Wie genau ich das anstelle ist mir eigentlich egal, ich waere auch bereit, dafuer so weit in eine neue Sprache einzusteigen, dass ich den Task at hand eben bewaeltigen kann. Viel mehr moechte ich mit der Plattform aber nicht zu tun haben. Kann mir jemand was empfehlen? Tia: - colo
mat Administrator Legends never die Registered: Aug 2003 Location: nö Posts: 25520	18.06.2007 - 18:05 war lustig zu lesen, so als würdest du dich "grausen". hey, das sind betriebssysteme, also alles halb so schlimm wenn du c++ beherrscht dann gibt es natürlich die unterste variante: win32. nicht unbedingt handlich, aber auch schon ewig alt. davon würde ich die finger lassen.. für ein kleines grafisches tool eigenet sich imo ein dialogbasierendes MFC-Programm. paar overrideables und die buttons auf den dialog stempeln und die sache ist erledigt. für die implementierung der prozessfunktionen steht dir die msdn zur verfügung. als letzte lösung bietet sich natürlich c# an. damit hab ich jedoch nicht viel am hut.
Prof_Albert Little Overclocker Registered: Aug 2004 Location: Weinviertel Posts: 124	18.06.2007 - 18:26 Also ich weiß das jetzt nicht sicher aber: Wurden nicht im Rahmen des Cygwin projekts, die fehlenden libs für Prozessverwaltung und Interprozesskommunikation mal nachgebaut? Wird teilweise halt etwas graulig emuliert. Aber das wäre mit wenig aufwand lösbar denk ich.
DKCH Administrator ... Registered: Aug 2002 Location: # Posts: 3299	18.06.2007 - 18:57 cygwin bietet fork und exec, jo.
COLOSSUS Administrator GNUltra Registered: Dec 2000 Location: ~ Posts: 12133	18.06.2007 - 21:07 Ja, ist mir klar - nur erfuellt cygwin (zumindest meiner Ansicht nach) Zitat ohne irgendwelche nonstandard-Runtimes auf Zielsystemen lauffaehig Danke an mat fuer den Input, jetzt weisz ich zumindest schon mal, wo ich in Doku herumstochern kann
DKCH Administrator ... Registered: Aug 2002 Location: # Posts: 3299	18.06.2007 - 23:55 würde sich aber wohl am ehesten als schmerzlos portieren bezeichnen lassen, aber das musst du ja selber wissen edit: wenn du aber sowieso relativ von vorn anfangen willst würd ich trotzdem C# ins auge fassen: mit dem System.Diagnostics-namespace solltest du sehr einfach zum ziel kommen. benötigt halt die .net-runtime...
gue Addicted Registered: Feb 2003 Location: Linz Posts: 400	19.06.2007 - 10:28 Also wenn du planst, demnächst Microsoft noch mehr zu hassen und/oder die Woche danach in einer Klapse zu verbringen, dann kannst du die MFC oder die Win32 API verwenden. Ansonsten kannst du noch probieren, das ganze mit pthreads zu meistern oder eben C# & .NET/Mono verwenden, was imho sehr angenehm zum Programmieren ist. Bei den neueren XPs (also mit SP2 oder so) ist iirc auch so eine .NET Runtime auch schon dabei.
Prof_Albert Little Overclocker Registered: Aug 2004 Location: Weinviertel Posts: 124	19.06.2007 - 17:13 Zitat von gue Bei den neueren XPs (also mit SP2 oder so) ist iirc auch so eine .NET Runtime auch schon dabei. .NET-runtime ist nicht dabei (zumindest musste ich die bis jetzt immer nachinstallieren). während es bei cygwin afaik genügt, die nötigen .dlls (cygwin.dll) im arbeitsverzeichnis zu haben Bearbeitet von Prof_Albert am 19.06.2007, 17:16
COLOSSUS Administrator GNUltra Registered: Dec 2000 Location: ~ Posts: 12133	19.06.2007 - 17:28 Zitat von Prof_Albert während es bei cygwin afaik genügt, die nötigen .dlls (cygwin.dll) im arbeitsverzeichnis zu haben Echt? Das waere ja genial... Muss ich heute abend checken, vielen Dank fuer den Hinweis
that Hoffnungsloser Optimist Registered: Mar 2000 Location: MeidLing Posts: 11342	19.06.2007 - 22:33 Zitat von COLOSSUS Echt? Das waere ja genial... Muss ich heute abend checken, vielen Dank fuer den Hinweis Ja, normalerweise reicht die cygwin1.dll. Ein Problem für dich könnte nur sein, dass das GPL-Software ist.
COLOSSUS Administrator GNUltra Registered: Dec 2000 Location: ~ Posts: 12133	19.06.2007 - 22:43 Ueberhaupt nicht, da auch das Gros der restlichen verwendeten Komponenten unter GPL steht. Aber damit sind sowohl der Auftraggeber als auch ich einverstanden - I love my own dogfood

Schmerzfreie Windows-Programmierung?

Forum Index > Software > Coding Stuff

COLOSSUS

mat

Prof_Albert

DKCH

COLOSSUS

DKCH

gue

Prof_Albert

COLOSSUS

that

COLOSSUS