Hello everyone,
 Aleksey suggested that I discuss this here, on the mailing list.
 First and foremost, these are enhancements to do for later, much later
 (what I would want for the next release is support for RAID / SCSI
 controllers). But I know that a developer doesn't actually keep
 something in his plans unless he's figured out a way to do it.
 I will paste and add additional comments to each of my suggestions.
 1. Compatibility with every version of Windows, from Vista until Windows
 3.1 / 3.11
  
  That means applications written for 3.1 should work
flawlessly on
 ReactOS, just like apps written for any other Windows. This is probably
 not hard, as at least XP does the same thing.
 However, drivers for Windows 3.1 most probably do not work. If the user
 actually has hardware that was left unsupported since 3.1, he should be
 able to use it.
 The same goes for the combination Vista-only driver / old Windows '95 or
 Windows 3.1 application.
  
  oiaohm said it's not really possible because VxD
drivers are not well
 documented. So, maybe in the distant future, maybe when Linux devs will
 have reversed VxD's on their own. Just don't forget this.
 2. Compatibility with DOS**
 This will probably not mean DOS drivers, as probably any hardware with
 DOS drivers also has some sort of Windows drivers. It would only mean
 application compatibility. However, applications with direct access to
 hardware will probably have to remain used from within DOS (e.g. BIOS
 update software). The major thing are games here. The ideal way to run
 DOS games is:
 - anything requested by the game is interpreted and passed on to the ROS API
 - Glide commands are interpreted and passed on to OpenGL or Direct3D,
 resulting in maybe a better image quality, via the use of features
 OpenGL has and Glide doesn't.
 - software rendering requested by games should be interpreted and passed
 on to OpenGL or Direct3D, again resulting in a better image quality.
 Of course, this will probably result in a compatibility layer, like you
 suggested.
 - redbook audio commands should be passed on to ReactOS, who will read
 in analog mode or digital mode, depending on what the ROS global
 settings are for that specific optical drive.
 My own thing about Descent, quickly: the game tries to access file "
 1.midi" but ReactOS plays "1.mp3". I have all the mp3's and will
provide
 them whenever needed in order to make this happen. This will transform
 the old Descent for DOS in the CD version, that had redbook audio tracks.
 Such enhancements were also created for Tomb Raider 1, by Paul that
 created Glidos ( 
www.glidos.net <http://www.glidos.net> ). Please see
 
http://www.glidos.net/retext.html?lang=en and
 
http://www.glidos.net/audio.html?lang=en
 Whenever Tomb Raider 1 asked for certain textures / audio data, it was
 "hijacked" or "redirected" to the better textures or audio files.
 Certainly, this DOS compatibility layer would probably need a
 Glidos-like application to control various specific settings from
 various DOS applications.
 Another DOS related thing would be a command prompt (terminal?) in
 ReactOS that has drag'n'drop, copy and paste functionality.
 Still oiaohm: for the distant future. Got it, understood it, I just want
 to convince you to keep it in your plans. oiaohm even said a
 compatibility layer already exists.
 3. Processors as a devices, in Device Manager *
 *
 For example, let's say a PC has a Pentium 4 at 3 GHz, with
 HyperThreading. Windows XP reports this processor as two identical ones
 in Device Manager. ReactOS should also do that. Apart from Windows, if
 the user does a right-click on a processor as a device, in the Device
 Manager tree, and chooses the Properties page of the processor device,
 that page should also mention the SPEED of the processor. More than
 that, it would be a blessing to also see the L1, L2 and L3 cache size,
 FSB and multiplier, like those SiSoft Sandra / Everest applications
 report. Maybe even further, the instruction sets supported - MMX,
 3DNow!, SSE, etc.
 oiaohm again: can be done, but not right now. Stability and usability
 beat extra information. Got it, too. Bug 2644.
 4. Clustering
 I discussed this with oiaohm and he said it's doable, as soon as ROS
 gets Active Directory Server. Only clustered in terms of processing
 power, the user has more machines in a cluster and he still sees ROS the
 normal way, it just works faster because there are more processors
 available. No hard drives in some sort of JBOD, and 3D data is only
 handled by the "master" machine(otherwise you need about 10 GB/sec
 between machines), the one the user actually interacts with. This is
 what he said would be the limitations.
 I have other details for this, but since it's very far away, it wouldn't
 make sense to bring them up right now.
 5. Driver extraction tool
 I already got one, DoubleDriver, that backs up the drivers for devices
 in the device manager. I was thinking about the hardware that only gets
 drivers from Windows Publisher (like my MSI Starkey 2.0). Users would
 need one.
 Again, oiaohm said replicating a freeware tool is not high on the list.
 I'm fine with that.
 6. A Windows Media Center equivalent
 **WMC doesn't do much. Just lists program schedules, can do scheduled
 recordings, is able to duplicate streams so that you may record whatever
 you're watching. It stops suddenly while doing a "record once" capture,
 when it should have waited for the user to say stop (it happened on
 Vista Home Premium, on a HP laptop). It has a "touchscreen" kind of
 interface, that would probably be great on an actual touchscreen, works
 ok when using a PC remote control, but is kind of stupid when using the
 mouse. It can record from one channel and let you watch another channel
 if you have at least two TV tuners in your computer. Naturally, ROS
 should do this with "n" TV tuners.
 It doesn't have composite or S-video capturing, like the vast majority
 of TV tuner software out there. It only captures in Microsoft's special
 "Microsoft recorded TV Show" format, extension .dvr-ms I think (no AVI
 capture, no mpg capture). It won't let you specify how the tuner
 provides sound from the antenna/cable signal to the sound card (PCI
 audio, internal cable, external cable, and if any of the last two, what
 sound card channel it is). While watching, it should be easier to find
 out what channel you're on, and what the time is, via some sort of OSD
 (on-screen display) that appears when you move the mouse or something,
 just like in WMC. The recording should not be affected by this (i.e. the
 OSD shouldn't show up on the recording if you moved the mouse, again
 just like in WMC). While watching, it's not possible (or at least not
 easy) to jump directly to a specific channel, it may only be used as a
 TV (next channel, next channel...). If the user tries to switch channels
 while recording, he gets "warning, you're recording, if you switch
 channels it's going to stop, you want that?" It should just stop, or at
 least let the user specify that he doesn't want to see that message
 again somehow. It doesn't let the user specify exactly the framerate,
 video size, video standard...just the country of origin. And, as an
 example, Romania officially uses the PAL D standard on "air" broadcast,
 that you can get with an antenna. But cable providers use PAL B, which
 is the German official standard. So, in WMC a guy with cable from
 Romania must say he's from Germany or else he won't hear anything!
 All of these should be properly implemented in ReactOS Media Center.
 Apart from them, "ROSMC" should have all the deinterlacing options and
 deinterlacing-method autodetection routines from Dscaler. That program
 also offers a whole lot of other image improvement things, like a good
 enough TV station logo killer and image de-noising that actually works.
 Even better than Dscaler, REMEMBER the settings the next time the user
 runs the program. Maybe also provide the user with basic video editing
 functionality, meaning most of the features from VirtualDub (the one I
 find most important is the ability to edit a film with "direct stream
 copy", meaning it just copies the video and/or audio stream, it doesn't
 re-encode it. Edit as in cutting parts of the film. In this scenario,
 the ability to go frame by frame is also very useful).
 And since it's the Media Center and not the Media Player, this should be
 the application that rips audio cd's or audio dvd's.
 Most of all, it should be "cluster-aware." Regardless of ROS being
 cluster aware or not, this one should be.
 oiaohm said this is not your job, but a job for other projects. He
 pointed me to MediaPortal. I e-mailed all of them (Virtualdub, Dscaler
 and MediaPortal) but I doubt they'll combine the three projects. Still,
 that's why John User still buys Windows. Linux is all over the Internet
 (docs all over forums, drivers all over sites, applications all over
 sites as well). Instead, Linux has "cool" stuff like "mousespedometa"
 (measures the speed with which you move the mouse). Some people don't
 even have Internet to get what they need (X servers, for instance). To
 be a Windows alternative, it should contain a lot of things Windows has.
 7. Running on 16-bit systems like 286/386/486 in a "ReactOS Essentials"
 (equivalent to a stripped-down XP) mode *
 *
 It should be the same operating system, but in 16-bit mode only. That's
 an ideal scenario and I'm sure it cannot be done no matter how good the
 programmers are. So, what can someone do on a 286 ? Listen to mp3's ? No
 way. Listen to audio CD's, yes, and hopefully digital playback, too.
 Watch TV ? Yes, if the user can find an ISA TV tuner (ATI made such
 tuners, but they required a PCI ATI video card, and if you have PCI why
 not get a better tuner?). Record TV shows ? Not on that kind of
 computer. Browse the internet ? That may be possible, with some really
 outdated, 16-bit browser, like the Internet Explorer for Windows 3.1.
 And I don't know how many sites will work on it. Play games ? Yes,
 either old DOS or Windows 3.1 ones or the ones that come with ReactOS,
 written in 16-bit especially for this mode. Join a hive as either master
 or slave ? Hopefully it will be possible, but probably in the year 2015
 at least. Use office applications ? Sure, if the user can find that last
 Microsoft Office or maybe Microsoft Works version compatible with
 Windows 3.1. Run a web server ? I know a guy who had a server running on
 a 386 system, on Windows 3.11. So yes, it is possible, only I don't know
 what software he used to actually serve the data. Act as a router ?
 Again, hopefully. That is, if the entire network is on 10 megabit,
 because I don't think there are ISA 100 megabit network cards (ISA
 bandwith is not enough). 2D graphics ? It was possible in Windows 3.1,
 why not ? Maybe the first Photoshop versions actually were 16-bit. 3D
 graphics ? The first 3D Studio Max (that is, 3D Studio) was for DOS
 only. That probably means 16-bit right from the start, and that should
 mean yes, you can do it, with the DOS compatibility layer. Web design ?
 If you can find a 16-bit application, yes.
 A separate ReactOS for 16-bit only, or just all the 16-bit functionality
 included in the normal ReactOS ? Things look better when it works out of
 the box, but it's a waste of space to include applications written for
 16-bit only. People that really need the 16-bit version will not mind
 paying extra attention to actually download this one and not the normal
 one. Besides that, ReactOS is free. And the presence of such a version
 would mean a selfless devotion to people. An act of charity for real.
 Allowing people to use their computers and do as many modern things as
 possible on them.
 An open source Windows 3.11 with better compatibility and adherence to
 standards. Compatible with all the 9x and ME. Has been tried in Free Win
 95, oiaohm said "dead and staying that way" about it, but maybe VxD
 documentation and whatever else you would need will appear (or be
 reverse engineered by someone). Once a bigger effort will be done, the
 missing info is probably easier to uncover.
 Those are my suggestions. They are not for now, they are not easy to do,
 etc. Just don't discard them, please.
 Alex
  
Well that is allot! I like ideas too! But~ need more developers here. The
best we will do for now is NT/2k/Xp/2k3/V. Downward compatibility is WOW and
we don't have WOW. If you want! Come and help us.
Now for win311,,, Take FreeDOS and Wine 16 bit retool the wine code base it on
information from "Undocumented Windows by A. Schulman, D. Maxey and M. Pietrek".
You will have a good project there! I would like to play with that but~ I have
to much right now.
Thanks,
James