VB Runtime implentieren

Hier können Sie auf Deutsch diskutieren. Bedenken Sie, dass Sie in den englischen Foren mehr Nutzer ansprechen.

Moderators: EmuandCo, Dr. Fred, frik85

Phlip
Posts: 11
Joined: Tue Oct 24, 2006 9:17 pm

VB Runtime implentieren

Post by Phlip » Sat Nov 04, 2006 2:21 pm

Hi,
ich habe die Idee die Runtimes von VB4/5/6 zu
implentieren bloß wie. Ich weiß nicht
wie man diese in das Endsetup einbaut
und registriert. Das Ziel sind laufende VB
Anwendungen auf ReactOS und somit
vielleicht können dann auch Dienstprogramme
leichter programmiert werden. Ich denke dann
melden sich auch mehr Programmierer für
Zusatzprogramme.

Phlip

nightshade
Posts: 14
Joined: Fri Dec 30, 2005 7:19 pm
Location: w4.noe.austria
Contact:

Post by nightshade » Sat Nov 04, 2006 9:17 pm

Willst du die vbruntime nachprogrammieren, oder willst du sie nur in setup miteinbinden? Letzteres ist sicher nicht erlaubt.

Aber ich denke du kannst eine batch datei schreiben die die runtime aus dem internet lädt und dann per regsvr32.exe registriert - falls das schon funktioniert.

Du solltest aber wissen, das nichts anderes in reactos eingebunden wird als c und c++. Ein vb programm wird also sicher nicht in reactos enthalten sein.
Diverse zusatzprogramme, wie etwa tuning tools oder dergleichen, gibt es für windows schon en masse. Die brauchen also nicht neu für reactos programmiert werden.

mfg ash

Phlip
Posts: 11
Joined: Tue Oct 24, 2006 9:17 pm

Lizenz

Post by Phlip » Sun Nov 05, 2006 9:37 am

Hi,
danke für die Info. Bloß ich
finde nirgendswo im Internet
ne Lizenz für die VB Runtimes.
Und da finde ich da könnte
ma die doch einbauen wenn
nirgend wo ne Lizenz auftaucht.

Phlip

frik85
Developer
Posts: 829
Joined: Fri Nov 26, 2004 7:48 pm
Location: Austria, Europe
Contact:

Re: Lizenz

Post by frik85 » Sun Nov 05, 2006 10:29 am

Phlip wrote:Bloß ich finde nirgendswo im Internet ne Lizenz für die VB Runtimes. Und da finde ich da könnte ma die doch einbauen wenn nirgend wo ne Lizenz auftaucht.
Nur weil du keine Lizenz findest, heißt es noch lange nicht das du machen kannst (mit der VB Runtime) was du möchtest. :roll:

... schon mal etwas von der MS EULA gehört ?

1) man kann die VB4-6 Runtime in ReactOS bereits installieren
2) VB 1-6 Reihe ist "Tod", und wird seitens MS nicht mehr unterstützt.
3) DotNet wird in einer der kommenden Versionen von ReactOS unterstützt werden.
4) Für ReactOS (das Betriebssystem selbst) kommen nur in C programmierte Programme/Treiber (mit GPL kompatibler Lizenz und Source Code) in Frage. In Ausnahmefällen auch C++ und ASM.
5) Andere Programme könne später mithilfe eines Package Managers installiert werden.


Warum gerade "C"?
C build tools gibt es für wirklich jede Platform.
In C programmierten Programme sind im Vergleich zu anderen Programmiersprachen um einiges performanter, schneller, benötigen weniger resourcen, etc.
C ist die derzeit ideale Sprache für Betriebssysteme.
C++ ist um einiges langsamer in der Ausführung als auch beim build Prozess. Der ObjectOrientierte Overhead ist deutlich erkennbar.
...

Phlip
Posts: 11
Joined: Tue Oct 24, 2006 9:17 pm

Lizenz

Post by Phlip » Sun Nov 05, 2006 12:00 pm

Hi,

Danke schön für die Info gut dann lass ich das mal und programmier in C. Macht mir nicht aus. Hab nicht gedacht das bereits die Runtime eingebaut sind. Hätte wäre sie noch nicht drin die Kompatibilität Zu Windows gestärkt meinte nur vielleicht kann ich mich so vielleicht ein bisschen bei dem Projekt mit helfen und MItarbeiter werden.

Phlip

Matthias
Posts: 496
Joined: Tue Dec 27, 2005 12:43 am

Re: Lizenz

Post by Matthias » Sun Nov 05, 2006 6:43 pm

frik85 wrote: Warum gerade "C"?
C build tools gibt es für wirklich jede Platform.
C++-Tools gibt's auch für jede Plattform auf der ReactOS je laufen wird.
frik85 wrote:In C programmierten Programme sind im Vergleich zu anderen Programmiersprachen um einiges performanter, schneller, benötigen weniger resourcen, etc.
Für die Performance eines Programms sind in erster Linie die Fähigkeiten des Programmierers verantwortlich - ein Heapsort ist auch in Perl schneller als ein Bubblesort in C. Außerdem kann man so allgemein nicht sagen, das C schneller sei - Fortran steckt bei numerischer Mathematik nach wie vor alles andere in die Tasche, die Wahl der Sprache hängt in erster Linie von der Anwendung ab.
frik85 wrote:C ist die derzeit ideale Sprache für Betriebssysteme.
Ohne weitere Begründung kann man kaum dagegen argumentieren. Dass das dennoch so gesehen wird kommt wohl daher, dass wichtigen Betriebssysteme in C geschrieben sind - über die Qualität der Sprache sagt das aber nichts aus.
frik85 wrote:C++ ist um einiges langsamer in der Ausführung als auch beim build Prozess. Der ObjectOrientierte Overhead ist deutlich erkennbar.
Das ist für 99,9% aller Anwendungen völlig vernachlässigbar und außerdem nicht immer wahr (z. B. gibt es das "inline"-Schlüsselwort nur in C++, und damit kann man oftmal erhebliche Geschwindigkeitsvorteile gegenüber C erzielen). Außerdem sind C-Programme schlecht lesbar und fehleranfällig (z. B. schreibt man schnell mal über Arrays hinaus usw.), die Sprache unterstützt Modularisierung nicht vernünftig (keine namespaces oder sowas), die Standardbibliothek ist extrem rudimentär, generischen Code zu schreiben ist fast unmöglich, es gibt keine Exceptions und und und... All das macht die Entwicklung in C fehlerträchtig, anstrengend und unproduktiv, ohne dass man dafür irgendeinen Ausgleich bekäme (OK, vielleicht 2% bessere Performance, dafür kann man sich dann ein Eis kaufen :roll:). Fazit: Wenn man sich aus Nostalgie 30 Jahre in die Vergangenheit zurückversetzen möchte, sollte man C verwenden. Wenn man dagegen in endlicher Zeit ein möglichst fehlerfreies und vollkommen ausreichend schnelles Programm schreiben möchte, verwendet man eine Sprache die dem aktuellen Stand der Technik entspricht. C++ ist ganz gut, weil es eine recht vollständige Sprache ist und keine Laufzeitumgebung a la Java oder C# benötigt (das wirkt sich dann zugegebenermaßen recht stark auf die Dauer des Programmstarts aus).

phoenix
Posts: 84
Joined: Mon Jul 24, 2006 12:37 am

Post by phoenix » Sun Nov 05, 2006 8:10 pm

Ich denke, der Performanceunterschied zwischen C/C++ ist schon etwas größer. Fakt ist aber, dass C++ definitiv einfacher zu schreiben und leichter zu warten ist. Deswegen sind meiner Meinung die beiden Sprachen relativ gleichwertig (Ich bevorzuge C++). Dass die Entwickler keinen C++-Code im Betriebssystemkern haben wollen, verstehe ich, ein Sprachenmix macht das ganze unübersichtlich.
Warum aber auch bei normalen Anwendungen "In Ausnahmefällen auch C++" erlaubt ist, verstehe ich nicht.
(Zumal ja doch einiges anscheinend in C++ geschrieben wurde, zB der Explorer.)
my blog: phoenix.de.am

frik85
Developer
Posts: 829
Joined: Fri Nov 26, 2004 7:48 pm
Location: Austria, Europe
Contact:

Post by frik85 » Sun Nov 05, 2006 9:02 pm

Der Explorer wird ggf. in C neu/um- geschrieben.

C++ hat eine "großen" Nachteil, das kompilieren dauert um ca. 10 Mal länger als ein gleichwertiger C Code.
Darum ist C++ im Hauptzweig von ReactOS nicht gern gesehen.
In RosApps ist es nicht ganz so arg, da dieser Teil seltener kompiliert wird.
Es ist übrigens nicht nur GNU g++ Schuld, auch der Objekt Orientierte Overhead benötigt länger zum optimieren, etc.

Matthias
Posts: 496
Joined: Tue Dec 27, 2005 12:43 am

Post by Matthias » Mon Nov 06, 2006 2:18 am

@frik85: woher nimmst Du die Information, dass der Explorer in C neu geschrieben werden soll? Das wäre IMO eine ziemlich unkluge Idee. Jedenfalls kann die zum kompilieren benötigte Zeit nicht das Problem sein. Die Zeit, die man beim kompilieren mit C spart, verliert man wieder wenn man drei Tage nach irgendwelchen Speicherzugriffsfehlern sucht die mit C++ nie passiert wären.

Dominik2
Posts: 141
Joined: Sat Dec 03, 2005 7:45 pm

Post by Dominik2 » Mon Nov 06, 2006 4:09 pm

Hallo,
ich finde es auch schade, dass man gegenüber C++ so konservativ eingestellt ist! Gerade die nicht so kritischen User-Mode-Programme sollte man schon mit C++ programmieren. Wenn man in einem Dateisystemtreiber aus Geschwindigkeitsgründen auf C++ verzichten möchte und lieber C einsetzt, OK. Aber bei Programmen wie Explorer, Wordpad, Paint und ähnlichem sollte alleine schon wegen der Wartbarkeit C++ eingesetzt werden.
Auf C++ wegen der Kompilierzeit zu verzichten, ist wirklich eine sehr (sehr, sehr :wink:) schlechte Idee. Da es immer schnellere Rechner gibt, wird sich so etwas mit der Zeit eh automatisch relativieren (der Endbenutzer ist davon sowieso nicht betroffen). Aber ein Programm von der Größe des (komplett fertigen) Explorers bis in alle Zeiten in C pflegen zu müssen, macht keinen Spaß. In der Ausführungsgeschwindigkeit ist ein gut programmiertes C++-Programm auch nicht wesentlich langsamer also ein C-Programm. Zumindest nicht in der Dimension, als dass sich eine Implementierung in C rechtfertigen würde.

C in allen Ehren, aber C++ (und ab ca. 2009 C++0x) gibt es nicht umsonst!

ThePhysicist
Developer
Posts: 508
Joined: Mon Apr 25, 2005 12:46 pm

Post by ThePhysicist » Mon Nov 06, 2006 11:01 pm

Eigentlich wollte ich hier jetzt nen längeren Kommentar schreiben, aber ich lass es. Kein Bock auf Language-Wars.
Ich finde es gut und sinnvoll, dass ROS in C programmiert ist und fände es gut, wenn der Explorer auch in C programmiert wäre. Aber soll jeder denken was er will. Ich erinnere mich, dass es da ein Projekt gab, ein OS in Turbo-Pascal zu programmieren. Hmm, warum nicht.

frik85
Developer
Posts: 829
Joined: Fri Nov 26, 2004 7:48 pm
Location: Austria, Europe
Contact:

Post by frik85 » Tue Nov 07, 2006 9:00 am

Matthias wrote:@frik85: woher nimmst Du die Information, dass der Explorer in C neu geschrieben werden soll?
Wenn man im #reactos irc channel jeden Tag ist, weiß man über den Stand der Dinge bescheid.

Ob jetzt wirklich ein Explorer in C implementiert wird, hängt davon ab ob der/die entsprechenden Dev(s) (jetzt ohne Namen zu nennen) die Zeit finden/haben.

Es geht um Minuten, die ein gleichwertige C++ app länger zum builden benötigt als ein gleichwertiges C app, jedenfalls im Falle des Explorer's.
Zudem ist der derzeitige Explorer leider ziemlich inkompatibel mit WinNT Explorer (Shell-Extentions, Themes, etc.).

Radhad
Posts: 605
Joined: Wed Apr 12, 2006 5:09 pm
Contact:

Post by Radhad » Tue Nov 07, 2006 5:18 pm

Wenn es an der Kompatibilität liegt, kann ich es verstehen. Auf meinem Rechner läuft ReactOS recht lahm (Virtualiserung über VMWare - 768 MB RAM für VM), von daher seh ich da nicht wirklich Performace-Unterschiede. Auch die "mehrere Minuten" die der Compiler länger benötigt kann ich an und für sich auch nicht nachvollziehen, liegt vielleicht auch daran, dass ich noch nicht solch ein komplexes Programm geschrieben habe (und auch keine Software entwickle).

Matthias
Posts: 496
Joined: Tue Dec 27, 2005 12:43 am

Post by Matthias » Thu Nov 09, 2006 7:04 pm

ThePhysicist wrote:fände es gut, wenn der Explorer auch in C programmiert wäre.
Begründung? Die Laufzeit-Geschwindigkeitsvorteile sind lächerlich, und die Compile-Zeiten sollten kein Argument gegen vernünftige Sprachen sein, entscheidend ist das Produkt, was herauskommt (und bei Verwendung eines ordentlichen make-Systems und ausreichender Modularisierung ist die Compile-Dauer vernachlässigbar.)

phoenix
Posts: 84
Joined: Mon Jul 24, 2006 12:37 am

Post by phoenix » Thu Nov 09, 2006 9:12 pm

die Compile-Zeiten sollten kein Argument gegen vernünftige Sprachen
Der BuildBot wird sich freuen... ^^
Der brauch ja schon lang genug zum Compilieren, wenn der für jede Revision einen Nightly erzeugt...
Auf meinem Rechner läuft ReactOS recht lahm (Virtualiserung über VMWare - 768 MB RAM für VM)
Also meine VMWare-Maschine läuft mit 64 MB Ram richtig flott... mehr brauch die ja auch nich.

Also wie gesagt: Für das Kernbetriebssystem ist C sinnvoll, für den Rest... naja, ist C++ zumindest gleichberechtigt.
my blog: phoenix.de.am

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests