- Ros-dev - ReactOS.org

Re: [ros-dev] [ros-diffs] [ekohl] 48722: [USETUP] Allocate a drive layout buffer that is l
by Pierre Schweitzer 07 Sep '10

07 Sep '10

Hi, why reimplementing an unsecure IoReadPartitionTable version? It even looks like IoReadPartitionTableEx() which may arrive soon in ReactOS ;). Best regards, P. Schweitzer

1 0

Re: [ros-dev] Usetup
by Love Nystrom 07 Sep '10

07 Sep '10

Hi, What You say makes sense of course. I can't find time to dig into the code, but it sounds like you acted correctly. We can of course improve the setup behavior as time goes and we learn how to do it right with various boot managers, no need to take after Microsoft here, but there will always be cases when we don't know how to wedge the boot in. We can always, as long as there is a free partition or free space to create one, get as far as installing the OS and it's partition boot, but may be unable to install a master boot, if the user has an unknown boot manager we don't recognize One way to deal with it would be to chain the master boot. That is, we save the original master boot to a file, and implement a query in our own master boot, whether the user want to boot ROS, or continue with the original master boot. It would be a small matter to load the original master boot and giving control over to it if need be. Sure, it's one more pit-stop on the way to OS, but it would take care of all the cases we cannot know, or cannot handle. Best Regards L from Hell Eric Kohl <eric.kohl(a)t-online.de> wrote: > Hi! > > Being cooperative was my intention when I wrote this part of usetup. > The bad thing about this approach is that usetup needs to deal with > all kinds of different situations that developers cannot even think > about. The only proper way to fix this situation was: "Don't touch it > if you don't know how to deal with it!" The result was that usetup > could only handle empty harddisks and Windows boot managers correctly. > Except for these two cases there are lots of different situations that > a setup application cannot deal with. That's where the user must fix > things. That's why usetup enables users to save the bootsector to a > floppy disk. This enables them to fix the unknown situations > themselves. Unfortunately this means that newbies might not be able to > install the bootcode properly. But I thought it was better not to > overwrite a bootsector that to unintentionally damage a system. > > The question how to handle this correctly is a difficult one. > Microsoft chose the easy way as they behave like they are the owner of > the system and overwrite everything as they see fit. But implementing > this part of the setup in a way that fits everyones needs is a very > difficult task. Just think about the different filesystems and > different versions of LILO and GRUB and what about other third-party > boot-managers... > > Regards, > Eric

1 0

[ros-diffs] [cgutman] 48700: [USETUP] - Remove code that was corrupting disk data and causing setup to fail in rare cases - Write the MBR in all cases (Windows setup behavior too) - We can overwrite GRUB and L...
by James Tabor 05 Sep '10

05 Sep '10

Hi! Please test this with GRUB and LILO, since I use LILO on my main hardware test. I do not have access to it for the moment. During the installation of the boot CD, I do not overwrite the MBR. I just hope it works when I get back to work with the project. Thanks, James

5 4

Re: [ros-dev] Convert fat12/16 boot sector helper code to gas syntax.
by Love Nystrom 04 Sep '10

04 Sep '10

Second that. If it ain't broke, don't bloody "fix" it. Best Regards L from Hell Alex Ionescu <ionucu(a)videotron.ca>: > This is retarded, GAS supports Intel syntax. Why did this require > rewriting everything in AT&T syntax and introducing bugs? And what's > up with calling AT&T syntax "GAS" Syntax. > > I wonder what Brian would say.... > > It's funny how this project gets rid of old developers, gets new > developers, and has them make the same mistakes/idiotic things the old > developers left for in the first place... > > Good job! > > Best regards, > Alex Ionescu > >

2 1

Bugzilla Workflow project
by Olaf Siejka 28 Aug '10

28 Aug '10

Allow me to present a small sub-project Gabriel and I are working on. We did a small scale consulting, but its the time to present it on a more wider scale. As a comment, specifically to Timo's post: 2nd class tags should not be conflicting with Component field when possible. In case of Kernel and win32k, a submodule should be used instead of module name: for example in case of kernel bugs, Components should be set to Kernel, whereas 2nd class tag should be pointing to kernel submodule, like iomgr:, ob:, mm: etc. All opinions are most welcome Best regards

1 0

Bugzilla interface
by Timo Kreuzer 28 Aug '10

28 Aug '10

Hi I'd like to propose an overhaul of our bugzilla interface. The reason is that the current interface is ugly and confusing and I think we can make filing and handling bugs less unenjoyable ;-) First I think it would be very useful, if we could edit the description field of the bugs. This way we don't need to browse through dozens of comments to find all neccessary info, while the description only contains useless stuff. This should be restricted to the original reporter and testers / developers. Then when filing a new bug or looking at a bug that is already filed, the layout is horrible. I'm not a webdesigner, so it's hard for me to say how it should look like, but definately not the way it is. This might be appropriate for projects whose website look like http://www.gnu.org/software/binutils/ but I'm sure, we can do better. Then when filing a bug there are the following fields: - reporter - I know who I am, so why show it to me? Unneccessary - Component: I don't think this field is really useful as it is. First: Patches are definately not a component. Then it's often hard to tell where the bug is. for example, if rapps doesn't download anything, is that related to network or is it a kernel bug or win32 or rapps or is only the server down? You often don't know it when filing a bug. Also win32 covers a lot from win32k to shell32, but are these more closely related than drivers and networking? - Severity: while I think this field is useful and important, it should only be editable by testers and developers and should not appear when a bug is filed. - Platform: should be removed - OS: should be removed - AssignTo, Cc: rarely used on first filing, should IMO only be editable by testers / developers - URL: While we use this field from time to time, I think the URL could as well, if neccessary be put into the description field (provided, it was editable). This versatile field should imo change it's purpose from URL to TAG. So we can add different tags, like REGRESSION, PATCH, HACK, that are currently put into the summery field. It could also contain the regression range or guilty version - Alias: we don't use this, or rather currently only misuse this for the guilty version, which is problematic, as soon as 2 bugs have the same guilty version, IMO unneccessary - Summery: should be as wide as the description field - Description: To get better bugreports, I suggest dividing this field into "Steps to reproduce:" "Experienced behaviour:" "Remarks" These fields can very well be automatically merged into one field, It's just to show people that they must provide steps to reproduce, instead of writing dozens of lines about their hardware configuration and how they feel about the bug. Regards, Timo

6 10

Regarding 48632
by Ros Arm 28 Aug '10

28 Aug '10

Hello, Many thanks for fixing this idiotic oversight of mine. I apologies for the long hours of debugging I must have caused. This fix is somewhat incomplete/at the wrong place; could this be marked as such in the code, perhaps with a FIXME under my name, so that I may fix this correctly upon my return to the US? Much obliged! -r Author: mjmartin Date: Sat Aug 28 00:26:02 2010 New Revision: 48632 URL: http://svn.reactos.org/svn/reactos?rev=48632&view=rev Log: [ntoskrnl/ps] - When deleting a Process remove the Process from the MmProcessList. Fixes random NonPaged Pool corruptions. Thanks aicom for assistance. Modified: trunk/reactos/ntoskrnl/ps/kill.c Modified: trunk/reactos/ntoskrnl/ps/kill.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ps/kill.c?rev=486… ============================================================================== --- trunk/reactos/ntoskrnl/ps/kill.c [iso-8859-1] (original) +++ trunk/reactos/ntoskrnl/ps/kill.c [iso-8859-1] Sat Aug 28 00:26:02 2010 @@ -300,6 +300,8 @@ /* Detach */ KeUnstackDetachProcess(&ApcState); + + RemoveEntryList(&Process->MmProcessLinks); /* Completely delete the Address Space */ MmDeleteProcessAddressSpace(Process);

2 1

Re: [ros-dev] [ros-diffs] [cgutman] 48593: [DHCPCSVC] - Write the DNS servers in a REG_MULTI_SZ value [IPHLPAPI] - Rewrite the registry reading code - Use HeapFree to free memory from the allocated from heap
by Timo Kreuzer 24 Aug '10

24 Aug '10

It looks like this change has caused some regressions in sysreg http://www.reactos.org/testman/compare.php?ids=3934,3935 cgutman(a)svn.reactos.org wrote: > Author: cgutman > Date: Sun Aug 22 22:22:27 2010 > New Revision: 48593 > > URL: http://svn.reactos.org/svn/reactos?rev=48593&view=rev > Log: > [DHCPCSVC] > - Write the DNS servers in a REG_MULTI_SZ value > [IPHLPAPI] > - Rewrite the registry reading code > - Use HeapFree to free memory from the allocated from heap > > Modified: > trunk/reactos/dll/win32/dhcpcsvc/dhcp/dhclient.c > trunk/reactos/dll/win32/iphlpapi/iphlpapi_private.h > trunk/reactos/dll/win32/iphlpapi/registry.c > trunk/reactos/dll/win32/iphlpapi/resinfo_reactos.c > > Modified: trunk/reactos/dll/win32/dhcpcsvc/dhcp/dhclient.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/dhcpcsvc/dhcp/dh… > ============================================================================== > --- trunk/reactos/dll/win32/dhcpcsvc/dhcp/dhclient.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/dhcpcsvc/dhcp/dhclient.c [iso-8859-1] Sun Aug 22 22:22:27 2010 > @@ -507,24 +507,25 @@ > char *nsbuf; > int i, addrs = > new_lease->options[DHO_DOMAIN_NAME_SERVERS].len / sizeof(ULONG); > - > - nsbuf = malloc( addrs * sizeof(IP_ADDRESS_STRING) ); > + int len = 0; > + > + nsbuf = malloc( addrs * sizeof(IP_ADDRESS_STRING) + 1 ); > > if( nsbuf) { > - nsbuf[0] = 0; > + memset(nsbuf, 0, addrs * sizeof(IP_ADDRESS_STRING) + 1); > for( i = 0; i < addrs; i++ ) { > nameserver.len = sizeof(ULONG); > memcpy( nameserver.iabuf, > new_lease->options[DHO_DOMAIN_NAME_SERVERS].data + > (i * sizeof(ULONG)), sizeof(ULONG) ); > strcat( nsbuf, piaddr(nameserver) ); > - if( i != addrs-1 ) strcat( nsbuf, "," ); > + len += strlen(nsbuf) + 1; > } > > DH_DbgPrint(MID_TRACE,("Setting DhcpNameserver: %s\n", nsbuf)); > > - RegSetValueExA( RegKey, "DhcpNameServer", 0, REG_SZ, > - (LPBYTE)nsbuf, strlen(nsbuf) + 1 ); > + RegSetValueExA( RegKey, "DhcpNameServer", 0, REG_MULTI_SZ, > + (LPBYTE)nsbuf, len + 1 ); > free( nsbuf ); > } > > > Modified: trunk/reactos/dll/win32/iphlpapi/iphlpapi_private.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/iphlpapi/iphlpap… > ============================================================================== > --- trunk/reactos/dll/win32/iphlpapi/iphlpapi_private.h [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/iphlpapi/iphlpapi_private.h [iso-8859-1] Sun Aug 22 22:22:27 2010 > @@ -139,6 +139,7 @@ > PWCHAR GetNthChildKeyName( HANDLE RegHandle, DWORD n ); > void ConsumeChildKeyName( PWCHAR Name ); > PWCHAR QueryRegistryValueString( HANDLE RegHandle, PWCHAR ValueName ); > +PWCHAR *QueryRegistryValueStringMulti( HANDLE RegHandle, PWCHAR ValueName ); > void ConsumeRegValueString( PWCHAR NameServer ); > BOOL isInterface( TDIEntityID *if_maybe ); > BOOL hasArp( HANDLE tcpFile, TDIEntityID *arp_maybe ); > > Modified: trunk/reactos/dll/win32/iphlpapi/registry.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/iphlpapi/registr… > ============================================================================== > --- trunk/reactos/dll/win32/iphlpapi/registry.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/iphlpapi/registry.c [iso-8859-1] Sun Aug 22 22:22:27 2010 > @@ -66,25 +66,123 @@ > if (Name) HeapFree( GetProcessHeap(), 0, Name ); > } > > -PWCHAR QueryRegistryValueString( HANDLE RegHandle, PWCHAR ValueName ) { > - PWCHAR Name; > - DWORD ReturnedSize = 0; > +PVOID QueryRegistryValue(HANDLE RegHandle, PWCHAR ValueName, LPDWORD RegistryType, LPDWORD Length) > +{ > + PVOID ReadValue = NULL; > + DWORD Error; > > - if (RegQueryValueExW( RegHandle, ValueName, NULL, NULL, NULL, > - &ReturnedSize ) != 0) { > - return 0; > - } else { > - Name = malloc( ReturnedSize); > - RegQueryValueExW( RegHandle, ValueName, NULL, NULL, (PVOID)Name, > - &ReturnedSize ); > - return Name; > - } > + *Length = 0; > + *RegistryType = REG_NONE; > + > + while (TRUE) > + { > + Error = RegQueryValueExW(RegHandle, ValueName, NULL, RegistryType, ReadValue, Length); > + if (Error == ERROR_SUCCESS) > + { > + if (ReadValue) break; > + } > + else if (Error == ERROR_MORE_DATA) > + { > + HeapFree(GetProcessHeap(), 0, ReadValue); > + } > + else break; > + > + ReadValue = HeapAlloc(GetProcessHeap(), 0, *Length); > + if (!ReadValue) return NULL; > + } > + > + if (Error != ERROR_SUCCESS) > + { > + if (ReadValue) HeapFree(GetProcessHeap(), 0, ReadValue); > + > + *Length = 0; > + *RegistryType = REG_NONE; > + ReadValue = NULL; > + } > + > + return ReadValue; > +} > + > +PWCHAR TerminateReadString(PWCHAR String, DWORD Length) > +{ > + PWCHAR TerminatedString; > + > + TerminatedString = HeapAlloc(GetProcessHeap(), 0, Length + sizeof(WCHAR)); > + if (TerminatedString == NULL) > + return NULL; > + > + memcpy(TerminatedString, String, Length); > + > + TerminatedString[Length / sizeof(WCHAR)] = UNICODE_NULL; > + > + return TerminatedString; > +} > + > +PWCHAR QueryRegistryValueString( HANDLE RegHandle, PWCHAR ValueName ) > +{ > + PWCHAR String, TerminatedString; > + DWORD Type, Length; > + > + String = QueryRegistryValue(RegHandle, ValueName, &Type, &Length); > + if (!String) return NULL; > + if (Type != REG_SZ) > + { > + DbgPrint("Type mismatch for %S (%d != %d)\n", ValueName, Type, REG_SZ); > + //HeapFree(GetProcessHeap(), 0, String); > + //return NULL; > + } > + > + TerminatedString = TerminateReadString(String, Length); > + HeapFree(GetProcessHeap(), 0, String); > + if (!TerminatedString) return NULL; > + > + return TerminatedString; > } > > void ConsumeRegValueString( PWCHAR Value ) { > - if (Value) free(Value); > + if (Value) HeapFree(GetProcessHeap(), 0, Value); > } > > PWCHAR *QueryRegistryValueStringMulti( HANDLE RegHandle, PWCHAR ValueName ) { > - return 0; /* FIXME if needed */ > + PWCHAR String, TerminatedString, Tmp; > + PWCHAR *Table; > + DWORD Type, Length, i, j; > + > + String = QueryRegistryValue(RegHandle, ValueName, &Type, &Length); > + if (!String) return NULL; > + if (Type != REG_MULTI_SZ) > + { > + DbgPrint("Type mismatch for %S (%d != %d)\n", ValueName, Type, REG_MULTI_SZ); > + //HeapFree(GetProcessHeap(), 0, String); > + //return NULL; > + } > + > + TerminatedString = TerminateReadString(String, Length); > + HeapFree(GetProcessHeap(), 0, String); > + if (!TerminatedString) return NULL; > + > + for (Tmp = TerminatedString, i = 0; *Tmp; Tmp++, i++) while (*Tmp) Tmp++; > + > + Table = HeapAlloc(GetProcessHeap(), 0, (i + 1) * sizeof(PWCHAR)); > + if (!Table) > + { > + HeapFree(GetProcessHeap(), 0, TerminatedString); > + return NULL; > + } > + > + for (Tmp = TerminatedString, j = 0; *Tmp; Tmp++, j++) > + { > + PWCHAR Orig = Tmp; > + > + for (i = 0; *Tmp; i++, Tmp++); > + > + Table[j] = HeapAlloc(GetProcessHeap(), 0, i * sizeof(WCHAR)); > + memcpy(Table[j], Orig, i * sizeof(WCHAR)); > + } > + > + Table[j] = NULL; > + > + HeapFree(GetProcessHeap(), 0, TerminatedString); > + > + return Table; > } > > Modified: trunk/reactos/dll/win32/iphlpapi/resinfo_reactos.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/iphlpapi/resinfo… > ============================================================================== > --- trunk/reactos/dll/win32/iphlpapi/resinfo_reactos.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/iphlpapi/resinfo_reactos.c [iso-8859-1] Sun Aug 22 22:22:27 2010 > @@ -122,47 +122,24 @@ > > void EnumNameServers( HANDLE RegHandle, PWCHAR Interface, > PVOID Data, EnumNameServersFunc cb ) { > - PWCHAR NameServerString = > - QueryRegistryValueString(RegHandle, L"DhcpNameServer"); > + PWCHAR *NameServerString = > + QueryRegistryValueStringMulti(RegHandle, L"DhcpNameServer"); > + DWORD i; > > if (!NameServerString) > - NameServerString = QueryRegistryValueString(RegHandle, L"NameServer"); > - > - if (NameServerString) { > - /* Now, count the non-empty comma separated */ > - DWORD ch; > - DWORD LastNameStart = 0; > - for (ch = 0; NameServerString[ch]; ch++) { > - if (NameServerString[ch] == ',') { > - if (ch - LastNameStart > 0) { /* Skip empty entries */ > - PWCHAR NameServer = > - malloc(((ch - LastNameStart) + 1) * sizeof(WCHAR)); > - if (NameServer) { > - memcpy(NameServer,NameServerString + LastNameStart, > - (ch - LastNameStart) * sizeof(WCHAR)); > - NameServer[ch - LastNameStart] = 0; > - cb( Interface, NameServer, Data ); > - free(NameServer); > - LastNameStart = ch +1; > - } > - } > - LastNameStart = ch + 1; /* The first one after the comma */ > - } > - } > - if (ch - LastNameStart > 0) { /* A last name? */ > - PWCHAR NameServer = malloc(((ch - LastNameStart) + 1) * sizeof(WCHAR)); > - if (NameServer) { > - memcpy(NameServer,NameServerString + LastNameStart, > - (ch - LastNameStart) * sizeof(WCHAR)); > - NameServer[ch - LastNameStart] = 0; > - cb( Interface, NameServer, Data ); > - free(NameServer); > - } > - } > - ConsumeRegValueString(NameServerString); > - } > -} > - > + NameServerString = QueryRegistryValueStringMulti(RegHandle, L"NameServer"); > + > + if (!NameServerString) return; > + > + for (i = 0; NameServerString[i]; i++) > + { > + cb(Interface, NameServerString[i], Data); > + > + HeapFree(GetProcessHeap(), 0, NameServerString[i]); > + } > + > + HeapFree(GetProcessHeap(), 0, NameServerString); > +} > static void CreateNameServerListEnumNamesFuncCount( PWCHAR Interface, > PWCHAR Server, > PVOID _Data ) { > > > >

4 4

Fedora 13 Build Error
by James Tabor 23 Aug '10

23 Aug '10

I ran into this on Fedora 13, [HOST-CC] tools/cabman/cabinet.cxx tools/cabman/cabinet.cxx: In member function ‘bool CCabinet::CreateSimpleCabinet()’: tools/cabman/cabinet.cxx:2177: error: no matching function for call to ‘stat::stat(char [260], stat*)’ /usr/include/bits/stat.h:40: note: candidates are: stat::stat() /usr/include/bits/stat.h:40: note: stat::stat(const stat&) from http://code.google.com/p/libproxy/issues/detail?id=122 the patch is based on this; http://code.google.com/p/libproxy/issues/attachmentText?id=122&aid=20023750… Index: tools/cabman/cabinet.cxx =================================================================== --- tools/cabman/cabinet.cxx (revision 48297) +++ tools/cabman/cabinet.cxx (working copy) @@ -21,7 +21,8 @@ #if !defined(WIN32) # include <dirent.h> #endif -#if defined(__FreeBSD__) || defined(__APPLE__) +#if !defined(WIN32) || defined(__FreeBSD__) || defined(__APPLE__) +# include <sys/types.h> # include <sys/stat.h> #endif // __FreeBSD__ #include "cabinet.h" Not sure this is right, so~ posted here for fast review and fix, James

3 4

Re: [ros-dev] [ros-diffs] [akhaldi] 48535: [CMAKE] - Add calc to build.
by Colin Finck 22 Aug '10

22 Aug '10

akhaldi(a)svn.reactos.org wrote: > +++ branches/cmake-bringup/base/applications/calc/CMakeLists.txt > [...] > > +file(GLOB_RECURSE SOURCE *.c) > +list(REMOVE_ITEM SOURCE > + ${CMAKE_CURRENT_SOURCE_DIR}/fun_mpfr.c > + ${CMAKE_CURRENT_SOURCE_DIR}/rpn_mpfr.c > + ${CMAKE_CURRENT_SOURCE_DIR}/utl_mpfr.c) Should GLOB_RECURSE and later removing unwanted source files really be the way to go? The only advantage I see are smaller CMakeLists files. On the contrary, it is quite an uncommon way and just adding a single unrelated file into an application's directory could render it unbuildable. Additionally, please take a look at http://public.kitware.com/pipermail/cmake/2010-July/037833.html. According to this user, CMake cannot automatically detect added files when using GLOB_RECURSE. In my opinion, we should list every source file to be included to prevent unexpected side effects. Cheers, Colin

3 2

Truncating ros-diffs subject lines
by Colin Finck 22 Aug '10

22 Aug '10

Hi everybody, Looking at http://www.reactos.org/pipermail/ros-diffs/2010-August/038197.html and the same message in Thunderbird, I now see a need to automatically truncate all subject lines in ros-diffs' mails to 200 characters. I don't think that anybody reads the full commit messages through subject lines, so 200 characters should be enough to identify a commit easily. If there are no objections, I'll try to change this in the next few days. Cheers, Colin

4 4

Re: [ros-dev] [ros-diffs] [tkreuzer] 48576: [WIN32K] - co_IntTranslateMouseMessage: properly initialize *HitTest and only send WM_NCHITTEST when the message is going to be removed - co_IntPeekMessage: Prevent possible use of uninitialized HitTest by ProcessMou
by Monkey Libre 21 Aug '10

21 Aug '10

2010/8/20, tkreuzer(a)svn.reactos.org <tkreuzer(a)svn.reactos.org>: > Author: tkreuzer > Date: Fri Aug 20 19:24:48 2010 > New Revision: 48576 > > URL: http://svn.reactos.org/svn/reactos?rev=48576&view=rev > Log: > [WIN32K] > - co_IntTranslateMouseMessage: properly initialize *HitTest and only send > WM_NCHITTEST when the message is going to be removed > - co_IntPeekMessage: Prevent possible use of uninitialized HitTest by > ProcessMouseMessage() > - Patch by Jan Roeloffzen [jroeloffzen at hotmail dot com] > - Fixes bug 2139 > > Modified: > trunk/reactos/subsystems/win32/win32k/ntuser/message.c > > Modified: trunk/reactos/subsystems/win32/win32k/ntuser/message.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/ntuser/message.c [iso-8859-1] > (original) > +++ trunk/reactos/subsystems/win32/win32k/ntuser/message.c [iso-8859-1] Fri > Aug 20 19:24:48 2010 > @@ -579,14 +579,20 @@ > return TRUE; > } > > + *HitTest = HTCLIENT; > + > UserRefObjectCo(Window, &Ref); > > if ( ThreadQueue == Window->pti->MessageQueue && > ThreadQueue->CaptureWindow != Window->hSelf) > { > /* only send WM_NCHITTEST messages if we're not capturing the window! > */ > - *HitTest = co_IntSendMessage(Window->hSelf, WM_NCHITTEST, 0, > - MAKELONG(Msg->pt.x, Msg->pt.y)); > + if (Remove ) > + { > + *HitTest = co_IntSendMessage(Window->hSelf, WM_NCHITTEST, 0, > + MAKELONG(Msg->pt.x, Msg->pt.y)); > + } > + /* else we are going to see this message again, but then with Remove > == TRUE */ > > if (*HitTest == (USHORT)HTTRANSPARENT) > { > @@ -625,10 +631,6 @@ > UserDerefObjectCo(DesktopWindow); > } > } > - } > - else > - { > - *HitTest = HTCLIENT; > } > > if ( gspv.bMouseClickLock && > @@ -800,6 +802,8 @@ > * WM_TIMER messages > */ > CheckMessages: > + > + HitTest = HTNOWHERE; > > Present = FALSE; > > > > -- My translator and tester profile: https://launchpad.net/~monkey-libre -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkq9LEMACgkQY9l6fYUypMPuvACeIZFzQSH3yxMy4wHpQpjK5y9t l34An2b5eHl/hA/AaB8GKbJczM2v0UcT =4iFN -----END PGP SIGNATURE-----

1 0

MyReactOS: A Proof of Concept
by victor martinez 15 Aug '10

15 Aug '10

Hello everyone! In the latest 6 months, Niski and I have been working on a testing ground/proof of concept of a ReactOS community site, currently called the ReactOS Portal. The idea of a ReactOS community site has been floating around for years due to the fact that our followers (Users and Non-Users) keep expecting more info and more features. For this purpose, and having in mind that a ReactOS community site needs to focus on the followers' needs, we've created a light, eyecandy, easy to maintain Drupal-based site, to serve as a testing ground, and also as a proof of concept for the ReactOS Community idea. Despite the fact that the community site is mainly targeted towards the project followers, we didn't forget our developers and official testers needs. We've already included some (hopefully) useful features, and we welcome ideas and suggestions. The community site is made for everyone, by everyone. To avoid quite a lengthy email, we'll enumerate the Top Features we've added. We've also prepared a PDF and a Video, that you can download from this URL: http://download.myreactos.com/?dir=Vicmarcal ) ************ALL+IN+1*********** All the info in ONE click (latest blog posts, forum replies, commits, ML posts and wiki activity) ******Multiblogging System***** Several blogs, managed from just one Blogging System. Easy to post and maintain. ***********IRC-CHAT************ An integrated IRC client for the ReactOS communiy. *********Contact Page********** Redesigned, full of info. **************FAQ************* A much more user oriented FAQ with new Tester and Translator sections. ************RosKarma*********** A new forum module : "More Karma an User has, more reliable he is" and a new Autobanning System : "Bye,bye Trolls". *********Answered Post********* Another new forum module : Answered topics turn Green(easy to spot) and get locked ("No more Necromancy"). ***********Rosquests*********** Another new Forum module : "Use Forum Users skills for ReactOS project". How? Read the PDF or watch the video for more details. **********MultivideoBox******** "An image is worth than thousand words". Videotutorials, ReactOS presentations... and much more. *******Social Networking******* "Facebook, Vimeo, Youtube, and Tweeter integration". And after getting some feedback we've added more features : ***Unlimited/Free FTP account*** Now Official Developers/Testers can have FTP accounts to easily and conveniently share ReactOS ISOs (or any other files). We're also considering integrating the Software Compatibility Database into the Portal. We hope you like it, your feedback is very important, so that we can create a comfortable, highly efficient Community Site. More info in the Video+PDF: http://download.myreactos.com/?dir=Vicmarcal Thanks to all the ReactOS members that are joining, posting and translating. Thanks to everyone involved ;) Victor Martinez Calvo Maciej Bialas www.myreactos.com

3 2

Re: [ros-dev] [ros-diffs] [cgutman] 48522: [MSAFD] - Update lpcbBytesReturned when FIONREAD is called - Fix the value inside lpErrno when XxxSocketInformation() fails - Pass the unrecognized IOCTLs to the winsock helper (no behavior change for this yet because wsh
by Gabriel ilardi 14 Aug '10

14 Aug '10

Was this meant for trunk instead of a branch ? After this commit DNS resolution doesn't work. Thanks. Gabriel. > Date: Thu, 12 Aug 2010 13:13:21 +0000 > To: ros-diffs(a)reactos.org > From: cgutman(a)svn.reactos.org > Subject: [ros-diffs] [cgutman] 48522: [MSAFD] - Update lpcbBytesReturned when FIONREAD is called - Fix the value inside lpErrno when XxxSocketInformation() fails - Pass the unrecognized IOCTLs to the winsock helper (no behavior change for this yet because wshtcpip's WSHIoctl is unimplemented) > > Author: cgutman > Date: Thu Aug 12 13:13:19 2010 > New Revision: 48522 > > URL: http://svn.reactos.org/svn/reactos?rev=48522&view=rev > Log: > [MSAFD] > - Update lpcbBytesReturned when FIONREAD is called > - Fix the value inside lpErrno when XxxSocketInformation() fails > - Pass the unrecognized IOCTLs to the winsock helper (no behavior change for this yet because wshtcpip's WSHIoctl is unimplemented) > > Modified: > trunk/reactos/dll/win32/msafd/misc/dllmain.c > > Modified: trunk/reactos/dll/win32/msafd/misc/dllmain.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msafd/misc/dllma… > ============================================================================== > --- trunk/reactos/dll/win32/msafd/misc/dllmain.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/msafd/misc/dllmain.c [iso-8859-1] Thu Aug 12 13:13:19 2010 > @@ -1910,6 +1910,7 @@ > OUT LPINT lpErrno) > { > PSOCKET_INFORMATION Socket = NULL; > + BOOLEAN NeedsCompletion; > > /* Get the Socket Structure associate to this Socket*/ > Socket = GetSocketStructure(Handle); > @@ -1918,6 +1919,8 @@ > *lpErrno = WSAENOTSOCK; > return SOCKET_ERROR; > } > + > + *lpcbBytesReturned = 0; > > switch( dwIoControlCode ) > { > @@ -1928,17 +1931,44 @@ > return SOCKET_ERROR; > } > Socket->SharedData.NonBlocking = *((PULONG)lpvInBuffer) ? 1 : 0; > - return SetSocketInformation(Socket, AFD_INFO_BLOCKING_MODE, (PULONG)lpvInBuffer, NULL); > + *lpErrno = SetSocketInformation(Socket, AFD_INFO_BLOCKING_MODE, (PULONG)lpvInBuffer, NULL); > + if (*lpErrno != NO_ERROR) > + return SOCKET_ERROR; > + else > + return NO_ERROR; > case FIONREAD: > if( cbOutBuffer < sizeof(INT) || IS_INTRESOURCE(lpvOutBuffer) ) > { > *lpErrno = WSAEFAULT; > return SOCKET_ERROR; > } > - return GetSocketInformation(Socket, AFD_INFO_RECEIVE_CONTENT_SIZE, (PULONG)lpvOutBuffer, NULL); > + *lpErrno = GetSocketInformation(Socket, AFD_INFO_RECEIVE_CONTENT_SIZE, (PULONG)lpvOutBuffer, NULL); > + if (*lpErrno != NO_ERROR) > + { > + *lpcbBytesReturned = sizeof(ULONG); > + return SOCKET_ERROR; > + } > + else > + return NO_ERROR; > default: > - *lpErrno = WSAEINVAL; > - return SOCKET_ERROR; > + *lpErrno = Socket->HelperData->WSHIoctl(Socket->HelperContext, > + Handle, > + Socket->TdiAddressHandle, > + Socket->TdiConnectionHandle, > + dwIoControlCode, > + lpvInBuffer, > + cbInBuffer, > + lpvOutBuffer, > + cbOutBuffer, > + lpcbBytesReturned, > + lpOverlapped, > + lpCompletionRoutine, > + (LPBOOL)&NeedsCompletion); > + > + if (*lpErrno != NO_ERROR) > + return SOCKET_ERROR; > + else > + return NO_ERROR; > } > } > > >

1 0

[ros-diffs] [akhaldi] 48502: [PSDK] - Move INPUTCONTEXT and ImmLockIMC to the wine imm.h - Add wingdi.h inclusion.
by James Tabor 10 Aug '10

10 Aug '10

Hi! Should INPUTCONTEXT be moved or added to dimm.h? Wine headers should be used for wine specific stuff not DDK, SDK or WDK.... James Reference: http://msdn.microsoft.com/en-us/library/aa741229(VS.85).aspx

1 0

Re: [ros-dev] [ros-diffs] [sir_richard] 48475: [KERNEL32]: While working on the CMAKE branch, Amine and myself discovered a rather serious issue in kernel32 (and perhaps other libraries as well). Unlike rbuild, CMake does not allow you to export non-existant DLL functions (try it: add "poopyhead" in kernel32's exports under RBuild, and will it export "poopyhead", God knowing what that will actually link to). As an additional feature on top of the "allow non-existing functions to be exported" "feature", beca
by Timo Kreuzer 08 Aug '10

08 Aug '10

sir_richard(a)svn.reactos.org wrote: > Author: sir_richard > Date: Sat Aug 7 05:02:58 2010 > New Revision: 48475 > > URL: http://svn.reactos.org/svn/reactos?rev=48475&view=rev > Log: > [KERNEL32]: While working on the CMAKE branch, Amine and myself discovered a rather serious issue in kernel32 (and perhaps other libraries as well). I'm sure noone else could have discovered this issue before. cmake was the key! ;-) > Unlike rbuild, CMake does not allow you to export non-existant DLL functions (try it: add "poopyhead" in kernel32's exports under RBuild, and will it export "poopyhead", God knowing what that will actually link to). > That's an undocumented rbuild feature, called api-out-of-thin-air. To understand how it works, you must study quantum chaos theory. > there already exists a function for: *RtlSetLastNtStatusFromWin32Error*. > I see, with cmake, this feature works on ntdll as well ;-p Regards, Timo PS: build is broken.

2 1

Re: [ros-dev] [ros-diffs] [sir_richard] 48475: [KERNEL32]: While working on the CMAKE branch, Amine and myself discovered a rather serious issue in kernel32 (and perhaps other libraries as well). Unlike rbuild, CMake does not allow you to export non-existant DLL functions (try it: add "poopyhead" in kernel32's exports under RBuild, and will it export "poopyhead", God knowing what that will actually link to). As an additional feature on top of the "allow non-existing functions to be exported" "feature", beca
by Aleksey Bragin 07 Aug '10

07 Aug '10

I have a couple of questions/suggestions. Even if it was a mistake to commit it to trunk, I still express my opinion because I think it's important for the changes to stay in trunk. 1. Channel-based system is preferred to the plain NDEBUG/DPRINT one. Kernel32 should not really be an exception. If there is something wrong, it's better to put some more time into it and fix the actual problem in that debug library. Everyone who ever tried to debug any usermode app in ROS, would understand. 2. .pspec file was also invented as a consistent way to be compatible with different compilers. Winebuild generates stubs for entries marked as "stub", so it's quite controllable. 3. Everything else is great, nice to see that mess being finally cleaned up. WBR, Aleksey Bragin. On Aug 7, 2010, at 9:02 AM, sir_richard(a)svn.reactos.org wrote: > Author: sir_richard > Date: Sat Aug 7 05:02:58 2010 > New Revision: 48475 > > URL: http://svn.reactos.org/svn/reactos?rev=48475&view=rev > Log: > [KERNEL32]: While working on the CMAKE branch...

2 1

Re: [ros-dev] [ros-diffs] [jgardou] 48465: [WIN32K] - Rewrite NtGdiStretchDIBitsInternal : clearer, faster, stronger (+1 wine test)
by Timo Kreuzer 06 Aug '10

06 Aug '10

Hi, Please take care about proper protection of the user mode buffer. The current solution: probe and forget is not safe. Possibilities are: 1) SEH protected copying of the buffer, pass the copy of the buffer to lower level functions -> Easy to do, large overhead for large bitmaps. 2) SEH protected call to a lower level function, passing the user mode buffer. -> Not possible if the lower level function is either allocating any resources (unless also protected by SEH + finally) or can pass execution to 3rd party provided code, like drivers. 3) Be sure to have SEH at the lowest level (DIB) -> Not possible as the function might end up in a driver. 4) Use Mm to protect the buffer. Either with MmSecureVirtualMemory or double mapping using MmProbeAndLockPages + MmGetSystemAddressForMdlSafe. I think 4 is the way to go. While the overhead of remapping should be relatively small compared to a full copy, we are still wasting large ammounts of system address space. MmSecureVirtualMemory might at first sound like a good solution, but beware, it has some pitfalls. While it protects a memory range from being freed, it doesn't protect it from being paged out. That wouldn't be a problem, unless the memory is not backed by the page file, but let say a network resource, which becomes unavailable after a page was paged out. In this case we would get an in page error when trying to access the page, leading to a kernel crash. So unless we can be sure that the memory is backed by the page file, we need to additionally lock the pages into memory to be safe. Final thing to note is that MmSecureVirtualMemory is not implemented yet, but I hope with current work on the VAD code, we'll soon get a present (hint). Regards, Timo jgardou(a)svn.reactos.org wrote: > Author: jgardou > Date: Thu Aug 5 21:12:57 2010 > New Revision: 48465 > > URL: http://svn.reactos.org/svn/reactos?rev=48465&view=rev > Log: > [WIN32K] > - Rewrite NtGdiStretchDIBitsInternal : clearer, faster, stronger (+1 wine test) > > Modified: > branches/reactos-yarotows/subsystems/win32/win32k/objects/dibobj.c > > Modified: branches/reactos-yarotows/subsystems/win32/win32k/objects/dibobj.c > URL: http://svn.reactos.org/svn/reactos/branches/reactos-yarotows/subsystems/win… > ============================================================================== > --- branches/reactos-yarotows/subsystems/win32/win32k/objects/dibobj.c [iso-8859-1] (original) > +++ branches/reactos-yarotows/subsystems/win32/win32k/objects/dibobj.c [iso-8859-1] Thu Aug 5 21:12:57 2010 > @@ -290,7 +290,7 @@ > > if(!(psurfSrc && psurfDst)) > { > - DPRINT1("Error, could not lock surfaces.\n"); > + DPRINT1("Error, could not lock surfaces\n"); > goto cleanup; > } > > @@ -663,15 +663,15 @@ > if(pbmci) > { > pbmci->bmciHeader.bcWidth = psurf->SurfObj.sizlBitmap.cx; > - pbmci->bmciHeader.bcHeight = (psurf->SurfObj.fjBitmap & BMF_TOPDOWN) ? > - -psurf->SurfObj.sizlBitmap.cy : > + pbmci->bmciHeader.bcHeight = (psurf->SurfObj.fjBitmap & BMF_TOPDOWN) ? > + -psurf->SurfObj.sizlBitmap.cy : > psurf->SurfObj.sizlBitmap.cy; > pbmci->bmciHeader.bcPlanes = 1; > pbmci->bmciHeader.bcBitCount = BitsPerFormat(psurf->SurfObj.iBitmapFormat); > } > Info->bmiHeader.biWidth = psurf->SurfObj.sizlBitmap.cx; > - Info->bmiHeader.biHeight = (psurf->SurfObj.fjBitmap & BMF_TOPDOWN) ? > - -psurf->SurfObj.sizlBitmap.cy : > + Info->bmiHeader.biHeight = (psurf->SurfObj.fjBitmap & BMF_TOPDOWN) ? > + -psurf->SurfObj.sizlBitmap.cy : > psurf->SurfObj.sizlBitmap.cy;; > Info->bmiHeader.biPlanes = 1; > Info->bmiHeader.biBitCount = BitsPerFormat(psurf->SurfObj.iBitmapFormat); > @@ -711,15 +711,15 @@ > case 8: > Info->bmiHeader.biClrUsed = 0; > > - /* If the bitmap if a DIB section and has the same format than what > + /* If the bitmap if a DIB section and has the same format than what > * we're asked, go ahead! */ > - if((psurf->hSecure) && > + if((psurf->hSecure) && > (BitsPerFormat(psurf->SurfObj.iBitmapFormat) == bpp)) > { > if(Usage == DIB_RGB_COLORS) > { > unsigned int colors = min(psurf->ppal->NumColors, 1 << bpp); > - > + > if(pbmci) > { > for(i=0; i < colors; i++) > @@ -773,7 +773,7 @@ > rgbTriples[i].rgbtGreen = pDcPal->IndexedColors[i].peGreen; > rgbTriples[i].rgbtBlue = pDcPal->IndexedColors[i].peBlue; > } > - > + > rgbQuads[i].rgbRed = pDcPal->IndexedColors[i].peRed; > rgbQuads[i].rgbGreen = pDcPal->IndexedColors[i].peGreen; > rgbQuads[i].rgbBlue = pDcPal->IndexedColors[i].peBlue; > @@ -822,7 +822,7 @@ > { > for(g = 0; g <= 5; g++) > { > - for(b = 0; b <= 5; b++) > + for(b = 0; b <= 5; b++) > { > colorTriple->rgbtRed = (r * 0xff) / 5; > colorTriple->rgbtGreen = (g * 0xff) / 5; > @@ -935,7 +935,7 @@ > /* Restore them */ > Info->bmiHeader.biWidth = width; > Info->bmiHeader.biHeight = height; > - > + > if(!hBmpDest) > { > DPRINT1("Unable to create a DIB Section!\n"); > @@ -972,7 +972,7 @@ > _SEH2_TRY > { > RtlCopyMemory(Bits, pDIBits, DIB_GetDIBImageBytes (width, height, bpp)); > - } > + } > _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > { > Status = _SEH2_GetExceptionCode(); > @@ -1021,95 +1021,104 @@ > UINT cjMaxBits, > HANDLE hcmXform) > { > - HBITMAP hBitmap, hOldBitmap = NULL; > - HDC hdcMem = NULL; > + PDC pdc; > + INT ret = 0; > + LONG height; > + LONG width; > + WORD planes, bpp; > + DWORD compr, size; > + HBITMAP hBitmap; > + BOOL fastpath = FALSE; > NTSTATUS Status = STATUS_SUCCESS; > - PVOID pvDIBits; > - INT Ret = 0; > + > > if (!Bits || !BitsInfo) > - { > - SetLastWin32Error(ERROR_INVALID_PARAMETER); > return 0; > - } > - > - /* Create a DIB Section, data will be probed there */ > - hBitmap = NtGdiCreateDIBSection(hDC, > - NULL, > - 0, > - BitsInfo, > - Usage, > - 0, > - 0, > - 0, > - &pvDIBits); > - > - if(!hBitmap) > - { > - DPRINT1("Failed to create a DIB.\n"); > - return 0; > - } > - > - /* Set bits */ > - _SEH2_TRY > - { > - ProbeForRead(Bits, cjMaxBits, 1); > - RtlCopyMemory(pvDIBits, Bits, DIB_GetDIBImageBytes(BitsInfo->bmiHeader.biWidth, > - BitsInfo->bmiHeader.biHeight, > - BitsInfo->bmiHeader.biBitCount)); > - } > - _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > - { > - Status = _SEH2_GetExceptionCode(); > - } > - _SEH2_END > - > - if(!NT_SUCCESS(Status)) > - { > - DPRINT1("Error : Could not read DIB bits\n"); > - SetLastNtError(Status); > - goto cleanup; > - } > - > - hdcMem = NtGdiCreateCompatibleDC(0); > - if(!hdcMem) > - { > - DPRINT1("Failed to create a memory DC!"); > - goto cleanup; > - } > - > - hOldBitmap = NtGdiSelectBitmap(hdcMem, hBitmap); > - if(!hOldBitmap) > - { > - DPRINT1("Could not select the DIB into the memory DC\n"); > - goto cleanup; > - } > - > - /* Do we want to stretch ? */ > - if((SrcWidth == DestWidth) && (SrcHeight == DestHeight)) > - { > - Ret = NtGdiBitBlt(hDC, XDest, YDest, XDest + DestWidth, YDest + DestHeight, > - hdcMem, XSrc, YSrc, ROP, 0, 0); > - } > - else > - { > - Ret = NtGdiStretchBlt(hDC, XDest, YDest, XDest + DestWidth, YDest + DestHeight, > - hdcMem, XSrc, YSrc, XSrc + SrcWidth, YSrc + SrcHeight, > - ROP, 0); > - } > - > - if(Ret) > - Ret = SrcHeight ; > - > + > + if (!(pdc = DC_LockDc(hDC))) return 0; > + > + > + _SEH2_TRY > + { > + ProbeForRead(BitsInfo, cjMaxInfo, 1); > + ProbeForRead(Bits, cjMaxBits, 1); > + if (DIB_GetBitmapInfo( &BitsInfo->bmiHeader, &width, &height, &planes, &bpp, &compr, &size ) == -1) > + { > + DPRINT1("Invalid bitmap\n"); > + Status = STATUS_INVALID_PARAMETER; > + } > + } > + _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > + { > + Status = _SEH2_GetExceptionCode(); > + } > + _SEH2_END > + > + if(!NT_SUCCESS(Status)) > + { > + DPRINT1("Error, failed to read the DIB bits\n"); > + goto cleanup; > + } > + > + if (width < 0) > + { > + DPRINT1("Bitmap has a negative width\n"); > + return 0; > + } > + > + hBitmap = NtGdiGetDCObject(hDC, OBJ_BITMAP); > + > + if (XDest == 0 && YDest == 0 && XSrc == 0 && XSrc == 0 && > + DestWidth == SrcWidth && DestHeight == SrcHeight && > + compr == BI_RGB && > + ROP == SRCCOPY) > + { > + BITMAP bmp; > + if (IntGdiGetObject(hBitmap, sizeof(bmp), &bmp) == sizeof(bmp)) > + { > + if (bmp.bmBitsPixel == bpp && > + bmp.bmWidth == SrcWidth && > + bmp.bmHeight == SrcHeight && > + bmp.bmPlanes == planes) > + fastpath = TRUE; > + } > + } > + > + if (fastpath) > + { > + /* fast path */ > + DPRINT1("using fast path\n"); > + ret = IntSetDIBits( pdc, hBitmap, 0, height, Bits, BitsInfo, Usage); > + } > + else > + { > + /* slow path - need to use StretchBlt */ > + HBITMAP hOldBitmap; > + HPALETTE hpal = NULL; > + HDC hdcMem; > + PVOID pvBits; > + > + hdcMem = NtGdiCreateCompatibleDC( hDC ); > + hBitmap = DIB_CreateDIBSection(pdc, BitsInfo, Usage, &pvBits, NULL, 0, 0); > + RtlCopyMemory(pvBits, Bits, cjMaxBits); > + hOldBitmap = NtGdiSelectBitmap( hdcMem, hBitmap ); > + > + /* Origin for DIBitmap may be bottom left (positive biHeight) or top > + left (negative biHeight) */ > + ret = NtGdiStretchBlt( hDC, XDest, YDest, DestWidth, DestHeight, > + hdcMem, XSrc, abs(height) - SrcHeight - YSrc, > + SrcWidth, SrcHeight, ROP, 0 ); > + if(hpal) > + GdiSelectPalette(hdcMem, hpal, FALSE); > + if(ret) > + ret = SrcHeight; > + NtGdiSelectBitmap( hdcMem, hOldBitmap ); > + NtGdiDeleteObjectApp( hdcMem ); > + GreDeleteObject( hBitmap ); > + } > cleanup: > - if(hdcMem) > - { > - if(hOldBitmap) NtGdiSelectBitmap(hdcMem, hOldBitmap); > - NtGdiDeleteObjectApp(hdcMem); > - } > - GreDeleteObject(hBitmap); > - > - return Ret; > + DC_UnlockDc(pdc); > + return ret; > } > > > @@ -1462,7 +1471,7 @@ > hpal = (HPALETTE) 0xFFFFFFFF; > } > } > - else > + else > { > hpal = BuildDIBPalette(bmi); > } > @@ -1563,7 +1572,7 @@ > * Get the info from a bitmap header. > * Return 0 for COREHEADER, 1 for INFOHEADER, -1 for error. > */ > -int > +int > FASTCALL > DIB_GetBitmapInfo( const BITMAPINFOHEADER *header, LONG *width, > LONG *height, WORD *planes, WORD *bpp, DWORD *compr, DWORD *size ) > @@ -1575,7 +1584,7 @@ > *height = core->bcHeight; > *planes = core->bcPlanes; > *bpp = core->bcBitCount; > - *compr = 0; > + *compr = BI_RGB; > *size = 0; > return 0; > } > @@ -1692,10 +1701,10 @@ > ppalEntries[i].peBlue = 0; > ppalEntries[i].peFlags = 0; > } > - > + > lpIndex++; > } > - > + > hpal = PALETTE_AllocPalette(PAL_INDEXED, nNumColors, (ULONG*)ppalEntries, 0, 0, 0); > > ExFreePoolWithTag(ppalEntries, TAG_COLORMAP); > > > >

2 1

Re: [ros-dev] [ros-diffs] [tkreuzer] 48461: [NTOSKRNL] - Fixed FsRtlIsNameInExpression to make it properly handle * in expressions - Fix formatting - Patch by Pierre Schweitzer - Fixes everything See issue #5541 for more details.
by Colin Finck 05 Aug '10

05 Aug '10

tkreuzer(a)svn.reactos.org wrote: > Author: tkreuzer > Date: Thu Aug 5 12:23:23 2010 > New Revision: 48461 > > URL: http://svn.reactos.org/svn/reactos?rev=48461&view=rev > Log: > [NTOSKRNL] > - Fixed FsRtlIsNameInExpression to make it properly handle * in expressions > - Fix formatting > - Patch by Pierre Schweitzer > - Fixes everything Could you add a test for this to one of our (Winetest-compatible) kernel-mode testing frameworks, so that nobody breaks this again? I know that we haven't decided on a radical test-based development approach yet, but it would certainly be helpful to avoid long trunk locks in the future. Cheers, Colin

1 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 48461: [NTOSKRNL] - Fixed FsRtlIsNameInExpression to make it properly handle * in expressions - Fix formatting - Patch by Pierre Schweitzer - Fixes everything See issue #5541 for more details.
by Ged Murphy 05 Aug '10

05 Aug '10

tkreuzer(a)svn.reactos.org wrote: > Author: tkreuzer > Date: Thu Aug 5 12:23:23 2010 > New Revision: 48461 > > URL: http://svn.reactos.org/svn/reactos?rev=48461&view=rev > Log: > [NTOSKRNL] > - Fixed FsRtlIsNameInExpression to make it properly handle * in expressions > - Fix formatting > - Patch by Pierre Schweitzer > - Fixes everything Reactos v1.0?

1 0

Trunk locked
by Aleksey Bragin 02 Aug '10

02 Aug '10

Hi, trunk is locked due to reaching critical level of regressions again. Currently the following people have write access: tkreuzer, sir_richard, fireball. If you would like to be on bugfix-committers team, please drop me a line. WBR, Aleksey Bragin.

3 2

[ros-diffs] [jgardou] 48359: [WIN32K] - Rewrite NtGdiGetDIBitsInternal, with WINE as a reference. - Get back DIB Section creation to classic BITMAPINFO. This si the beginnig of the end for all this BITMAPV5INFO stuff. It is horrible, BITMAPCOREINFO->
by James Tabor 01 Aug '10

01 Aug '10

Hi! BitmapCoreInfo !Should Be! handled in Gdi32 and converted there! The latest BitmapInfo "must be" handled in win32k. So not get it confused. James

3 4

Re: [ros-dev] [ros-diffs] [fireball] 48380: - Fix incorrect function definitions. To be submitted upstream.
by Timo Kreuzer 31 Jul '10

31 Jul '10

fireball(a)svn.reactos.org schrieb: > - Fix incorrect function definitions. To be submitted upstream. > > I remember just recently joking about all our "Needs to be ...", "Someone should ...", "Please someone ..." commit messages, which usually mean "I'm too lazy to ..." and result in things never being done ;-) Timo

2 1

Re: [ros-dev] [ros-diffs] [akhaldi] 48236: Create a branch for cmake bringup.
by Ged Murphy 31 Jul '10

31 Jul '10

This may be a good time to restructure the tree? http://www.reactos.org/wiki/Techwiki:File_Layout <http://www.reactos.org/wiki/Techwiki:File_Layout> This will make ros much more modular and allow things like minwin to be built. Ged. On 24 July 2010 19:52, <akhaldi(a)svn.reactos.org> wrote: > Author: akhaldi > Date: Sat Jul 24 18:52:44 2010 > New Revision: 48236 > > URL: http://svn.reactos.org/svn/reactos?rev=48236&view=rev > Log: > Create a branch for cmake bringup. > > Added: > branches/cmake-bringup/ (props changed) > - copied from r48235, trunk/reactos/ > > Propchange: branches/cmake-bringup/ > > ------------------------------------------------------------------------------ > --- bugtraq:logregex (added) > +++ bugtraq:logregex Sat Jul 24 18:52:44 2010 > @@ -1,0 +1,2 @@ > +([Ii]ssue|[Bb]ug)s? #?(\d+)(,? ?#?(\d+))*(,? ?(and |or )?#?(\d+))? > +(\d+) > > Propchange: branches/cmake-bringup/ > > ------------------------------------------------------------------------------ > bugtraq:message = See issue #%BUGID% for more details. > > Propchange: branches/cmake-bringup/ > > ------------------------------------------------------------------------------ > bugtraq:url = http://www.reactos.org/bugzilla/show_bug.cgi?id=%BUGID% > > Propchange: branches/cmake-bringup/ > > ------------------------------------------------------------------------------ > --- svn:ignore (added) > +++ svn:ignore Sat Jul 24 18:52:44 2010 > @@ -1,0 +1,14 @@ > +*.iso > +makefile.auto > +makefile-*.auto > +config-*.rbuild > +obj-* > +output-* > +reactos > +reactos.* > +RosBE-Logs > +*.sln > +*.ncb > +*.suo > +versionreport.xml > +config.rbuild > > Propchange: branches/cmake-bringup/ > > ------------------------------------------------------------------------------ > --- svn:mergeinfo (added) > +++ svn:mergeinfo Sat Jul 24 18:52:44 2010 > @@ -1,0 +1,4 @@ > +/branches/header-work:45691-47721 > +/branches/reactos-yarotows:46372,46848,46966,47800,48026,48064 > +/branches/ros-amd64-bringup:36852 > > +/branches/ros-amd64-bringup/reactos:34711-34712,34741,34743,34770,34780-34782,34803,34812,34839,34842,34864,34870,34874,34877,34908-34909,34917,34965,35323-35324,35347-35348,35361,35436,35509,35515,35588,35655,35683,35739,35746,35762,35771,35777,35781,35789,35805,35823,35827,35902,35904-35906,35942,35947-35949,35952-35953,35966,36011-36013,36172,36360,36380,36388-36389,36393,36397,36445,36475,36502-36503,36505,36570,36614,36852,36898-36899,36930,36936,36949,36951,36958,36961,36964,36969,36972,36987-36988,36990,36992,37019,37322-37323,37333-37334,37434,37472,37475,37536,37820-37821,37868-37869,37873,37990-37991,38013-38014,38092,38100,38148-38151,38264-38265,38268,38355,39151,39333,39335,39345,39639,40120,40122-40123,40125,40127-40128,40155,40247,40324,40608,40753,40926-40928,40986-40987,40989,40991,40993,40995-40996,41000-41001,41027-41030,41044-41045,41047-41050,41052,41070,41082-41086,41097-41098,41101,41449,41479-41480,41484-41485,41499-41500,41502,41531,41536,41540,41546-41547,41549,43080,43426,43451,43454,43506,43566,43574,43598,43600-43602,43604-43605,43677,43682,43757,43775,43836,43838-43840,43852,43857-43858,43860,43905-43907,43952,43954,43965,43969,43979,43981,43992,44002,44036-44037,44039-44040,44044-44045,44053,44065,44095,44123,44143-44144,44205,44238,44257,44259,44294,44338-44339,44385,44389,44391,44426,44460,44467-44468,44470-44471,44499,44501,44503-44504,44506,44510-44512,44521,44523-44526,44530,44540,44601,44634,44639,44772,44818,45124,45126-45127,45430,46394,46404,46478,46511,46523-46524,46526,46534-46535,46537-46539,46589,46805,46868,47472,47846-47847,47878,47882 > > Propchange: branches/cmake-bringup/ > > ------------------------------------------------------------------------------ > tsvn:logminsize = 10 > > >

11 30

Re: [ros-dev] [ros-diffs] [jgardou] 48359: [WIN32K] - Rewrite NtGdiGetDIBitsInternal, with WINE as a reference. - Get back DIB Section creation to classic BITMAPINFO. This si the beginnig of the end for all this BITMAPV5INFO stuff. It is horrible, BI
by James Tabor 31 Jul '10

31 Jul '10

Hi! 2010/7/30 Jérôme Gardou <jerome.gardou(a)laposte.net>: > That's why I began to revert all of this stuff, which is horrible :-) > Regards. > Jérôme. > Oh! That is great news! Good work! James

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