Ros-dev October 2007

ros-dev@reactos.org

30 participants
45 discussions

Trying to push ideas (again:) )
by Alexandru Lovin 25 Sep '08

25 Sep '08

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

10 12

[ros-diffs] [weiden] 29670: Tweak the ScrollDC implementation a bit so that it produces a better output. The implementation still is completely incorrect as it should call the driver for this operation instead of doing a BitBlt operation...
by Timo Kreuzer 14 Nov '07

14 Nov '07

NtGdiBitBlt calls IntEngBitBlt, wich calls DrvBitBlt if available. There's no DrvScroll function. Timo > Author: weiden > Date: Fri Oct 19 07:23:04 2007 > New Revision: 29670 > > URL: http://svn.reactos.org/svn/reactos?rev=29670&view=rev <http://svn.reactos.org/svn/reactos?rev=29670&view=rev> > Log: > Tweak the ScrollDC implementation a bit so that it produces a better output. The implementation still is completely incorrect as it should call the driver for this operation instead of doing a BitBlt operation... > > Modified: > trunk/reactos/subsystems/win32/win32k/ntuser/painting.c >

3 2

Re: [ros-dev] [ros-diffs] [weiden] 29670: Tweak the ScrollDC implementation
by tamlin＠algonet.se 08 Nov '07

08 Nov '07

jimtabor wrote: >I noticed WndProc messages originate from win32k too. The window thread is >locked and then the message is sent out. > >Example: Function call User32 -> Win32k -> send message. > >Maybe we are doing double the work when we scroll on a bar. The rapid >blinking of the bar too. We maybe sending more than one message out. Trying a hypothesis here, could it work if all such w32k-registered- and-managed window classes, if not subclassed by the app, lock visual updates while calling back into usermode (cmp. LockWindowUpdate(hWnd) )? (recursive calls, whether intentional or from buggy user-mode app code could invalidate it) >4. Fix bugs. >5. Get paid! If you solve that... :-) -- Mike

2 2

Re: [ros-dev] [ros-diffs] [gbrunmar] 29929: Made each service have its own pipe name as done in Windows
by Aleksey Bragin 29 Oct '07

29 Oct '07

On Oct 28, 2007, at 5:13 PM, gbrunmar(a)svn.reactos.org wrote: > - DPRINT("CreateNamedPipeW() done\n"); > + DPRINT1("CreateNamedPipeW(%S) done\n", NtControlPipeName); Success reports should usually remain DPRINT, so that they don't pollute the debug log. WBR, Aleksey Bragin.

2 1

Re: [ros-dev] Moving some screensavers to rosapps
by Aleksey Bragin 28 Oct '07

28 Oct '07

Hi, "reactos" should have only bare minimum, so I agree about 1 gdi and 1 opengl. Other must be moved to rosapps. WBR, Aleksey Bragin. On Oct 28, 2007, at 2:32 AM, Colin Finck wrote: > Hello everyone, > > Now that we have 5 screensavers in trunk, and they are all in the > "reactos" > directory, it might be a good idea to move some of them to "rosapps". > The big question is now: Which ones shall be kept in "reactos" and > which > ones shall be moved to "rosapps"? > >> From the technical view, it's probably the best idea to keep one >> OpenGL and > one GDI screensaver in "reactos" (for example 3dtext and logon). > Please share your ideas about that. > > Regards, > > Colin

1 0

Moving some screensavers to rosapps
by Colin Finck 27 Oct '07

27 Oct '07

Hello everyone, Now that we have 5 screensavers in trunk, and they are all in the "reactos" directory, it might be a good idea to move some of them to "rosapps". The big question is now: Which ones shall be kept in "reactos" and which ones shall be moved to "rosapps"? >From the technical view, it's probably the best idea to keep one OpenGL and one GDI screensaver in "reactos" (for example 3dtext and logon). Please share your ideas about that. Regards, Colin

1 0

Re: [ros-dev] [ros-diffs] 29826 ...
by tamlin＠algonet.se 27 Oct '07

27 Oct '07

Alex Ionescu wrote: >>> 1) Why implement new, complex features in the kernel instead of >>> fixing current bugs? >> >> You pay, you get a saying in what I work on. I pay, I decide. > >No, this is an open source project, everyone gets a say on what you >work on -- you're free to ignore such sayings at your leisure. Seems I was too imprecise (or again a language barrier/misunderstanding). Sorry. My intention was to communicate that if you pay, you get the option of (trying to) tell me what to work on. When I pay, I decide. Obviously anyone is at any time free to comment. >The quota code is called by the process functions, and maybe even by >drivers, but it doesn't affect their behavior. I'm going out on a limb here (as I haven't checked it), but can't a JOB (artificially) limit available resources? That's part of their intention, isn't it? (please read on) >Two choices: > >1) Implement a rather complex quota implementation, including commit >charges in Mm (which is several thousand lines of code in NT), I knew I got into a rather large area, but this sounds insane for something as seemingly "simple". > to a fragile kernel If it's that fragile it needs to be fixed. If you got a better idea to do it than implementing previously missing functionality to expose those fragile parts of it, especially as what I started to work on apparently exposed those fragile parts, I'm all ears. > & > Use up a valuable developer's time, probably a couple man-weeks Should that be how I chose to spend my time - what's the difference if I hadn't been around at all? None, except the end result might make Win32 GlobalMemoryStatus and VM_COUNTERS present useful and usable data. > & > Add new bugs to a hot path during process/object creation/ >deletion (I hope you'll agree all new code has bugs) Only by convention, not by definition. :-) >OR > >2) Continue working on bug fixing the fragile parts of the kernel and >OS || Implement critical missing functionality for a target driver/ >application & This actually started as fixing critical missing functionality (Wax: feel free to chime in). Currently ROS does not COMMIT on such allocation requests. It happily allows an exe in a 128MB machine with 32MB pagefile to COMMIT almost 2GB memory. The error is of course in the way ROS handles COMMIT requests to VirtualAlloc, in that it defers committing the memory until something touches it... (that is no joke) The first step to research this was (for me) to see the behaviour of GlobalMemoryStatus, and indeed it was broken - it was unimplemented... So what do I do? I "dig where I stand". I start an attempt implementing the missing functionality. So the reason I came to touch Ps, and am digging way deeper in Mm than I'd really like to, is simply the GlobalMemoryStatus(Ex) Win32 API function(s), to even be able to verify, from user-mode, behaviour. [...] >> On a sidenote, the only public reference to PS_QUOTA_TYPE I could find >> were from a PDB file transcript from ntdll, posted at a french site. > >It should be added to the NDK. Agreed. But as I didn't know if that's still your baby (SVN access or not) and only synched at intervals, or if it has been "adopted", and if adding such data types, even if suspected to be correct, from such few and vague information source was even acceptable... I played it safe and used just the indices. Thanks for sharing the typename. If concensus is that adding that data type introduces no problems, even if from such a vague source, I'm in favor of adding it (as it'd solve more than one immediate problem). >>> 7) The quota routines require interlocks >> >> Yep. Even requires a lock for checking and updating QuotaPeak. > >No it doesn't, you can use Interlocked Compare Exchange. Are you thinking of the, semantically non-obvious for maintenance programmers, OldVal = Interlocked*Add(&Quota, Addend); InterlockedCompareExchange(&Peak, OldVal + Addend, OldVal + Addend); ? I think using a spinlock for that would make it much more obvious. Should profiling display it had a measurable impact on execution, sure. But we should also keep in mind we are then trading a single spinlock for two *locked* (bus-snooping/cache-invalidating) instructions. I don't know which is worse (performance wise). >>> 8) They also require a global spinlock in the "give back" case. >> >> I don't follow. Why? I'd imagine the "give back" case to be simpler >> than the charge case, as the former only needs to decrement the usage >> (InterlockedExchangeAdd with a negative value), while the latter needs >> to increment, followed by comparing with and possibly update Peak. > >The global spinlock is required when inserting new quota blocks, >dereferencing them, expanding the quota and giving back the quota. Ah, right... the quota blocks. As already displayed I didn't touch them (I honestly don't even know what they are for yet). I only looked at the (immediate) process quota entries. The linked lists I never touched. >I still disagree with trunk-is-a-playground I have never disagreed with that, so I'm not sure what you're referring to. >and I think that pseudo-code should go in branches, but you're free to disagree. I suggest you take that discussion with the project coordinator, that I cleared that diff with and he explicitly stated a preference for it even after I mentioned "branch". I disagree with you re. comments. I think pseudo-code in comments (in trunk even) is to prefer, as it can explain behaviours and intentions way better than plain english or even documentation. If those comments help maintenance-programmers ten or more years from now, even if only one single person, the comments were well spent time and place. -- Mike

1 0

Re: [ros-diffs] 29826 ...
by tamlin＠algonet.se 25 Oct '07

25 Oct '07

Alex Ionescu wrote: > 1) Why implement new, complex features in the kernel instead of > fixing current bugs? You pay, you get a saying in what I work on. I pay, I decide. > I had already written all these functions, but deleted them, Wasn't that a bonehead thing to do? > because nobody needed them, ... at the time. > and the Mm part was too complex to do. Guess what; I'm currently trying to actually implement it for Mm. Ps was a first step in that direction. Yes, Mm is complex, and yes I don't understand it enough yet - not by a longshot. But checking in incremental improvements, so that the code doesn't get lost, and disabled by default to not affect the behaviour of trunk - that's a good thing. It means people can both review and test the incremental changes, and perhaps even suggest improvements - like you did in pt. 5 below. > 2) Why are you bothering with PspPoolQuotaIndexFromPoolType? Ignorance of: > In case you haven't noticed, there's something called pool masks PAGED_POOL_MASK. Got it. > 5) Instead of duplicating code, perhaps consider calling a main > worker function such as PspChargeQuota? A sound refactoring suggestion. > 6) Consider using an enum instead of magic numbers inside the > quota entries, I believe it's called PS_QUOTA_TYPE. I just followed the lead of existing code. Had there been any mention of an enumeration for nonpaged, paged and pagefile, I would obviously have used those names. On a sidenote, the only public reference to PS_QUOTA_TYPE I could find were from a PDB file transcript from ntdll, posted at a french site. > 7) The quota routines require interlocks Yep. Even requires a lock for checking and updating QuotaPeak. > 8) They also require a global spinlock in the "give back" case. I don't follow. Why? I'd imagine the "give back" case to be simpler than the charge case, as the former only needs to decrement the usage (InterlockedExchangeAdd with a negative value), while the latter needs to increment, followed by comparing with and possibly update Peak. > 9) Committing code that won't even build, even with the define on, > isn't very appropriate. I agree. > If someone wants to actually test this, they won't be able to build it That's an interesting statement. Care to elaborate on how you reached such a factually wrong conclusion? > because of things like "refuse" Some people prefer pseudo-code over nothing at all. Some prefer void. Some people are able to spot C comment blocks. Some are not. Me, I checked that in with both the approval and a statement of preference for this kind of committs by the project coordinator. It not only compiles, it partially works too. > SVN should contain code that builds at any time. It's > not hard to write /* TODO */.. You really need (new?) glasses. You even quoted it yourself! "/* TODO: Check with Process->QuotaBlock if this can be satisfied, */" -- Mike

2 1

Re: [ros-diffs] 29702 ...
by tamlin＠algonet.se 25 Oct '07

25 Oct '07

Alex Ionescu wrote: > Windows uses the FILE_READ_DATA flag here, not FILE_READ_ATTRIBUTES. Yes? And? Let's study the code and the open modes used here. This code tries to open Device\HarddiskN\Partition0 (N = 0 ...) for the sole purpose of checking for availability, and immediately close the handle if the open succeeded. Why would one use FILE_READ_DATA if one never intended to read anything? The code also uses SYNCHRONIZE. Why would one use SYNCHRONIZE if one never intended to wait on the handle? As I see it, that's just requesting extra work for the purpose of nothing. The purpose of that open call is only to see if the disk exists, and if so create the symbolic link PhysicalDriveN -> HarddiskN\Partition0. I don't buy "Windows does this" without backing it up with any arguments whatsoever as to why Windows does this. Perhaps Windows does more with the returned handle than immediately closing it, something that actually requires READ_DATA? > all this is doing is hiding the bug (which is somewhere in vfat) I'm looking forward to the explanation of how opening HarddiskN\Partition0 (not "Partition1", not "Partition1\", but "Partition0" - aka the whole disk) would involve any filesystem activity whatsoever? > Because it's now gone, it'll probably happen in some mysterious > application 2 years from now and nobody will know why. Hahaha, you really are a joker. An app? Calling xHalIoAssignDriveLetters, that is called with a frickin' LoaderBlock? That function is used exactly once, during system startup. Health reasons suggest not holding your breath while waiting for such an application. :-) -- Mike

2 1

Re: [ros-dev] [ros-diffs] [mnordell] 29702: Don't try to open a harddisk for reading when checking for it to create the PhysicalDriveN links. Instead, request FILE_READ_ATTRIBUTES. This silences a hack-warning in IopParseDevice, that now possibly can be removed.
by Alex Ionescu 23 Oct '07

23 Oct '07

Windows uses the FILE_READ_DATA flag here, not FILE_READ_ATTRIBUTES. Silencing a warning does not mean fixing it -- all this is doing is hiding the bug (which is somewhere in vfat) in a place that's quite exposed. Because it's now gone, it'll probably happen in some mysterious application 2 years from now and nobody will know why. -- Best regards, Alex Ionescu On 20-Oct-07, at 3:36 AM, mnordell(a)svn.reactos.org wrote: > Author: mnordell > Date: Sat Oct 20 11:36:17 2007 > New Revision: 29702 > > URL: http://svn.reactos.org/svn/reactos?rev=29702&view=rev > Log: > Don't try to open a harddisk for reading when checking for it to > create the PhysicalDriveN links. Instead, request > FILE_READ_ATTRIBUTES. This silences a hack-warning in > IopParseDevice, that now possibly can be removed. > > Modified: > trunk/reactos/ntoskrnl/fstub/disksup.c > trunk/reactos/ntoskrnl/io/iomgr/file.c > > Modified: trunk/reactos/ntoskrnl/fstub/disksup.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ > fstub/disksup.c?rev=29702&r1=29701&r2=29702&view=diff > ====================================================================== > ======== > --- trunk/reactos/ntoskrnl/fstub/disksup.c (original) > +++ trunk/reactos/ntoskrnl/fstub/disksup.c Sat Oct 20 11:36:17 2007 > @@ -481,7 +481,7 @@ > NULL); > > Status = ZwOpenFile(&FileHandle, > - FILE_READ_DATA | SYNCHRONIZE, > + FILE_READ_ATTRIBUTES | SYNCHRONIZE, > &ObjectAttributes, > &StatusBlock, > FILE_SHARE_READ, > > Modified: trunk/reactos/ntoskrnl/io/iomgr/file.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/ > iomgr/file.c?rev=29702&r1=29701&r2=29702&view=diff > ====================================================================== > ======== > --- trunk/reactos/ntoskrnl/io/iomgr/file.c (original) > +++ trunk/reactos/ntoskrnl/io/iomgr/file.c Sat Oct 20 11:36:17 2007 > @@ -404,6 +404,9 @@ > > /* FIXME: Small hack still exists, have to check why... > * This is triggered multiple times by usetup and then once > per boot. > + * TMN: NOTE: It might have been fixed now, by changing the > requested > + * openmode in xHalIoAssignDriveLetters from FILE_READ_DATA to > + * FILE_READ_ATTRIBUTES. If verified, this hack should be > removed. > */ > if (!(DirectOpen) && > !(RemainingName->Length) && > >

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev October 2007