Ros-dev

ros-dev@reactos.org

1 participants
5790 discussions

Re: [ros-dev] [ros-diffs] [ekohl] 49646: [NPFS] - Rename DEVICE_EXTENSION to NPFS_VCB. - Add a type variable to distinguish FCBs and CCBs for device, directory or pipe. - Attach an FCB to the VCB that represents the root di...

by Aleksey Bragin

Great work, one more driver incompatibility away! WBR, Aleksey Bragin. On Nov 20, 2010, at 1:42 AM, ekohl(a)svn.reactos.org wrote: > Author: ekohl > Date: Fri Nov 19 22:42:53 2010 > New Revision: 49646 > > URL: http://svn.reactos.org/svn/reactos?rev=49646&view=rev > Log: > [NPFS] > - Rename DEVICE_EXTENSION to NPFS_VCB. > - Add a type variable to distinguish FCBs and CCBs for device, > directory or pipe. > - Attach an FCB to the VCB that represents the root directory of > the file system and implement an open routine for the root directory. > - Make NpfsWaitPipe work when it is called for the root directory. > > [KERNEL32] > - Remove the old version of WaitNamedPipeW. > > This patch fixes the broken wait pipe code. It was written and > tested on r49458 because later revisions do not work for me.

14 years, 9 months

Something for the holidays?

by Ros Arm

http://img824.imageshack.us/img824/734/stuffy.png -r

14 years, 9 months

Virtualization tool to run ReactOS

by Arko Provo Mukherjee

Dear All, Can you please kindly let me know which Virtualization tool I can use to run ReactOS. I am using Ubuntu currently and want to run ReactOS in top of that using a VM. Thanks a lot in advance! Warm regards Arko Provo Mukherjee

14 years, 9 months

winetest related regressions

by Timo Kreuzer

Just for the record: The changes are between r7324487 and r7281232. gdi32:palette +2 failures shell32:shlexec: crash user32:combo: +4 failures user32:cursoricon: -8 tests / +8 failures user32:edit: crash user32:monitor: not run user32:msg not run user32:win: -5743 tests winmm:mixer -192 tests

14 years, 9 months

Question regarding declaration of RTL_DRIVE_LETTER_CURDIR in include\ndk\rtltypes.h

by Sven Barth

Hello together! I'm currently poking around in the NDK headers very much and I noted a small inconsistency in the declaration of one type. The declaration is the following in include\ndk\rtltypes.h: ==== source begin ==== typedef struct RTL_DRIVE_LETTER_CURDIR { USHORT Flags; USHORT Length; ULONG TimeStamp; UNICODE_STRING DosPath; } RTL_DRIVE_LETTER_CURDIR, *PRTL_DRIVE_LETTER_CURDIR; ==== source end ==== Shouldn't it be "_RTL_DRIVE_LETTER_CURDIR" instead of "RTL_DRIVE_LETTER_CURDIR"? I don't know what influences this missing underscore has on compilation and such, cause I can read C without big problems and write a bit as well, but I don't understand every single bit a C compiler does ^^ Regards, Sven

14 years, 9 months

Re: [ros-dev] ReactOS official compatibility target and the new build system

by Samuel serapion

Doesn't windows use SxS to provide multiple versions of some dlls? I know its not for exacly the same purpose but perhaps coupled with some sort of app compat wizard we could really set hard version targets... but ofcourse it would mean building many dlls more than once On Nov 13, 2010 2:09 PM, "Colin Finck" <mail(a)colinfinck.de> wrote:

14 years, 9 months

ReactOS official compatibility target and the new build system

by Jérôme Gardou

Dear reactos developers. Once again, bringing reactos build to cmake arises questions. When this "port" has begun, it was decided that import libraries would be shipped with build environment, the now famous RosBE. This decision was made considering that : 1) functions exported by dlls do not change often. 2) Building an import library is a process that requires unneeded extra time. 3) 1 makes 2 unworthy. 4) If dll A imports function from dll B, it's not necessary to build B before A. 5) Solving 4 solves the problem of cross-dependency. As our target is win2k3 sp1 compatibility, a wise choice would be to choose import libraries that expose function only present on win2k3 sp1. The problem is that some wine dlls export functions that are from other windows versions, and, worse, use them. Let's see why this is a problem. - function A is a vista function from dll foo - function B is an XP function from dll bar - for some reasons, B implementation calls A. As you're clever developers ;-), you've seen that this would raise an error from the linker, as A is not present in our libfoo.a Hopefully, those cases are not too widespread, but they exist. Let's consider solutions that have arisen as of now : 1) Implement A as an inline function in headers, so anyone requiring it has it. 2) Linking bar.dll to some winefoo.dll, which forwards everything from foo.dll and exports the function A. 3) Add a "#if WIN32_WINNT > 0x502" before the guilty part of code, and "#else" with a win2k3 compliant implementation. 4) Oh dreams -> Ideally, convince wine to do it themself (./configure --wintarget=2k3sp1). 5) Change our target to win7, so we're ahead of wine. :-p 6) Do not change anything, and let our user mode libraries be a complete inconsistent anarchy. As 4 and 5 won't happen in a short time, let's consider 1, 2, 3 and 6: 1 is the best solution for easy winesyncs. We guard inline implementation by #ifndef BUILDING_FOO_DLL 2 would put a whole mess in system32 directory, but should be the most easy thing to do. 3 requires some extra work when syncing wine dlls. Though doing it often would reduce hassle. 6 isn't what I'd wish. What do you think? Your input is much appreciated. Best regards. The french speaking cmake team :-)

14 years, 9 months

[PREFIXES] in commit messages still useful?

by Colin Finck

Hi everyone, I'm wondering whether our [PREFIXES] in commit messages are still useful as of today? If I recall correctly, they were once added to autogenerate a changelog. I also remember that this dramatically failed when Ziliang created the 0.3.12 changelog and the full changelog needed to be redone from scratch, manually of course. Furthermore, I doubt that prefixes like "[SPRINTF]" (r49512) or faulty ones like "{ASM]" (r49413) can still be reasonably associated to a changelog category. After all, we don't even have a list of valid prefixes, so one has to first look at all used ones anyway. Of course, I don't want them to be dropped instantly tomorrow, but I'm interested in your opinions. I also don't yet know about the planned method for creating the 0.3.13 changelog, so I might be wrong on this. Cheers, Colin

14 years, 9 months

Networking

by Oleg Baikalow

Hi, I see you're busy discussing other stuff and my message went unnoticed :) I made a look to existing network branches, found many of them. LWIP is interesting. Alexey said the best way is to join your irc channel. I will try to occasionally join, but in your project, mailing list must be a primary point of discussion not irc channel. I think I start from making a simple, but robust tcpip driver (with help of numerously available source code of tcp/ip protocol implementations). Hopefully you could give me branch access, it's gonna be hard to develop it with patches. // Oleg Baikalow. P.S. I really like your "kernel coding style", quite rare to see that in opensource projects. Most of foss projects utilize linux-alike stlye, whic is harder to read and not that clean.

14 years, 9 months

Hook rewrite / regressions

by Aleksey Bragin

Hello, we have a serious regression in trunk which started 23rd of October with revision 49231 ("hook rewrite"). Considerable amount of time passed, automatic testing is not possible thus I'm afraid we are accumulating bugs. I think there is a need to revert 49231 + its dependencies in trunk to allow automated testing to work again and also fix regressions caused by this rewrite, and move this rewrite to a branch if possible. In future, it would be a good idea to: a. Discuss such serious rewrite merges beforehand (like Timo did with Yarotows). b. Try not to merge all rewrites simulteneously. E.g. I have to wait with heap rewrite merge (every rewrite contains a certain amount of bugs, by definition) even though it's fully ready. James - could you please share your opinion? The decision is yours, as you are the author of that commit. WBR, Aleksey Bragin.

14 years, 9 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev