The most obvious missing features of ReactOS is ofcourse what makes ReactOS different form MS Windows...
... The high prize and all the MS Logos stuck everywhere
Or was it the other things ... ...well anyway, all the things you mentioned earlier are good, but I miss some:
- PRINTING
- Driver installation
- Win98 driver support
- A good distribution including all interesting apps Web(browse and create), Mail, Office, Gfx, and a lot more
- A GUI that updates correctly (the right panes in regedit.exe and explorer.exe)
- Office software
- Support for Autodesk Inventor
- All the things that makes it possible to exchange WinServers with ReactOS Servers
Some company do not have windows XP drivers (since they no longer exist) and the windows 98 drivers dont work on xp. I would like ot see support for those drivers, since i have such hardware.
Jaix wrote:The most obvious missing features of ReactOS is ofcourse what makes ReactOS different form MS Windows...
... The high prize and all the MS Logos stuck everywhere
Or was it the other things ... ...well anyway, all the things you mentioned earlier are good, but I miss some:
- Win98 driver support
Reactos will never support windows 3.x, Windows 95/98/ME driver.
the arch are to diffrent.
1. it are dos kernel. the driver can speak direcly to any hardware or bios.
this is not alllown todo in ntkerel.
2. the timer intervall
and alot of other stuff.
if you allown a drv talk direcly with a other hardware or with the hardware you got a system that crach alot.
reactos are base on NT kernel that does not allown alot of stuff that the dos kernel allown. yes windows 9x/me are using dos kernel
01) Stability
02) Performance
03) Real hardware drivers
04) Networking, TCP/IP
05) USB
06) Plug&Play
07) DirectX
08) VB Apps Support
09) CTRL+ALT+DEL shows Task manager
10) Compatibility with Windows Boot Loader
11) Automatic Update
12) Printing Support
13) Win 9x/Me Driver Support
14) Better and most beautifull setup
15) Few consoles like in Linux
16) More FileSystems Support (Ext2, Ext3, ReiserFS, Reiser4, XFS, JFS, Minix, RomFS, NTFS, HPFS, BeFS, and more)
17) User switching
18) i18n (MultiLanguage)
19) Windows Skins
20) Better shell instead of Explorer
21) DHCP Client
22) DHCP Server
23) Configuration soft grouped in something like Control Panel
24) SymLinks support
25) Better Windows Software compatibility
GreatLord wrote:Reactos will never support windows 3.x, Windows 95/98/ME driver.
the arch are to diffrent.
1. it are dos kernel. the driver can speak direcly to any hardware or bios.
this is not alllown todo in ntkerel.
2. the timer intervall
What if you're executing the Win9x drivers in PL3 ? Then you should be able to intercept all I/O-Accesses and INT calls ...
EDIT:
BTW: I personally think that it doesn't make sense to put any effort into Win98 driver support.
Regards,
Mark
Last edited by mjs on Sun Mar 13, 2005 1:11 pm, edited 1 time in total.
GreatLord wrote:
if you allown a drv talk direcly with a other hardware or with the hardware you got a system that crach alot.
reactos are base on NT kernel that does not allown alot of stuff that the dos kernel allown. yes windows 9x/me are using dos kernel
This depends greatly on how this support would be written, actually you do not need to give it direct access to the hardware but it can be made as a layer between the hardware and the driver, much like vmware.
GreatLord wrote:Reactos will never support windows 3.x, Windows 95/98/ME driver.
the arch are to diffrent.
1. it are dos kernel. the driver can speak direcly to any hardware or bios.
this is not alllown todo in ntkerel.
2. the timer intervall
What if you're executing the Win9x drivers in PL3 ? Then you should be able to intercept all I/O-Accesses and INT calls ...
BTW: I personally don't think that it doesn't make sense to put any effort into Win98 driver support.
Regards,
Mark
Once ROS has reached a certain level of maturity it might be an idea to implement Win98 driver support as an option which is disabled by default.
As you indicated, it might actually be possible to pull it off in a manner which won't compromise the NT-kernel model, so it should at least be considered.
http://www.acc.umu.se/~bosse/ Romfs is most likely supported would someone give it a test with reactos.(I don't have my reactos up at moment)
Windows 9x drivers are LX format. This is a big problem. We don't have opensource linker to produce LX files or a Gcc to produce them. Makes it hard to test the subsystem not risking some licence trap. Note a tool to convert Windows 9x driver to NT drivers would be most likely the safest option. Ie the tool can yell this driver users features that cannot be done in NT. Not have this happen when the driver is running causing a system lockup due repeated retrying.
Most important feature is a reform of the bootloader code.
I have tryed 4 times to build a interface between Grub and reactos directly ie no chainloader. This is a minor change all drivers loaded at startup must be taged and Identifyed by tag not name. Muliboot format of reactos changed to Grub compad(Grub created Muliboot format) And freeloader updated to support this. This would fix alot of problems I have major trouble creating code to convert standard Muliboot to reactos Muliboot. Grub can tag on modules in its config file yes this is not tidy but it stop having to install a boot loader to run reactos.
The required changes would require global reactos support because things are going to have to be changed. And I don't like the sign of standard complance breach without good cause. Comon argument is that windows has it own bootloader so there is no reason for compad. This is completely wrong this means we are stuck with one boot loader and if anything goes wrong with it we cannot use a backup system.(might be harder but worth it)
I can't follow everything you're saying, but although it is not possible to boot ntoskrnl.exe from Grub, it is possible to boot freeldr.sys as a multiboot program from Grub and then have freeldr.sys take care of loading ntoskrnl, drivers, registry, hardware detection.
GvG wrote:I can't follow everything you're saying, but although it is not possible to boot ntoskrnl.exe from Grub, it is possible to boot freeldr.sys as a multiboot program from Grub and then have freeldr.sys take care of loading ntoskrnl, drivers, registry, hardware detection.
I guess it's important to know what we all want out of ReactOS, but IMHO I think we should be asking ourselves at this time "what features minimum do I need in order to put ReactOS to work?" rather than "what features do I expect from my dream OS?" I'm sure we could dream forever about what we want out of an OS, but if there are a few things that could make ReactOS truely usable now, I think it would help to talk about those.
No, unless you get grub to detect hardware, load the registry to examine which drivers need to be loaded at boottime and then hands control over to ntoskrnl.
... ...well anyway, all the things you mentioned earlier are good, but I miss some:
