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 ). 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,
Romaniaofficially 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
SumatraPDF is a lightweight Win32 pdf viewer app
http://blog.kowalczyk.info/software/sumatrapdf/http://code.google.com/p/sumatrapdf/
The name "sumatra" sounds weird (for an app), so I renamed the
directory and the output exe file to "SmartPDF" (based on suggestions
from #reactos).
SumatraPDF comes with VS 2k5 project files.
I have fixed various compile issues so that libjpeg, poppler,
fitz/mupdf and sumatra app itself compile without errors in mingw
(RosBE 0.3.7.2 Win32).
All code changes can be found by grep/search for "@note:", I added a
comment to each changed code line.
The remaining problem is the linking issue. Currently it does NOT link
correctly.
Timo Kreuzer mentioned on 2007-09-27 in #reactos something that may be
related to the issue:
"it [sumatrapdf] imports a function from winspool.drv by number, when
you add that number to winspool.def, it starts"
Please have a look at it, fixes are appreciated :)
Klemens
Hi,
Alex nudged me in IRC about this, but sadly I've not quite figured this out
yet.
It appears my definitions for Kernel Streaming GUIDs are not quite right.
This results in ugly code like so:
--
const GUID foo_audio_category = STATIC_KSCATEGORY_AUDIO;
DoSomethingWithTheGuid(&foo_audio_category);
--
Which consequently results in a barrage of compiler complaints about brace
initialization.
It should be possible to just do:
DoSomethingWithTheGuid(KSCATEGORY_AUDIO);
I'm clearly going wrong somewhere in KS.H or KSMEDIA.H but to be honest am
blind to whatever is causing the problem.
If anyone can figure out what I'm doing wrong here, I'd appreciate it.
Thanks.
-Andrew
Hello,
I'd just like to do a remark about ReactOS apps, dlls, which be translated. When a dev change something to the interface, or the core app, it could be great to update EVERY language file (*.rc) and not only some of them (or even worse : only english one). It does not take many times to do (I know because I've already done that), and for a translator that's quite easier to see what has changed without having to compare his language file and the english one. And most of all, it avoids uncomplete, or outdated language files. Finally, for end-user, that's better : that's even better to have English string instead of nothing (I mean blank string).
Thanks,
Pierre Schweitzer, French Language Maintainer
On Sep 22, 2007, at 10:19 PM, João Jerónimo wrote:
> The point of a possible 3rd party audit is raising the legal
> credibility of
> the ReactOS project by ensuring that no tainted code is left in the
> source
> tree, right?
The word "tainted" is actually quite wrong, and is being misused
everywhere.
A tea was tainted by polonium in a not-so-recent accident in the UK.
ReactOS is not a tea, and we have no "polonium" commiters.
There will be a WineConf event in 1 or 2 weeks, and they say they are
going to clear up the legal situation around Wine, around SFLC audit
and around requirements to the developers, whose code may be commited
to the tree.
When they do it, I would be very glad to know those requirements, and
enforce them on ReactOS developers, so that we are on the common ground.
>
> Well, if the project is going to wait until more modules stabilize,
> won't
> this stabilization process obfuscate most of the tainted source
> code, and
> make them hard to find?
Your mind is ahead of you. "Taint obfuscated code", "Obfuscate
tainted code", ...
Your question is obfuscated and may be tainted, I won't answer it.
WBR,
Aleksey Bragin.
Please stop rumouring this topic. I clearly said "if there are strong
circumstances, in future, only then we will think about doing 3rd
party audit, and only from agreement of all devs". That's 3 or 4
years away from now, if such legal problems ever happen.
Also noone ever said SFLC is taking up copyrights to themselves. At
least it's first time I hear this.
I just grepped Wine source code base for word "SFLC" - doesn't appear
anywhere. Also, open up any of Wine's source code file, you'll see
"Copyright 200x Person's Name".
And again, I didn't suggest SFLC or FSF or whoever. Time will show
who and if we need, and who and if agrees to.
WBR,
Aleksey Bragin.
On Sep 24, 2007, at 2:58 PM, Magnus Olsen wrote:
> It seam u fall into he SFLC traps they are trying push doing the
> audlt of
> ros from a 3 part project
> of ros, and we shall obay theirs rules it mean all api that is not
> document
> in msdn shall be remove
> and so on. That mean 80% of ntoskrnl will go away, for around 80% of
> ntoskrnl are not in msdn
> 80% of win32k will go aways, for thuse api are not in msdn, then
> shall we
> not talk about audio
> no audio system and so on.
>
> that mean no ros, if we play after SLFC and we need also write
> papper give
> up our copyright to
> them. no thanks
Well-well, please calm down, we had enough flamewars, a new one is
not necessary.
No decisions are made, and no decisions are going to be made without
agreement with all our developers.
WBR,
Aleksey Bragin.
On Sep 23, 2007, at 3:40 PM, Ged wrote:
> James Tabor wrote:
>>
>> Wine is the Pot calling the kettle BLACK! Bunch of RE coders using
>> smoke and
>> mirrors when it comes to case testing! It's a easy out!
>>
>
> I agree with Aleksey, we must adopt their way of working in the
> hope of
> rebuilding the bridges and additionally improving our credability
> within
> the open source world. If this means offering ourselves to an external
> audit, then so be it. We can't be a hobbiest project forever if we aim
> to bring ReactOS to the public sector as a viable alternative to
> Windows.
>
>
> Ged.
Thanks for all the replies so far.
I find it quite insane that MSDN compares ioctl to DeviceIoControl. Whilst
they achieve
the same results, the actual parameters used etc. are entirely different.
I'm not sure if Steven's suggestion would work (ie, use ws2_32) since, to
my knowledge,
that particular implementation is specific to sockets.
Probably the best way around this then, would be to make an ioctl wrapper
that takes the
OSS-specific IOCTL codes, and translates them into custom NT IOCTL codes.
The wrapper
would take things like structures being passed via the ioctl and send them
via
DeviceIoControl instead.
It does seem like a fair amount of work but if an appropriate "wrapper" is
created, it
could work...
Original Message:
-----------------
From: King InuYasha ngompa13(a)gmail.com
Date: Sat, 22 Sep 2007 10:28:50 -0500
To: ros-dev(a)reactos.org
Subject: Re: [ros-dev] Open Sound System porting
Couldn't the source be patched to use DeviceIOControl instead of ioctl?
According to MSDN about porting from UNIX to Win32, ioctl maps directly to
DeviceIOControl, so it could be possible to simply change all the instances
of ioctl to DeviceIOControl...
On 9/22/07, Aleksey Bragin <aleksey(a)reactos.org> wrote:
>
> I didn't thoroughly look through the OSS source code, but if it has
> some kind of platform-independent design in mind, then I would really
> recommend porting, and porting with as minimal changes to the
> original source code required (you probably are going to need a
> wrapper-library, for ioctls at least, plus NT-specific parts).
>
> I may help too, because of the usb stack wrapping I did a while ago.
>
>
> WBR,
> Aleksey Bragin.
>
> >
> > I've been in touch with the guy that ported OSS to Haiku (open-
> > source BeOS)
> > after some
> > discussion with the folks over at #winehackers to get some help
> > with audio
> > development.
> >
> > Anyway, basically the idea so far is to use OSS as a "fall-back" audio
> > driver
> > implementation. So unless there is a "better" driver installed (ie an
> > official one for
> > an audio device), ReactOS can use an Open Sound System driver instead.
> >
> > The result? There will at least be sound functionality.
> >
> > OSS is designed to be mostly platform-independent. By rewriting a
> > few of
> > the core
> > modules, the entire set of drivers will be able to work with whatever
> > platform you
> > desire.
> >
> > This can be implemented on top of the existing MME API architecture
> > for the
> > moment, and
> > can later be translated to use the WDM audio framework.
> >
> > Anyway, having stuck the OSS code into my local ReactOS source
> > tree, I'm
> > trying to
> > figure out how to get it to compile using rbuild. The first hurdle
> > I have
> > come across is
> > that there is extensive use of ioctl. Indeed it seems that most
> > ports of
> > OSS work on
> > platforms based on Posix (Unix?)
> >
> > So my main question at this time is how to handle this? The calls in
> > question appear to
> > be documented inside a file called "soundcard.h" in the OSS sources
> > however
> > this just
> > seems to be definitions for the ioctl codes. So I suspect a
> > majority of the
> > drivers are
> > calling ioctl.
> >
> > Therefore, I figure the best way around this is probably to provide
> > a fake
> > ioctl that
> > provides the expected functionality, and make this wrap
> > DeviceIoControl
> > with something
> > that can translate the ioctl parameters into whatever...
> >
> > The only other way I see around this is to rewrite all calls to
> > ioctl, and
> > rewrite the
> > IOCTL codes with NT-style ones.
> >
> > Thoughts/ideas?
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
--------------------------------------------------------------------
mail2web.com What can On Demand Business Solutions do for you?
http://link.mail2web.com/Business/SharePoint
4Front.
Apparently it's "better".
Original Message:
-----------------
From: King InuYasha ngompa13(a)gmail.com
Date: Sat, 22 Sep 2007 16:32:11 -0500
To: reactos-development(a)silverblade.co.uk, ros-dev(a)reactos.org
Subject: Re: [ros-dev] Open Sound System porting
Which OSS implementation are you looking at? The OSS/Free one, or the OSS
one from 4Front?
On 9/22/07, reactos-development(a)silverblade.co.uk <
reactos-development(a)silverblade.co.uk> wrote:
>
> Thanks for all the replies so far.
>
> I find it quite insane that MSDN compares ioctl to DeviceIoControl. Whilst
> they achieve
> the same results, the actual parameters used etc. are entirely different.
>
> I'm not sure if Steven's suggestion would work (ie, use ws2_32) since, to
> my knowledge,
> that particular implementation is specific to sockets.
>
> Probably the best way around this then, would be to make an ioctl wrapper
> that takes the
> OSS-specific IOCTL codes, and translates them into custom NT IOCTL codes.
> The wrapper
> would take things like structures being passed via the ioctl and send them
> via
> DeviceIoControl instead.
>
> It does seem like a fair amount of work but if an appropriate "wrapper" is
> created, it
> could work...
>
>
> Original Message:
> -----------------
> From: King InuYasha ngompa13(a)gmail.com
> Date: Sat, 22 Sep 2007 10:28:50 -0500
> To: ros-dev(a)reactos.org
> Subject: Re: [ros-dev] Open Sound System porting
>
>
> Couldn't the source be patched to use DeviceIOControl instead of ioctl?
> According to MSDN about porting from UNIX to Win32, ioctl maps directly to
> DeviceIOControl, so it could be possible to simply change all the
> instances
> of ioctl to DeviceIOControl...
>
> On 9/22/07, Aleksey Bragin <aleksey(a)reactos.org> wrote:
> >
> > I didn't thoroughly look through the OSS source code, but if it has
> > some kind of platform-independent design in mind, then I would really
> > recommend porting, and porting with as minimal changes to the
> > original source code required (you probably are going to need a
> > wrapper-library, for ioctls at least, plus NT-specific parts).
> >
> > I may help too, because of the usb stack wrapping I did a while ago.
> >
> >
> > WBR,
> > Aleksey Bragin.
> >
> > >
> > > I've been in touch with the guy that ported OSS to Haiku (open-
> > > source BeOS)
> > > after some
> > > discussion with the folks over at #winehackers to get some help
> > > with audio
> > > development.
> > >
> > > Anyway, basically the idea so far is to use OSS as a "fall-back" audio
> > > driver
> > > implementation. So unless there is a "better" driver installed (ie an
> > > official one for
> > > an audio device), ReactOS can use an Open Sound System driver instead.
> > >
> > > The result? There will at least be sound functionality.
> > >
> > > OSS is designed to be mostly platform-independent. By rewriting a
> > > few of
> > > the core
> > > modules, the entire set of drivers will be able to work with whatever
> > > platform you
> > > desire.
> > >
> > > This can be implemented on top of the existing MME API architecture
> > > for the
> > > moment, and
> > > can later be translated to use the WDM audio framework.
> > >
> > > Anyway, having stuck the OSS code into my local ReactOS source
> > > tree, I'm
> > > trying to
> > > figure out how to get it to compile using rbuild. The first hurdle
> > > I have
> > > come across is
> > > that there is extensive use of ioctl. Indeed it seems that most
> > > ports of
> > > OSS work on
> > > platforms based on Posix (Unix?)
> > >
> > > So my main question at this time is how to handle this? The calls in
> > > question appear to
> > > be documented inside a file called "soundcard.h" in the OSS sources
> > > however
> > > this just
> > > seems to be definitions for the ioctl codes. So I suspect a
> > > majority of the
> > > drivers are
> > > calling ioctl.
> > >
> > > Therefore, I figure the best way around this is probably to provide
> > > a fake
> > > ioctl that
> > > provides the expected functionality, and make this wrap
> > > DeviceIoControl
> > > with something
> > > that can translate the ioctl parameters into whatever...
> > >
> > > The only other way I see around this is to rewrite all calls to
> > > ioctl, and
> > > rewrite the
> > > IOCTL codes with NT-style ones.
> > >
> > > Thoughts/ideas?
> > _______________________________________________
> > Ros-dev mailing list
> > Ros-dev(a)reactos.org
> > http://www.reactos.org/mailman/listinfo/ros-dev
> >
>
>
> --------------------------------------------------------------------
> mail2web.com What can On Demand Business Solutions do for you?
> http://link.mail2web.com/Business/SharePoint
>
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://link.mail2web.com/mail2web
