Ros-general

ros-general@reactos.org

3 participants
1050 discussions

by Steven Edwards

lets replace rosapps/calc with this. --- James Briggs <james(a)ActionMessage.com> wrote: > From: "James Briggs" <james(a)ActionMessage.com> > To: wine-patches(a)winehq.org > Subject: Please review winecalc source > Date: Fri, 30 Jan 2004 01:19:59 -0800 > > Hello wineapps comrades. > > I have posted the source to my LGPL Windows calc clone here: > > http://am0.net/winecalc/ > > Although it needs an updated parser (a day's work by me or somebody > else), > the program is otherwise in good shape. (I understand a dual stack > approach for args and operators has worked for other calculator > projects.) > > It builds on MSVC 7.0 and lcc. > > Please take a look at the source and notify me of what needs > to be improved for wine apps checkin acceptance. > > Also, there are the standard language files a la winemine that > need to be translated from English. > > I am interested in doing at least one more Wine desktop app in 2004, > so > your suggestions are welcome. > > Thanks, James Briggs. > > > > __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/

20 years, 10 months

Interest in ReactOS

by Ge van Geldorp

It seems the release of 0.2 generated a lot of interest. Most of the reactions are pretty predictable, either "Why???" or "Wow!!!" with the "Wow" ones being in the majority I think. The website served 1.8 million requests the last 24 hours. At times it was overloaded, but it seems we have found a set of parameters which works pretty well now. Gé van Geldorp.

20 years, 10 months

German FAQ

by Robert K.

Hi Michael, i made a german FAQ for your website, tonight. I've post it here. Maybe some of the german capable readers have still some comments or suggestions to it. Werden alle Windowsprogramme laufen? ReactOS implementiert das Win32-API. Theoretisch sollten dann alle Programme laufen. Doch unterscheidet sich die Theorie mal wieder von der Praxis und einige Programme werden nicht laufen. Das sind dann solche Programme, die sich auf irgendwelche (meist undokumentierten) Besonderheiten der Microsoftsysteme verlassen bzw. die Betriebssystemversion prüfen. Im Moment sieht es mit funktionierenden Programmen naturgemäß schlecht aus. Doch über die Zeit werden immer mehr Programme laufen. Da es sich um ein Quelloffenes System handelt dürften über die Zeit vielleicht sogar alle win32-Programme laufen. Wieso macht ihr das? Wir hassen Microsoft und seine Art Windows zu implementieren. Wir können uns aber auch nicht mit Linux auf dem Desktop anfreunden und diesem Flickwerk zwischen Millionen Dateien, Wine, X, Windowmanagern, Toolkits und Drucksystemen. Da das technische Konzept hinter WindowsNT und Nachfolger gar nicht so schlecht ist, wie viele immer glauben, deshalb tun wir das. Windows ist doch so Sch* wieso baut ihr das nach? Windows war Mist und ist es wieder geworden -- Zugegeben. Insbesondere die DOS-Versionen. Hier geht es aber um die NT-Versionen. Und die sind gar nicht mal so schlecht, wie viele immer glauben. Insbesondere wenn man mal den NT-Kernel verstanden hat, wird einem klar, dass der von jemandem entworfen wurde, der sein Handwerk wirklich verstand. Es war Dave Cutler von Digital, der zu diesem Zweck von Microsoft mitsamt seinem Team gekauft wurde. Insofern ist der NT-Kernel keine Microsoftentwicklung. In diesem Kernel stecken viele tolle Konzepte drin. Auch das Konzept des eigentlichen Betriebsystems (Durchgehende Sicherheit, Subsysteme, Dateisystemtreiber, Dienste, Registry) ist ausgezeichnet. Nur was Microsoft daraus gemacht hat, das ist wahrlich nicht mehr das gelbe vom Ei. Dies lässt sich ändern, wenn man an die Quelltexte von Windows dran käme. Da das jedoch nicht möglich ist, außer wenn man es nachbaut, haben wir diese Projekt in Angriff genommen. Warum helft ihr nicht dem Wine-Projekt? Wir arbeiten doch mit dem Wine-Projekt zusammen. Wine hat vermutlich mehr mit ReactOS gemeinsam als mit Linux. Das Wine-Projekt hat sich zur Aufgabe gestellt, neben dem winserver und den Kern-DLLs alle APIs von Windows nachzuprogrammieren. ReactOS und sein Win32-Subsystem besteht im Wesentlichen aus dem Kernel und den Kern-DLLs (NTDLL.DLL, USER32.DLL, KERNEL32.DLL, GDI32.DLL und ADVAPI.DLL). Diese zu Implementieren ist unsere eigene Aufgabe. Alles Weitere (z.B. COMDLG32.DLL) können wir jedoch mit dem Wine-Projekt teilen. Unsere gemeinsame Aufgabe ist es, die Wine-DLLs über beide Systeme portabel zu gestalten, und die unter WINE nicht relevanten und somit fehlenden Funktionen für ReactOS nachzurüsten. Wieso nehmt ihr nicht den Linux-Kernel und Wine? Wir sind überzeugt, Linux+Wine nie eine echte Windows-Alternative sein kann. Das ist wohl nur mit einem "windowsartigen" Betriebssystem möglich. Der Knackpunkt rund um Wine ist doch der: Wer jetzt Linux auf dem Desktop hat, der verwendet Linux-Programme und wer im kritischen Bereich / ernsthaft unterschiedliche Windowsprogramme einsetzen muss/will, der geht zu Microsoft. Und das bringt Wine nicht voran. Darüber hinaus haben wir mit einem Kernel, der WindowsNT-Treiber laden kann, doch die ideal unterstützte Plattform. Das Problem Treiber existiert quasi nicht. Wird ReactOS auch so instabil? Welch eine Frage... Ernsthaft gesehen war Windows NT und folgende eigentlich nie instabil. Abstürze bzw. die berühmten blauen Bildschirme hatten in aller Regel zwei Ursachen: Treiber, die unsauber programmiert wurden und Hardwarefehler bzw. Ressourcenkonflikte. ReactOS hat momentan naturgemäß noch ziemlich Absturzfreudig. Doch das wird sich mit der Zeit ändern. So schnell wie bei Linux wird es allerdings nicht gehen. Immerhin implementieren wir von Anfang an Merkmale, die zum Teil Linux erst mit Version 2.6 bekommt. Aber dann, wenn ReactOS stabil ist, sind es nur die Treiber, die das Gebäude zum Einsturz bringen können. Warum ist die Grafik nicht auf Ring 3 sondern auf Ring 0? Kurz: Weil Microsoft es genauso macht, und wir nur so dieselben Treiber verwenden können. Und warum macht es Microsoft so? Weil sich daraus Geschwindigkeitsvorteile ergeben. Im Gegensatz zu einem Grafikserver, der in einem eigenen Prozess läuft, sind hier keine Kontextwechsel bei Grafikausgaben nötig. Das macht natürlich die Architektur unsauberer und wenn die Grafik abstürzt, dann ist das ganze System weg. Außerdem wird dadurch der Kernel aufgebläht. Dieselbe Diskussion hat es in Redmond auch gegeben, als die Grafik bei WinNT 4.0 in den Kernel wanderte. Dabei ist man zu dem Schluss gekommen, dass die Grafik inzwischen so ausgereift ist, dass nichts mehr passiert und wenn im Benutzermodus etwas schief geht, dann sind die Konsequenzen ähnlich. Die meisten Prozesse werden abgewürgt. Insofern muss man die ReactOS Grafik einfach mit der Linuxkonsole vergleichen. Wenn dort ein Fehler drin ist, dann ist auch der Teufel los. Aber wenn man stabile Grafiktreiber hat und das Grafiksystem ausgereift ist, dann passiert dort auch nichts. Hat ReactOS die gleichen Sicherheitsmängel? Windows NT und Nachfolger sind an sich eigentlich keine inhärent unsicheren Systeme. Es ist nur so, dass Microsoft ein an sich sicheres System durch fehlgeleitete Entwicklung unsicher gemacht hat. So richtet z.B. WinXP jeden Benutzer als Administrator ein. Der Internet Explorer ist ein Scheunentor. Dienste sind Schlampig implementiert. Der Benutzerkomfort geht vor Sicherheit. Dies erkannt können wir es anders machen. Problematisch wird dabei jedoch sein, dass Microsoft zu wenig Druck auf die Softwarehersteller ausgeübt hat, ihre Produkte auch unter normalen Benutzerkennungen lauffähig zu machen. Welche Oberfläche kann ich verwenden? Dazu muss man erst einmal verstehen, wie in ReactOS / WinNT die Oberfläche funktioniert. -Die Win32-Kernelgrafik mit Grafiktreibern. Diese Komponente bietet Grafikprimitive wie Rechtecke, Linien und BitBlit-Operationen. -Das Win32-Subsystem (CSRSS.EXE). Dieses Stellt Fensterrahmen und Konsolenfenster zur Verfügung. -Die Biliothek USER32.DLL. Diese stellt die Grafischen Kontrollelemente etc. zur Verfügung -Die Shell (z.B. Explorer). Das ist ein normales Programm, das nur als erstes gestartet wird und evtl. den kompletten Bildschirm einnimmt. Technisch wäre es möglich XFree86 laufen zu lasen. Für OS/2 gibt es z.B. einen derartigen Port. Dann laufen allerdings keine Win32-Anwendungen mehr auf ReactOS, denn das Win32-Subsystem basiert auf der Win32-Kernelgrafik. Es müsste daher umprogrammiert werden. Doch das macht nicht wirklich Sinn, denn ReactOS soll als Basis für viele Subsysteme dienen und da macht es sich gut, wenn nur eine Grafikschnittstelle existiert. Außerdem erschließt man sich so die vielen guten und schnellen Grafiktreiber die es so gibt. Man kann also technisch X, Y, Fresco oder picoGUI laufen lassen, doch wird man dann auf das win32-Subsystem und die Grafiktreiber verzichten müssen. Welche Shell läuft? Das ReactOS-App-Team programmiert einen eigenen Explorer, der dem "original" ähnlich sieht. Es steht allerdings jedem frei, das Shellprogramm seiner Wahl zu verwenden. Auch bei WinNT und Nachfolgern ist es nur ein Registry-Eintrag, um z.B. CMD als Shell zu verwenden. Wenn das OS/2- Subsystem fertig ist, kann man auch die WPS als Shell verwenden...alles ist erlaubt. Zu diesem Zweck wird unser Winlogon ein entsprechendes Kombinationsfeld enthalten. Was passiert wenn Microsoft ReactOS findet? Vermutlich hat Microsoft RectOS schon längst entdeckt. Um gegen Klagen gefeit zu sein, wurde die ReactOS-Foundation gegündet. Dabei handelt es sich um so etwas Ähnliches wie einen gemeinnützigen Verein. Kommt eine Klage, geht die ROS-F pleite und eine neue wird gegründet. Aber warum sollte Microsoft überhaupt etwas machen? Überlegt mal, was wohl passiert, wenn Microsoft einen Prozess gegen die ReactOS-Foundation anstrengt. ReactOS wird vermutlich noch bekannter als Linux (wer erinnert sich noch an Mike Rowe Soft?). Dies kann nicht im Interesse von Microsoft sein, denn dann heißt es in der Industrie noch mehr ReactOS als jetzt schon Linux. Und selbst in den USA ist ein ausforschen von Schnittstellen erlaubt, um eine eigene Implementierung zu erstellen. Gibt es immer noch Laufwerksbuchstaben? Ja, leider. Laufwerksbuchstaben sind eine Semantik, die zu Win32 dazugehört. Theoretisch sollte heute eigentlich keine Anwendung mehr vollqualifizierte Dateinamen auf Gültigkeit überprüfen, denn dazu gibt es Systemeigene Routinen. Doch man glaubt nicht wie viel schlecht programmierte Software in der Welt ist. Denkbar wäre jedenfalls eine abwärtskompatible Erweiterung des Laufwerkskonzepts -- wir arbeiten dran. Laufen DirectX-Spiele auf ReactOS? Momentan: Nein. Aber es ist geplant. Momentan gibt es jedoch noch Millionen anderer wichtiger Dinge. Laufen DOS-Programme? Momentan: Nein. Sobald allerdings Bochs läuft funktionieren DOS-Programme. Ein dediziertes DOS-Subsystem im v86-Mode wie bei WinNT ist nicht geplant bzw. noch nicht. Denkbar wäre jedoch, Bochs derart zu modifizieren, dass ein transparenter Dateizugriff möglich ist und alle Programme Interpretiert werden. So, wie es auch auf den nicht x86-Portierungen von NT der Fall war. Laufen Linux-Programme? Momentan: Nein. Ziel ist es jedoch. Es existiert die Basis eines POSIX-Subsystems. Da Linux-Programme zumeist eh im Quelltext vorliegen wäre das eine Möglichkeit. Anfang 2004 ist coLinux herausgekommen. coLinux ist ein Linuxkernel, der unter WinNT läuft. Die Leute vom coLinux-Projekt haben zugesagt, ihn auch auf ReactOS zum laufen zu bringen und daraus irgendwie geartet ein Linux-Subsystem zu machen -- Lassen wir uns überraschen. Laufen FreeBSD-Programme? Nein. Bislang ist auch nichts Derartiges geplant. Wobei es allerdings nicht abwegig ist, z.B. die FreeBSD-Peronality von Darwin (die Grundlage von MacOS X) zu portieren. Gibt es ein POSIX-Subsytem? Es existiert eine Basis eines POSIX-Subsystems. Laufen OS/2-Programme? Momentan: Nein. Es ist jedoch in Planung und eine Materialsammlung existiert bereits. Die Truppe von OSfree, die ein freies OS/2 implementieren will, wird vermutlich den Kernel von ReactOS als Basis verwenden und es wird somit ein OS/2-Subsystem entstehen. Ziel ist es 32-Bit OS/2-Anwendungen inklusive Presentation Manager laufen zu lassen. Läuft Java auf ReactOS? Ja. Solange sie im Textmodus laufen -- doch werden die ersten Swing und SWT-Programme nicht mehr lange auf sich warten lassen. Daneben gibt es noch das Projekt JOS, dessen Ziel es ist, ein Java-Subsystem für ReactOS zu bauen, und ein JavaOS auf ReactOS-Basis herauszubringen. Laufen .NET-Anwendungen? Keine Ahnung. Aber früher oder später bestimmt. Es kommen dazu sowohl Mono als auch Microsofts .NET-Framework als Laufzeitumgebung in betracht. Hat ReactOS einen X-Server? Ein X-Server ist primär kein Bestandteil des Betriebssystems, so auch nicht von Reactos. Für ein Linux- /Posix- /BSD-Subsystem macht er aber durchaus Sinn. Dennoch bleibt es jedem selbst überlassen, einen X-Server zu installieren. Funktioniert meine Hardware mit ReactOS? Wenn sie WDM-Treiber (Windows Driver Model Treiber) mitbringt, und diese sich nicht gegen ReactOS wenden, Ja. Momentan (1/04) sieht es aber mit funktionierenden Treibern noch ziemlich Mau aus. Das liegt einfach daran, dass die Infrastruktur im Kernel noch nicht so weit ist. Funktionieren die Treiber von Windows? Theoretisch Ja. Momentan (1/04) sieht es aber mit funktionierenden Treibern noch ziemlich Mau aus. Das liegt einfach daran, dass die Infrastruktur im Kernel noch nicht so weit ist. Läuft das Netzwerk? Nein. Mit einer Realtec-Karte kann man eine ReactOS-Kiste anpingen. Das war's. Aber die Zeit wird auch das bringen. Kann man ReactOS im Textmodus betreiben? Ja. Die ersten Versionen waren nur im Textmodus. ReactOS schaltet in den Grafikmodus, sobald eine Anwendung ein Fenster öffnen will. Es ist geplant, dass man ReactOS auch weiterhin ohne grafische Oberfläche verwenden kann. Welche Dateisysteme werden Unterstützt? Im Moment gibt es nur (V)FAT in all seinen Varianten mit 12, 16 und 32 Bit. Es wird an einem NTFS-Treiber gearbeitet, doch wie man am Beispiel Linux-NTFS sieht handelt es sich dabei nicht um ein geringes Vorhaben. Es wird daher noch eine Weile dauern, bis NTFS voll unterstützt wird. Von dritter Seite existieren inzwischen einfache Dateisystemtreiber für ext2/3 und ReiserFS. Das Dateisystem JFS ist in Planung. Irgendwann wird es dann wohl auch BFS, UFS und FFS-Treiber geben. Werdet ihr Samba einsetzen? Nein. Zumindest nicht in der Form. Samba ist ein unix-Programm und auf dessen Semantik angepasst. Es erfordert umfangreiche Änderungen, damit es sich in das Rechte- und Dienstesystem von ReactOS einfügt. Daher wird wahrscheinlich der Kern von Samba, die Protokolle, in einen eigens entwickelten Dienst eingebaut. Kann mit ReactOS ein eigenes Betriebsystem machen? Ja. Der Kernel mitsamt seinen Stadardtreibern steht unter der GPL und jeder kann daraus etwas machen. Für ein "neues Betriebssytem" auf Basis des ReactOS-Kernels muss man lediglich ein neues Subsystem schreiben. Unterstützt die grafische Oberfläche TrueType-Schriften? Ja. Wir verwenden für die GUI die FreeType2-Bibliothek zum Rendern der Schriften. Was also FreeType2 kann kann auch die GUI. Mitgeliefert werden die von Bitstream frei gegebenen TrueType-Schriften. Für welche Plattformen / Prozessoren gibt es ReactOS? Im Moment gibt es ReactOS nur für x86 bzw. IA-32 -Prozessoren. Da ReactOS auf Portabilität ausgelegt ist, wird es wohl in nicht all zu ferner Zeit auch auf anderen Prozessoren laufen. Angedacht sind auf jeden Fall nebst PowerPC, Alpha und AMD64 auch ARM und die RS-Familie für den Embedded-Bereich. Unter welcher Lizenz steht ReactOS? Unter der GPL. Die Kern-DLLs und Headerdateien diverser Subsysteme stehen unter der LGPL, so dass es gefahrlos möglich ist kommerzielle Anwendungen dafür zu entwickeln. Hat ReactOS auch eine Registry? Ja. Sie ist sogar bis auf Formatebene kompatibel. Warum benutzt ihr diese fürchterliche Registrierung und nicht Textdateien? Aus Kompatibilität, und weil eine Textdatei gnadenlos langsam würde. Wir können die Reg-APIs nicht derart umbiegen, dass sie fortan auf Textdateien arbeiten, denn sie beziehen sich auf die Registrierung als Ganzes und das würde dann nicht mehr gehen. Viele führen ja an, die Registrierung sei die Ursache für große Undurchsichtigkeit der Konfiguration. Doch das stimmt so nicht. Wie so oft ist das Konzept gut, nur nicht gut umgesetzt. Bei vielen Programmen herrscht einfach nicht genug Disziplin, was das benutzen der Registrierung angeht. Viele Programme sind ja noch nicht einmal Mehrbenutzerfähig und speichern eine globale Konfiguration, was dann zumeist auch die Ausführung als Administrator impliziert. Es spricht übrigens nichts dagegen, dass ein Programm auch heute noch alles über INI-Dateien löst. Es ist nur eine Frage des Wollens. Zur Beruhigung sei gesagt, dass wir die Registrierung mehr oder weniger neu aufbauen und mithin ausmisten - bis sich eben auch dort keiner mehr auskennt.

20 years, 10 months

RE: [ros-general] Serious bug in the video driver?

by lists＠silverblade.co.uk

Yes, I use boot.bat to boot ReactOS (on real hardware.) In Bochs, using Freeldr, I don't get the problem. Original Message: ----------------- From: Ge van Geldorp ge(a)gse.nl Date: Fri, 30 Jan 2004 12:30:10 +0100 To: ros-general(a)reactos.com Subject: RE: [ros-general] Serious bug in the video driver? > From: Andrew "Silver Blade" Greenwood > > I, and a couple of other people it seems, have a problem > booting ReactOS on real hardware. > > After the disk checking stage, it freezes. If I modify the > registry so it boots into a console, it works, but as soon as > I run any graphical application, it freezes. How do you boot into ReactOS, using freeldr or the boot.bat method? Everyone having this problem so far seems to be using boot.bat. Gé van Geldorp. _______________________________________________ ros-general mailing list ros-general(a)reactos.com http://reactos.com/mailman/listinfo/ros-general -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ .

20 years, 10 months

Serious bug in the video driver?

by Andrew "Silver Blade" Greenwood

I, and a couple of other people it seems, have a problem booting ReactOS on real hardware. After the disk checking stage, it freezes. If I modify the registry so it boots into a console, it works, but as soon as I run any graphical application, it freezes. A few people on the reactos.com forum have mentioned something similar happen to them, so it doesn't just seem to be my crappy machine I use to test it. It only seems to happen when changing into graphics mode, too. Just thought I'd mention it - someone might be able to fix it as I wouldn't know where to look!

20 years, 10 months

dubious web site

by Martin Fuchs

What's this?! There is a web site, which tries to start a boycott against ReactOS: http://www.nt.net/donkey/index.htm

20 years, 10 months

Ros does not work for me

by jh

Help please, I have tried to run ros yet again, but without success. My system is a pentium 450 - 64mb ram - 4.3 HD - Hercules 3D Prorhet 2 mx (agp socket) - optical mouse (ps2 socket). The system is a bit buggy, but runs win95. The error messages start here:- (ntuser/input.c:86) win32K:Failed to open mouse. ***** 13 lines of messages simular to the next line below, which is the thirteenth line .******* LdrGetExportByOrdinal (Ordinal 152) = 76167ede (NTDLL:ldr/utils.c:2041) Failed to create or open dll section of ` wineoss.drv ' (Status c0000135) (NTDLL:ldr/utils.c:1191)LdrGetExportByName(): Failed to Find GetModulesHandle16 (NTDLL:ldr/utils.c:1191)LdrGetExportByName(): Failed to Find LoadLibrary16 (NTDLL:ldr/utils.c:2041)Failed to create or open dll section of ` msacm.drv ' (Status c0000135) (NTDLL:ldr/utils.c:2041)Failed to create or open dll section of ` midimap.drv ' (Status c0000135) Everything is stopped at the above line, the only thing to note is, that the floppy drive light is on and remains on. Is the fault in Ros or is it my buggy system. Thanks for any help regards jh

20 years, 10 months

Re: [ros-general] Interest in ReactOS

by ea＠iol.it

> But the bottom line is that the semantics are part of the API. The best > you could do is a UNC path like: > > \\myhost\root\blah\blah > > And then *really* SMB serve that to yourself locally. It seems like a lot > of effort for very little gains. Keep also in mind the new path semantics introduced by the Windows 2000 Server Distributed File System (DFS) service, when the DFS root is hosted in an Active Directory (AD) Domain Controller (DC). Assume your directory is "example.com". You have two DCs (DC1 and DC2). Your DFS root is in \\DC1\root and you have a DFS replica in \\DC2\root. From PCs with Win2k, Win2k3 and WinXP belonging to the "example.com" AD, you can simply write "\\example.com\root" to access the DFS root (but you don't know which physical host (DC1, or DC2) you will be actually redirected to). Emanuele

20 years, 10 months

Re: Interest in ReactOS (tappak)

by Semyon Novikov

If anybody want have UNIX fs style on ROS, just use zsh from Unix2Win tools. And now you can use pathes such as "/ReactOS/system32/psxss.sys" But peoples! What you thing about "device filesystem" for ReactOS? Just directory or drive, who contain some "device" files? I'm too yang to do that, but, may be anything else want to start this project? -- Best regards, Semyon Sorry for my english :)

20 years, 11 months

Re:[ros-general] Drive letters

by ea＠iol.it

> Maybe I'm missing something obvious here, but on my Win2k system I can > mount any partition I want on any (NTFS) directory, just like you can > mount filesystems on directories in Unix. So just make your C: drive > NTFS, mount the other partitions, and forget about the C: if you want > Unix-style paths. This is exactly what I did here, but later I was forced to dismount the CD-ROM unit and the burner, because Nero 5.5 was not compatible with mounted devices.

20 years, 11 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Ros-general