Ros-dev April 2008

ros-dev@reactos.org

15 participants
11 discussions

by Alexandru Lovin

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

16 years

Re: [ros-dev] [ros-diffs] [dchapyshev] 33106: - Keyboard layout switching works now in ReactOS!

by gedmurphy

Just to clarify to anyone following this thread, the change from SystemParametersInfo to sending a message isn't incorrect. kbswitch is meant to be a sort of makeshift ctfmon.exe, and isn't meant for switching keyboards system-wide as intl.cpl does. The buffer overflow problems still stand though. Ged. > -----Original Message----- > From: gedmurphy [mailto:gedmurphy@gmail.com] > Sent: 22 April 2008 21:03 > To: 'ros-dev(a)reactos.org' > Subject: RE: [ros-diffs] [dchapyshev] 33106: - Keyboard layout > switching works now in ReactOS! > > dchapyshev(a)svn.reactos.org wrote: > > > > Author: dchapyshev > > Date: Tue Apr 22 14:01:56 2008 > > New Revision: 33106 > > > > URL: http://svn.reactos.org/svn/reactos?rev=33106&view=rev > > Log: > > - Keyboard layout switching works now in ReactOS! > > > Hi, just a few points about this patch. > > > > + if (RegOpenKeyEx(HKEY_CURRENT_USER, _T("Keyboard > > Layout\\Substitutes"), 0, KEY_QUERY_VALUE, &hKey) == ERROR_SUCCESS) > > + { > > + dwBufLen = MAX_PATH; > > + > > + if (RegQueryValueEx(hKey, szTempLCID, NULL, NULL, > > (LPBYTE)szLCID, &dwBufLen) != ERROR_SUCCESS) > > > Firstly, Reg functions work on bytes, so you introduced a potential > buffer overflow here. > But this is irrelevant due to the next point ;) > > > > - Ret = SystemParametersInfo(SPI_SETDEFAULTINPUTLANG, 0, &hKl, > > SPIF_SENDWININICHANGE); > > + EnumWindows(EnumWindowsProc, (LPARAM) hKl); > > > This looks like a hack. The original method was correct, it just need > implementing in win32k. > Have a look in NtUserSystemParametersInfo. > > Thirdly, what is this kbswitch app? It's not a standard windows tool, > yet it's included in our base. > Keyboard switching is done in intl.cpl, or via ctfmon (which we don't > yet have) on a per app basis. > > Regards, > Ged.

16 years, 5 months

Re: [ros-dev] [ros-diffs] [dchapyshev] 33106: - Keyboard layout switching works now in ReactOS!

by gedmurphy

dchapyshev(a)svn.reactos.org wrote: > > Author: dchapyshev > Date: Tue Apr 22 14:01:56 2008 > New Revision: 33106 > > URL: http://svn.reactos.org/svn/reactos?rev=33106&view=rev > Log: > - Keyboard layout switching works now in ReactOS! Hi, just a few points about this patch. > + if (RegOpenKeyEx(HKEY_CURRENT_USER, _T("Keyboard > Layout\\Substitutes"), 0, KEY_QUERY_VALUE, &hKey) == ERROR_SUCCESS) > + { > + dwBufLen = MAX_PATH; > + > + if (RegQueryValueEx(hKey, szTempLCID, NULL, NULL, > (LPBYTE)szLCID, &dwBufLen) != ERROR_SUCCESS) Firstly, Reg functions work on bytes, so you introduced a potential buffer overflow here. But this is irrelevant due to the next point ;) > - Ret = SystemParametersInfo(SPI_SETDEFAULTINPUTLANG, 0, &hKl, > SPIF_SENDWININICHANGE); > + EnumWindows(EnumWindowsProc, (LPARAM) hKl); This looks like a hack. The original method was correct, it just need implementing in win32k. Have a look in NtUserSystemParametersInfo. Thirdly, what is this kbswitch app? It's not a standard windows tool, yet it's included in our base. Keyboard switching is done in intl.cpl, or via ctfmon (which we don't yet have) on a per app basis. Regards, Ged.

16 years, 5 months

Re: [ros-dev] [ros-diffs] [greatlrd] 33014: fixed pipe working again from cmd more investigate are need it to figout who to really solv bat and pipe and gui apps issue so none regress and working fine in all case. rember gui apps can resive pipe from cmd or send to

by Aleksey

Any real explanation in the commit message about what was done in this commit? Short, real and clean, so every developer reading the commit messages could understand what was done and why. I'm suspicious that it "fixes" one bug, and reopens another. The same note applies to "start kill the bad macro DXG_GET_INDEX_FUNCTION that is instable" (rev. 33012). Macro is a preprocessor definition, it can't be stable or not, it's being performed before the actual compile stage. Better to explain while enumerating through all functions to find the best one is worse than just getting a pointer by indexing. Or why it was done so in the beginning. With the best regards, Aleksey Bragin. ----- Original Message ----- From: <greatlrd(a)svn.reactos.org> To: <ros-diffs(a)reactos.org> Sent: Friday, April 18, 2008 4:56 AM Subject: [ros-diffs] [greatlrd] 33014: fixed pipe working again from cmd more investigate are need it to figout who to really solv bat and pipe and gui apps issue so none regress and working fine in all case. rember gui apps can resive pipe from cmd or send to cmd > Author: greatlrd > Date: Thu Apr 17 19:56:01 2008 > New Revision: 33014 > > URL: http://svn.reactos.org/svn/reactos?rev=33014&view=rev > Log: > fixed pipe working again from cmd > more investigate are need it to figout who to really solv bat and pipe and > gui apps issue > so none regress and working fine in all case. rember gui apps can resive > pipe from cmd or send to cmd

16 years, 6 months

ReactOS gdt limit

by Henning Schild

Hello ROS dev-team, i am currently working on qemu/kqemu and found that ROS sets the gdt limit to 0x800. At least this is what i see in qemu, i did not check ROS source. http://www.intel.com/design/processor/manuals/253668.pdf (3.5.1 p. 3-21) >> the GDT limit should always be one less than an integral multiple of >> eight (that is, 8N – 1) This may or may not be a problem. For all i can say ROS was the only of many different OSs that triggered the check in my setup. I may be wrong and wont investigate this any further. Just wanted to let you know. I used this version: http://prdownloads.sourceforge.net/reactos/ReactOS-0.3.4-REL-qemu.zip and that are the values i saw: base = 0x808bdac0 limit = 0x00000800 regards, Henning

16 years, 6 months

Ntifs.h

by Gabriel ilardi

Hi Team, I came across this site: http://www.acc.umu.se/~bosse/ which has some windows drivers examples, and talks about filesystem drivers, it has a gnu version of ntifs.h (http://www.acc.umu.se/~bosse/ntifs.h), I've taken a look at it, and noticed that ours misses some defines and some definitions use other types instead of ours. I thought perhaps someone from the team would want to take a look at it, perhaps we could use it. Thanks. Best regards, Gabriel ilardi. PS: If you already knew about it please ignore this email. _________________________________________________________________ Racconta le tue emozioni sul blog! http://home.services.spaces.live.com/

16 years, 6 months

Re : [ros-bugs] [Bug 3177] New: I try ReactOS-0.3.4-QEMU. When i try screensaver it gives bluescreen

by Sylvain Petreolle

Fireball, could you commit the bug writing guidelignes change to avoid this, please ? *saying Pleaase ... Help as Milla Jovovitch in the Fifth Element* Kind regards,Sylvain Petreolle (aka Usurp) Support artists, not multinationals - http://Iwouldntsteal.net Supportez les artistes, pas les multinationales - http://Iwouldntsteal.net ----- Message d'origine ---- > De : "ReactOS.Bugzilla(a)www.reactos.org" <ReactOS.Bugzilla(a)www.reactos.org> > À : ros-bugs(a)reactos.org > Envoyé le : Samedi, 12 Avril 2008, 22h08mn 14s > Objet : [ros-bugs] [Bug 3177] New: I try ReactOS-0.3.4-QEMU. When i try screensaver it gives bluescreen > > http://www.reactos.org/bugzilla/show_bug.cgi?id=3177 > > Summary: I try ReactOS-0.3.4-QEMU. When i try screensaver it > gives bluescreen > Product: ReactOS > Version: 0.3.4 > Platform: QEmu > OS/Version: Microsoft Windows XP > Status: UNCONFIRMED > Severity: normal > Priority: P3 > Component: Win32 > AssignedTo: ros-bugs(a)reactos.org > ReportedBy: maviates(a)gmail.com > QAContact: ros-bugs(a)reactos.org > > > Created an attachment (id=2431) > --> (http://www.reactos.org/bugzilla/attachment.cgi?id=2431) > BlueScreen > > I try ReactOS-0.3.4-QEMU. When i try screensaver it gives bluescreen > > > -- > Configure bugmail: http://www.reactos.org/bugzilla/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the QA contact for the bug. > You are the assignee for the bug. > _______________________________________________ > Ros-bugs mailing list > Ros-bugs(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-bugs >

16 years, 6 months

Re: [ros-dev] [ros-diffs] [cfinck] 32909: Manually sync "comctl32" and "comdlg32" on request of Apostolos Alexiadis. Just translation updates

by Aleksey

I thought those are on auto-winesync, aren't they? If you come to agreement with Herve, I don't mind. But anyway, Apostolos should submit those translation updates to Wine project. WBR, Aleksey Bragin. ----- Original Message ----- From: <cfinck(a)svn.reactos.org> To: <ros-diffs(a)reactos.org> Sent: Friday, April 11, 2008 1:00 AM Subject: [ros-diffs] [cfinck] 32909: Manually sync "comctl32" and "comdlg32" on request of Apostolos Alexiadis. Just translation updates > Author: cfinck > Date: Thu Apr 10 16:00:16 2008 > New Revision: 32909 > > URL: http://svn.reactos.org/svn/reactos?rev=32909&view=rev > Log: > Manually sync "comctl32" and "comdlg32" on request of Apostolos Alexiadis. > Just translation updates > > Modified: > trunk/reactos/dll/win32/comctl32/comctl_El.rc > trunk/reactos/dll/win32/comctl32/comctl_Si.rc > trunk/reactos/dll/win32/comdlg32/cdlg_El.rc > trunk/reactos/dll/win32/comdlg32/cdlg_No.rc > trunk/reactos/dll/win32/comdlg32/cdlg_Si.rc

16 years, 6 months

About ext2 driver installer

by King InuYasha

I looked at the ReactOS website and noticed that you guys are having problems getting an installer written for an ext2 driver for Windows XP? I would be happy to write an NSIS-based installer for the ext2 driver, if either someone could compile the driver for me, or tell me where the driver is in the ReactOS tree so I can build it myself and create an installer for it. I have written NSIS installers before, some that have advanced functionalities using Component Manager and ExperienceUI. Please let me know if you guys would like me to make this installer....

16 years, 6 months

win32k public headers

by Timo Kreuzer

I am currently trying to clean up our win32k headers. The situation so far: - ntgdi.h in psdk which should be compatible to ms version of ntgdi.h from the sdk - ntgdytyp.h containing a bunch of gdi related types in include/reactos/win32k - ntgdihdl.h containing handle related types and macros in include/reactos/win32k - ntgdibad.h containing private and ms incompatible functions and structures in include/reactos/win32k - ntuser.h containing ntuser functions and types in include/reactos/win32k - ntusertyp.h containing ntuser related types in include/reactos/win32k - W32CLIENTINFO is defined in both ntusertyp.h and ntgdityp.h (less complete). - there is the PATRECT structure in ntuser.h, and if ntuser.h is not included, also in ntgdityp.h, this should be named POLYPATBLT as defined in ntgdi.h, but there is only an incomplete type without the structure definition. (IMO ms should have put this structure into wingdi.h together with PolyPatBlt, but they don't seem to want anyone use that gdi32 exported function.) I wonder why ms put ntgdi.h into the sdk at all, as it's completely useless to user mode application writers, but well, ncie to have the prototypes ;-) So how do we clean up this mess? Suggestions: - when ms puts ntgdi.h into the sdk, we could also put ntuser.h there. - if we want to stay 100% compatible with sdk headers, we can add a define, like #ifdef USE_NON_SDK // put non sdk compatible but still windows compatible definitions here #endif - use a version definition, like I did with the simplecall definitions in ntuser.h to make it compatible to different windows versions - keep ntgdibad.h and create ntuserbad.h for incompatible definitions - ntgdihdl.h is used by win32k and gdi32, both also import ntgdityp.h. So I'd suggest merging that stuff into ntgdityp.h - maybe merge types into ntgdi.h and ntuser.h? Some definitions are already in there. - create win32ktypes.h and put ntuser/ntgdi shared stuff there, like W32CLIENTINFO - maybe add POLYPATBLT and PolyPatBlt() (others?) to wingdi.h inside USE_NON_SDK ifdef plus a POLYPATBLT_DEFINED I don't think it's a problem to make our sdk headers more complete than ms ones. This might help if we don't want a header mess or extra definitions inside the .c files. Comments appreciated. Thanks, Timo

16 years, 6 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev April 2008