- Ros-dev - ReactOS.org

ReactOS Hybrid CDs
by Hermès BÉLUSCA - MAÏTO 20 Jan '15

20 Jan '15

Hi all ! Our build system is now able to build so-called hybrid cds . What are they? They are boot+live-cd all-in-one. In addition it is now possible with them to load the live cd as a ramdisk. For that the contents of the bootcd is placed into a bootcd/ directory, the contents of the livecd is placed into a livecd/ directory, and the livecd image itself is also included (this is the one that is used for livecd ramdisk). You can notice that makes a lot of redundancy, but its the best thing I could do for now. The best way would be to build some kind of flat HDD image that is used as the livecd ramdisk (and never use the livecd with reads from the cd as we currently do) . Anyways. So here it is ! In addition you can add extra custom files via the build process: just place your files into a <your_ROS_source>/modules/hybridcd_extras/ directory (this directory doesnt exist by default, its up to you to create and populate it; I think its better to create a directory somewhere else and then add a symlink hybridcd_extras to this directory, inside the modules/ directory, as you already do with rosapps and rostests). After that you configure a build, build the host-tools and then ninja hybridcd !! If then you need to change the custom files, do it and then reconfigure a build with the cmake . command (when youre inside <your_ROS_builddir>/reactos/ ) so that cmake can build again the list of files to be included into the hybridcd. See https://jira.reactos.org/browse/CORE-9069 for few more details. Cheers, Hermès.

2 4

Revision 66026 - Directory Listing Modified Sun Jan 11 14:38:26 2015 UTC (3 days, 7 hours ago) by dreimer [RAPPS] Database Update. This fixes the now dead LibreOffice link, too. I completely skipped MirandaIM because they suck by deciding to do the same shit, Filezilla did. SF Malware "optimized" installer!
by Javier Agustìn Fernàndez Arroyo 19 Jan '15

19 Jan '15

Hello Daniel, There are links to filezilla which doesnt lead to the malware installer shit. This link ends with ".../download?nowrap" maybe adding this works for MirandaIM too http://sourceforge.net/projects/filezilla/files/FileZilla_Client/3.10.0.1/F…

3 4

Installing ReactOS to a folder
by João Jerónimo 19 Jan '15

19 Jan '15

Hello, Is there a build command to install ReactOS to a folder. Something equivalent to "make install" of good old RBuild days? I used to install ReactOS on real hardware this way, because it allowed me to have more control over the install process (aka control it completely). Thanks, João Jerónimo

6 8

LDAP going live
by Colin Finck 18 Jan '15

18 Jan '15

Hi all, After finally setting up replication slaves for redundancy, our LDAP setup went live today! BuildBot and all SVN repositories now authenticate against a shared user directory. If everything went well, you shouldn't notice a difference :) Except that you can now change your SVN password yourself at https://lam.reactos.org Keep your credentials safe. We can now easily add more ReactOS developer services like file sharing and Mumble without needing to duplicate all user information. And we will do so! Cheers, Colin

1 0

Could someone take over CORE-7864?
by David Quintana (gigaherz) 15 Jan '15

15 Jan '15

Link, for ease of access: https://jira.reactos.org/browse/CORE-7864 The bug was assigned to me a while ago, but this seems to be primarily win32k issues, which are outside my area of expertise. Someone else may be able to handle it better.

1 0

ReactOS Hybrid-USB Key attempt
by Hermès BÉLUSCA - MAÏTO 15 Jan '15

15 Jan '15

Hi all ! In this video : https://drive.google.com/file/d/0BzFtJhksW7viRDRVMzluTnFjMlU/view?usp=sharin g (with strong French accent, sorry :P, and it was my first attempt at making a video with a camera in one hand while doing the other things with the other hand ^^), I show an attempt to create a hybrid-USB key by configuring freeldr to load either a livecd (shown in the video) or a bootcd in ramdisk. Many remarks are in order: - theres a crash when booting the bootcd image, early in phase 1 boot in Io (can be reproduced locally on vbox for example, with similar freeldr.ini parameters that I show in the video). - the whole story consists in loading a ramdisk, so I avoid all the USB-related storage problems we could (and certainly) encounter if I used the USB key more like as we do for our current livecds, i.e. permanent reads to the removable device. - a ROS livecd that can be removable (in the sense that one can use another cd to test something, while ROS is still running) should be done with some kind of hdd image file instead, that is then loaded in memory (so that we can then read and write to this virtual drive). - something weird happens when freeldr loads the livecd iso in memory: first it takes 7 minutes to just try to open the iso file, and then 7 other minutes to load the iso proper. This problem needs to be investigated. - we still report strange dates when listing files from the livecd (at least when it is mounted as ramdisk), see the video. - finally, when using Standard PC (non-ACPI) HAL, I dont really think we reposition HDD heads into sleep position, because when I switch PC power off with the button I can hear the HDD making the noise of the heads quickly going back to sleep position, whereas I dont think this should happen if the heads were being already in the correct position before I switch power off (when using the shutdown command of FreeDOS, the other OS I have installed in the PC, the noise isnt produced). Cheers, Hermès. PS: I keep the right to remove the video at any time if I notice misuses. And its not an official video (even if I was playing around with Windows Movie Maker with the ReactOS logo during the first seven seconds, and with the website links at the end) !!

4 4

Downtime tomorrow at noon CET
by Pierre Schweitzer 14 Jan '15

14 Jan '15

Dear all, Due to a hard disk dying, we'll attempt to anticipate its total death tomorrow at noon CET to change it before it quits working. It is a disk in one of our hypervisor. The following services will be hit: -> ReactOS main website -> Jira/Fisheye -> Main DNS server -> ReactOS community website Sorry for the caused inconvenience. With my best regards, -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

2 1

Bulk ordering USB flash drives for exhibitions - call to action
by Colin Finck 12 Jan '15

12 Jan '15

Hi all, As more and more computers these days come without optical drives, we're thinking about switching from ReactOS CD giveaways to USB flash drive giveaways on exhibitions (like this month's FOSDEM). ReactOS would then come preinstalled in a VM on these drives. When ReactOS' USB support gets better, we may even think about making these drives bootable. Now the prices for 1GB USB drives haven't quite reached the costs of blank CDs yet. Also many countries put a high fee on USB drives, because you will for sure always use them to pirate copyrighted work... For example, we're talking about a fee of 1€/unit here in Germany. Germany is fair enough though to not apply the fee if you're ordering from outside Germany. Maybe this also works the other way round, i.e. we as ReactOS Deutschland e.V. order USB drives from another European country and don't have to pay this fee. Sooo, who of you knows a good supplier in your (European) country for bulk ordering USB drives with the best per-unit price? Even better if your supplier can print a custom logo on these drives. Depending on the price, we're talking about 50-200 drives here. Reply on the forum please: https://reactos.org/forum/viewtopic.php?f=2&t=13917 Thanks for your help in making a great ReactOS presentation at exhibitions! - Colin

6 7

Re: [ros-dev] [ros-diffs] [hbelusca] 66022: [FREELDR]: Commit a temporary "hackfix" for (Pc)GetTime: on VBox when booting with PXE, for some mysterious reason, Int386(0x1A) call with AH = 0x02 (Get CMOS Time) *never ever* r...
by Pierre Schweitzer 10 Jan '15

10 Jan '15

From our investigations (Timo & I), there seems to be a memory corruption when using a PXE boot on VBox. You're committing a hack to workaround this memory corruption (which replaces code which seems correct by some other code which is probably correct), which lets you go a little bit further, where memory corruption seems to strike again. And thus, this doesn't bring PXE boot in better shape. Furthermore, it appears that you're working around a bug which isn't in ReactOS but in VBox. As a reminder, PXE boot works fine with Qemu, with VMware. And when changing the ROM of VBox [1], then PXE boot works on VBox as well. Revert and report to VirtualBox instead. Our code is correct. Thanks to Timo & Hervé for their help on digging into this issue. [1]: https://git.ipxe.org/ipxe.git/blob/HEAD:/src/config/vbox/README On 10/01/2015 01:21, hbelusca(a)svn.reactos.org wrote: > Author: hbelusca > Date: Sat Jan 10 00:21:33 2015 > New Revision: 66022 > > URL: http://svn.reactos.org/svn/reactos?rev=66022&view=rev > Log: > [FREELDR]: Commit a temporary "hackfix" for (Pc)GetTime: on VBox when booting with PXE, for some mysterious reason, Int386(0x1A) call with AH = 0x02 (Get CMOS Time) *never ever* returns!! (however without PXE everything works). So... is it some kind of stack overflow or whatever that makes the Int386 function stack messy? Or something else? So in the meantime we use direct CMOS port reads. Timo, Hervé (and others), can you please review? And in particular why does it happen only with PXE? > > Modified: > trunk/reactos/boot/freeldr/freeldr/arch/i386/pcrtc.c > > Modified: trunk/reactos/boot/freeldr/freeldr/arch/i386/pcrtc.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/… > ============================================================================== > --- trunk/reactos/boot/freeldr/freeldr/arch/i386/pcrtc.c [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/freeldr/arch/i386/pcrtc.c [iso-8859-1] Sat Jan 10 00:21:33 2015 > @@ -20,10 +20,50 @@ > > #define BCD_INT(bcd) (((bcd & 0xf0) >> 4) * 10 + (bcd &0x0f)) > > +#ifndef INT386_WITH_INT_1A_AH_02_04__IS__FIXED > + > +/* CMOS Registers and Ports */ > +#define CMOS_CONTROL_PORT (PUCHAR)0x70 > +#define CMOS_DATA_PORT (PUCHAR)0x71 > + > +#define RTC_REGISTER_A 0x0A > +#define RTC_REG_A_UIP 0x80 > + > +static UCHAR > +HalpReadCmos(IN UCHAR Reg) > +{ > + /* Select the register */ > + WRITE_PORT_UCHAR(CMOS_CONTROL_PORT, Reg); > + > + /* Query the value */ > + return READ_PORT_UCHAR(CMOS_DATA_PORT); > +} > + > +#endif > + > TIMEINFO* > PcGetTime(VOID) > { > static TIMEINFO TimeInfo; > + > +#ifndef INT386_WITH_INT_1A_AH_02_04__IS__FIXED > + > + /* Loop while update is in progress */ > + while ((HalpReadCmos(RTC_REGISTER_A)) & RTC_REG_A_UIP); > + > + /* Set the time data */ > + TimeInfo.Second = BCD_INT(HalpReadCmos(0)); > + TimeInfo.Minute = BCD_INT(HalpReadCmos(2)); > + TimeInfo.Hour = BCD_INT(HalpReadCmos(4)); > + TimeInfo.Day = BCD_INT(HalpReadCmos(7)); > + TimeInfo.Month = BCD_INT(HalpReadCmos(8)); > + TimeInfo.Year = BCD_INT(HalpReadCmos(9)); > + > + /* Compensate for the century field */ > + TimeInfo.Year += (TimeInfo.Year > 80) ? 1900: 2000; > + > +#else > + > REGS Regs; > > for (;;) > @@ -86,6 +126,9 @@ > > break; > } > + > +#endif > + > return &TimeInfo; > } > > > -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

2 1

Re: [ros-dev] [ros-diffs] [hbelusca] 65997: [SPEC2DEF]: Turn the tab character into its control code. Timo, is this tab really needed for ARM stubs, or not? (in that case maybe removing it would be better?)
by Timo Kreuzer 08 Jan '15

08 Jan '15

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 65982: [FREELDR] - Correctly append a backslash to the BootPath (if needed). - Be able to specify relative boot paths (relative to the current boot device): as a consequence, remove the ...
by Pierre Schweitzer 05 Jan '15

05 Jan '15

On 05/01/2015 00:49, hbelusca(a)svn.reactos.org wrote: > Author: hbelusca > Date: Sun Jan 4 23:49:18 2015 > New Revision: 65982 > > URL: http://svn.reactos.org/svn/reactos?rev=65982&view=rev > Log: > [FREELDR] > - Correctly append a backslash to the BootPath (if needed). > - Be able to specify relative boot paths (relative to the current boot device): as a consequence, remove the "LiveCD" hackish special value that was introduced long long ago. > - Fix BootPath retrieval in ReactOSSetup mode (via the SystemPath optional value), and use a better way to build the temporary txtsetup.sif full file names. > > As a consequence we can now build hybrid cds with the following architecture: > \ > --> loader\ (bootsectors + free/setupldr.sys) > --> myboot\ (contents of what_defaults_to_reactos directory for the bootcd) > --> mylive\ (contents of what_defaults_to_reactos directory for the livecd) > --> <regular_files> > and > freeldr.ini specifying the following values: > > ; The Setup entry > [Setup] > BootType=ReactOSSetup > SystemPath=\myboot > > ; The LiveCD entry > [LiveCD] > BootType=Windows2003 > SystemPath=\mylive > Options=/MININT > > Part 2/2 > CORE-9023 > > Modified: > trunk/reactos/boot/bootdata/livecd.ini > trunk/reactos/boot/freeldr/freeldr/CHANGELOG > trunk/reactos/boot/freeldr/freeldr/windows/setupldr.c > trunk/reactos/boot/freeldr/freeldr/windows/winldr.c > > Modified: trunk/reactos/boot/freeldr/freeldr/windows/setupldr.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/windo… > ============================================================================== > --- trunk/reactos/boot/freeldr/freeldr/windows/setupldr.c [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/freeldr/windows/setupldr.c [iso-8859-1] Sun Jan 4 23:49:18 2015 > @@ -178,17 +178,40 @@ > HasSection = IniOpenSection(SectionName, &SectionId); > > UiDrawBackdrop(); > - UiDrawProgressBarCenter(1, 100, "Loading NT..."); > + UiDrawProgressBarCenter(1, 100, "Loading ReactOS Setup..."); > > /* Read the system path is set in the .ini file */ > if (!HasSection || > !IniReadSettingByName(SectionId, "SystemPath", BootPath, sizeof(BootPath))) > { > + // MachDiskGetBootPath(BootPath, sizeof(BootPath)); > + // strcpy(BootPath, SectionName); > + } Why? Can you please stop commenting out code without further explanations? Either you comment out (better doing so with #if 0, for the record) and you explain why you do so alongside in the code, for next developers coming into the code, or you don't comment out. So, just don't answer here, just commit an explanation ;-). Cheers, -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

1 0

ReactOS at FOSDEM
by Pierre Schweitzer 04 Jan '15

04 Jan '15

Dear all, ReactOS will be present this year at FOSDEM, in Brussels, on the 31st of Jan & the 1st of Feb. More information at: https://fosdem.org/2015/ We will have a stand so that you can come and meet the people behind ReactOS! We will dispatch more information about the stand & its location when we have them. We're looking forward to seeing you at Brussels! Cheers, -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

1 0

Re: [ros-dev] great chance
by Robert Naumann 03 Jan '15

03 Jan '15

Just a friendly reminder. The remaining time to participate becomes lesser and lesser. I still think we have good chances as this is organized by heise and they published much news about ros in the last year, so I think they are really interested. Here an English link: http://developerworld.heise.de/en/call-for-papers/ Am 04.12.2014 09:50 schrieb "Thomas Mueller" <mueller6723(a)twc.com>: > Hey guys, > I previously talked to daniel and colin about this thing and colin told me > to write a mail to this list. > I read about a big chance for the preject to show a presentation at the > CeBIT, the biggest german IT convention. > Sadly, I only have links to german websites but maybe you are satisfied > with google translation. > Here they are: > http://www.golem.de/news/call-for-papers-open-source-forum-sucht-experten-f… > http://www.linux-magazin.de/NEWS/Call-for-Papers-Open-Source-Forum-auf-der-… > This would be a big chance for the project as there are people from all > over the world and a bigger audience than the one of all Linux days > together could learn about the project. > Best Regards > Robert Sounds like a great idea. ReactOS could use the publicity, and it might recruit more developers to ReactOS. I have read about CeBIT on heise online (www.heise.de). Tom _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev

1 0

Re: [ros-dev] Question(s) about FreeLoader
by Rubén Mendoza Luna 02 Jan '15

02 Jan '15

> A final note, too (plus question): since our recent PXE support (that > appears to work! Thanks to Jérôme + Pierre effort, and numerous testers) > somebody oriented me to how this is done in Windows: they have a > STARTROM.0 file that is the bootstrap (downloaded and ran by PXE thing) > which then loads a NTLDR (somewhat). I binary analyzed it and it seems to be > of the same nature as the STPBOOT.BIN file, i.e. 16-bit bootstraper. > Question: does it load (after download) directly the 32-bit OSLOADER? OR > does it load the full NTLDR instead?, i.e. loading the 16-bit NTLDR part > (that then loads the 32-bit part)? StartROM.0 (called startrom.com and startrom.n12 ins the installation media) loads only a 32/64bit PE Setupldr.exe/Osloader.exe image, which is included with every Windows versión based in the NT Kernel, in a compressed form ofc, that's definitive. StartROM.0 is in effect the rought equivalent to STPBOOT.BIN in your example, but enabled for PXE booting. The confusión comes because StartROM expects to find the loader image with the specific NTLDR file name, renaming process which is done by the built-in Windows Server RIS server, when you créate a Windows distribution directory with the provided tools.

1 0

Question(s) about FreeLoader
by Hermès BÉLUSCA - MAÏTO 02 Jan '15

02 Jan '15

Hi all, Ive some questions/remarks about FreeLoader. But first lets start with some introduction On Windows (up to 2k3, things changed starting Vista), the boot loader is in two flavours, the usual one (NTLDR) used for loading Windows when it is installed, and another one (SETUPLDR) used only for text-mode setup. NTLDR shows the classical OS menu (as we do in ReactOS), whereas SETUPLDR can be seen when you boot with a Windows setup CD: it shows some kind of text-mode blue-screen, displaying in a status bar the status of loading some boot-time drivers, possibly allowing you to press a function key to be able to give additional drivers to be loaded. After that, things are loaded (HAL, kernel) and the text-mode setup program proper is loaded (usetup.exe aka smss.exe in the disc). Whichever bootloader being considered, it is made of two parts (concatenated): - a 16 (real-mode)-to-32 bits part, lets call it STPBOOT.BIN (to follow the convention of http://reboot.pro/topic/5900-make-your-own-nt-os-loader-ntldrsetupldr/ ), - and a 32-bit one. The 16-bit part is some kind of stub which switches the CPU to 32 bit (and may also contain some utility functions to make real-mode callbacks). This stub is the same for both NTLDR and SETUPLDR, whereas the 32-bit part differs. In the Windows CD, in the \I386 directory you have those files, NTLDR and SETUPLDR.BIN. But if you analyze them, and after noticing the (compressed) files OSLOADER.NT_ (that expands to OSLOADER.NTD, but is in fact a native .EXE), and SETUPLDR.EX_ (that expands to SETUPLDR.EXE, also native EXE), you notice that in fact NTLDR == STPBOOT.BIN + OSLOADER.EXE and SETUPLDR.BIN == STPBOOT.BIN + SETUPLDR.EXE . (EDIT: During writing this mail I discovered that http://en.wikipedia.org/wiki/Windows_NT_startup_process#CD-ROM_boot_image_ph ase mentions the same thing in the Boot loader phase paragraph). On ReactOS we do the same: our FREELDR.SYS is made of a 16-bit part FRLDR16.BIN concatenated with FREELDR_PE.DLL (using the names of the generated files when you compile ROS). Also we had two targets, FREELDR and SETUPLDR, the former for generating the usual boot loader whereas the latter was used for the bootcd. However starting revision 65832 (http://svn.reactos.org/svn/reactos?view=revision <http://svn.reactos.org/svn/reactos?view=revision&revision=65832> &revision=65832 ) both SETUPLDR and FREELDR became the same. Why? What differed them was the support of the boot loading option ReactOSSetup: SETUPLDR was in fact FREELDR *with* the support of this option (in some revisions ago there was also support for some setup-like blue UI, see revision 57933: http://svn.reactos.org/svn/reactos?view=revision <http://svn.reactos.org/svn/reactos?view=revision&revision=57933> &revision=57933 and references within). Starting r65832 the setup support is automatically included in FREELDR. Therefore when we generate the bootcds, we generate a FREELDR and a SETUPLDR but both files are the same binary-wise. Hence the question: Should we still keep the SETUPLDR target, or just directly use FREELDR in all situations?. One may say keep it for compatibility purposes (filename-wise), but then one might just keep only the setupldr.sys file in the bootcd (and remove the freeldr.sys one)? Another question would be: Should we restore a SETUPLDR target (i.e. put setup-oriented code for SETUPLDR only and not in the usual FREELDR) in order to be able, in the future, to implement some sort of on-demand extra driver loading, as Windows SETUPLDR does? A final note, too (plus question): since our recent PXE support (that appears to work! Thanks to Jérôme + Pierre effort, and numerous testers) somebody oriented me to how this is done in Windows: they have a STARTROM.0 file that is the bootstrap (downloaded and ran by PXE thing) which then loads a NTLDR (somewhat). I binary analyzed it and it seems to be of the same nature as the STPBOOT.BIN file, i.e. 16-bit bootstraper. Question: does it load (after download) directly the 32-bit OSLOADER? OR does it load the full NTLDR instead?, i.e. loading the 16-bit NTLDR part (that then loads the 32-bit part)? Answers and comments are highly welcome!! Happy new year to everyone! Hermès.

1 1

Re: [ros-dev] [ros-diffs] [pschweitzer] 65856: [NTOSKRNL] - Implement IopGetDeviceAttachmentBase() which allows getting the base device of the device stack given any device object in it - Implement IopGetDevicePDO() which r...
by Thomas Faber 28 Dec '14

28 Dec '14

On 2014-12-28 11:05, pschweitzer(a)svn.reactos.org wrote: > +extern ERESOURCE IopSecurityResource; This resource is only ever acquired shared, meaning it doesn't provide any mutual exclusion at all. Is that intentional?

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 65449: [KERNEL32][CONSRV] - Remove the USE_CONSOLE_INIT_HANDLES define since now we "support" the console initialization events. - The events in the CONSOLE_START_INFO structure are cons...
by Thomas Faber 28 Dec '14

28 Dec '14

On 2014-11-22 23:13, hbelusca(a)svn.reactos.org wrote: > + Status = NtCreateEvent(&Console->InputBuffer.ActiveEvent, EVENT_ALL_ACCESS, > + &ObjectAttributes, NotificationEvent, FALSE); > + if (!NT_SUCCESS(Status)) > + { > + return STATUS_UNSUCCESSFUL; > + // return Status; > + } This was a while ago, but I'm curious: what's the point of this? Avoiding STATUS_UNSUCCESSFUL is usually a good thing.

1 0

Re: [ros-dev] [ros-diffs] [jimtabor] 65815: [NtUser] - Crash while in recursion through hook calls. Move fast calls to api. Placed safe guards for removing message queue structures. Lock threads while calling hooks. Just ad...
by Thomas Faber 23 Dec '14

23 Dec '14

On 2014-12-23 20:05, jimtabor(a)svn.reactos.org wrote: > @@ -732,6 +732,7 @@ > return NULL; > } > > + RtlZeroMemory(Message, sizeof(Message)); > RtlMoveMemory(&Message->Msg, Msg, sizeof(MSG)); > > return Message; You mean sizeof(*Message)

1 0

Re: [ros-dev] [ros-diffs] [gadamopoulos] 65766: [COMCTL32] * Do not add two additional pixels at the top margin of the toolbar. This is the behaviour of comctl32 v6 and our explorer depends on that to appear properly. We do...
by Alex Ionescu 21 Dec '14

21 Dec '14

Isn't the correct solution to use SxS with an activation context? Best regards, Alex Ionescu On Sun, Dec 21, 2014 at 1:49 AM, <gadamopoulos(a)svn.reactos.org> wrote: > Author: gadamopoulos > Date: Sat Dec 20 16:49:31 2014 > New Revision: 65766 > > URL: http://svn.reactos.org/svn/reactos?rev=65766&view=rev > Log: > [COMCTL32] > * Do not add two additional pixels at the top margin of the toolbar. This > is the behaviour of comctl32 v6 and our explorer depends on that to appear > properly. We don't have a proper solution for these differences in behavior > and since we already opt to use the v6 behavior I think it is fine. > > CORE-5483 #resolve #comment Committed a slightly different version of the > patch, thanks. > > Modified: > trunk/reactos/dll/win32/comctl32/toolbar.c > > Modified: trunk/reactos/dll/win32/comctl32/toolbar.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/comctl32/toolbar… > > ============================================================================== > --- trunk/reactos/dll/win32/comctl32/toolbar.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/comctl32/toolbar.c [iso-8859-1] Sat Dec 20 > 16:49:31 2014 > @@ -244,7 +244,12 @@ > > static inline int default_top_margin(const TOOLBAR_INFO *infoPtr) > { > +#if 0 > return (infoPtr->dwStyle & TBSTYLE_FLAT ? 0 : TOP_BORDER); > +#else > + /* This is the behaviour in comctl32 v6 */ > + return 0; > +#endif > } > > static inline BOOL TOOLBAR_HasDropDownArrows(DWORD exStyle) > > >

3 2

Re: [ros-dev] [ros-diffs] [gadamopoulos] 65766: [COMCTL32] * Do not add two additional pixels at the top margin of the toolbar. This is the behaviour of comctl32 v6 and our explorer depends on that to appear properly. We do...
by David Quintana 21 Dec '14

21 Dec '14

Ideally, we'd fork comctl32 into two libraries like windows does, but that would probably mean we'd have to fork from wine, moving the maintenance effort to our side. That's why we did not do it yet. Sent from my Windows Phone ------------------------------ From: Alex Ionescu Sent: 21/12/2014 09:05 To: ReactOS Development List Cc: Linda Wang; Filip Subject: Re: [ros-dev] [ros-diffs] [gadamopoulos] 65766: [COMCTL32] * Do not add two additional pixels at the top margin of the toolbar. This is the behaviour of comctl32 v6 and our explorer depends on that to appear properly. We do... Isn't the correct solution to use SxS with an activation context? Best regards, Alex Ionescu On Sun, Dec 21, 2014 at 1:49 AM, <gadamopoulos(a)svn.reactos.org> wrote: > Author: gadamopoulos > Date: Sat Dec 20 16:49:31 2014 > New Revision: 65766 > > URL: http://svn.reactos.org/svn/reactos?rev=65766&view=rev > Log: > [COMCTL32] > * Do not add two additional pixels at the top margin of the toolbar. This > is the behaviour of comctl32 v6 and our explorer depends on that to appear > properly. We don't have a proper solution for these differences in behavior > and since we already opt to use the v6 behavior I think it is fine. > > CORE-5483 #resolve #comment Committed a slightly different version of the > patch, thanks. > > Modified: > trunk/reactos/dll/win32/comctl32/toolbar.c > > Modified: trunk/reactos/dll/win32/comctl32/toolbar.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/comctl32/toolbar… > > ============================================================================== > --- trunk/reactos/dll/win32/comctl32/toolbar.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/comctl32/toolbar.c [iso-8859-1] Sat Dec 20 > 16:49:31 2014 > @@ -244,7 +244,12 @@ > > static inline int default_top_margin(const TOOLBAR_INFO *infoPtr) > { > +#if 0 > return (infoPtr->dwStyle & TBSTYLE_FLAT ? 0 : TOP_BORDER); > +#else > + /* This is the behaviour in comctl32 v6 */ > + return 0; > +#endif > } > > static inline BOOL TOOLBAR_HasDropDownArrows(DWORD exStyle) > > >

1 0

Status Meeting
by Aleksey Bragin 19 Dec '14

19 Dec '14

Hey, since we skipped the meeting this week, I propose we do make a joint November-December meeting somewhere in the middle of December. (as we did in the previous year too). How about 18th of December? Regards, Aleksey Bragin

5 8

Re: [ros-dev] [ros-diffs] [akhaldi] 65617: [USER32] We're not using any debugging routines here.
by Timo Kreuzer 13 Dec '14

13 Dec '14

Honestly, I don't see any point in these modifications. The next time someone wants to use these debug routines, he will need to add it back. Or he will start using DPRINT stuff again. I'd prefer to have this in all files! Am 12.12.2014 14:23, schrieb akhaldi(a)svn.reactos.org: > Author: akhaldi > Date: Fri Dec 12 13:23:45 2014 > New Revision: 65617 > > URL: http://svn.reactos.org/svn/reactos?rev=65617&view=rev > Log: > [USER32] We're not using any debugging routines here. > > Modified: > trunk/reactos/win32ss/user/user32/misc/rtlstr.c > > Modified: trunk/reactos/win32ss/user/user32/misc/rtlstr.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/user32/misc/r… > ============================================================================== > --- trunk/reactos/win32ss/user/user32/misc/rtlstr.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/user/user32/misc/rtlstr.c [iso-8859-1] Fri Dec 12 13:23:45 2014 > @@ -10,10 +10,6 @@ > /* INCLUDES ******************************************************************/ > > #include <user32.h> > - > -#include <wine/debug.h> > - > -WINE_DEFAULT_DEBUG_CHANNEL(user32); > > /* FUNCTIONS *****************************************************************/ > VOID > > >

2 1

Server downtime tomorrow (Monday)
by Colin Finck 12 Dec '14

12 Dec '14

Hi all, Due to an OS upgrade on one of our VMs, the following services will temporarily be down tomorrow (Monday): * SVN * BuildBot Buildmaster * Git Mirror * Secondary nameserver * File server at svn.reactos.org I'll try to get this done as fast as possible, so that the downtime will be reduced to a minimum. Sorry for the inconveniences! Cheers, Colin

2 4

Re: [ros-dev] [ros-diffs] [pschweitzer] 65596: [NTOSKRNL] THE oneliner.... Properly read the information from the IRP to get the reparse tag. This fixes the handling of reparse mount points in ReactOS. To make it short and ...
by Michael Fritscher 10 Dec '14

10 Dec '14

Hi, congratulations! It's a pity that MS hardcodes the C:\ at more and more places... Original Windows NT 4.0 can boot completely even if the drive-letter changes, WinNT + IE throws an error message but works, on Windows 2000 one is automatically logged out again if it changes, on Windows XP even the login-Screen doesn't appear... Best regards, Michael Fritscher

3 2

Partition size and FAT32 cluster size?
by Thomas Mueller 08 Dec '14

08 Dec '14

What is the biggest partition size compatible with 4096-byte (4 KB) cluster size, cluster size being the minimum amount of space taken by a file however small? I googled some years ago and found it to be about 8 GB, however now I wonder if that was wrong, and I can accommodate a bigger partition. >From what I read years back, minimum cluster size would go to 8 KB when partition size goes above 8 GB, 16 GB when partition size goes above 16 GB, 32 KB when partition size goes above 32 GB, meaning a lot of disk space wasted by small files. I believe the best file system ReactOS can use so far is FAT32, true also for FreeDOS. My first formatting might be done from FreeBSD, NetBSD or Linux, since I don't have ReactOS or MS-Windows installation currently. Tom

3 3

Re: [ros-dev] [ros-diffs] [dreimer] 65574: Rule #1 of today: If you steal from resources... then at least steal from the most fitting one in layout matters... [OSK] Fix german layout by moving the "#" button where it should...
by Thomas Faber 07 Dec '14

07 Dec '14

On 2014-12-06 08:43, dreimer(a)svn.reactos.org wrote: > [OSK] > Fix german layout by moving the "#" button where it should be and adding the "<" button next to "Y" Erm... hard-coding keyboard layouts into OSK is a broken design by the way. It should determine the current layout from the OS and display that. (Point in case: some people *cough cough* use custom keyboard layouts)

1 0

[ros-diffs] [hbelusca] 65569: [OSK] - Fix some coding style (whitespace): this is not win32k!! - Remove unneeded headers.
by James Tabor 05 Dec '14

05 Dec '14

Watch OUT! This was from the ORIGINAL patch!!! I did not code it!!!! James

2 1

silverblade´s wife
by Javier Agustìn Fernàndez Arroyo 05 Dec '14

05 Dec '14

Hello guys, I have just read this sad news on facebook Andrew´s wife has passed away this thursday evening. May i ask web developers to put the attached image in the webpage? for those who dont know who Andrew is, he is the first responsable of the audio stack in ReactOS. He is known as silverblade in IRC and the web My condolences to him and families and friends, from here.

1 0

great chance
by Robert Naumann 04 Dec '14

04 Dec '14

Hey guys, I previously talked to daniel and colin about this thing and colin told me to write a mail to this list. I read about a big chance for the preject to show a presentation at the CeBIT, the biggest german IT convention. Sadly, I only have links to german websites but maybe you are satisfied with google translation. Here they are: http://www.golem.de/news/call-for-papers-open-source-forum-sucht-experten-f… http://www.linux-magazin.de/NEWS/Call-for-Papers-Open-Source-Forum-auf-der-… This would be a big chance for the project as there are people from all over the world and a bigger audience than the one of all Linux days together could learn about the project. Best Regards Robert

2 1

Claim your commits
by Alexander Rechitskiy 30 Nov '14

30 Nov '14

2 5

Re: [ros-dev] [ros-diffs] [hbelusca] 65519: [WIN32K][ROSTESTS] So... ... first of all NtUserQueryInformationThread takes only 4 parameters in Win2k3 so do it as well... ... and since we claim at being compatible with Win2k3...
by Aleksey Bragin 29 Nov '14

29 Nov '14

The one who does it - please make sure to stick to the appropriate Service Pack version too. Regards, Aleksey Bragin On 29.11.2014 2:19, hbelusca(a)svn.reactos.org wrote: > Author: hbelusca > Date: Fri Nov 28 23:19:25 2014 > New Revision: 65519 > > URL: http://svn.reactos.org/svn/reactos?rev=65519&view=rev > Log: > [WIN32K][ROSTESTS] > So... > ... first of all NtUserQueryInformationThread takes only 4 parameters in Win2k3 so do it as well... > ... and since we claim at being compatible with Win2k3 (and not XP), one **MUST** review **ALL** our win32k exports, in win32ss/w32ksvc.db database first, and then in our w32kdll apitests !!!!! > But I won't do it ! >

1 0

Mention of ReactOS in some security book...
by Hermès BÉLUSCA - MAÏTO 27 Nov '14

27 Nov '14

Hi ! While searching for something I stumbled upon this : http://books.google.fr/books?id=YjwKAwAAQBAJ <http://books.google.fr/books?id=YjwKAwAAQBAJ&pg=RA1-PA331&lpg=RA1-PA331&dq= reactos+shell+new&source=bl&ots=D1hNcK_QQx&sig=n95n-VyBUgC326b3vbqg6p1QgXU&h l=fr&sa=X&ei=7VZ3VN-5O8viaqbSgSg&ved=0CEgQ6AEwCQ#v=onepage&q=reactos%20shell %20new&f=false> &pg=RA1-PA331&lpg=RA1-PA331&dq=reactos+shell+new&source=bl&ots=D1hNcK_QQx&si g=n95n-VyBUgC326b3vbqg6p1QgXU&hl=fr&sa=X&ei=7VZ3VN-5O8viaqbSgSg&ved=0CEgQ6AE wCQ#v=onepage&q=reactos%20shell%20new&f=false Read section: Creating a Custom Shell. They use ReactOS (and RosBE 1.5, a piece of history ^^) for their purpose :D Hermès.

1 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 65501: [FASTFAT] Set clean shutdown bit on dismount
by Jérôme Gardou 27 Nov '14

27 Nov '14

Hey Pierre! This flag > + if (DeviceExt->VolumeFcb->Flags & VCB_CLEAR_DIRTY) > + { > + /* Set clean shutdown bit */ > + Status = GetNextCluster(DeviceExt, 1, &eocMark); > + if (NT_SUCCESS(Status)) > + { > + eocMark |= DeviceExt->CleanShutBitMask; > + if (NT_SUCCESS(WriteCluster(DeviceExt, 1, eocMark))) and that one > + DeviceExt->VolumeFcb->Flags &= ~VCB_IS_DIRTY; > + } > + } > + > /* Flush volume & files */ > VfatFlushVolume(DeviceExt, (PVFATFCB)FileObject->FsContext); > > > don't really seem to match. Or is the former a part of a OR combination defining the latter ? Cheers. Jérôme.

2 1

Selling ReactOS CDs
by Hermès BÉLUSCA - MAÏTO 25 Nov '14

25 Nov '14

Hi all ! In the forums some spokesperson of an Indian company offering services related to FOSS wants to add us to their online shop, see http://www.reactos.org/forum/viewtopic.php?f=13 <http://www.reactos.org/forum/viewtopic.php?f=13&t=13780> &t=13780 for more information. What do you think about this? How should we react? Should we make clearer our line of conduct about such kind of things? Cheers, Hermès.

5 5

Re: [ros-dev] [ros-diffs] [pschweitzer] 65462: [NTFS] - In NtfsQueryDirectory(), don't upcase name in dir search pattern, it can conflict with POSIX names. - In CompareFileName(), handle the fact that for Win32 & DOS we do ...
by Thomas Faber 24 Nov '14

24 Nov '14

On 2014-11-23 10:49, pschweitzer(a)svn.reactos.org wrote: > + ASSERT(NT_SUCCESS(RtlUpcaseUnicodeString(&IntFileName, FileName, TRUE))); You need NT_VERIFY here or this will break debug builds.

2 1

Re: [ros-dev] [ros-diffs] [akhaldi] 65249: [SHELL32] * bool => BOOL.
by Timo Kreuzer 24 Nov '14

24 Nov '14

There is a difference between a C++ bool and a win32 BOOL. bool is 8 bit and aware of things like (bool Foo = FlagsValue & 0x80000000); BOOLEAN BooleanFlag = Foo;" with BOOL this would fail. I don't really know whether a BOOL is really the right thing to use here. Am 04.11.2014 21:00, schrieb akhaldi(a)svn.reactos.org: > Author: akhaldi > Date: Tue Nov 4 20:00:09 2014 > New Revision: 65249 > > URL: http://svn.reactos.org/svn/reactos?rev=65249&view=rev > Log: > [SHELL32] > * bool => BOOL. > > Modified: > branches/shell-experiments/dll/win32/shell32/folders/CDesktopFolder.cpp > branches/shell-experiments/dll/win32/shell32/folders/CDesktopFolder.h > branches/shell-experiments/dll/win32/shell32/folders/CFSFolder.cpp > branches/shell-experiments/dll/win32/shell32/folders/CFSFolder.h > branches/shell-experiments/dll/win32/shell32/shellfolder.h > > Modified: branches/shell-experiments/dll/win32/shell32/folders/CDesktopFolder.cpp > URL: http://svn.reactos.org/svn/reactos/branches/shell-experiments/dll/win32/she… > ============================================================================== > --- branches/shell-experiments/dll/win32/shell32/folders/CDesktopFolder.cpp [iso-8859-1] (original) > +++ branches/shell-experiments/dll/win32/shell32/folders/CDesktopFolder.cpp [iso-8859-1] Tue Nov 4 20:00:09 2014 > @@ -1189,7 +1189,7 @@ > return ret; > } > > -HRESULT WINAPI CDesktopFolder::CopyItems(IShellFolder *pSFFrom, UINT cidl, LPCITEMIDLIST *apidl, bool bCopy) > +HRESULT WINAPI CDesktopFolder::CopyItems(IShellFolder *pSFFrom, UINT cidl, LPCITEMIDLIST *apidl, BOOL bCopy) > { > CComPtr<IPersistFolder2> ppf2; > WCHAR szSrcPath[MAX_PATH]; > > Modified: branches/shell-experiments/dll/win32/shell32/folders/CDesktopFolder.h > URL: http://svn.reactos.org/svn/reactos/branches/shell-experiments/dll/win32/she… > ============================================================================== > --- branches/shell-experiments/dll/win32/shell32/folders/CDesktopFolder.h [iso-8859-1] (original) > +++ branches/shell-experiments/dll/win32/shell32/folders/CDesktopFolder.h [iso-8859-1] Tue Nov 4 20:00:09 2014 > @@ -88,7 +88,7 @@ > virtual HRESULT WINAPI GetUniqueName(LPWSTR pwszName, UINT uLen); > virtual HRESULT WINAPI AddFolder(HWND hwnd, LPCWSTR pwszName, LPITEMIDLIST *ppidlOut); > virtual HRESULT WINAPI DeleteItems(UINT cidl, LPCITEMIDLIST *apidl); > - virtual HRESULT WINAPI CopyItems(IShellFolder *pSFFrom, UINT cidl, LPCITEMIDLIST *apidl, bool bCopy); > + virtual HRESULT WINAPI CopyItems(IShellFolder *pSFFrom, UINT cidl, LPCITEMIDLIST *apidl, BOOL bCopy); > > DECLARE_REGISTRY_RESOURCEID(IDR_SHELLDESKTOP) > DECLARE_NOT_AGGREGATABLE(CDesktopFolder) > > Modified: branches/shell-experiments/dll/win32/shell32/folders/CFSFolder.cpp > URL: http://svn.reactos.org/svn/reactos/branches/shell-experiments/dll/win32/she… > ============================================================================== > --- branches/shell-experiments/dll/win32/shell32/folders/CFSFolder.cpp [iso-8859-1] (original) > +++ branches/shell-experiments/dll/win32/shell32/folders/CFSFolder.cpp [iso-8859-1] Tue Nov 4 20:00:09 2014 > @@ -1030,7 +1030,7 @@ > * copies items to this folder > */ > HRESULT WINAPI CFSFolder::CopyItems(IShellFolder * pSFFrom, UINT cidl, > - LPCITEMIDLIST * apidl, bool bCopy) > + LPCITEMIDLIST * apidl, BOOL bCopy) > { > CComPtr<IPersistFolder2> ppf2 = NULL; > WCHAR szSrcPath[MAX_PATH]; > > Modified: branches/shell-experiments/dll/win32/shell32/folders/CFSFolder.h > URL: http://svn.reactos.org/svn/reactos/branches/shell-experiments/dll/win32/she… > ============================================================================== > --- branches/shell-experiments/dll/win32/shell32/folders/CFSFolder.h [iso-8859-1] (original) > +++ branches/shell-experiments/dll/win32/shell32/folders/CFSFolder.h [iso-8859-1] Tue Nov 4 20:00:09 2014 > @@ -102,7 +102,7 @@ > virtual HRESULT WINAPI GetUniqueName(LPWSTR pwszName, UINT uLen); > virtual HRESULT WINAPI AddFolder(HWND hwnd, LPCWSTR pwszName, LPITEMIDLIST *ppidlOut); > virtual HRESULT WINAPI DeleteItems(UINT cidl, LPCITEMIDLIST *apidl); > - virtual HRESULT WINAPI CopyItems(IShellFolder *pSFFrom, UINT cidl, LPCITEMIDLIST *apidl, bool bCopy); > + virtual HRESULT WINAPI CopyItems(IShellFolder *pSFFrom, UINT cidl, LPCITEMIDLIST *apidl, BOOL bCopy); > > DECLARE_REGISTRY_RESOURCEID(IDR_SHELLFSFOLDER) > DECLARE_NOT_AGGREGATABLE(CFSFolder) > > Modified: branches/shell-experiments/dll/win32/shell32/shellfolder.h > URL: http://svn.reactos.org/svn/reactos/branches/shell-experiments/dll/win32/she… > ============================================================================== > --- branches/shell-experiments/dll/win32/shell32/shellfolder.h [iso-8859-1] (original) > +++ branches/shell-experiments/dll/win32/shell32/shellfolder.h [iso-8859-1] Tue Nov 4 20:00:09 2014 > @@ -42,7 +42,7 @@ > STDMETHOD(GetUniqueName)(THIS_ LPWSTR lpName, UINT uLen) PURE; > STDMETHOD(AddFolder)(THIS_ HWND hwnd, LPCWSTR lpName, LPITEMIDLIST * ppidlOut) PURE; > STDMETHOD(DeleteItems)(THIS_ UINT cidl, LPCITEMIDLIST * apidl) PURE; > - STDMETHOD(CopyItems)(THIS_ IShellFolder * pSFFrom, UINT cidl, LPCITEMIDLIST * apidl, bool bCopy) PURE; > + STDMETHOD(CopyItems)(THIS_ IShellFolder * pSFFrom, UINT cidl, LPCITEMIDLIST * apidl, BOOL bCopy) PURE; > }; > #undef INTERFACE > > > >

9 32

Re: [ros-dev] Replacing unsafe TRUE comparisons (Following Re: bool => BOOL)
by Daniel Reimer 23 Nov '14

23 Nov '14

Heheh, who could it be... ^^ It was always a event to watch you two arguing. ^^ Am 23.11.2014 21:57 schrieb Alex Ionescu <ionucu(a)videotron.ca>: > > I'm just going to chime in here and confirm that Timo does indeed own a master's diploma on surviving pissing contests, taught by the greatest master there ever was. > > Best regards, > Alex Ionescu > > On Sat, Nov 22, 2014 at 11:47 AM, Timo Kreuzer <timo.kreuzer(a)web.de> wrote: >> >> Am 22.11.2014 11:39, schrieb Love Nystrom: >>> >>> >>> On 2014-11-21 04.00, Timo Kreuzer wrote: >>>> >>>> Am 20.11.2014 14:18, schrieb Love Nystrom: >>>>> >>>>> >>>>> Well... Actually not exactly the same.. ;) >>>>> "if (f != FALSE)" requires an explicit comparison with a second operand, >>>> >>>> No, it does not. It requries the compiler to generate code that executes the following statement, when f is not 0. >>> >>> >>> I suspect we look at it from two different viewpoints here.. >>> Yours is "C centric" and mine is "object code centric". >>> You talk about what the compiler is required to do, >>> and I talk about what comes out at the end of compilation. >> >> And what comes out at the end of the compilation is what the compiler creates. And the compiler is following the rules of the C standard and the rules of logic. >> You claimed '"if (f != FALSE)" requires an explicit comparison with a second operand,' and that is factually wrong. No matter whether you are looking at it from the compiler perspective or from the perspective of an expressionist painter living in a yellow tree house on the bottom of Lake Tanganyika. >> >>> >>> And.. dear friend.. don't turn this into a pissing contest. >> >> Don't even get me started. I battled the grand master and I survived. >> >> >>> Let's check the egos in with the coat check girl at the entrance. >>> May I ask how old you are? >> >> Are we talking about age or maturity? >> >> We better end this discussion, it's not leading anywhere. And you don't want me to turn into the Grinch and steal your Christmas. >> >> Thanks, >> Timo >> >> >> _______________________________________________ >> Ros-dev mailing list >> Ros-dev(a)reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >> >

1 0

Re: [ros-dev] [ros-diffs] [aandrejevic] 65441: [FAST486] Attempt to write the value to the stack before subtracting from the actual ESP register in Fast486StackPush.
by Timo Kreuzer 22 Nov '14

22 Nov '14

Are you sure this is the correct order of execution? The instruction is documented as first lowering the stack pointer, then writing to the new location. If a stack exception occurs, you might have esp off by 4. Am 21.11.2014 10:46, schrieb aandrejevic(a)svn.reactos.org: > Author: aandrejevic > Date: Fri Nov 21 09:46:57 2014 > New Revision: 65441 > > URL: http://svn.reactos.org/svn/reactos?rev=65441&view=rev > Log: > [FAST486] > Attempt to write the value to the stack before subtracting from the actual ESP register > in Fast486StackPush. > > > Modified: > trunk/reactos/lib/fast486/common.inl > > Modified: trunk/reactos/lib/fast486/common.inl > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/fast486/common.inl?rev… > ============================================================================== > --- trunk/reactos/lib/fast486/common.inl [iso-8859-1] (original) > +++ trunk/reactos/lib/fast486/common.inl [iso-8859-1] Fri Nov 21 09:46:57 2014 > @@ -317,15 +317,19 @@ > return FALSE; > } > > + /* Store the value in SS:[ESP - 4] */ > + if (!Fast486WriteMemory(State, > + FAST486_REG_SS, > + State->GeneralRegs[FAST486_REG_ESP].Long - sizeof(ULONG), > + &Value, > + sizeof(ULONG))) > + { > + /* Exception occurred */ > + return FALSE; > + } > + > /* Subtract ESP by 4 */ > State->GeneralRegs[FAST486_REG_ESP].Long -= sizeof(ULONG); > - > - /* Store the value in SS:ESP */ > - return Fast486WriteMemory(State, > - FAST486_REG_SS, > - State->GeneralRegs[FAST486_REG_ESP].Long, > - &Value, > - sizeof(ULONG)); > } > else > { > @@ -339,16 +343,22 @@ > return FALSE; > } > > + /* Store the value in SS:[SP - 2] */ > + if (!Fast486WriteMemory(State, > + FAST486_REG_SS, > + LOWORD(State->GeneralRegs[FAST486_REG_ESP].LowWord - sizeof(USHORT)), > + &ShortValue, > + sizeof(USHORT))) > + { > + /* Exception occurred */ > + return FALSE; > + } > + > /* Subtract SP by 2 */ > State->GeneralRegs[FAST486_REG_ESP].LowWord -= sizeof(USHORT); > - > - /* Store the value in SS:SP */ > - return Fast486WriteMemory(State, > - FAST486_REG_SS, > - State->GeneralRegs[FAST486_REG_ESP].LowWord, > - &ShortValue, > - sizeof(USHORT)); > - } > + } > + > + return TRUE; > } > > FORCEINLINE > > >

2 1

Rant
by Giannis Adamopoulos 21 Nov '14

21 Nov '14

I don't know how many times I need to send the same link here but let's say that this is the last time: this is a post about wpf but in the middle there is a paragraph about how win32k in windows processes mouse messages: http://blogs.msdn.com/b/dwayneneed/archive/2008/09/08/transparent-windows-i… And here is the important part: Which HWND is the mouse over? The operating system must respond very quickly to mouse movement. Windows uses a dedicated Raw Input Thread (RIT), running in the kernel, to handle the signals from the mouse hardware. The RIT quickly scans over the HWND hierarchy to see which window the mouse is over. Because the system must be responsive, no application code is invoked. For normal windows, the RIT checks the mouse position against the window's rectangle (or region, if one is set). But for layered windows, the RIT looks in the bitmap that specifies the content for the window and checks the effective transparency at that location (which can be affected by the constant opacity setting, the color key setting, or the per-pixel alpha channel). If the pixel is 100% transparent, the RIT skips the window and keeps looking. Once a window has been located, the mouse move flag is set on the thread that owns the window. This will cause the thread to receive a WM_MOUSEMOVE message the next time it calls GetMessage() and there are no other higher-priority messages. Now let me explain why a flag is needed. The window manager needs to coalesce mouse move messages. If the mouse moves over a window and the system registers 10 positions over it, if the window doesn't process messages fast enough the unprocessed positions are dropped and only the last is kept. Even if another message gets between these mouse move messages get lost. That's why the last mouse position is not stored in a message queue but in a field in the thread info. That's how the window manager worked the last 20 years in windows. I'm sick and tired to see readable and correct code to be rewritten by shitty code, that is not readable and has obvious bugs without any reason why the previous implementation was wrong. I just give up. Do whatever you like with this shitty project of yours. I don't care anymore.

2 1

Re: [ros-dev] [ros-diffs] [dquintana] 65415: [SHELL32] * Commit the folder location fixes. They are mostly untested due to being unable to boot to desktop, but looking at the contents of the HDD after syssetup runs seems th...
by Thomas Faber 21 Nov '14

21 Nov '14

On 2014-11-15 13:34, dquintana(a)svn.reactos.org wrote: > [SHELL32] > * Commit the folder location fixes. They are mostly untested due to being unable to boot to desktop, but looking at the contents of the HDD after syssetup runs seems that the shortcuts are all created in their rightful place. If anyone is able to boot, feel free to test. > > Modified: > branches/shell-experiments/dll/win32/shell32/wine/shellpath.c So which is it; to Wine or not to Wine? If we need to fork this then let's put it in another file? Or at least #ifdef __REACTOS__?

3 2

Re: [ros-dev] EPIC: ReactOS@Samsung Galaxy S III mini
by Love Nystrom 20 Nov '14

20 Nov '14

On 2014-09-29 19.00, ros-dev-request(a)reactos.org wrote: > w0000t > natively? via an emulator??? > what the.... > \o/ @ Javier I just stumbled by and saw it.. Выглядит безумно, но я установил и запустил ReactOS через обертку Qemu - Limbo ARM 7 на своем Samsung Galaxy S III mini. It looks crazy, but I installed and started the ReactOS through wrapper Qemu - Limbo ARM 7 on your Samsung Galaxy S III mini. // It might be interesting to try wedging an ARM build into the S3 though. I was mulling over the possibility to squeeze it into an Maple Native.. Love

3 2

Re: [ros-dev] [ros-diffs] [tkreuzer] 65390: [WIN32SS] if (BooleanValue == TRUE) -> if (!BooleanValue) Patch by Love Nystrom CORE-8799
by Timo Kreuzer 13 Nov '14

13 Nov '14

obviously it was meant to be "if (BooleanValue == TRUE) -> if (BooleanValue)" Am 13.11.2014 11:31, schrieb tkreuzer(a)svn.reactos.org: > Author: tkreuzer > Date: Thu Nov 13 10:31:45 2014 > New Revision: 65390 > > URL: http://svn.reactos.org/svn/reactos?rev=65390&view=rev > Log: > [WIN32SS] > if (BooleanValue == TRUE) -> if (!BooleanValue) > Patch by Love Nystrom > CORE-8799 > > Modified: > trunk/reactos/win32ss/drivers/displays/framebuf/ddenable.c > trunk/reactos/win32ss/drivers/displays/framebuf/pointer.c > trunk/reactos/win32ss/drivers/displays/framebufacc/ddenable.c > trunk/reactos/win32ss/drivers/displays/vga/main/enable.c > trunk/reactos/win32ss/drivers/displays/vga/vgavideo/vgavideo.c > trunk/reactos/win32ss/gdi/dib/floodfill.c > trunk/reactos/win32ss/gdi/gdi32/misc/gdientry.c > trunk/reactos/win32ss/user/ntuser/hotkey.c > trunk/reactos/win32ss/user/ntuser/message.c > trunk/reactos/win32ss/user/ntuser/msgqueue.c > trunk/reactos/win32ss/user/user32/controls/appswitch.c > trunk/reactos/win32ss/user/user32/misc/desktop.c > trunk/reactos/win32ss/user/user32/misc/winsta.c > trunk/reactos/win32ss/user/winsrv/consrv/frontends/gui/conwnd.c > trunk/reactos/win32ss/user/winsrv/consrv_new/frontends/gui/guiterm.c > trunk/reactos/win32ss/user/winsrv/usersrv/register.c > > Modified: trunk/reactos/win32ss/drivers/displays/framebuf/ddenable.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/drivers/displays/f… > ============================================================================== > --- trunk/reactos/win32ss/drivers/displays/framebuf/ddenable.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/drivers/displays/framebuf/ddenable.c [iso-8859-1] Thu Nov 13 10:31:45 2014 > @@ -38,7 +38,7 @@ > { > PPDEV ppdev = (PPDEV)dhpdev; > > - if (ppdev->bDDInitialized == TRUE) > + if (ppdev->bDDInitialized) > { > return TRUE; > } > @@ -237,7 +237,7 @@ > { > ppdev->pvmList = pvmList; > > - if ( bDDrawHeap == TRUE) > + if (bDDrawHeap) > { > pvmList->dwFlags = VIDMEM_ISLINEAR ; > pvmList->fpStart = ppdev->ScreenHeight * ppdev->ScreenDelta; > > Modified: trunk/reactos/win32ss/drivers/displays/framebuf/pointer.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/drivers/displays/f… > ============================================================================== > --- trunk/reactos/win32ss/drivers/displays/framebuf/pointer.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/drivers/displays/framebuf/pointer.c [iso-8859-1] Thu Nov 13 10:31:45 2014 > @@ -110,7 +110,7 @@ > VOID FASTCALL > IntShowMousePointer(PPDEV ppdev, SURFOBJ *DestSurface) > { > - if (ppdev->PointerAttributes.Enable == TRUE) > + if (ppdev->PointerAttributes.Enable) > { > return; > } > > Modified: trunk/reactos/win32ss/drivers/displays/framebufacc/ddenable.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/drivers/displays/f… > ============================================================================== > --- trunk/reactos/win32ss/drivers/displays/framebufacc/ddenable.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/drivers/displays/framebufacc/ddenable.c [iso-8859-1] Thu Nov 13 10:31:45 2014 > @@ -38,7 +38,7 @@ > { > PPDEV ppdev = (PPDEV)dhpdev; > > - if (ppdev->bDDInitialized == TRUE) > + if (ppdev->bDDInitialized) > { > return TRUE; > } > @@ -237,7 +237,7 @@ > { > ppdev->pvmList = pvmList; > > - if ( bDDrawHeap == TRUE) > + if (bDDrawHeap) > { > pvmList->dwFlags = VIDMEM_ISLINEAR ; > pvmList->fpStart = ppdev->ScreenHeight * ppdev->ScreenDelta; > > Modified: trunk/reactos/win32ss/drivers/displays/vga/main/enable.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/drivers/displays/v… > ============================================================================== > --- trunk/reactos/win32ss/drivers/displays/vga/main/enable.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/drivers/displays/vga/main/enable.c [iso-8859-1] Thu Nov 13 10:31:45 2014 > @@ -302,7 +302,7 @@ > PPDEV ppdev = (PPDEV)DPev; > ULONG returnedDataLength; > > - if(Enable==TRUE) > + if (Enable) > { > /* Reenable our graphics mode */ > if (!InitPointer(ppdev)) > > Modified: trunk/reactos/win32ss/drivers/displays/vga/vgavideo/vgavideo.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/drivers/displays/v… > ============================================================================== > --- trunk/reactos/win32ss/drivers/displays/vga/vgavideo/vgavideo.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/drivers/displays/vga/vgavideo/vgavideo.c [iso-8859-1] Thu Nov 13 10:31:45 2014 > @@ -560,7 +560,7 @@ > pb++; > } > > - if (edgePixel == TRUE) > + if (edgePixel) > { > b1 = *pb; > if(b1 != trans) vgaPutPixel(x2, j, b1); > > Modified: trunk/reactos/win32ss/gdi/dib/floodfill.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/dib/floodfill.… > ============================================================================== > --- trunk/reactos/win32ss/gdi/dib/floodfill.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/dib/floodfill.c [iso-8859-1] Thu Nov 13 10:31:45 2014 > @@ -61,7 +61,7 @@ > { > if (RECTL_bPointInRect(DstRect,x,y)) > { > - if (isSurf == TRUE && > + if (isSurf && > DibFunctionsForBitmapFormat[DstSurf->iBitmapFormat].DIB_GetPixel(DstSurf, x, y) != Color) > { > return; > > Modified: trunk/reactos/win32ss/gdi/gdi32/misc/gdientry.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/gdi32/misc/gdi… > ============================================================================== > --- trunk/reactos/win32ss/gdi/gdi32/misc/gdientry.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/gdi32/misc/gdientry.c [iso-8859-1] Thu Nov 13 10:31:45 2014 > @@ -1837,7 +1837,7 @@ > { > /* Free it */ > Return = NtGdiDdDeleteDirectDrawObject((HANDLE)pDirectDrawGlobal->hDD); > - if (Return == TRUE) > + if (Return) > { > pDirectDrawGlobal->hDD = 0; > } > @@ -1852,7 +1852,7 @@ > { > /* Delete the object */ > Return = NtGdiDdDeleteDirectDrawObject(ghDirectDraw); > - if (Return == TRUE) > + if (Return) > { > ghDirectDraw = 0; > } > > Modified: trunk/reactos/win32ss/user/ntuser/hotkey.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/hotkey… > ============================================================================== > --- trunk/reactos/win32ss/user/ntuser/hotkey.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/user/ntuser/hotkey.c [iso-8859-1] Thu Nov 13 10:31:45 2014 > @@ -212,7 +212,7 @@ > if (!bIsDown) > { > /* WIN and F12 keys are not hardcoded here. See comments on top of this file. */ > - if (pHotKey->id == IDHK_WINKEY && bWinHotkeyActive == TRUE) > + if (pHotKey->id == IDHK_WINKEY && bWinHotkeyActive) > { > pWnd = ValidateHwndNoErr(InputWindowStation->ShellWindow); > if (pWnd) > > Modified: trunk/reactos/win32ss/user/ntuser/message.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/messag… > ============================================================================== > --- trunk/reactos/win32ss/user/ntuser/message.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/user/ntuser/message.c [iso-8859-1] Thu Nov 13 10:31:45 2014 > @@ -2087,7 +2087,7 @@ > > UserLeave(); > > - if (Ret == TRUE) > + if (Ret) > { > _SEH2_TRY > { > > Modified: trunk/reactos/win32ss/user/ntuser/msgqueue.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/msgque… > ============================================================================== > --- trunk/reactos/win32ss/user/ntuser/msgqueue.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/user/ntuser/msgqueue.c [iso-8859-1] Thu Nov 13 10:31:45 2014 > @@ -805,7 +805,7 @@ > *Message->Result = Result; > } > > - if (Message->HasPackedLParam == TRUE) > + if (Message->HasPackedLParam) > { > if (Message->Msg.lParam) > ExFreePool((PVOID)Message->Msg.lParam); > @@ -887,7 +887,7 @@ > KeSetEvent(SentMessage->CompletionEvent, IO_NO_INCREMENT, FALSE); > } > > - if (SentMessage->HasPackedLParam == TRUE) > + if (SentMessage->HasPackedLParam) > { > if (SentMessage->Msg.lParam) > ExFreePool((PVOID)SentMessage->Msg.lParam); > @@ -1966,7 +1966,7 @@ > KeSetEvent(CurrentSentMessage->CompletionEvent, IO_NO_INCREMENT, FALSE); > } > > - if (CurrentSentMessage->HasPackedLParam == TRUE) > + if (CurrentSentMessage->HasPackedLParam) > { > if (CurrentSentMessage->Msg.lParam) > ExFreePool((PVOID)CurrentSentMessage->Msg.lParam); > @@ -1998,7 +1998,7 @@ > KeSetEvent(CurrentSentMessage->CompletionEvent, IO_NO_INCREMENT, FALSE); > } > > - if (CurrentSentMessage->HasPackedLParam == TRUE) > + if (CurrentSentMessage->HasPackedLParam) > { > if (CurrentSentMessage->Msg.lParam) > ExFreePool((PVOID)CurrentSentMessage->Msg.lParam); > > Modified: trunk/reactos/win32ss/user/user32/controls/appswitch.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/user32/contro… > ============================================================================== > --- trunk/reactos/win32ss/user/user32/controls/appswitch.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/user/user32/controls/appswitch.c [iso-8859-1] Thu Nov 13 10:31:45 2014 > @@ -522,7 +522,7 @@ > return TRUE; > > case WM_SHOWWINDOW: > - if (wParam == TRUE) > + if (wParam) > { > PrepareWindow(); > ati = (PALTTABINFO)GetWindowLongPtrW(hWnd, 0); > > Modified: trunk/reactos/win32ss/user/user32/misc/desktop.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/user32/misc/d… > ============================================================================== > --- trunk/reactos/win32ss/user/user32/misc/desktop.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/user/user32/misc/desktop.c [iso-8859-1] Thu Nov 13 10:31:45 2014 > @@ -610,7 +610,7 @@ > GetProcessWindowStation(), > 0); > > - if( fInherit == TRUE ) > + if( fInherit ) > { > ObjectAttributes.Attributes |= OBJ_INHERIT; > } > > Modified: trunk/reactos/win32ss/user/user32/misc/winsta.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/user32/misc/w… > ============================================================================== > --- trunk/reactos/win32ss/user/user32/misc/winsta.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/user/user32/misc/winsta.c [iso-8859-1] Thu Nov 13 10:31:45 2014 > @@ -372,7 +372,7 @@ > hWindowStationsDir, > 0); > > - if( fInherit == TRUE ) > + if( fInherit ) > { > ObjectAttributes.Attributes |= OBJ_INHERIT; > } > > Modified: trunk/reactos/win32ss/user/winsrv/consrv/frontends/gui/conwnd.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/winsrv/consrv… > ============================================================================== > --- trunk/reactos/win32ss/user/winsrv/consrv/frontends/gui/conwnd.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/user/winsrv/consrv/frontends/gui/conwnd.c [iso-8859-1] Thu Nov 13 10:31:45 2014 > @@ -1784,7 +1784,7 @@ > static VOID > Copy(PGUI_CONSOLE_DATA GuiData) > { > - if (OpenClipboard(GuiData->hWindow) == TRUE) > + if (OpenClipboard(GuiData->hWindow)) > { > PCONSOLE_SCREEN_BUFFER Buffer = GuiData->ActiveBuffer; > > @@ -1814,7 +1814,7 @@ > static VOID > Paste(PGUI_CONSOLE_DATA GuiData) > { > - if (OpenClipboard(GuiData->hWindow) == TRUE) > + if (OpenClipboard(GuiData->hWindow)) > { > PCONSOLE_SCREEN_BUFFER Buffer = GuiData->ActiveBuffer; > > > Modified: trunk/reactos/win32ss/user/winsrv/consrv_new/frontends/gui/guiterm.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/winsrv/consrv… > ============================================================================== > --- trunk/reactos/win32ss/user/winsrv/consrv_new/frontends/gui/guiterm.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/user/winsrv/consrv_new/frontends/gui/guiterm.c [iso-8859-1] Thu Nov 13 10:31:45 2014 > @@ -1336,7 +1336,7 @@ > static VOID > GuiConsoleCopy(PGUI_CONSOLE_DATA GuiData) > { > - if (OpenClipboard(GuiData->hWindow) == TRUE) > + if (OpenClipboard(GuiData->hWindow)) > { > PCONSOLE Console = GuiData->Console; > PCONSOLE_SCREEN_BUFFER Buffer = ConDrvGetActiveScreenBuffer(Console); > @@ -1364,7 +1364,7 @@ > static VOID > GuiConsolePaste(PGUI_CONSOLE_DATA GuiData) > { > - if (OpenClipboard(GuiData->hWindow) == TRUE) > + if (OpenClipboard(GuiData->hWindow)) > { > PCONSOLE Console = GuiData->Console; > PCONSOLE_SCREEN_BUFFER Buffer = ConDrvGetActiveScreenBuffer(Console); > > Modified: trunk/reactos/win32ss/user/winsrv/usersrv/register.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/winsrv/usersr… > ============================================================================== > --- trunk/reactos/win32ss/user/winsrv/usersrv/register.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/user/winsrv/usersrv/register.c [iso-8859-1] Thu Nov 13 10:31:45 2014 > @@ -53,7 +53,7 @@ > { > PUSER_REGISTER_SERVICES_PROCESS RegisterServicesProcessRequest = &((PUSER_API_MESSAGE)ApiMessage)->Data.RegisterServicesProcessRequest; > > - if (ServicesProcessIdValid == TRUE) > + if (ServicesProcessIdValid) > { > /* Only accept a single call */ > return STATUS_INVALID_PARAMETER; > > >

1 0

NTFS in ReactOS: heise online article
by Thomas Mueller 13 Nov '14

13 Nov '14

I saw an article on heise online (German-language website) http://www.heise.de/newsticker/ on ReactOS liest NTFS http://www.heise.de/newsticker/meldung/ReactOS-liest-NTFS-2442615.html Date is 05.11.2014, meaning just yesterday. I subsequently looked on reactos.org and couldn't find any reference to this article. So far, this is only for reading NTFS on ReactOS; writing ability stil has to be worked on. This is the first article I've seen on this subject: looks like progress. Some ReactOS developers must be familiar with this? Tom

3 8

Re: [ros-dev] [ros-diffs] [jgardou] 65388: [TCPIP] - Comment out an optimisation which doesn't work. Reviews of why would be most appreciated.
by Timo Kreuzer 12 Nov '14

12 Nov '14

tcpip.c:264 /* Keep this list sorted */ InsertHeadList(ListEntry, &OutInstance->ListEntry); This should probably be InsertTailList(), since you want to insert before the current ListEntry Am 12.11.2014 12:39, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Wed Nov 12 11:39:13 2014 > New Revision: 65388 > > URL: http://svn.reactos.org/svn/reactos?rev=65388&view=rev > Log: > [TCPIP] > - Comment out an optimisation which doesn't work. > Reviews of why would be most appreciated. > > Modified: > branches/tcpip_revolution/drivers/network/tcpip/entities.c > > Modified: branches/tcpip_revolution/drivers/network/tcpip/entities.c > URL: http://svn.reactos.org/svn/reactos/branches/tcpip_revolution/drivers/networ… > ============================================================================== > --- branches/tcpip_revolution/drivers/network/tcpip/entities.c [iso-8859-1] (original) > +++ branches/tcpip_revolution/drivers/network/tcpip/entities.c [iso-8859-1] Wed Nov 12 11:39:13 2014 > @@ -309,9 +309,11 @@ > return STATUS_SUCCESS; > } > > +#if 0 > /* The list is sorted, so we can cut the loop a bit */ > if (ID.tei_instance < Instance->InstanceId.tei_instance) > break; > +#endif > > ListEntry = ListEntry->Flink; > } > > >

1 0

Re: [ros-dev] [ros-diffs] [spetreolle] 65378: [ADVAPI_WINETEST] Make peace^W tests, not war.☮ Wave a hello to sysreg so that it doesn't kill us. ROSTESTS-56
by Thomas Faber 11 Nov '14

11 Nov '14

Hmm, my thought behind disabling this was more that this one test doesn't justify increasing our whole test run time by 10%. On 2014-11-11 11:12, spetreolle(a)svn.reactos.org wrote: > Author: spetreolle > Date: Tue Nov 11 16:12:14 2014 > New Revision: 65378 > > URL: http://svn.reactos.org/svn/reactos?rev=65378&view=rev > Log: > [ADVAPI_WINETEST] > Make peace^W tests, not war.☮ > Wave a hello to sysreg so that it doesn't kill us. > ROSTESTS-56 > > Modified: > trunk/rostests/winetests/advapi32/service.c > > Modified: trunk/rostests/winetests/advapi32/service.c > URL: http://svn.reactos.org/svn/reactos/trunk/rostests/winetests/advapi32/servic… > ============================================================================== > --- trunk/rostests/winetests/advapi32/service.c [iso-8859-1] (original) > +++ trunk/rostests/winetests/advapi32/service.c [iso-8859-1] Tue Nov 11 16:12:14 2014 > @@ -2166,6 +2166,9 @@ > DWORD le1, le2; > SERVICE_STATUS status; > > +#ifdef __REACTOS__ > + fprintf(stdout, "ROSTESTS-56: Hello sysreg, I am awake\n"); > +#endif > ret = StartServiceA(svc_handle, 0, NULL); > le1 = GetLastError(); > ok(!ret, "%s: StartServiceA() should have failed\n", name); > @@ -2260,12 +2263,6 @@ > * insanely long timeout: 120s. So skip the rest of the tests. > */ > win_skip("Skip some service start/stop tests on NT4\n"); > - goto cleanup; > - } > - > - if (!winetest_interactive) > - { > - skip("ROSTESTS-56: Skipping service start timeout tests!\n"); > goto cleanup; > } >

1 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 65352: [NTOSKRNL] So... Because actual ReactOS mood is to worship hacks instead of looking for proper fixes to have decent behavior: reenable the IopParseDevice hack. But, so far, onl...
by Alex Ionescu 10 Nov '14

10 Nov '14

Let me make a simple arrogant comment: Don't try to fix hacks that I spent years trying to fix (and failed). They just can't be fixed :P Best regards, Alex Ionescu On Mon, Nov 10, 2014 at 1:45 AM, <pschweitzer(a)svn.reactos.org> wrote: > Author: pschweitzer > Date: Mon Nov 10 09:45:43 2014 > New Revision: 65352 > > URL: http://svn.reactos.org/svn/reactos?rev=65352&view=rev > Log: > [NTOSKRNL] > So... Because actual ReactOS mood is to worship hacks instead of looking > for proper fixes to have decent behavior: reenable the IopParseDevice hack. > > But, so far, only reenable it for the 1st stage: the most intensive > storage stack stage (unless you start playing with partitions & formating > in 3rd stage). > > CORE-8732 #resolve #comment Bug is now properly hidden with r65352 > > Modified: > trunk/reactos/ntoskrnl/io/iomgr/file.c > > Modified: trunk/reactos/ntoskrnl/io/iomgr/file.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/iomgr/file.c?r… > > ============================================================================== > --- trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] Mon Nov 10 > 09:45:43 2014 > @@ -404,6 +404,27 @@ > /* Check if we can simply use a dummy file */ > UseDummyFile = ((OpenPacket->QueryOnly) || (OpenPacket->DeleteOnly)); > > + /* FIXME: Small hack still exists, have to check why... > + * This is triggered multiple times by usetup and then once per boot. > + */ > + if (ExpInTextModeSetup && > + !(DirectOpen) && > + !(RemainingName->Length) && > + !(OpenPacket->RelatedFileObject) && > + ((wcsstr(CompleteName->Buffer, L"Harddisk")) || > + (wcsstr(CompleteName->Buffer, L"Floppy"))) && > + !(UseDummyFile)) > + { > + DPRINT1("Using IopParseDevice() hack. Requested invalid > attributes: %lx\n", > + DesiredAccess & ~(SYNCHRONIZE | > + FILE_READ_ATTRIBUTES | > + READ_CONTROL | > + ACCESS_SYSTEM_SECURITY | > + WRITE_OWNER | > + WRITE_DAC)); > + DirectOpen = TRUE; > + } > + > /* Check if this is a direct open */ > if (!(RemainingName->Length) && > !(OpenPacket->RelatedFileObject) && > > >

3 2

Re: [ros-dev] [ros-diffs] [pschweitzer] 65367: [PARTTEST] Add a dummy application that will open first disk and check first sector for MBR and then will open first partition to check for something known (& not MBR)
by Michael Fritscher 10 Nov '14

10 Nov '14

Hi, > + if (Sector->BytesPerSector * Sector->SectorsPerCluster > 32 * 1024) > + { > + return FALSE; > + } FAT supports cluster sizes until 64KB ;-) At least the WinNT series can work with them. Best regards, Michael Fritscher

2 1

Re: [ros-dev] [ros-diffs] [pschweitzer] 65352: [NTOSKRNL] So... Because actual ReactOS mood is to worship hacks instead of looking for proper fixes to have decent behavior: reenable the IopParseDevice hack. But, so far, onl...
by Aleksey Bragin 10 Nov '14

10 Nov '14

Thank you for working on this hack (partial) removal! After all, having it only in the 1st stage is a win over having it enabled all the time. Regards, Aleksey On 10.11.2014 12:45, pschweitzer(a)svn.reactos.org wrote: > Author: pschweitzer > Date: Mon Nov 10 09:45:43 2014 > New Revision: 65352 > > URL: http://svn.reactos.org/svn/reactos?rev=65352&view=rev > Log: > [NTOSKRNL] > So... Because actual ReactOS mood is to worship hacks instead of looking for proper fixes to have decent behavior: reenable the IopParseDevice hack. > > But, so far, only reenable it for the 1st stage: the most intensive storage stack stage (unless you start playing with partitions & formating in 3rd stage). > > CORE-8732 #resolve #comment Bug is now properly hidden with r65352 > > Modified: > trunk/reactos/ntoskrnl/io/iomgr/file.c > > Modified: trunk/reactos/ntoskrnl/io/iomgr/file.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/iomgr/file.c?r… > ============================================================================== > --- trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] Mon Nov 10 09:45:43 2014 > @@ -404,6 +404,27 @@ > /* Check if we can simply use a dummy file */ > UseDummyFile = ((OpenPacket->QueryOnly) || (OpenPacket->DeleteOnly)); > > + /* FIXME: Small hack still exists, have to check why... > + * This is triggered multiple times by usetup and then once per boot. > + */ > + if (ExpInTextModeSetup && > + !(DirectOpen) && > + !(RemainingName->Length) && > + !(OpenPacket->RelatedFileObject) && > + ((wcsstr(CompleteName->Buffer, L"Harddisk")) || > + (wcsstr(CompleteName->Buffer, L"Floppy"))) && > + !(UseDummyFile)) > + { > + DPRINT1("Using IopParseDevice() hack. Requested invalid attributes: %lx\n", > + DesiredAccess & ~(SYNCHRONIZE | > + FILE_READ_ATTRIBUTES | > + READ_CONTROL | > + ACCESS_SYSTEM_SECURITY | > + WRITE_OWNER | > + WRITE_DAC)); > + DirectOpen = TRUE; > + } > + > /* Check if this is a direct open */ > if (!(RemainingName->Length) && > !(OpenPacket->RelatedFileObject) && > >

2 1

Re: [ros-dev] [ros-diffs] [hbelusca] 65337: [NTOS:PNPMGR] - Remove an unneeded ExFreePool(DeviceInstance.Buffer); call in IopGetInterfaceDeviceList because at this point DeviceInstance is not yet initialized. Fixes MSVC bui...
by Timo Kreuzer 09 Nov '14

09 Nov '14

You add parentheses to conform to coding style (our coding style guidelines do not require it) and on the other hand you convert a 2 line if statement into one line, which does not conform to our coding style? Am 09.11.2014 03:26, schrieb hbelusca(a)svn.reactos.org: > Author: hbelusca > Date: Sun Nov 9 02:26:49 2014 > New Revision: 65337 > > URL: http://svn.reactos.org/svn/reactos?rev=65337&view=rev > Log: > [NTOS:PNPMGR] > - Remove an unneeded ExFreePool(DeviceInstance.Buffer); call in IopGetInterfaceDeviceList because at this point DeviceInstance is not yet initialized. Fixes MSVC build. > - No need to check for DeviceInstance.Buffer being NULL or not (in IopDeviceStatus), because in case it was NULL the IopCaptureUnicodeString call already failed. > - Add some brackets to conform to code style. > > Modified: > trunk/reactos/ntoskrnl/io/pnpmgr/plugplay.c > > Modified: trunk/reactos/ntoskrnl/io/pnpmgr/plugplay.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/pnpmgr/plugpla… > ============================================================================== > --- trunk/reactos/ntoskrnl/io/pnpmgr/plugplay.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/io/pnpmgr/plugplay.c [iso-8859-1] Sun Nov 9 02:26:49 2014 > @@ -199,8 +199,7 @@ > } > _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > { > - if (Name.Buffer) > - ExFreePool(Name.Buffer); > + if (Name.Buffer) ExFreePool(Name.Buffer); > Status = _SEH2_GetExceptionCode(); > } > _SEH2_END; >

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 65336: [NTVDM]: Use variable-length buffers in DisplayMessage, in case we display a very long message (uses the _vscwprintf CRT function, not available on Win2k. You need to recompile NT...
by Timo Kreuzer 09 Nov '14

09 Nov '14

Am 09.11.2014 02:46, schrieb hbelusca(a)svn.reactos.org: > Author: hbelusca > Date: Sun Nov 9 01:46:31 2014 > New Revision: 65336 > > URL: http://svn.reactos.org/svn/reactos?rev=65336&view=rev > Log: > [NTVDM]: Use variable-length buffers in DisplayMessage, in case we display a very long message (uses the _vscwprintf CRT function, not available on Win2k. You need to recompile NTVDM with WIN2K_COMPLIANT define if you want to be able to run it on win2k. In that case DisplayMessage uses a quite large enough buffer for its needs). If somebody knows an alternative to _vscwprintf that does the very same job, and which exists on Win2k, I would be happy to use it instead. Since _vscwprintf will do the whole work already anyway, you could as well directly print it into the static buffer. You could use _vsnwprintf or StringCbPrintfW, which internally uses the former, and use the result to decide whether the buffer was large enough. This will be more performant, since you only need to print once, when the buffer is large enough.

1 0

Re: [ros-dev] [ros-diffs] [tfaber] 65269: [FASTFAT] - VfatCleanupFile: do not dereference the FCB when closing the volume file object. ObDereferenceObject already causes an IRP_MJ_CLOSE request to be sent, which dereference...
by Thomas Faber 05 Nov '14

05 Nov '14

Oh... Jérôme, I only just saw that you added this in r65140... And my change does break the msi tests again. :\ Any idea what's going wrong here? I'm relatively certain my change is correct because vfatFCBInitializeCacheFromVolume takes one reference, and VfatCloseFile invoked via ObDereferenceObject will remove that reference again. So apparently we're leaking a directory reference somewhere else? :( Not sure if your previous investigation into this issue can provide any pointers. Otherwise I'll have to start digging for the leak all over again... Thanks. -Thomas On 2014-11-05 19:52, tfaber(a)svn.reactos.org wrote: > --- trunk/reactos/drivers/filesystems/fastfat/cleanup.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/fastfat/cleanup.c [iso-8859-1] Wed Nov 5 18:52:11 2014 > @@ -92,7 +92,6 @@ > pFcb->FileObject = NULL; > CcUninitializeCacheMap(tmpFileObject, NULL, NULL); > ObDereferenceObject(tmpFileObject); > - vfatReleaseFCB(IrpContext->DeviceExt, pFcb); > } > > CcPurgeCacheSection(FileObject->SectionObjectPointer, NULL, 0, FALSE); > >

2 1

Re: [ros-dev] [ros-diffs] [tkreuzer] 65255: Merged revision(s) 62353, 62531-62532, 62853, 64152, 64173-64174 from branches/kernel-fun/reactos: [NTOSKRNL] Implement SystemPrioritySeperation case in NtSetSystemInformation ......
by Thomas Faber 04 Nov '14

04 Nov '14

On 2014-11-04 21:47, tkreuzer(a)svn.reactos.org wrote: > --- trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] Tue Nov 4 20:47:18 2014 > @@ -1580,6 +1580,8 @@ > if (OpenPacket.ParseCheck != TRUE) > { > /* Parse failed */ > + DPRINT1("IopQueryAttributesFile failed for '%wZ' with 0x%lx\n", > + ObjectAttributes->ObjectName, Status); > return Status; > } > else This one seems to be super noisy on testbot.

1 0

Re: [ros-dev] [ros-diffs] [jgardou] 65210: [NTOS/PS] - Do not leak a reference to the process object when setting quotas.
by Timo Kreuzer 03 Nov '14

03 Nov '14

Doesn't this change Windows behaviour? No, luckily it does not change *Windows* behaviour. It does not even change ReactOS behaviour, but only, because it was already broken before. Since MS implemented this function in an arbitrary and hard to comprehend way, we need to follow this pattern. This means, the function must not fail on process reference failure, unless certain conditions are met, otherwise we will fail with the wrong Status code. To fix the situation, we could remember the fact that the process couldn't be referenced (possibly by setting Process to NULL) and later check that after other checks were done. The alternative is referencing the process individually in each and every case, which will make the function even more huge and does not really help with it's readability. Or we can factor our each case and implement it as a separate function. It would add a lot of code duplication, but might help a bit with readability and maintainability. Am 03.11.2014 10:52, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Mon Nov 3 09:52:08 2014 > New Revision: 65210 > > URL: http://svn.reactos.org/svn/reactos?rev=65210&view=rev > Log: > [NTOS/PS] > - Do not leak a reference to the process object when setting quotas. > > Modified: > trunk/reactos/ntoskrnl/include/internal/ps.h > trunk/reactos/ntoskrnl/ps/query.c > trunk/reactos/ntoskrnl/ps/quota.c > > Modified: trunk/reactos/ntoskrnl/include/internal/ps.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/internal/… > ============================================================================== > --- trunk/reactos/ntoskrnl/include/internal/ps.h [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/include/internal/ps.h [iso-8859-1] Mon Nov 3 09:52:08 2014 > @@ -303,7 +303,7 @@ > NTSTATUS > NTAPI > PspSetQuotaLimits( > - _In_ HANDLE ProcessHandle, > + _In_ PEPROCESS Process, > _In_ ULONG Unused, > _In_ PVOID QuotaLimits, > _In_ ULONG QuotaLimitsLength, > > Modified: trunk/reactos/ntoskrnl/ps/query.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ps/query.c?rev=65… > ============================================================================== > --- trunk/reactos/ntoskrnl/ps/query.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ps/query.c [iso-8859-1] Mon Nov 3 09:52:08 2014 > @@ -1528,6 +1528,7 @@ > /* Validate the number */ > if ((BasePriority > HIGH_PRIORITY) || (BasePriority <= LOW_PRIORITY)) > { > + ObDereferenceObject(Process); > return STATUS_INVALID_PARAMETER; > } > > @@ -1918,11 +1919,12 @@ > > case ProcessQuotaLimits: > > - return PspSetQuotaLimits(ProcessHandle, > + Status = PspSetQuotaLimits(Process, > 1, > ProcessInformation, > ProcessInformationLength, > PreviousMode); > + break; > > case ProcessWorkingSetWatch: > DPRINT1("WS watch not implemented\n"); > > Modified: trunk/reactos/ntoskrnl/ps/quota.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ps/quota.c?rev=65… > ============================================================================== > --- trunk/reactos/ntoskrnl/ps/quota.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ps/quota.c [iso-8859-1] Mon Nov 3 09:52:08 2014 > @@ -292,14 +292,13 @@ > NTSTATUS > NTAPI > PspSetQuotaLimits( > - _In_ HANDLE ProcessHandle, > + _In_ PEPROCESS Process, > _In_ ULONG Unused, > _In_ PVOID QuotaLimits, > _In_ ULONG QuotaLimitsLength, > _In_ KPROCESSOR_MODE PreviousMode) > { > QUOTA_LIMITS_EX CapturedQuotaLimits; > - PEPROCESS Process; > PEPROCESS_QUOTA_BLOCK QuotaBlock, OldQuotaBlock; > BOOLEAN IncreaseOkay; > KAPC_STATE SavedApcState; > @@ -368,19 +367,6 @@ > } > _SEH2_END; > > - /* Reference the process */ > - Status = ObReferenceObjectByHandle(ProcessHandle, > - PROCESS_SET_QUOTA, > - PsProcessType, > - PreviousMode, > - (PVOID*)&Process, > - NULL); > - if (!NT_SUCCESS(Status)) > - { > - DPRINT1("Failed to reference process handle: 0x%lx\n", Status); > - return Status; > - } > - > /* Check the caller changes the working set size limits */ > if ((CapturedQuotaLimits.MinimumWorkingSetSize != 0) && > (CapturedQuotaLimits.MaximumWorkingSetSize != 0)) > @@ -418,7 +404,6 @@ > /* Check if the caller has the required privilege */ > if (!SeSinglePrivilegeCheck(SeIncreaseQuotaPrivilege, PreviousMode)) > { > - ObDereferenceObject(Process); > return STATUS_PRIVILEGE_NOT_HELD; > } > > @@ -460,8 +445,6 @@ > Status = STATUS_SUCCESS; > } > > - /* Dereference the process and return the status */ > - ObDereferenceObject(Process); > return Status; > } > > > >

1 0

Fezile server downtime this evening
by Colin Finck 03 Nov '14

03 Nov '14

Hi all, Jan and I will finally install the remote management card in Fezile this evening and verify the cabling of our UPS systems. This will cause a short downtime of the Fezile server along with its testslaves, cppcheck, Doxygen, Git and iso.reactos.org. In case we notice a fault in UPS cabling, we may also be required to temporarily shut down other servers, replug their power cables and boot them up again. This may cause very short downtimes as well. After this measure, we will be able to totally manage this important server remotely, even if its OS has failed at some point. Proper UPS cabling also ensures smooth operations in case of sudden power outages. Thanks for your understanding! Cheers, Colin

1 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 65166: [NTFS] Simplify buffer size management in GetNtfsFileRecord(). As tests shown, Windows doesn't care about the real size of the file record and expects the caller to pass the co...
by Thomas Faber 01 Nov '14

01 Nov '14

On 2014-11-01 11:02, pschweitzer(a)svn.reactos.org wrote: > - OutputBuffer->FileRecordLength = FileRecord->BytesInUse; > - RtlCopyMemory(OutputBuffer->FileRecordBuffer, FileRecord, FileRecord->BytesInUse); > + OutputBuffer->FileRecordLength = DeviceExt->NtfsInfo.BytesPerFileRecord; > + RtlCopyMemory(OutputBuffer->FileRecordBuffer, FileRecord, DeviceExt->NtfsInfo.BytesPerFileRecord); Wait, now there's no check against OutputBufferLength at all? It should at least be min(DeviceExt->NtfsInfo.BytesPerFileRecord, Stack->Parameters.FileSystemControl.OutputBufferLength) in the memcpy size. Or am I missing something?

2 3

Re: [ros-dev] [ros-diffs] [jgardou] 65140: [FASTFAT] - Fix renaming files in case the target file already exists. - Plug a few reference count leaks on FCBs. CORE-8660 #comment fixed in r65140 #resolve CORE-8633 #comment fi...
by Pierre Schweitzer 31 Oct '14

31 Oct '14

Warm thanks for debugging this issue Jérôme. I do value your help. This should unlock many autoupdating apps in ReactOS. Thanks again. On 31/10/2014 12:04, jgardou(a)svn.reactos.org wrote: > Author: jgardou > Date: Fri Oct 31 11:04:12 2014 > New Revision: 65140 > > URL: http://svn.reactos.org/svn/reactos?rev=65140&view=rev > Log: > [FASTFAT] > - Fix renaming files in case the target file already exists. > - Plug a few reference count leaks on FCBs. > CORE-8660 #comment fixed in r65140 #resolve > CORE-8633 #comment fixed in r65140 #resolve > CORE-4758 #comment fixed in r65140 #resolve > > Modified: > trunk/reactos/drivers/filesystems/fastfat/cleanup.c > trunk/reactos/drivers/filesystems/fastfat/create.c > trunk/reactos/drivers/filesystems/fastfat/finfo.c > > Modified: trunk/reactos/drivers/filesystems/fastfat/cleanup.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfa… > ============================================================================== > --- trunk/reactos/drivers/filesystems/fastfat/cleanup.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/fastfat/cleanup.c [iso-8859-1] Fri Oct 31 11:04:12 2014 > @@ -92,6 +92,7 @@ > pFcb->FileObject = NULL; > CcUninitializeCacheMap(tmpFileObject, NULL, NULL); > ObDereferenceObject(tmpFileObject); > + vfatReleaseFCB(IrpContext->DeviceExt, pFcb); > } > > CcPurgeCacheSection(FileObject->SectionObjectPointer, NULL, 0, FALSE); > > Modified: trunk/reactos/drivers/filesystems/fastfat/create.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfa… > ============================================================================== > --- trunk/reactos/drivers/filesystems/fastfat/create.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/fastfat/create.c [iso-8859-1] Fri Oct 31 11:04:12 2014 > @@ -365,7 +365,6 @@ > DPRINT("'%wZ'\n", &FileObject->RelatedFileObject->FileName); > > *ParentFcb = FileObject->RelatedFileObject->FsContext; > - vfatGrabFCB(DeviceExt, *ParentFcb); > } > else > { > > Modified: trunk/reactos/drivers/filesystems/fastfat/finfo.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfa… > ============================================================================== > --- trunk/reactos/drivers/filesystems/fastfat/finfo.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/fastfat/finfo.c [iso-8859-1] Fri Oct 31 11:04:12 2014 > @@ -396,41 +396,53 @@ > /* If it exists */ > if (NT_SUCCESS(Status)) > { > + DPRINT("Target file %wZ exists. FCB Flags %08x\n", NewName, TargetFcb->Flags); > /* Check whether we are allowed to replace */ > if (ReplaceIfExists) > { > /* If that's a directory or a read-only file, we're not allowed */ > - if (vfatFCBIsDirectory(TargetFcb) || ((*TargetFcb->Attributes & FILE_ATTRIBUTE_READONLY) == FILE_ATTRIBUTE_READONLY)); > - { > + if (vfatFCBIsDirectory(TargetFcb) || ((*TargetFcb->Attributes & FILE_ATTRIBUTE_READONLY) == FILE_ATTRIBUTE_READONLY)) > + { > + DPRINT("And this is a readonly file!\n"); > vfatReleaseFCB(DeviceExt, *ParentFCB); > *ParentFCB = NULL; > vfatReleaseFCB(DeviceExt, TargetFcb); > return STATUS_OBJECT_NAME_COLLISION; > } > > - /* Attempt to flush (might close the file) */ > - if (!MmFlushImageSection(TargetFcb->FileObject->SectionObjectPointer, MmFlushForDelete)) > - { > + > + /* If we still have a file object, close it. */ > + if (TargetFcb->FileObject) > + { > + if (!MmFlushImageSection(TargetFcb->FileObject->SectionObjectPointer, MmFlushForDelete)) > + { > + DPRINT("MmFlushImageSection failed.\n"); > + vfatReleaseFCB(DeviceExt, *ParentFCB); > + *ParentFCB = NULL; > + vfatReleaseFCB(DeviceExt, TargetFcb); > + return STATUS_ACCESS_DENIED; > + } > + > + TargetFcb->FileObject->DeletePending = TRUE; > + VfatCloseFile(DeviceExt, TargetFcb->FileObject); > + } > + > + /* If we are here, ensure the file isn't open by anyone! */ > + if (TargetFcb->OpenHandleCount != 0) > + { > + DPRINT("There are still open handles for this file.\n"); > vfatReleaseFCB(DeviceExt, *ParentFCB); > *ParentFCB = NULL; > vfatReleaseFCB(DeviceExt, TargetFcb); > return STATUS_ACCESS_DENIED; > } > > - /* If we are, ensure the file isn't open by anyone! */ > - if (TargetFcb->OpenHandleCount != 0) > - { > - vfatReleaseFCB(DeviceExt, *ParentFCB); > - *ParentFCB = NULL; > - vfatReleaseFCB(DeviceExt, TargetFcb); > - return STATUS_ACCESS_DENIED; > - } > - > /* Effectively delete old file to allow renaming */ > + DPRINT("Effectively deleting the file.\n"); > VfatDelEntry(DeviceExt, TargetFcb, NULL); > - vfatGrabFCB(DeviceExt, *ParentFCB); > vfatReleaseFCB(DeviceExt, TargetFcb); > *Deleted = TRUE; > + return STATUS_SUCCESS; > } > else > { > > -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

1 0

Re: [ros-dev] [ros-diffs] [akhaldi] 65133: [LOGOFF] * Plug some leaks. CIDs 716284 and 716285. CORE-7975
by Thomas Faber 31 Oct '14

31 Oct '14

Hey, On 2014-10-31 10:22, akhaldi(a)svn.reactos.org wrote: > @@ -90,6 +91,7 @@ > //Invalid parameter detected > if (AllocAndLoadString(&lpIllegalMsg, GetModuleHandle(NULL), IDS_ILLEGAL_PARAM)) > _putts(lpIllegalMsg); > + LocalFree(lpIllegalMsg); > return FALSE; > } > } > This needs braces. Both puts and LocalFree should only be executed if AllocAndLoadString succeeds (but return FALSE in either case). Thanks!

1 0

BuildBot changes
by Colin Finck 30 Oct '14

30 Oct '14

Hi all, As you can see in project-tools SVN, I've improved our Bash scripts for Buildslaves. They're now also usable under Windows (in a Cygwin environment) and I'm already doing this on our new Windows Buildslave Carrier-Win7. Bash on Windows may look hacky at first, but it's definitely more comfortable than Batch! Moreover, we now only have a single version of build scripts to maintain for all our Buildslaves! This also involved some naming changes on the existing slaves to maintain a consistent scheme. Tell me if anything broke. Bringing all desired Windows builders back will still take some time. I've only started with a RosBE-Windows based one right now and I need your help here: For some reason, VirtualBox 4.3.18 (used for reg-testing) doesn't want to run headless. I can do a 'runas /user:buildbot VBoxManage controlvm "ReactOS Testbot" poweroff' in a CMD and it will work well. The very same command executed through BuildBot ends with: ==================================================================== VBoxManage.exe: error: Failed to create the VirtualBox object! VBoxManage.exe: error: Code E_ACCESSDENIED (0x80070005) - General access denied error (extended info not available) VBoxManage.exe: error: Most likely, the VirtualBox COM server is not running or failed to start. ==================================================================== See http://build.reactos.org/builders/Carrier-Win7%20VBox-Testbot/builds/6/step… VBoxSVC.log isn't touched when BuildBot tries this command, so I have no additional information. Haven't found a solution yet, so I'm asking here if any of the VBox experts know what could be going wrong. Cheers, Colin

5 10

Do not waste 65432 and 65536 GET!
by Alexander Rechitskiy 30 Oct '14

30 Oct '14

1 0

Status Meeting (October 2014)
by Aleksey Bragin 29 Oct '14

29 Oct '14

Hello, Let me invite you to the monthly status meeting taking place 30th of October, 19:00 UTC (that's tomorrow!). IRC service will only be started shortly before the meeting. Your participation passwords and server address will be emailed to you shortly before the meeting starts, and they are going to be different once again as they are not stored in any database. Hopefully it's not much of inconvenience. If someone still is not getting passwords sent before a meeting - please email Pierre before the meeting started to get one. Please send agenda proposals to me before the meeting, so that we can start with a proposed agenda. Regards, Aleksey Bragin

1 0

Monthly Meeting?
by Hermès BÉLUSCA - MAÏTO 29 Oct '14

29 Oct '14

Hi ! Is there our monthly meeting tomorrow ? Cheers, Hermès.

1 0

Re: [ros-dev] [ros-diffs] [akhaldi] 64994: [ADVAPI32] * Update ImpersonateNamedPipeClient(). CORE-8540
by Ged Murphy 27 Oct '14

27 Oct '14

Eeww, these are a bit ugly :( On 25/10/2014 19:30, "akhaldi(a)svn.reactos.org" <akhaldi(a)svn.reactos.org> wrote: >Author: akhaldi >Date: Sat Oct 25 18:30:05 2014 >New Revision: 64994 > >URL: http://svn.reactos.org/svn/reactos?rev=64994&view=rev >Log: >[ADVAPI32] >* Update ImpersonateNamedPipeClient(). >CORE-8540 > >Modified: > trunk/reactos/dll/win32/advapi32/wine/security.c > >Modified: trunk/reactos/dll/win32/advapi32/wine/security.c >URL: >http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/advapi32/wine/s >ecurity.c?rev=64994&r1=64993&r2=64994&view=diff >========================================================================== >==== >--- trunk/reactos/dll/win32/advapi32/wine/security.c [iso-8859-1] >(original) >+++ trunk/reactos/dll/win32/advapi32/wine/security.c [iso-8859-1] Sat Oct >25 18:30:05 2014 >@@ -954,37 +954,14 @@ > return TRUE; > } > >-/********************************************************************** >- * ImpersonateNamedPipeClient EXPORTED >- * >- * @implemented >- */ >-BOOL >-WINAPI >-ImpersonateNamedPipeClient(HANDLE hNamedPipe) >-{ >- IO_STATUS_BLOCK StatusBlock; >- NTSTATUS Status; >- >- TRACE("ImpersonateNamedPipeClient() called\n"); >- >- Status = NtFsControlFile(hNamedPipe, >- NULL, >- NULL, >- NULL, >- &StatusBlock, >- FSCTL_PIPE_IMPERSONATE, >- NULL, >- 0, >- NULL, >- 0); >- if (!NT_SUCCESS(Status)) >- { >- SetLastError(RtlNtStatusToDosError(Status)); >- return FALSE; >- } >- >- return TRUE; >+BOOL WINAPI ImpersonateNamedPipeClient( HANDLE hNamedPipe ) >+{ >+ IO_STATUS_BLOCK io_block; >+ >+ TRACE("(%p)\n", hNamedPipe); >+ >+ return set_ntstatus( NtFsControlFile(hNamedPipe, NULL, NULL, NULL, >+ &io_block, FSCTL_PIPE_IMPERSONATE, NULL, 0, >NULL, 0) ); > } > > /* > >

3 4

Re: [ros-dev] [ros-diffs] [tfaber] 64974: [CRT] - Add frame pointer omission information to assembly string functions to fix debugging annoyances. Reviews appreciated
by Timo Kreuzer 25 Oct '14

25 Oct '14

Am 25.10.2014 02:08, schrieb tfaber(a)svn.reactos.org: > Author: tfaber > Date: Sat Oct 25 00:08:23 2014 > New Revision: 64974 > > URL: http://svn.reactos.org/svn/reactos?rev=64974&view=rev > Log: > [CRT] > - Add frame pointer omission information to assembly string functions to fix debugging annoyances. Reviews appreciated > > > > Modified: trunk/reactos/lib/sdk/crt/string/i386/tcsnlen.inc > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/sdk/crt/string/i386/tc… > ============================================================================== > --- trunk/reactos/lib/sdk/crt/string/i386/tcsnlen.inc [iso-8859-1] (original) > +++ trunk/reactos/lib/sdk/crt/string/i386/tcsnlen.inc [iso-8859-1] Sat Oct 25 00:08:23 2014 > @@ -5,7 +5,8 @@ > PUBLIC _tcsnlen > .code > > -_tcsnlen: > +FUNC _tcsnlen > + FPO 0, 1, 1, 1, 0, FRAME_FPO This one has 2 parameters

1 0

Tuesday is a best day for software\pr releases
by Alexander Rechitskiy 24 Oct '14

24 Oct '14

3 2

Re: [ros-dev] [ros-diffs] [jgardou] 64911: [USER32] - Fix LookupIconIdFromDirectoryEx, returning 0 when no matching entry is found. - Fix error handling when opening a cursor file. - Various code beautification here and the...
by Thomas Faber 23 Oct '14

23 Oct '14

On 2014-10-23 11:32, jgardou(a)svn.reactos.org wrote: > - if ( dwFileSize < (sizeof(*dir) + sizeof(dir->idEntries[0])*(dir->idCount-1)) ) > + if (dwFileSize < (sizeof(*dir) + FIELD_OFFSET(CURSORICONFILEDIR, idEntries[dir->idCount]))) Did you mean to remove the sizeof(*dir)?

2 1

Re: [ros-dev] [ros-diffs] [tfaber] 64889: [NTOS:MM] - Add a way to generate a pool tag from the calling driver name if none is specified. Disabled by default.
by Timo Kreuzer 22 Oct '14

22 Oct '14

Simpler: + if (LdrEntry) + { + ULONG i; + Tag = '____'; // IMO better than ' ' + for (i = 0; i < min(4, LdrEntry->BaseDllName.Length / sizeof(WCHAR)); i++) + ((PCHAR)&Tag)[i] = (LdrEntry->BaseDllName.Buffer[i] & 0xff); + } Maybe we can also add support for tracking backtraces of pool allocations. Am 22.10.2014 15:26, schrieb tfaber(a)svn.reactos.org: > Author: tfaber > Date: Wed Oct 22 13:26:50 2014 > New Revision: 64889 > > URL: http://svn.reactos.org/svn/reactos?rev=64889&view=rev > Log: > [NTOS:MM] > - Add a way to generate a pool tag from the calling driver name if none is specified. Disabled by default. > > Modified: > trunk/reactos/ntoskrnl/mm/ARM3/expool.c > > Modified: trunk/reactos/ntoskrnl/mm/ARM3/expool.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/expool.c?… > ============================================================================== > --- trunk/reactos/ntoskrnl/mm/ARM3/expool.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/mm/ARM3/expool.c [iso-8859-1] Wed Oct 22 13:26:50 2014 > @@ -2046,10 +2046,25 @@ > ExAllocatePool(POOL_TYPE PoolType, > SIZE_T NumberOfBytes) > { > - // > - // Use a default tag of "None" > - // > - return ExAllocatePoolWithTag(PoolType, NumberOfBytes, TAG_NONE); > + ULONG Tag = TAG_NONE; > +#if 0 && DBG > + PLDR_DATA_TABLE_ENTRY LdrEntry; > + > + /* Use the first four letters of the driver name, or "None" if unavailable */ > + LdrEntry = KeGetCurrentIrql() <= APC_LEVEL > + ? MiLookupDataTableEntry(_ReturnAddress()) > + : NULL; > + if (LdrEntry) > + { > + ULONG i; > + Tag = 0; > + for (i = 0; i < min(4, LdrEntry->BaseDllName.Length / sizeof(WCHAR)); i++) > + Tag = Tag >> 8 | (LdrEntry->BaseDllName.Buffer[i] & 0xff) << 24; > + for (; i < 4; i++) > + Tag = Tag >> 8 | ' ' << 24; > + } > +#endif > + return ExAllocatePoolWithTag(PoolType, NumberOfBytes, Tag); > } > > /* > @@ -2513,7 +2528,7 @@ > // > // Allocate the pool > // > - return ExAllocatePoolWithQuotaTag(PoolType, NumberOfBytes, 'enoN'); > + return ExAllocatePoolWithQuotaTag(PoolType, NumberOfBytes, TAG_NONE); > } > > /* > > >

1 0

Re: [ros-dev] [ros-diffs] [khornicek] 64882: [SERVMAN] - fix resource leaks CID 716292, 716293, 716294 - fix CID 716772 (double free), 513719 (wrong NULL check), 1206739 (cosmetic) - make line endings CR LF when exporting t...
by Timo Kreuzer 22 Oct '14

22 Oct '14

Am 22.10.2014 00:58, schrieb khornicek(a)svn.reactos.org: > - if (LVText != NULL) > + if (_tcslen(LVText)) > { > WriteFile(hFile, > LVText, I think LVText might not be zero terminated, when the SendMessage call fails. What about if (dwTextLength != 0)?

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 64773: [FAST486]: Do not call RtlCopyMemory for copying few bytes (2 and 4).
by Alex Ionescu 21 Oct '14

21 Oct '14

memcpy already has logic to handle, 1, 2, 4, 8, etc.. sizes. Best regards, Alex Ionescu On Thu, Oct 16, 2014 at 2:48 PM, <hbelusca(a)svn.reactos.org> wrote: > Author: hbelusca > Date: Thu Oct 16 21:48:18 2014 > New Revision: 64773 > > URL: http://svn.reactos.org/svn/reactos?rev=64773&view=rev > Log: > [FAST486]: Do not call RtlCopyMemory for copying few bytes (2 and 4). > > Modified: > trunk/reactos/lib/fast486/fast486.c > trunk/reactos/lib/fast486/opgroups.c > > Modified: trunk/reactos/lib/fast486/fast486.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/lib/fast486/fast486.c?rev=… > > ============================================================================== > --- trunk/reactos/lib/fast486/fast486.c [iso-8859-1] (original) > +++ trunk/reactos/lib/fast486/fast486.c [iso-8859-1] Thu Oct 16 21:48:18 > 2014 > @@ -117,7 +117,6 @@ > Fast486MemReadCallback(PFAST486_STATE State, ULONG Address, PVOID Buffer, > ULONG Size) > { > UNREFERENCED_PARAMETER(State); > - > RtlMoveMemory(Buffer, (PVOID)Address, Size); > } > > @@ -126,7 +125,6 @@ > Fast486MemWriteCallback(PFAST486_STATE State, ULONG Address, PVOID > Buffer, ULONG Size) > { > UNREFERENCED_PARAMETER(State); > - > RtlMoveMemory((PVOID)Address, Buffer, Size); > } > > > Modified: trunk/reactos/lib/fast486/opgroups.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/lib/fast486/opgroups.c?rev… > > ============================================================================== > --- trunk/reactos/lib/fast486/opgroups.c [iso-8859-1] (original) > +++ trunk/reactos/lib/fast486/opgroups.c [iso-8859-1] Thu Oct 16 > 21:48:18 2014 > @@ -2016,6 +2016,7 @@ > > FAST486_OPCODE_HANDLER(Fast486OpcodeGroup0F01) > { > + // FAST486_TABLE_REG TableReg; > UCHAR TableReg[6]; > FAST486_MOD_REG_RM ModRegRm; > BOOLEAN OperandSize, AddressSize; > @@ -2054,8 +2055,9 @@ > } > > /* Fill the 6-byte table register */ > - RtlCopyMemory(TableReg, &State->Gdtr.Size, sizeof(USHORT)); > - RtlCopyMemory(&TableReg[sizeof(USHORT)], > &State->Gdtr.Address, sizeof(ULONG)); > + // TableReg = State->Gdtr; > + *((PUSHORT)&TableReg) = State->Gdtr.Size; > + *((PULONG)&TableReg[sizeof(USHORT)]) = State->Gdtr.Address; > > /* Store the GDTR */ > return Fast486WriteMemory(State, > @@ -2076,8 +2078,9 @@ > } > > /* Fill the 6-byte table register */ > - RtlCopyMemory(TableReg, &State->Idtr.Size, sizeof(USHORT)); > - RtlCopyMemory(&TableReg[sizeof(USHORT)], > &State->Idtr.Address, sizeof(ULONG)); > + // TableReg = State->Idtr; > + *((PUSHORT)&TableReg) = State->Idtr.Size; > + *((PULONG)&TableReg[sizeof(USHORT)]) = State->Idtr.Address; > > /* Store the IDTR */ > return Fast486WriteMemory(State, > @@ -2117,7 +2120,8 @@ > } > > /* Load the new GDT */ > - State->Gdtr.Size = *((PUSHORT)TableReg); > + // State->Gdtr = TableReg; > + State->Gdtr.Size = *((PUSHORT)&TableReg); > State->Gdtr.Address = *((PULONG)&TableReg[sizeof(USHORT)]); > > /* In 16-bit mode the highest byte is masked out */ > @@ -2156,7 +2160,8 @@ > } > > /* Load the new IDT */ > - State->Idtr.Size = *((PUSHORT)TableReg); > + // State->Idtr = TableReg; > + State->Idtr.Size = *((PUSHORT)&TableReg); > State->Idtr.Address = *((PULONG)&TableReg[sizeof(USHORT)]); > > /* In 16-bit mode the highest byte is masked out */ > > >

2 1

Re: [ros-dev] [ros-diffs] [hbelusca] 64747: [NTVDM]: Zero-fill memory with RtlZeroMemory (that exists also in NT mode), and use sizeof(object) instead of sizeof(type_of_object).
by Timo Kreuzer 20 Oct '14

20 Oct '14

Looks like bugs Am 15.10.2014 00:46, schrieb hbelusca(a)svn.reactos.org: > Author: hbelusca > Date: Tue Oct 14 22:46:40 2014 > New Revision: 64747 > > URL: http://svn.reactos.org/svn/reactos?rev=64747&view=rev > Log: > [NTVDM]: Zero-fill memory with RtlZeroMemory (that exists also in NT mode), and use sizeof(object) instead of sizeof(type_of_object). > /* Clear the current directory buffer */ > - ZeroMemory(CurrentDirectories, sizeof(CurrentDirectories)); > + RtlZeroMemory(CurrentDirectories, sizeof(CurrentDirectories)); > @@ -2901,7 +2901,7 @@ > WCHAR Buffer[256]; > > /* Clear the current directory buffer */ > - ZeroMemory(CurrentDirectories, sizeof(CurrentDirectories)); > + RtlZeroMemory(CurrentDirectories, sizeof(CurrentDirectories)); > @@ -1901,7 +1901,7 @@ > > VOID VgaClearMemory(VOID) > { > - ZeroMemory(VgaMemory, sizeof(VgaMemory)); > + RtlZeroMemory(VgaMemory, sizeof(VgaMemory)); > } > >

4 4

Re: [ros-dev] RtlUlonglongByteSwap (Thomas Faber)
by Love Nystrom 20 Oct '14

20 Oct '14

On 2014-10-17 19.00, ros-dev-request(a)reactos.org wrote: > Fastcall passes 64 bit arguments on the stack. Aaagh.. I didn't know that.. Thanks for pointing it out. IMO that's incredibly stupid, as a 32-bit CPU (or x64 running 32bit) uses the register combination EAX:EDX for 64 bit integers, and EAX:EDX is used for 64 bit return values (again in 32bit mode). The compiler designers need to smarten up! Best Regards Love > And yes, this is about an ntdll/ntoskrnl export, so we must be binary > compatible with what Windows does. > But the implementation that is normally used is an inline/intrinsic > function anyway. This is just about the export (or rather, importing > it). > > On 2014-10-17 00:24, Love Nystrom wrote: >> >@Timo, @Thomas, @Ged >> > >> >Byte order swappers should always be fastcall for perfomance reasons. >> >They have no need for the benefits of the cdecl call convention. >> >Using cdecl in this case would make the binary code pitifully slow. >> > >> >Think about it for a bit.. Some pseudocode show what I mean: >> > >> >..CDECL... >> > >> > push hi >> > push lo >> > call Swapper >> > mov dsthi, edx >> > mov dstlo, eax >> > add esp, 4 >> > ... >> > >> >// UINT64 __cdecl >> >Swapper: >> > push ebp >> > mov ebp, esp >> > mov eax, ebp+8 // lo >> > mov eax, ebp+12 // hi >> > bswap >> > xchg eax, edx >> > bswap >> > pop ebp >> > ret >> > >> >..FASTCALL... >> > >> > mov edx, hi >> > mov eax, lo >> > call Swapper >> > mov dsthi, edx >> > mov dstlo, eax >> > ... >> > >> >// UINT64 __declspec(naked) __fastcall >> >Swapper: >> > bswap >> > xchg eax, edx >> > bswap >> > ret >> > >> >Sadly the compiler designers were not (yet) clever enough >> >to make the fastcall regs EAX, EDX, ECX, in that exact order, >> >but even as it stands today.. >> > >> >Swapper: >> > mov eax, ecx >> > bswap >> > xchg eax, edx >> > bswap >> > ret >> > >> > >> >(If you actually link against a binary swapper compiled out of your >> >control with >> >cdecl convention, the argument falls of course, as you must comply with >> >the binary.) >> > >> >Keep up the good work.. >> >Best Regards >> >// Love >

1 0

Video of our ReactOS presentation online
by Colin Finck 19 Oct '14

19 Oct '14

Hi all, As the question usually arises: The video of Daniel's and my ReactOS presentation at Kieler Linux Tage is online: http://youtu.be/oQsKzW_Rx3k Do whatever you want with it ;) This is probably the first ever ReactOS presentation held using ReactOS itself! And it worked like a charm! We also met an author of German news site heise.de there, who wants to publish an article about the current state ReactOS soon. Cheers, Colin

4 6

Re: [ros-dev] [ros-diffs] [akhaldi] 64795: [CMAKE] * Make the minimum required version 2.8. * Remove redundant psdk dependencies. * Tidy up CMake files.
by Thomas Faber 18 Oct '14

18 Oct '14

On 2014-10-18 01:28, akhaldi(a)svn.reactos.org wrote: > [CMAKE] > * Make the minimum required version 2.8. As Víctor just found out the hard way, using target_include_directories makes our minimum version 2.8.11. Should we set that as the minimum to create a more obvious error message? Current error: CMake Error at dll/keyboard/CMakeLists.txt:92 (target_include_directories): Unknown CMake command "target_include_directories".

1 0

Re: [ros-dev] RtlUlonglongByteSwap
by Love Nystrom 16 Oct '14

16 Oct '14

@Timo, @Thomas, @Ged Byte order swappers should always be fastcall for perfomance reasons. They have no need for the benefits of the cdecl call convention. Using cdecl in this case would make the binary code pitifully slow. Think about it for a bit.. Some pseudocode show what I mean: ..CDECL... push hi push lo call Swapper mov dsthi, edx mov dstlo, eax add esp, 4 ... // UINT64 __cdecl Swapper: push ebp mov ebp, esp mov eax, ebp+8 // lo mov eax, ebp+12 // hi bswap xchg eax, edx bswap pop ebp ret ..FASTCALL... mov edx, hi mov eax, lo call Swapper mov dsthi, edx mov dstlo, eax ... // UINT64 __declspec(naked) __fastcall Swapper: bswap xchg eax, edx bswap ret Sadly the compiler designers were not (yet) clever enough to make the fastcall regs EAX, EDX, ECX, in that exact order, but even as it stands today.. Swapper: mov eax, ecx bswap xchg eax, edx bswap ret (If you actually link against a binary swapper compiled out of your control with cdecl convention, the argument falls of course, as you must comply with the binary.) Keep up the good work.. Best Regards // Love

2 1

Re: [ros-dev] [ros-diffs] [tfaber] 64749: [PSDK] - Use macro version of RtlUlonglongByteSwap in winternl.h because using the fastcall version causes stack corruption CORE-8632 #resolve
by Ged Murphy 16 Oct '14

16 Oct '14

There shouldn't really be anything using this header -----Original Message----- From: Ros-diffs [mailto:ros-diffs-bounces@reactos.org] On Behalf Of tfaber(a)svn.reactos.org Sent: 15 October 2014 17:38 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [tfaber] 64749: [PSDK] - Use macro version of RtlUlonglongByteSwap in winternl.h because using the fastcall version causes stack corruption CORE-8632 #resolve Author: tfaber Date: Wed Oct 15 16:38:13 2014 New Revision: 64749 URL: http://svn.reactos.org/svn/reactos?rev=64749&view=rev Log: [PSDK] - Use macro version of RtlUlonglongByteSwap in winternl.h because using the fastcall version causes stack corruption CORE-8632 #resolve Modified: trunk/reactos/include/psdk/winternl.h Modified: trunk/reactos/include/psdk/winternl.h URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/psdk/winternl.h?re… ============================================================================== --- trunk/reactos/include/psdk/winternl.h [iso-8859-1] (original) +++ trunk/reactos/include/psdk/winternl.h [iso-8859-1] Wed Oct 15 16:38:13 2014 @@ -2310,7 +2310,12 @@ BOOLEAN WINAPI RtlTimeToSecondsSince1980(const LARGE_INTEGER *,LPDWORD); BOOL WINAPI RtlTryEnterCriticalSection(RTL_CRITICAL_SECTION *); +#ifdef __REACTOS__ ULONGLONG __fastcall RtlUlonglongByteSwap(ULONGLONG); +#define RtlUlonglongByteSwap(_x) _byteswap_uint64((_x)) #else ULONGLONG +__cdecl RtlUlonglongByteSwap(ULONGLONG); #endif DWORD WINAPI RtlUnicodeStringToAnsiSize(const UNICODE_STRING*); NTSTATUS WINAPI RtlUnicodeStringToAnsiString(PANSI_STRING,PCUNICODE_STRING,BOOLEAN); NTSTATUS WINAPI RtlUnicodeStringToInteger(const UNICODE_STRING *,ULONG,ULONG *);

4 6

Re: [ros-dev] [ros-diffs] [tfaber] 64762: [NPFS] - Don't call RtlEqualUnicodeString (paged code) while holding a spin lock. Powered by Driver Verifier.
by Hermès BÉLUSCA - MAÏTO 16 Oct '14

16 Oct '14

What is the *root* reason for this problem (ok Ive seen in the comment, paged code and holding spin lock, but it doesnt answer my question)? Because Ive looked at our code of RtlEqualUnicodeString and I see that it just calls RtlCompareUnicodeString that in turns just loops over the two memory buffers, checks their contents (and in case we check for char case, calls RtlUpcaseUnicodeChar). And RtlCompareMemory does that, too? What Im missing? Hermès. ------------------------------------------------------------------------- Author: tfaber Date: Thu Oct 16 16:40:13 2014 New Revision: 64762 URL: http://svn.reactos.org/svn/reactos?rev=64762&view=rev Log: [NPFS] - Don't call RtlEqualUnicodeString (paged code) while holding a spin lock. Powered by Driver Verifier. Modified: trunk/reactos/drivers/filesystems/npfs/waitsup.c Modified: trunk/reactos/drivers/filesystems/npfs/waitsup.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/npfs/wa itsup.c?rev=64762&r1=64761&r2=64762&view=diff ============================================================================ == --- trunk/reactos/drivers/filesystems/npfs/waitsup.c [iso-8859-1] (original) +++ trunk/reactos/drivers/filesystems/npfs/waitsup.c [iso-8859-1] Thu Oct 16 16:40:13 2014 @@ -97,6 +97,22 @@ { InitializeListHead(&WaitQueue->WaitList); KeInitializeSpinLock(&WaitQueue->WaitLock); +} + +static +BOOLEAN +NpEqualUnicodeString(IN PCUNICODE_STRING String1, + IN PCUNICODE_STRING String2) +{ + SIZE_T EqualLength; + + if (String1->Length != String2->Length) + return FALSE; + + EqualLength = RtlCompareMemory(String1->Buffer, + String2->Buffer, + String1->Length); + return EqualLength == String1->Length; } NTSTATUS @@ -156,7 +172,8 @@ PipeName.MaximumLength = PipeName.Length; } - if (RtlEqualUnicodeString(&WaitName, &PipeName, FALSE)) + /* Can't use RtlEqualUnicodeString with a spinlock held */ + if (NpEqualUnicodeString(&WaitName, &PipeName)) { /* Found a matching wait. Cancel it */ RemoveEntryList(&WaitIrp->Tail.Overlay.ListEntry);

2 1

Re: [ros-dev] [ros-diffs] [tkreuzer] 64757: [NTOSKRNL] Don't use an uninitialized variable in MmArmAccessFault (Alex, please review). Brought to you by MSVC runtime checks.
by Alex Ionescu 16 Oct '14

16 Oct '14

Wow, does static analyzer really not catch this? Best regards, Alex Ionescu On Wed, Oct 15, 2014 at 3:03 PM, <tkreuzer(a)svn.reactos.org> wrote: > Author: tkreuzer > Date: Wed Oct 15 22:03:50 2014 > New Revision: 64757 > > URL: http://svn.reactos.org/svn/reactos?rev=64757&view=rev > Log: > [NTOSKRNL] > Don't use an uninitialized variable in MmArmAccessFault (Alex, please > review). Brought to you by MSVC runtime checks. > > Modified: > trunk/reactos/ntoskrnl/mm/ARM3/pagfault.c > > Modified: trunk/reactos/ntoskrnl/mm/ARM3/pagfault.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/pagfault.… > > ============================================================================== > --- trunk/reactos/ntoskrnl/mm/ARM3/pagfault.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/mm/ARM3/pagfault.c [iso-8859-1] Wed Oct 15 > 22:03:50 2014 > @@ -1511,7 +1511,7 @@ > NTSTATUS Status; > PMMSUPPORT WorkingSet; > ULONG ProtectionCode; > - PMMVAD Vad; > + PMMVAD Vad = NULL; > PFN_NUMBER PageFrameIndex; > ULONG Color; > BOOLEAN IsSessionAddress; > > >

2 1

Re: [ros-dev] [ros-diffs] [pschweitzer] 64752: [NTFS] Implement NtfsDateTimeToFileTime() which convert epoch time (1970) to Windows time (1601)
by Thomas Faber 15 Oct '14

15 Oct '14

On 2014-10-15 22:23, pschweitzer(a)svn.reactos.org wrote: > +/* See: > + -> http://msdn.microsoft.com/en-us/library/ms724228 > + -> http://bos.asmhackers.net/docs/filesystems/ntfs/standard.html#layout > + */ > +VOID > +NtfsDateTimeToFileTime(ULONGLONG NtfsTime, > + PLARGE_INTEGER SystemTime) > +{ > + > + SystemTime->QuadPart = NtfsTime + 116444736000000000; > +} Doesn't NTFS use FILETIME directly? I thought that's the reason it's called "file time" in the first place. ;) Wikipedia says "Date range: 1 January 1601 – 28 May 60056 (File times are 64-bit numbers counting 100-nanosecond intervals (ten million per second) since 1601, which is 58,000+ years)" and your link doesn't seem to disagree.

2 1

Re: [ros-dev] [ros-diffs] [tfaber] 64695: [ROSAUTOTEST] - DbgPrint expects a format string! ROSTESTS-145 #resolve
by Colin Finck 15 Oct '14

15 Oct '14

tfaber(a)svn.reactos.org wrote: > - DbgPrint(DbgString); > + OutputDebugStringA(DbgString); FYI, we had OutputDebugStringA there in the first place, but I changed it to DbgPrint in r40147. IIRC, output from DbgPrint was directly sent to the debug port while OutputDebugStringA buffers the data first. This is especially bad, when a test crashes the OS and we lose several kilobytes of log data before they are printed out. Probably, a DbgPrint("%s", DbgString) is the better alternative here. - Colin

2 1

Re: [ros-dev] [ros-diffs] [tkreuzer] 64658: [NTDLL] Don't assert that the caller of exported APIs passes correct parameters.
by Alex Ionescu 12 Oct '14

12 Oct '14

Windows does. Why shouldn't we? It's a non-documented API. Best regards, Alex Ionescu On Sat, Oct 11, 2014 at 1:52 AM, <tkreuzer(a)svn.reactos.org> wrote: > Author: tkreuzer > Date: Sat Oct 11 08:52:33 2014 > New Revision: 64658 > > URL: http://svn.reactos.org/svn/reactos?rev=64658&view=rev > Log: > [NTDLL] > Don't assert that the caller of exported APIs passes correct parameters. > > Modified: > trunk/reactos/dll/ntdll/ldr/ldrapi.c > > Modified: trunk/reactos/dll/ntdll/ldr/ldrapi.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/ntdll/ldr/ldrapi.c?rev… > > ============================================================================== > --- trunk/reactos/dll/ntdll/ldr/ldrapi.c [iso-8859-1] (original) > +++ trunk/reactos/dll/ntdll/ldr/ldrapi.c [iso-8859-1] Sat Oct 11 > 08:52:33 2014 > @@ -209,9 +209,6 @@ > /* A normal failure */ > return STATUS_INVALID_PARAMETER_3; > } > - > - /* Do or Do Not. There is no Try */ > - ASSERT((Disposition != NULL) || !(Flags & > LDR_LOCK_LOADER_LOCK_FLAG_TRY_ONLY)); > > /* If the flag is set, make sure we have a valid pointer to use */ > if ((Flags & LDR_LOCK_LOADER_LOCK_FLAG_TRY_ONLY) && !(Disposition)) > > >

3 3

Re: [ros-dev] [ros-diffs] [tfaber] 64665: [NTOS:KE] - Implement KiRaiseSecurityCheckFailure[Handler] to handle int 0x29 (__fastfail). Based on patch by Timo Kreuzer. (Yes, this is a Windows 8 feature. However all it does is...
by Alex Ionescu 12 Oct '14

12 Oct '14

Now improve the LIST_ENTRY Macros to use it :) Best regards, Alex Ionescu On Sat, Oct 11, 2014 at 6:15 AM, <tfaber(a)svn.reactos.org> wrote: > Author: tfaber > Date: Sat Oct 11 13:15:10 2014 > New Revision: 64665 > > URL: http://svn.reactos.org/svn/reactos?rev=64665&view=rev > Log: > [NTOS:KE] > - Implement KiRaiseSecurityCheckFailure[Handler] to handle int 0x29 > (__fastfail). Based on patch by Timo Kreuzer. > (Yes, this is a Windows 8 feature. However all it does is improve the > debugging experience, and we have a need for that) > CORE-8419 > > Modified: > trunk/reactos/include/reactos/mc/bugcodes.mc > trunk/reactos/ntoskrnl/ke/i386/trap.s > trunk/reactos/ntoskrnl/ke/i386/traphdlr.c > > Modified: trunk/reactos/include/reactos/mc/bugcodes.mc > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/include/reactos/mc/bugcode… > > ============================================================================== > --- trunk/reactos/include/reactos/mc/bugcodes.mc [iso-8859-1] > (original) > +++ trunk/reactos/include/reactos/mc/bugcodes.mc [iso-8859-1] Sat > Oct 11 13:15:10 2014 > @@ -1128,7 +1128,7 @@ > Run a system diagnostic utility supplied by your hardware manufacturer. > In particular, run a memory check, and check for faulty or mismatched > memory. Try changing video adapters. > - > + > Disable or remove any newly installed hardware and drivers. Disable or > remove any newly installed software. If you need to use Safe Mode to > remove or disable components, restart your computer, press F8 to select > @@ -1322,7 +1322,7 @@ > SymbolicName=DRIVER_CORRUPTED_EXPOOL > Language=English > A device driver has pool. > - > + > Check to make sure any new hardware or software is properly installed. > If this is a new installation, ask your hardware or software manufacturer > for any ReactOS updates you might need. > @@ -1478,7 +1478,7 @@ > must not contain such items. Usually this is memory being freed. This > is usually caused by a device driver that has not cleaned up properly > before freeing memory. > - > + > If Parameter1 == 1, an attempt was made to queue an executive worker item > with a usermode execution routine. > . > @@ -1570,3 +1570,11 @@ > Language=English > An attempt was made to execute to non-executable memory. > . > + > +MessageId=0x139 > +Severity=Success > +Facility=System > +SymbolicName=KERNEL_SECURITY_CHECK_FAILURE > +Language=English > +A critical kernel security check failed. > +. > > Modified: trunk/reactos/ntoskrnl/ke/i386/trap.s > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/trap.s?re… > > ============================================================================== > --- trunk/reactos/ntoskrnl/ke/i386/trap.s [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ke/i386/trap.s [iso-8859-1] Sat Oct 11 > 13:15:10 2014 > @@ -59,9 +59,11 @@ > idt _KiTrap11, INT_32_DPL0 /* INT 11: Align Check Exception > (#AC) */ > idt _KiTrap0F, INT_32_DPL0 /* INT 12: Machine Check Exception > (#MC)*/ > idt _KiTrap0F, INT_32_DPL0 /* INT 13: SIMD FPU Exception (#XF) > */ > -REPEAT 22 > -idt _KiTrap0F, INT_32_DPL0 /* INT 14-29: UNDEFINED INTERRUPTS > */ > +REPEAT 21 > +idt _KiTrap0F, INT_32_DPL0 /* INT 14-28: UNDEFINED INTERRUPTS > */ > ENDR > +idt _KiRaiseSecurityCheckFailure, INT_32_DPL3 > + /* INT 29: Handler for __fastfail > */ > idt _KiGetTickCount, INT_32_DPL3 /* INT 2A: Get Tick Count Handler > */ > idt _KiCallbackReturn, INT_32_DPL3 /* INT 2B: User-Mode Callback Return > */ > idt _KiRaiseAssertion, INT_32_DPL3 /* INT 2C: Debug Assertion Handler > */ > @@ -113,6 +115,7 @@ > TRAP_ENTRY KiTrap10, KI_PUSH_FAKE_ERROR_CODE > TRAP_ENTRY KiTrap11, KI_PUSH_FAKE_ERROR_CODE > TRAP_ENTRY KiTrap13, KI_PUSH_FAKE_ERROR_CODE > +TRAP_ENTRY KiRaiseSecurityCheckFailure, KI_PUSH_FAKE_ERROR_CODE > TRAP_ENTRY KiGetTickCount, KI_PUSH_FAKE_ERROR_CODE > TRAP_ENTRY KiCallbackReturn, KI_PUSH_FAKE_ERROR_CODE > TRAP_ENTRY KiRaiseAssertion, KI_PUSH_FAKE_ERROR_CODE > > Modified: trunk/reactos/ntoskrnl/ke/i386/traphdlr.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/traphdlr.… > > ============================================================================== > --- trunk/reactos/ntoskrnl/ke/i386/traphdlr.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ke/i386/traphdlr.c [iso-8859-1] Sat Oct 11 > 13:15:10 2014 > @@ -1462,6 +1462,46 @@ > > VOID > FASTCALL > +KiRaiseSecurityCheckFailureHandler(IN PKTRAP_FRAME TrapFrame) > +{ > + /* Save trap frame */ > + KiEnterTrap(TrapFrame); > + > + /* Decrement EIP to point to the INT29 instruction (2 bytes, not 1 > like INT3) */ > + TrapFrame->Eip -= 2; > + > + /* Check if this is a user trap */ > + if (KiUserTrap(TrapFrame)) > + { > + /* Dispatch exception to user mode */ > + KiDispatchException1Args(STATUS_STACK_BUFFER_OVERRUN, > + TrapFrame->Eip, > + TrapFrame->Ecx, > + TrapFrame); > + } > + else > + { > + EXCEPTION_RECORD ExceptionRecord; > + > + /* Bugcheck the system */ > + ExceptionRecord.ExceptionCode = STATUS_STACK_BUFFER_OVERRUN; > + ExceptionRecord.ExceptionFlags = EXCEPTION_NONCONTINUABLE; > + ExceptionRecord.ExceptionRecord = NULL; > + ExceptionRecord.ExceptionAddress = (PVOID)TrapFrame->Eip; > + ExceptionRecord.NumberParameters = 1; > + ExceptionRecord.ExceptionInformation[0] = TrapFrame->Ecx; > + > + KeBugCheckWithTf(KERNEL_SECURITY_CHECK_FAILURE, > + TrapFrame->Ecx, > + (ULONG_PTR)TrapFrame, > + (ULONG_PTR)&ExceptionRecord, > + 0, > + TrapFrame); > + } > +} > + > +VOID > +FASTCALL > KiGetTickCountHandler(IN PKTRAP_FRAME TrapFrame) > { > UNIMPLEMENTED_DBGBREAK(); > > >

2 2

Re: [ros-dev] [ros-diffs] [tkreuzer] 64591: [NTOSKRNL] - Improve the random address base code in MiCreatePebOrTeb to actually make sense and not rely on retarded hacks implicitly hardcoding the PEB size in pages into the ra...
by Alex Ionescu 12 Oct '14

12 Oct '14

Where't the unit test proving your 'improved' algorithm matches XP SP2/SRV03 SP1? Best regards, Alex Ionescu On Tue, Oct 7, 2014 at 5:31 PM, <tkreuzer(a)svn.reactos.org> wrote: > Author: tkreuzer > Date: Wed Oct 8 00:31:35 2014 > New Revision: 64591 > > URL: http://svn.reactos.org/svn/reactos?rev=64591&view=rev > Log: > [NTOSKRNL] > - Improve the random address base code in MiCreatePebOrTeb to actually > make sense and not rely on retarded hacks implicitly hardcoding the PEB > size in pages into the random value generation. > > Modified: > trunk/reactos/ntoskrnl/mm/ARM3/procsup.c > > Modified: trunk/reactos/ntoskrnl/mm/ARM3/procsup.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/procsup.c… > > ============================================================================== > --- trunk/reactos/ntoskrnl/mm/ARM3/procsup.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/mm/ARM3/procsup.c [iso-8859-1] Wed Oct 8 > 00:31:35 2014 > @@ -48,13 +48,13 @@ > NTAPI > MiCreatePebOrTeb(IN PEPROCESS Process, > IN ULONG Size, > - OUT PULONG_PTR Base) > + OUT PULONG_PTR BaseAddress) > { > PETHREAD Thread = PsGetCurrentThread(); > PMMVAD_LONG Vad; > NTSTATUS Status; > - ULONG RandomCoeff; > - ULONG_PTR StartAddress, EndAddress; > + ULONG_PTR HighestAddress, RandomBase; > + ULONG AlignedSize; > LARGE_INTEGER CurrentTime; > TABLE_SEARCH_RESULT Result = TableFoundNode; > PMMADDRESS_NODE Parent; > @@ -83,25 +83,30 @@ > /* Check if this is a PEB creation */ > if (Size == sizeof(PEB)) > { > - /* Start at the highest valid address */ > - StartAddress = (ULONG_PTR)MM_HIGHEST_VAD_ADDRESS + 1; > - > - /* Select the random coefficient */ > + /* Create a random value to select one page in a 64k region */ > KeQueryTickCount(&CurrentTime); > - CurrentTime.LowPart &= ((64 * _1KB) >> PAGE_SHIFT) - 1; > - if (CurrentTime.LowPart <= 1) CurrentTime.LowPart = 2; > - RandomCoeff = CurrentTime.LowPart << PAGE_SHIFT; > - > - /* Select the highest valid address minus the random coefficient > */ > - StartAddress -= RandomCoeff; > - EndAddress = StartAddress + ROUND_TO_PAGES(Size) - 1; > + CurrentTime.LowPart &= (_64K / PAGE_SIZE) - 1; > + > + /* Calculate a random base address */ > + RandomBase = (ULONG_PTR)MM_HIGHEST_VAD_ADDRESS + 1; > + RandomBase -= CurrentTime.LowPart << PAGE_SHIFT; > + > + /* Make sure the base address is not too high */ > + AlignedSize = ROUND_TO_PAGES(Size); > + if ((RandomBase + AlignedSize) > > (ULONG_PTR)MM_HIGHEST_VAD_ADDRESS + 1) > + { > + RandomBase = (ULONG_PTR)MM_HIGHEST_VAD_ADDRESS + 1 - > AlignedSize; > + } > + > + /* Calculate the highest allowed address */ > + HighestAddress = RandomBase + AlignedSize - 1; > > /* Try to find something below the random upper margin */ > Result = MiFindEmptyAddressRangeDownTree(ROUND_TO_PAGES(Size), > - EndAddress, > + HighestAddress, > PAGE_SIZE, > &Process->VadRoot, > - Base, > + BaseAddress, > &Parent); > } > > @@ -113,7 +118,7 @@ > > (ULONG_PTR)MM_HIGHEST_VAD_ADDRESS, > PAGE_SIZE, > &Process->VadRoot, > - Base, > + BaseAddress, > &Parent); > /* Bail out, if still nothing free was found */ > if (Result == TableFoundNode) > @@ -125,12 +130,12 @@ > } > > /* Validate that it came from the VAD ranges */ > - ASSERT(*Base >= (ULONG_PTR)MI_LOWEST_VAD_ADDRESS); > + ASSERT(*BaseAddress >= (ULONG_PTR)MI_LOWEST_VAD_ADDRESS); > > /* Build the rest of the VAD now */ > - Vad->StartingVpn = (*Base) >> PAGE_SHIFT; > - Vad->EndingVpn = ((*Base) + Size - 1) >> PAGE_SHIFT; > - Vad->u3.Secured.StartVpn = *Base; > + Vad->StartingVpn = (*BaseAddress) >> PAGE_SHIFT; > + Vad->EndingVpn = ((*BaseAddress) + Size - 1) >> PAGE_SHIFT; > + Vad->u3.Secured.StartVpn = *BaseAddress; > Vad->u3.Secured.EndVpn = (Vad->EndingVpn << PAGE_SHIFT) | (PAGE_SIZE > - 1); > Vad->u1.Parent = NULL; > > @@ -146,7 +151,7 @@ > Vad->ControlArea = NULL; // For Memory-Area hack > Vad->FirstPrototypePte = NULL; > DPRINT("VAD: %p\n", Vad); > - DPRINT("Allocated PEB/TEB at: 0x%p for %16s\n", *Base, > Process->ImageFileName); > + DPRINT("Allocated PEB/TEB at: 0x%p for %16s\n", *BaseAddress, > Process->ImageFileName); > MiInsertNode(&Process->VadRoot, (PVOID)Vad, Parent, Result); > > /* Release the working set */ > > >

2 2

Re: [ros-dev] [ros-diffs] [jgardou] 64537: [NTOS/MM] - Do not assert in case of stack overflow, just let the page fault handler raise STATUS_STACK_OVERFLOW
by Alex Ionescu 12 Oct '14

12 Oct '14

The ASSERT is there because of the missing functionality. Please see the comment just above. Best regards, Alex Ionescu On Sun, Oct 5, 2014 at 2:57 AM, <jgardou(a)svn.reactos.org> wrote: > Author: jgardou > Date: Sun Oct 5 09:57:02 2014 > New Revision: 64537 > > URL: http://svn.reactos.org/svn/reactos?rev=64537&view=rev > Log: > [NTOS/MM] > - Do not assert in case of stack overflow, just let the page fault > handler raise STATUS_STACK_OVERFLOW > > Modified: > trunk/reactos/ntoskrnl/mm/ARM3/pagfault.c > > Modified: trunk/reactos/ntoskrnl/mm/ARM3/pagfault.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/pagfault.… > > ============================================================================== > --- trunk/reactos/ntoskrnl/mm/ARM3/pagfault.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/mm/ARM3/pagfault.c [iso-8859-1] Sun Oct 5 > 09:57:02 2014 > @@ -82,7 +82,6 @@ > { > /* We don't -- Windows would try to make this guard page valid > now */ > DPRINT1("Close to our death...\n"); > - ASSERT(FALSE); > return STATUS_STACK_OVERFLOW; > } > > > >

2 4

Re: [ros-dev] [ros-diffs] [tkreuzer] 64593: [NTOSKRNL] Modify MiCreatePebOrTeb to use MiInsertVadEx instead of doing everything "by hand". No, this does not "change Windows behavior". The TEB creation works exactly as befor...
by Alex Ionescu 11 Oct '14

11 Oct '14

Why do you think PEB creation cannot fail in the first place? Best regards, Alex Ionescu On Tue, Oct 7, 2014 at 5:31 PM, <tkreuzer(a)svn.reactos.org> wrote: > Author: tkreuzer > Date: Wed Oct 8 00:31:49 2014 > New Revision: 64593 > > URL: http://svn.reactos.org/svn/reactos?rev=64593&view=rev > Log: > [NTOSKRNL] > Modify MiCreatePebOrTeb to use MiInsertVadEx instead of doing everything > "by hand". No, this does not "change Windows behavior". The TEB creation > works exactly as before, and the only difference in the PEB creation is > that if the first attempt fails, we will no longer try again from the top > of the address space. But since this cannot fail in the first place, at > least not due to the VA range not being free, another attempt would be > pointless anyway! > > Modified: > trunk/reactos/ntoskrnl/mm/ARM3/procsup.c > > Modified: trunk/reactos/ntoskrnl/mm/ARM3/procsup.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/procsup.c… > > ============================================================================== > --- trunk/reactos/ntoskrnl/mm/ARM3/procsup.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/mm/ARM3/procsup.c [iso-8859-1] Wed Oct 8 > 00:31:49 2014 > @@ -50,14 +50,11 @@ > IN ULONG Size, > OUT PULONG_PTR BaseAddress) > { > - PETHREAD Thread = PsGetCurrentThread(); > PMMVAD_LONG Vad; > NTSTATUS Status; > ULONG_PTR HighestAddress, RandomBase; > ULONG AlignedSize; > LARGE_INTEGER CurrentTime; > - TABLE_SEARCH_RESULT Result = TableFoundNode; > - PMMADDRESS_NODE Parent; > > /* Allocate a VAD */ > Vad = ExAllocatePoolWithTag(NonPagedPool, sizeof(MMVAD_LONG), 'ldaV'); > @@ -70,6 +67,7 @@ > Vad->u.VadFlags.PrivateMemory = TRUE; > Vad->u.VadFlags.Protection = MM_READWRITE; > Vad->u.VadFlags.NoChange = TRUE; > + Vad->u1.Parent = NULL; > > /* Setup the secondary flags to make it a secured, writable, long VAD > */ > Vad->u2.LongFlags2 = 0; > @@ -77,10 +75,11 @@ > Vad->u2.VadFlags2.LongVad = TRUE; > Vad->u2.VadFlags2.ReadOnly = FALSE; > > - /* Lock the process address space */ > - KeAcquireGuardedMutex(&Process->AddressCreationLock); > + Vad->ControlArea = NULL; // For Memory-Area hack > + Vad->FirstPrototypePte = NULL; > > /* Check if this is a PEB creation */ > + ASSERT(sizeof(TEB) != sizeof(PEB)); > if (Size == sizeof(PEB)) > { > /* Create a random value to select one page in a 64k region */ > @@ -100,68 +99,27 @@ > > /* Calculate the highest allowed address */ > HighestAddress = RandomBase + AlignedSize - 1; > - > - /* Try to find something below the random upper margin */ > - Result = MiFindEmptyAddressRangeDownTree(ROUND_TO_PAGES(Size), > - HighestAddress, > - PAGE_SIZE, > - &Process->VadRoot, > - BaseAddress, > - &Parent); > - } > - > - /* Check for success. TableFoundNode means nothing free. */ > - if (Result == TableFoundNode) > - { > - /* For TEBs, or if a PEB location couldn't be found, scan the VAD > root */ > - Result = MiFindEmptyAddressRangeDownTree(ROUND_TO_PAGES(Size), > - > (ULONG_PTR)MM_HIGHEST_VAD_ADDRESS, > - PAGE_SIZE, > - &Process->VadRoot, > - BaseAddress, > - &Parent); > - /* Bail out, if still nothing free was found */ > - if (Result == TableFoundNode) > - { > - KeReleaseGuardedMutex(&Process->AddressCreationLock); > - ExFreePoolWithTag(Vad, 'ldaV'); > - return STATUS_NO_MEMORY; > - } > - } > - > - /* Validate that it came from the VAD ranges */ > - ASSERT(*BaseAddress >= (ULONG_PTR)MI_LOWEST_VAD_ADDRESS); > - > - /* Build the rest of the VAD now */ > - Vad->StartingVpn = (*BaseAddress) >> PAGE_SHIFT; > - Vad->EndingVpn = ((*BaseAddress) + Size - 1) >> PAGE_SHIFT; > - Vad->u3.Secured.StartVpn = *BaseAddress; > - Vad->u3.Secured.EndVpn = (Vad->EndingVpn << PAGE_SHIFT) | (PAGE_SIZE > - 1); > - Vad->u1.Parent = NULL; > - > - /* FIXME: Should setup VAD bitmap */ > - Status = STATUS_SUCCESS; > - > - /* Pretend as if we own the working set */ > - MiLockProcessWorkingSetUnsafe(Process, Thread); > - > - /* Insert the VAD */ > - ASSERT(Vad->EndingVpn >= Vad->StartingVpn); > - Process->VadRoot.NodeHint = Vad; > - Vad->ControlArea = NULL; // For Memory-Area hack > - Vad->FirstPrototypePte = NULL; > - DPRINT("VAD: %p\n", Vad); > - DPRINT("Allocated PEB/TEB at: 0x%p for %16s\n", *BaseAddress, > Process->ImageFileName); > - MiInsertNode(&Process->VadRoot, (PVOID)Vad, Parent, Result); > - > - /* Release the working set */ > - MiUnlockProcessWorkingSetUnsafe(Process, Thread); > - > - /* Release the address space lock */ > - KeReleaseGuardedMutex(&Process->AddressCreationLock); > - > - /* Return the status */ > - return Status; > + } > + else > + { > + HighestAddress = (ULONG_PTR)MM_HIGHEST_VAD_ADDRESS; > + } > + > + *BaseAddress = 0; > + Status = MiInsertVadEx((PMMVAD)Vad, > + BaseAddress, > + BYTES_TO_PAGES(Size), > + HighestAddress, > + PAGE_SIZE, > + MEM_TOP_DOWN); > + if (!NT_SUCCESS(Status)) > + { > + ExFreePoolWithTag(Vad, 'ldaV'); > + return STATUS_NO_MEMORY; > + } > + > + /* Success */ > + return STATUS_SUCCESS; > } > > VOID > > >

3 2

Re: [ros-dev] [ros-diffs] [tkreuzer] 64595: [NTOSKRNL] Fix a status code
by Alex Ionescu 11 Oct '14

11 Oct '14

Would be great to have JIRA issues associated to such fixes as well as a test proving the change is correct. For example, are you merely assuming that you should return "STATUS_NO_MEMORY", or do you know for a fact that STATUS_CONFLICTING_ADDRESSES is the wrong code here? Best regards, Alex Ionescu On Wed, Oct 8, 2014 at 12:38 AM, <tkreuzer(a)svn.reactos.org> wrote: > Author: tkreuzer > Date: Wed Oct 8 07:38:56 2014 > New Revision: 64595 > > URL: http://svn.reactos.org/svn/reactos?rev=64595&view=rev > Log: > [NTOSKRNL] > Fix a status code > > Modified: > trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c > > Modified: trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c… > > ============================================================================== > --- trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c [iso-8859-1] Wed Oct 8 > 07:38:56 2014 > @@ -261,7 +261,7 @@ > { > DPRINT1("Not enough free space to insert this VAD node!\n"); > KeReleaseGuardedMutex(&CurrentProcess->AddressCreationLock); > - return STATUS_CONFLICTING_ADDRESSES; > + return STATUS_NO_MEMORY; > } > > ASSERT(StartingAddress != 0); > > >

2 1

Re: [ros-dev] [ros-diffs] [tkreuzer] 64589: [NTOSKRNL] Implement MiInsertVadEx, replacing duplicated code from NtAllocateVirtualMemory and MiMapViewOfDataSection
by Alex Ionescu 11 Oct '14

11 Oct '14

I think it would be really great that instead of combining functions together for "removing code duplication" and not even bothering to think why there's a reason why the code was duplicated, people would work on actual improvements like Jerome or Pierre, instead of re-factoring code that works just to make it 'simpler'. Especially since this introduced a few bugs which had to be later fixed. There's a million bugs in ReactOS, including in the memory manager, so fixing those seems to make more sense than refactoring. Just my 2 cents. Best regards, Alex Ionescu On Tue, Oct 7, 2014 at 5:31 PM, <tkreuzer(a)svn.reactos.org> wrote: > Author: tkreuzer > Date: Wed Oct 8 00:31:17 2014 > New Revision: 64589 > > URL: http://svn.reactos.org/svn/reactos?rev=64589&view=rev > Log: > [NTOSKRNL] > Implement MiInsertVadEx, replacing duplicated code from > NtAllocateVirtualMemory and MiMapViewOfDataSection > > Modified: > trunk/reactos/ntoskrnl/mm/ARM3/miarm.h > trunk/reactos/ntoskrnl/mm/ARM3/section.c > trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c > trunk/reactos/ntoskrnl/mm/ARM3/virtual.c > > Modified: trunk/reactos/ntoskrnl/mm/ARM3/miarm.h > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/miarm.h?r… > > ============================================================================== > --- trunk/reactos/ntoskrnl/mm/ARM3/miarm.h [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/mm/ARM3/miarm.h [iso-8859-1] Wed Oct 8 > 00:31:17 2014 > @@ -2144,6 +2144,16 @@ > IN PEPROCESS Process > ); > > +NTSTATUS > +NTAPI > +MiInsertVadEx( > + _Inout_ PMMVAD Vad, > + _In_ ULONG_PTR *BaseAddress, > + _In_ SIZE_T ViewSize, > + _In_ ULONG_PTR HighestAddress, > + _In_ ULONG_PTR Alignment, > + _In_ ULONG AllocationType); > + > VOID > NTAPI > MiInsertBasedSection( > > Modified: trunk/reactos/ntoskrnl/mm/ARM3/section.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/section.c… > > ============================================================================== > --- trunk/reactos/ntoskrnl/mm/ARM3/section.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/mm/ARM3/section.c [iso-8859-1] Wed Oct 8 > 00:31:17 2014 > @@ -1252,9 +1252,7 @@ > IN ULONG AllocationType) > { > PMMVAD_LONG Vad; > - PETHREAD Thread = PsGetCurrentThread(); > - PMMSUPPORT AddressSpace; > - ULONG_PTR StartAddress, EndingAddress; > + ULONG_PTR StartAddress; > ULONG_PTR ViewSizeInPages; > PSUBSECTION Subsection; > PSEGMENT Segment; > @@ -1263,8 +1261,6 @@ > ULONG QuotaCharge = 0, QuotaExcess = 0; > PMMPTE PointerPte, LastPte; > MMPTE TempPte; > - PMMADDRESS_NODE Parent; > - TABLE_SEARCH_RESULT Result; > DPRINT("Mapping ARM3 data section\n"); > > /* Get the segment for this section */ > @@ -1361,6 +1357,7 @@ > > /* Write all the data required in the VAD for handling a fault */ > Vad->ControlArea = ControlArea; > + Vad->u.VadFlags.CommitCharge = 0; > Vad->u.VadFlags.Protection = ProtectionMask; > Vad->u2.VadFlags2.FileOffset = (ULONG)(SectionOffset->QuadPart >> 16); > Vad->u2.VadFlags2.Inherit = (InheritDisposition == ViewShare); > @@ -1437,100 +1434,23 @@ > StartAddress = 0; > } > > - /* Lock the address space and make sure the process is alive */ > - AddressSpace = MmGetCurrentAddressSpace(); > - MmLockAddressSpace(AddressSpace); > - if (Process->VmDeleted) > - { > - MmUnlockAddressSpace(AddressSpace); > - ExFreePoolWithTag(Vad, 'ldaV'); > - DPRINT1("The process is dying\n"); > - return STATUS_PROCESS_IS_TERMINATING; > - } > - > - /* Did the caller specify an address? */ > - if (StartAddress == 0) > - { > - /* ARM3 does not support these flags yet */ > - ASSERT(Process->VmTopDown == 0); > - ASSERT(ZeroBits == 0); > - > - /* Which way should we search? */ > - if (AllocationType & MEM_TOP_DOWN) > - { > - /* No, find an address top-down */ > - Result = MiFindEmptyAddressRangeDownTree(*ViewSize, > - > (ULONG_PTR)MM_HIGHEST_VAD_ADDRESS, > - _64K, > - &Process->VadRoot, > - &StartAddress, > - &Parent); > - } > - else > - { > - /* No, find an address bottom-up */ > - Result = MiFindEmptyAddressRangeInTree(*ViewSize, > - _64K, > - &Process->VadRoot, > - &Parent, > - &StartAddress); > - } > - > - /* Check if we found a suitable location */ > - if (Result == TableFoundNode) > - { > - DPRINT1("Not enough free space to insert this section!\n"); > - MmUnlockAddressSpace(AddressSpace); > - MiDereferenceControlArea(ControlArea); > - ExFreePoolWithTag(Vad, 'ldaV'); > - return STATUS_CONFLICTING_ADDRESSES; > - } > - > - /* Get the ending address, which is the last piece we need for > the VAD */ > - EndingAddress = StartAddress + (ViewSizeInPages * PAGE_SIZE) - 1; > - } > - else > - { > - /* Get the ending address, which is the last piece we need for > the VAD */ > - EndingAddress = StartAddress + (ViewSizeInPages * PAGE_SIZE) - 1; > - > - /* Make sure it doesn't conflict with an existing allocation */ > - Result = MiCheckForConflictingNode(StartAddress >> PAGE_SHIFT, > - EndingAddress >> PAGE_SHIFT, > - &Process->VadRoot, > - &Parent); > - if (Result == TableFoundNode) > - { > - DPRINT1("Conflict with SEC_BASED or manually based > section!\n"); > - MmUnlockAddressSpace(AddressSpace); > - MiDereferenceControlArea(ControlArea); > - ExFreePoolWithTag(Vad, 'ldaV'); > - return STATUS_CONFLICTING_ADDRESSES; > - } > - } > - > - /* Now set the VAD address */ > - Vad->StartingVpn = StartAddress >> PAGE_SHIFT; > - Vad->EndingVpn = EndingAddress >> PAGE_SHIFT; > - > - /* Pretend as if we own the working set */ > - MiLockProcessWorkingSetUnsafe(Process, Thread); > - > /* Insert the VAD */ > - Process->VadRoot.NodeHint = Vad; > - MiInsertNode(&Process->VadRoot, (PVOID)Vad, Parent, Result); > - > - /* Release the working set */ > - MiUnlockProcessWorkingSetUnsafe(Process, Thread); > - > - /* Unlock the address space */ > - MmUnlockAddressSpace(AddressSpace); > + Status = MiInsertVadEx((PMMVAD)Vad, > + &StartAddress, > + ViewSizeInPages * PAGE_SIZE, > + MAXULONG_PTR >> ZeroBits, > + MM_VIRTMEM_GRANULARITY, > + AllocationType); > + if (!NT_SUCCESS(Status)) > + { > + return Status; > + } > > /* Windows stores this for accounting purposes, do so as well */ > if (!Segment->u2.FirstMappedVa) Segment->u2.FirstMappedVa = > (PVOID)StartAddress; > > /* Finally, let the caller know where, and for what size, the view > was mapped */ > - *ViewSize = (ULONG_PTR)EndingAddress - (ULONG_PTR)StartAddress + 1; > + *ViewSize = ViewSizeInPages * PAGE_SIZE; > *BaseAddress = (PVOID)StartAddress; > DPRINT("Start and region: 0x%p, 0x%p\n", *BaseAddress, *ViewSize); > return STATUS_SUCCESS; > > Modified: trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c… > > ============================================================================== > --- trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c [iso-8859-1] Wed Oct 8 > 00:31:17 2014 > @@ -193,6 +193,138 @@ > MiInsertNode(&Process->VadRoot, (PVOID)Vad, Parent, Result); > } > > +NTSTATUS > +NTAPI > +MiInsertVadEx( > + _Inout_ PMMVAD Vad, > + _In_ ULONG_PTR *BaseAddress, > + _In_ SIZE_T ViewSize, > + _In_ ULONG_PTR HighestAddress, > + _In_ ULONG_PTR Alignment, > + _In_ ULONG AllocationType) > +{ > + ULONG_PTR StartingAddress, EndingAddress; > + PEPROCESS CurrentProcess; > + PETHREAD CurrentThread; > + TABLE_SEARCH_RESULT Result; > + PMMADDRESS_NODE Parent; > + > + /* Align the view size to pages */ > + ViewSize = ALIGN_UP_BY(ViewSize, PAGE_SIZE); > + > + /* Get the current process */ > + CurrentProcess = PsGetCurrentProcess(); > + > + /* Acquire the address creation lock and make sure the process is > alive */ > + KeAcquireGuardedMutex(&CurrentProcess->AddressCreationLock); > + if (CurrentProcess->VmDeleted) > + { > + KeReleaseGuardedMutex(&CurrentProcess->AddressCreationLock); > + DPRINT1("The process is dying\n"); > + return STATUS_PROCESS_IS_TERMINATING; > + } > + > + /* Did the caller specify an address? */ > + if (*BaseAddress == 0) > + { > + /* Make sure HighestAddress is not too large */ > + HighestAddress = min(HighestAddress, > (ULONG_PTR)MM_HIGHEST_VAD_ADDRESS); > + > + /* Which way should we search? */ > + if ((AllocationType & MEM_TOP_DOWN) || CurrentProcess->VmTopDown) > + { > + /* Find an address top-down */ > + Result = MiFindEmptyAddressRangeDownTree(ViewSize, > + HighestAddress, > + Alignment, > + > &CurrentProcess->VadRoot, > + &StartingAddress, > + &Parent); > + } > + else > + { > + /* Find an address bottom-up */ > + Result = MiFindEmptyAddressRangeInTree(ViewSize, > + Alignment, > + > &CurrentProcess->VadRoot, > + &Parent, > + &StartingAddress); > + } > + > + /* Get the ending address, which is the last piece we need for > the VAD */ > + EndingAddress = StartingAddress + ViewSize - 1; > + > + /* Check if we found a suitable location */ > + if ((Result == TableFoundNode) || (EndingAddress > > HighestAddress)) > + { > + DPRINT1("Not enough free space to insert this VAD node!\n"); > + KeReleaseGuardedMutex(&CurrentProcess->AddressCreationLock); > + return STATUS_CONFLICTING_ADDRESSES; > + } > + > + ASSERT(StartingAddress != 0); > + ASSERT(StartingAddress < (ULONG_PTR)HighestAddress); > + ASSERT(EndingAddress > StartingAddress); > + } > + else > + { > + /* Calculate the starting and ending address */ > + StartingAddress = ALIGN_DOWN_BY(*BaseAddress, Alignment); > + EndingAddress = StartingAddress + ViewSize - 1; > + > + /* Make sure it doesn't conflict with an existing allocation */ > + Result = MiCheckForConflictingNode(StartingAddress >> PAGE_SHIFT, > + EndingAddress >> PAGE_SHIFT, > + &CurrentProcess->VadRoot, > + &Parent); > + if (Result == TableFoundNode) > + { > + DPRINT1("Given address conflicts with existing node\n"); > + KeReleaseGuardedMutex(&CurrentProcess->AddressCreationLock); > + return STATUS_CONFLICTING_ADDRESSES; > + } > + } > + > + /* Now set the VAD address */ > + Vad->StartingVpn = StartingAddress >> PAGE_SHIFT; > + Vad->EndingVpn = EndingAddress >> PAGE_SHIFT; > + > + /* Check if the VAD is to be secured */ > + if (Vad->u2.VadFlags2.OneSecured) > + { > + /* This *must* be a long VAD! */ > + ASSERT(Vad->u2.VadFlags2.LongVad); > + > + /* Yeah this is retarded, I didn't invent it! */ > + ((PMMVAD_LONG)Vad)->u3.Secured.StartVpn = StartingAddress; > + ((PMMVAD_LONG)Vad)->u3.Secured.EndVpn = EndingAddress; > + } > + > + /* Lock the working set */ > + CurrentThread = PsGetCurrentThread(); > + MiLockProcessWorkingSetUnsafe(CurrentProcess, CurrentThread); > + > + /* Insert the VAD */ > + CurrentProcess->VadRoot.NodeHint = Vad; > + MiInsertNode(&CurrentProcess->VadRoot, (PVOID)Vad, Parent, Result); > + > + /* Release the working set */ > + MiUnlockProcessWorkingSetUnsafe(CurrentProcess, CurrentThread); > + > + /* Update the process' virtual size, and peak virtual size */ > + CurrentProcess->VirtualSize += ViewSize; > + if (CurrentProcess->VirtualSize > CurrentProcess->PeakVirtualSize) > + { > + CurrentProcess->PeakVirtualSize = CurrentProcess->VirtualSize; > + } > + > + /* Unlock the address space */ > + KeReleaseGuardedMutex(&CurrentProcess->AddressCreationLock); > + > + *BaseAddress = StartingAddress; > + return STATUS_SUCCESS; > +} > + > VOID > NTAPI > MiInsertBasedSection(IN PSECTION Section) > > Modified: trunk/reactos/ntoskrnl/mm/ARM3/virtual.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/virtual.c… > > ============================================================================== > --- trunk/reactos/ntoskrnl/mm/ARM3/virtual.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/mm/ARM3/virtual.c [iso-8859-1] Wed Oct 8 > 00:31:17 2014 > @@ -4304,12 +4304,12 @@ > { > PEPROCESS Process; > PMEMORY_AREA MemoryArea; > - PFN_NUMBER PageCount; > PMMVAD Vad = NULL, FoundVad; > NTSTATUS Status; > PMMSUPPORT AddressSpace; > PVOID PBaseAddress; > - ULONG_PTR PRegionSize, StartingAddress, EndingAddress, HighestAddress; > + ULONG_PTR PRegionSize, StartingAddress, EndingAddress; > + ULONG_PTR HighestAddress = (ULONG_PTR)MM_HIGHEST_VAD_ADDRESS; > PEPROCESS CurrentProcess = PsGetCurrentProcess(); > KPROCESSOR_MODE PreviousMode = KeGetPreviousMode(); > PETHREAD CurrentThread = PsGetCurrentThread(); > @@ -4319,7 +4319,6 @@ > MMPTE TempPte; > PMMPTE PointerPte, PointerPde, LastPte; > TABLE_SEARCH_RESULT Result; > - PMMADDRESS_NODE Parent; > PAGED_CODE(); > > /* Check for valid Zero bits */ > @@ -4544,7 +4543,6 @@ > // This is a blind commit, all we need is the region size > // > PRegionSize = ROUND_TO_PAGES(PRegionSize); > - PageCount = BYTES_TO_PAGES(PRegionSize); > EndingAddress = 0; > StartingAddress = 0; > > @@ -4563,13 +4561,6 @@ > goto FailPathNoLock; > } > } > - else > - { > - // > - // Use the highest VAD address as maximum > - // > - HighestAddress = (ULONG_PTR)MM_HIGHEST_VAD_ADDRESS; > - } > } > else > { > @@ -4579,8 +4570,8 @@ > // fall based on the aligned address and the passed in region > size > // > EndingAddress = ((ULONG_PTR)PBaseAddress + PRegionSize - 1) | > (PAGE_SIZE - 1); > - StartingAddress = ROUND_DOWN((ULONG_PTR)PBaseAddress, _64K); > - PageCount = BYTES_TO_PAGES(EndingAddress - StartingAddress); > + PRegionSize = EndingAddress + 1 - > ROUND_DOWN((ULONG_PTR)PBaseAddress, _64K); > + StartingAddress = (ULONG_PTR)PBaseAddress; > } > > // > @@ -4594,7 +4585,7 @@ > goto FailPathNoLock; > } > > - Vad->u.LongFlags = 0; > + RtlZeroMemory(Vad, sizeof(MMVAD_LONG)); > if (AllocationType & MEM_COMMIT) Vad->u.VadFlags.MemCommit = 1; > Vad->u.VadFlags.Protection = ProtectionMask; > Vad->u.VadFlags.PrivateMemory = 1; > @@ -4602,124 +4593,24 @@ > Vad->ControlArea = NULL; // For Memory-Area hack > > // > - // Lock the address space and make sure the process isn't already > dead > - // > - AddressSpace = MmGetCurrentAddressSpace(); > - MmLockAddressSpace(AddressSpace); > - if (Process->VmDeleted) > - { > - Status = STATUS_PROCESS_IS_TERMINATING; > - goto FailPath; > - } > - > - // > - // Did we have a base address? If no, find a valid address that > is 64KB > - // aligned in the VAD tree. Otherwise, make sure that the address > range > - // which was passed in isn't already conflicting with an existing > address > - // range. > - // > - if (!PBaseAddress) > - { > - /* Which way should we search? */ > - if ((AllocationType & MEM_TOP_DOWN) || Process->VmTopDown) > - { > - /* Find an address top-down */ > - Result = MiFindEmptyAddressRangeDownTree(PRegionSize, > - HighestAddress, > - _64K, > - > &Process->VadRoot, > - &StartingAddress, > - &Parent); > - } > - else > - { > - /* Find an address bottom-up */ > - Result = MiFindEmptyAddressRangeInTree(PRegionSize, > - _64K, > - &Process->VadRoot, > - &Parent, > - &StartingAddress); > - } > - > - if (Result == TableFoundNode) > - { > - Status = STATUS_NO_MEMORY; > - goto FailPath; > - } > - > - // > - // Now we know where the allocation ends. Make sure it > doesn't end up > - // somewhere in kernel mode. > - // > - ASSERT(StartingAddress != 0); > - ASSERT(StartingAddress < (ULONG_PTR)MM_HIGHEST_USER_ADDRESS); > - EndingAddress = (StartingAddress + PRegionSize - 1) | > (PAGE_SIZE - 1); > - ASSERT(EndingAddress > StartingAddress); > - if (EndingAddress > HighestAddress) > - { > - Status = STATUS_NO_MEMORY; > - goto FailPath; > - } > - } > - else > - { > - /* Make sure it doesn't conflict with an existing allocation > */ > - Result = MiCheckForConflictingNode(StartingAddress >> > PAGE_SHIFT, > - EndingAddress >> > PAGE_SHIFT, > - &Process->VadRoot, > - &Parent); > - if (Result == TableFoundNode) > - { > - // > - // The address specified is in conflict! > - // > - Status = STATUS_CONFLICTING_ADDRESSES; > - goto FailPath; > - } > - } > - > - // > - // Write out the VAD fields for this allocation > - // > - Vad->StartingVpn = StartingAddress >> PAGE_SHIFT; > - Vad->EndingVpn = EndingAddress >> PAGE_SHIFT; > - > - // > - // FIXME: Should setup VAD bitmap > - // > - Status = STATUS_SUCCESS; > - > - // > - // Lock the working set and insert the VAD into the process VAD > tree > - // > - MiLockProcessWorkingSetUnsafe(Process, CurrentThread); > - Process->VadRoot.NodeHint = Vad; > - MiInsertNode(&Process->VadRoot, (PVOID)Vad, Parent, Result); > - MiUnlockProcessWorkingSetUnsafe(Process, CurrentThread); > - > - // > - // Make sure the actual region size is at least as big as the > - // requested region size and update the value > - // > - ASSERT(PRegionSize <= (EndingAddress + 1 - StartingAddress)); > - PRegionSize = (EndingAddress + 1 - StartingAddress); > - > - // > - // Update the virtual size of the process, and if this is now the > highest > - // virtual size we have ever seen, update the peak virtual size > to reflect > - // this. > - // > - Process->VirtualSize += PRegionSize; > - if (Process->VirtualSize > Process->PeakVirtualSize) > - { > - Process->PeakVirtualSize = Process->VirtualSize; > - } > - > - // > - // Release address space and detach and dereference the target > process if > + // Insert the VAD > + // > + Status = MiInsertVadEx(Vad, > + &StartingAddress, > + PRegionSize, > + HighestAddress, > + MM_VIRTMEM_GRANULARITY, > + AllocationType); > + if (!NT_SUCCESS(Status)) > + { > + DPRINT1("Failed to insert the VAD!\n"); > + goto FailPathNoLock; > + } > + > + // > + // Detach and dereference the target process if > // it was different from the current process > // > - MmUnlockAddressSpace(AddressSpace); > if (Attached) KeUnstackDetachProcess(&ApcState); > if (ProcessHandle != NtCurrentProcess()) > ObDereferenceObject(Process); > > > >

2 1

Re: [ros-dev] [ros-diffs] [aandrejevic] 64656: [FAST486] Update the copyright year. Implement the first batch of FPU instructions. These are still experimental.
by Timo Kreuzer 11 Oct '14

11 Oct '14

Seriously? Am 11.10.2014 01:07, schrieb aandrejevic(a)svn.reactos.org: > + /* Count the leading zeros */ > + while (!(Data->Mantissa & (1 << (63 - LeadingZeros)))) LeadingZeros++;

1 0

Re: [ros-dev] EPIC: ReactOS@Samsung Galaxy S III mini
by Love Nystrom 10 Oct '14

10 Oct '14

@Timo Yes of course.. It was a fleeting idea it would be cute to run on a computer 5x10x1 cm. ;-) I didn't realize the ARM branch was in poor condition though. But it stands to reason.. Porting Intel assembly to ARM assembly and considering all the archiectural differences is/would be a gargantuan job. Keep up the good work.. Love On 2014-10-09 19.00, ros-dev-request(a)reactos.org wrote: > Guys, I don't want to spoil your hopes, but native ARM support is far > away from being usable. It doesn't even compile. There is no native ARM! > And there won't be for ages, until we have a really knowledged ARM > hacker, with the kernel and hardware knowledge of Alex, who would invest > a huge lot of time into getting it up and running. So unless we want to > hire someone fulltime for at least half a year, who would probably like > to be paid a normal software engineer wage, which we cannot afford, we > won't have ARM support anytime soon. > x64 is a much more reasonable task, mostly lacking stuff in Mm. > And that will still require a lot of work. > And I have more than enough other things to do

1 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 64617: [NTFS] - Add a directory entry into FCB which will be a copy of the $FILE_NAME attribute of the FILE record. Though, it won't contain the name itself (in the FCB instead), so k...
by Thomas Faber 08 Oct '14

08 Oct '14

On 2014-10-08 21:32, pschweitzer(a)svn.reactos.org wrote: > + MftRecord = ExAllocatePoolWithTag(NonPagedPool, > + Vcb->NtfsInfo.BytesPerFileRecord, > + TAG_NTFS); > + if (MftRecord == NULL) > + { > + return NULL; > + } > + > + if (!NT_SUCCESS(ReadFileRecord(Vcb, NTFS_FILE_ROOT, MftRecord))) > + { > + return NULL; > + } > + > + FileName = GetFileNameFromRecord(MftRecord); > + if (!FileName) > + { > + return NULL; > + } > > Fcb = NtfsCreateFCB(L"\\", Vcb); > - > -// memset(Fcb->entry.Filename, ' ', 11); > - > -// Fcb->Entry.DataLengthL = Vcb->CdInfo.RootSize; > -// Fcb->Entry.ExtentLocationL = Vcb->CdInfo.RootStart; > -// Fcb->Entry.FileFlags = 0x02; // FILE_ATTRIBUTE_DIRECTORY; > + if (!Fcb) > + { > + return NULL; > + } These failure cases look like they're all at least leaking MftRecord :p

2 1

Re: [ros-dev] [ros-diffs] [jgardou] 64525: [KERNEL32] - Always allocate a guard page at the bottom of the stack. It doesn't depend on it being reserved or committed, it just has to be here.
by Alex Ionescu 06 Oct '14

06 Oct '14

Hi, This code changes Windows behavior. Best regards, Alex Ionescu On Sat, Oct 4, 2014 at 1:25 PM, <jgardou(a)svn.reactos.org> wrote: > Author: jgardou > Date: Sat Oct 4 20:25:35 2014 > New Revision: 64525 > > URL: http://svn.reactos.org/svn/reactos?rev=64525&view=rev > Log: > [KERNEL32] > - Always allocate a guard page at the bottom of the stack. > It doesn't depend on it being reserved or committed, it just has to be > here. > > Modified: > trunk/reactos/dll/win32/kernel32/client/utils.c > > Modified: trunk/reactos/dll/win32/kernel32/client/utils.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/… > > ============================================================================== > --- trunk/reactos/dll/win32/kernel32/client/utils.c [iso-8859-1] > (original) > +++ trunk/reactos/dll/win32/kernel32/client/utils.c [iso-8859-1] Sat > Oct 4 20:25:35 2014 > @@ -358,7 +358,6 @@ > NTSTATUS Status; > PIMAGE_NT_HEADERS Headers; > ULONG_PTR Stack; > - BOOLEAN UseGuard; > ULONG PageSize, Dummy, AllocationGranularity; > SIZE_T StackReserveHeader, StackCommitHeader, GuardPageSize, > GuaranteedStackCommit; > DPRINT("BaseCreateStack (hProcess: %p, Max: %lx, Current: %lx)\n", > @@ -426,18 +425,6 @@ > /* Update the Stack Position */ > Stack += StackReserve - StackCommit; > > - /* Check if we will need a guard page */ > - if (StackReserve > StackCommit) > - { > - Stack -= PageSize; > - StackCommit += PageSize; > - UseGuard = TRUE; > - } > - else > - { > - UseGuard = FALSE; > - } > - > /* Allocate memory for the stack */ > Status = NtAllocateVirtualMemory(hProcess, > (PVOID*)&Stack, > @@ -457,25 +444,21 @@ > InitialTeb->StackLimit = (PVOID)Stack; > > /* Create a guard page */ > - if (UseGuard) > - { > - /* Set the guard page */ > - GuardPageSize = PAGE_SIZE; > - Status = NtProtectVirtualMemory(hProcess, > - (PVOID*)&Stack, > - &GuardPageSize, > - PAGE_GUARD | PAGE_READWRITE, > - &Dummy); > - if (!NT_SUCCESS(Status)) > - { > - DPRINT1("Failure to set guard page\n"); > - return Status; > - } > - > - /* Update the Stack Limit keeping in mind the Guard Page */ > - InitialTeb->StackLimit = > (PVOID)((ULONG_PTR)InitialTeb->StackLimit + > - GuardPageSize); > - } > + GuardPageSize = PageSize; > + Status = NtProtectVirtualMemory(hProcess, > + (PVOID*)&Stack, > + &GuardPageSize, > + PAGE_GUARD | PAGE_READWRITE, > + &Dummy); > + if (!NT_SUCCESS(Status)) > + { > + DPRINT1("Failure to set guard page\n"); > + return Status; > + } > + > + /* Update the Stack Limit keeping in mind the Guard Page */ > + InitialTeb->StackLimit = (PVOID)((ULONG_PTR)InitialTeb->StackLimit + > + GuardPageSize); > > /* We are done! */ > return STATUS_SUCCESS; > > >

1 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 64449: [DLLEXPORT_TEST] Fix a typo
by Thomas Faber 02 Oct '14

02 Oct '14

On 2014-10-02 09:30, tkreuzer(a)svn.reactos.org wrote: > -add_executable(dllimport_test > +add_library(dllimport_test > dllimport_framedyn.cpp) Isn't the point of this test to check for linker errors?

1 0

Re: [ros-dev] [ros-diffs] [jgardou] 64396: [NTOS/CM] - Add NtQueryKey(KeyNameInformation) implementation. CORE-8581 #resolve
by Timo Kreuzer 01 Oct '14

01 Oct '14

A few remarks: - There should be only one SEH, not for performance, but since the KeyNameInfo->NameLength = 0; needs to be in SEH as well - The function duplicates a lot of code from CmpConstructName, possibly even incomplete - There was already an implementation in the kernel-fun branch Unrelated to your code, just something I spotted in that file: - CmpQueryKeyData cannot be wrapped in SEH (it would cause reference leaks on exception), but is wrapped in SEH in CmEnumerateKey - CmpQueryKeyData does not use SEH, but is called with user mode pointers from CmQueryKey Timo Am 29.09.2014 18:27, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Mon Sep 29 16:27:16 2014 > New Revision: 64396 > > URL: http://svn.reactos.org/svn/reactos?rev=64396&view=rev > Log: > [NTOS/CM] > - Add NtQueryKey(KeyNameInformation) implementation. > CORE-8581 #resolve > >

1 0

Re: [ros-dev] [ros-diffs] [jgardou] 64392: [NDK] - Fix KEY_NAME_INFORMATION structure
by Timo Kreuzer 29 Sep '14

29 Sep '14

Wow, ... IMO we should autogenerate a header for usermode stuff from XDK, instead of using NDK. Am 29.09.2014 15:32, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Mon Sep 29 13:32:44 2014 > New Revision: 64392 > > URL: http://svn.reactos.org/svn/reactos?rev=64392&view=rev > Log: > [NDK] > - Fix KEY_NAME_INFORMATION structure > > Modified: > trunk/reactos/include/ndk/cmtypes.h > > Modified: trunk/reactos/include/ndk/cmtypes.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/ndk/cmtypes.h?rev=… > ============================================================================== > --- trunk/reactos/include/ndk/cmtypes.h [iso-8859-1] (original) > +++ trunk/reactos/include/ndk/cmtypes.h [iso-8859-1] Mon Sep 29 13:32:44 2014 > @@ -296,6 +296,7 @@ > > typedef struct _KEY_NAME_INFORMATION > { > + ULONG NameLength; > WCHAR Name[1]; > } KEY_NAME_INFORMATION, *PKEY_NAME_INFORMATION; > > > >

1 0

EPIC: ReactOS@Samsung Galaxy S III mini
by Alexander Rechitskiy 29 Sep '14

29 Sep '14

3 2

Re: [ros-dev] [ros-diffs] [jgardou] 64311: [WIN32K] - Simplify IntRemoveWindowProp - Complain loudly if a NULL list entry sneaks into a window property list. CORE-8562
by Jérôme Gardou 26 Sep '14

26 Sep '14

Uh oh, seems like I screwed up these two. The spec2def part of this commit should indeed belong to r64312. Le 26/09/2014 14:43, jgardou(a)svn.reactos.org a écrit : > Author: jgardou > Date: Fri Sep 26 12:43:12 2014 > New Revision: 64311 > > URL: http://svn.reactos.org/svn/reactos?rev=64311&view=rev > Log: > [WIN32K] > - Simplify IntRemoveWindowProp > - Complain loudly if a NULL list entry sneaks into a window property list. > CORE-8562 > > Modified: > trunk/reactos/tools/spec2def/spec2def.c > trunk/reactos/win32ss/user/ntuser/prop.c > > Modified: trunk/reactos/tools/spec2def/spec2def.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/spec2def/spec2def.c?… > ============================================================================== > --- trunk/reactos/tools/spec2def/spec2def.c [iso-8859-1] (original) > +++ trunk/reactos/tools/spec2def/spec2def.c [iso-8859-1] Fri Sep 26 12:43:12 2014 > @@ -38,6 +38,7 @@ > typedef int (*PFNOUTLINE)(FILE *, EXPORT *); > int gbMSComp = 0; > int gbImportLib = 0; > +int gbTracing = 0; > int giArch = ARCH_X86; > char *pszArchString = "i386"; > char *pszArchString2; > @@ -52,6 +53,9 @@ > FL_STUB = 2, > FL_NONAME = 4, > FL_ORDINAL = 8, > + FL_NORELAY = 16, > + FL_RET64 = 32, > + FL_REGISTER = 64, > }; > > enum > @@ -161,52 +165,126 @@ > OutputHeader_stub(FILE *file) > { > fprintf(file, "/* This file is autogenerated, do not edit. */\n\n" > - "#include <stubs.h>\n\n"); > + "#include <stubs.h>\n"); > + > + if (gbTracing) > + { > + fprintf(file, "#include <wine/debug.h>\n"); > + fprintf(file, "#include <inttypes.h>\n"); > + fprintf(file, "WINE_DECLARE_DEBUG_CHANNEL(relay);\n"); > + } > + > + fprintf(file, "\n"); > } > > int > OutputLine_stub(FILE *file, EXPORT *pexp) > { > int i; > + int bRelay = 0; > + int bInPrototype; > > if (pexp->nCallingConvention != CC_STUB && > - (pexp->uFlags & FL_STUB) == 0) return 0; > - > - fprintf(file, "int "); > - if ((giArch == ARCH_X86) && > - pexp->nCallingConvention == CC_STDCALL) > - { > - fprintf(file, "__stdcall "); > - } > - > - /* Check for C++ */ > - if (pexp->strName.buf[0] == '?') > - { > - fprintf(file, "stub_function%d(", pexp->nNumber); > + (pexp->uFlags & FL_STUB) == 0) > + { > + /* Only relay trace stdcall C functions */ > + if (!gbTracing || (pexp->nCallingConvention != CC_STDCALL) > + || (pexp->uFlags & FL_NORELAY) > + || (pexp->strName.buf[0] == '?')) > + { > + return 0; > + } > + bRelay = 1; > + } > + > + /* Declare the "real" function */ > + if (bRelay) > + { > + fprintf(file, "extern "); > + bInPrototype = 1; > + } > + > + do > + { > + if (pexp->uFlags & FL_REGISTER) > + { > + /* FIXME: Not sure this is right */ > + fprintf(file, "void "); > + } > + else if (pexp->uFlags & FL_RET64) > + { > + fprintf(file, "__int64 "); > + } > + else > + { > + fprintf(file, "int "); > + } > + > + if ((giArch == ARCH_X86) && > + pexp->nCallingConvention == CC_STDCALL) > + { > + fprintf(file, "__stdcall "); > + } > + > + /* Check for C++ */ > + if (pexp->strName.buf[0] == '?') > + { > + fprintf(file, "stub_function%d(", pexp->nNumber); > + } > + else > + { > + if (!bRelay || bInPrototype) > + fprintf(file, "%.*s(", pexp->strName.len, pexp->strName.buf); > + else > + fprintf(file, "$relaytrace$%.*s(", pexp->strName.len, pexp->strName.buf); > + } > + > + for (i = 0; i < pexp->nArgCount; i++) > + { > + if (i != 0) fprintf(file, ", "); > + switch (pexp->anArgs[i]) > + { > + case ARG_LONG: fprintf(file, "long"); break; > + case ARG_PTR: fprintf(file, "void*"); break; > + case ARG_STR: fprintf(file, "char*"); break; > + case ARG_WSTR: fprintf(file, "wchar_t*"); break; > + case ARG_DBL: fprintf(file, "double"); break; > + case ARG_INT64 : fprintf(file, "__int64"); break; > + case ARG_INT128 : fprintf(file, "__int128"); break; > + case ARG_FLOAT: fprintf(file, "float"); break; > + } > + fprintf(file, " a%d", i); > + } > + > + if (bInPrototype) > + { > + fprintf(file, ");\n\n"); > + } > + } while (bInPrototype--); > + > + if (!bRelay) > + { > + fprintf(file, ")\n{\n\tDbgPrint(\"WARNING: calling stub %.*s(", > + pexp->strName.len, pexp->strName.buf); > } > else > { > - fprintf(file, "%.*s(", pexp->strName.len, pexp->strName.buf); > - } > - > - for (i = 0; i < pexp->nArgCount; i++) > - { > - if (i != 0) fprintf(file, ", "); > - switch (pexp->anArgs[i]) > - { > - case ARG_LONG: fprintf(file, "long"); break; > - case ARG_PTR: fprintf(file, "void*"); break; > - case ARG_STR: fprintf(file, "char*"); break; > - case ARG_WSTR: fprintf(file, "wchar_t*"); break; > - case ARG_DBL: > - case ARG_INT64 : fprintf(file, "__int64"); break; > - case ARG_INT128 : fprintf(file, "__int128"); break; > - case ARG_FLOAT: fprintf(file, "float"); break; > - } > - fprintf(file, " a%d", i); > - } > - fprintf(file, ")\n{\n\tDbgPrint(\"WARNING: calling stub %.*s(", > - pexp->strName.len, pexp->strName.buf); > + fprintf(file, ")\n{\n"); > + if (pexp->uFlags & FL_REGISTER) > + { > + /* No return value */ > + } > + else if (pexp->uFlags & FL_RET64) > + { > + fprintf(file, "\t__int64 retval;\n"); > + } > + else > + { > + fprintf(file, "\tint retval;\n"); > + } > + fprintf(file, "\tif(TRACE_ON(relay))\n\t\tDPRINTF(\"%s: %.*s(", > + pszDllName, pexp->strName.len, pexp->strName.buf); > + } > > for (i = 0; i < pexp->nArgCount; i++) > { > @@ -246,8 +324,42 @@ > { > fprintf(file, "\t__wine_spec_unimplemented_stub(\"%s\", __FUNCTION__);\n", pszDllName); > } > - > - fprintf(file, "\treturn 0;\n}\n\n"); > + else if (bRelay) > + { > + if (pexp->uFlags & FL_REGISTER) > + { > + fprintf(file,"\t"); > + } > + else > + { > + fprintf(file, "\tretval = "); > + } > + fprintf(file, "%.*s(", pexp->strName.len, pexp->strName.buf); > + > + for (i = 0; i < pexp->nArgCount; i++) > + { > + if (i != 0) fprintf(file, ", "); > + fprintf(file, "a%d", i); > + } > + fprintf(file, ");\n"); > + } > + > + if (!bRelay) > + fprintf(file, "\treturn 0;\n}\n\n"); > + else if ((pexp->uFlags & FL_REGISTER) == 0) > + { > + if (pexp->uFlags & FL_RET64) > + { > + fprintf(file, "\tif(TRACE_ON(relay))\n\t\t(\"%s: %.*s: retval = %%\"PRIx64\"\\n\", retval);\n", > + pszDllName, pexp->strName.len, pexp->strName.buf); > + } > + else > + { > + fprintf(file, "\tTRACE_(relay)(\"%.*s: retval = 0x%%lx\\n\", retval);\n", > + pexp->strName.len, pexp->strName.buf); > + } > + fprintf(file, "\treturn retval;\n}\n\n"); > + } > > return 1; > } > @@ -458,11 +570,18 @@ > /* C++ stubs are forwarded to C stubs */ > fprintf(fileDest, "=stub_function%d", pexp->nNumber); > } > + else if (gbTracing && ((pexp->uFlags & FL_NORELAY) == 0) && (pexp->nCallingConvention == CC_STDCALL) && > + (pexp->strName.buf[0] != '?')) > + { > + /* Redirect it to the relay-tracing trampoline */ > + fprintf(fileDest, "=$relaytrace$%.*s", pexp->strName.len, pexp->strName.buf); > + } > } > > void > OutputLine_def_GCC(FILE *fileDest, EXPORT *pexp) > { > + int bTracing = 0; > /* Print the function name, with decoration for export libs */ > PrintName(fileDest, pexp, &pexp->strName, gbImportLib); > DbgPrint("Generating def line for '%.*s'\n", pexp->strName.len, pexp->strName.buf); > @@ -482,6 +601,19 @@ > { > /* C++ stubs are forwarded to C stubs */ > fprintf(fileDest, "=stub_function%d", pexp->nNumber); > + } > + else if (gbTracing && ((pexp->uFlags & FL_NORELAY) == 0) && (pexp->nCallingConvention == CC_STDCALL) && > + (pexp->strName.buf[0] != '?')) > + { > + /* Redirect it to the relay-tracing trampoline */ > + char buf[256]; > + STRING strTarget; > + fprintf(fileDest, "="); > + sprintf(buf, "$relaytrace$%.*s", pexp->strName.len, pexp->strName.buf); > + strTarget.buf = buf; > + strTarget.len = pexp->strName.len + 12; > + PrintName(fileDest, pexp, &strTarget, 1); > + bTracing = 1; > } > > /* Special handling for stdcall and fastcall */ > @@ -500,7 +632,7 @@ > fprintf(fileDest, "==%.*s", pexp->strName.len, pexp->strName.buf); > } > } > - else if (!pexp->strTarget.buf) > + else if ((!pexp->strTarget.buf) && !(bTracing)) > { > /* Write a forwarder to the actual decorated symbol */ > fprintf(fileDest, "="); > @@ -694,11 +826,17 @@ > { > exp.uFlags |= FL_STUB; > } > - else if (CompareToken(pc, "-norelay") || > - CompareToken(pc, "-register") || > - CompareToken(pc, "-ret64")) > - { > - /* silently ignore these */ > + else if (CompareToken(pc, "-norelay")) > + { > + exp.uFlags |= FL_NORELAY; > + } > + else if (CompareToken(pc, "-ret64")) > + { > + exp.uFlags |= FL_RET64; > + } > + else if (CompareToken(pc, "-register")) > + { > + exp.uFlags |= FL_REGISTER; > } > else > { > @@ -862,6 +1000,9 @@ > fprintf(stderr, "error: line %d, additional tokens after ')'\n", nLine); > return -17; > } > + > + /* Don't relay-trace forwarded functions */ > + exp.uFlags |= FL_NORELAY; > } > else > { > @@ -886,16 +1027,17 @@ > > void usage(void) > { > - printf("syntax: spec2pdef [<options> ...] <spec file>\n" > + printf("syntax: spec2def [<options> ...] <spec file>\n" > "Possible options:\n" > - " -h --help prints this screen\n" > - " -l=<file> generates an asm lib stub\n" > - " -d=<file> generates a def file\n" > - " -s=<file> generates a stub file\n" > - " --ms msvc compatibility\n" > - " -n=<name> name of the dll\n" > - " --implib generate a def file for an import library\n" > - " -a=<arch> Set architecture to <arch>. (i386, x86_64, arm)\n"); > + " -h --help prints this screen\n" > + " -l=<file> generates an asm lib stub\n" > + " -d=<file> generates a def file\n" > + " -s=<file> generates a stub file\n" > + " --ms msvc compatibility\n" > + " -n=<name> name of the dll\n" > + " --implib generate a def file for an import library\n" > + " -a=<arch> Set architecture to <arch>. (i386, x86_64, arm)\n" > + " --with-tracing generates wine-like \"+relay\" trace trampolines. (necessitates -s)\n"); > } > > int main(int argc, char *argv[]) > @@ -945,6 +1087,15 @@ > { > gbMSComp = 1; > } > + else if ((strcasecmp(argv[i], "--with-tracing") == 0)) > + { > + if (!pszStubFileName) > + { > + fprintf(stderr, "Error: cannot use --with-tracing without -s option.\n"); > + return -1; > + } > + gbTracing = 1; > + } > else if (argv[i][1] == 'a' && argv[i][2] == '=') > { > pszArchString = argv[i] + 3; > > Modified: trunk/reactos/win32ss/user/ntuser/prop.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/prop.c… > ============================================================================== > --- trunk/reactos/win32ss/user/ntuser/prop.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/user/ntuser/prop.c [iso-8859-1] Fri Sep 26 12:43:12 2014 > @@ -19,9 +19,18 @@ > int i; > > ListEntry = Window->PropListHead.Flink; > + > for (i = 0; i < Window->PropListItems; i++ ) > { > Property = CONTAINING_RECORD(ListEntry, PROPERTY, PropListEntry); > + > + if (ListEntry == NULL) > + { > + ERR("Corrupted (or uninitialized?) property list for window %p. Prop count %d. Atom %d.\n", > + Window, Window->PropListItems, Atom); > + return NULL; > + } > + > if (Property->Atom == Atom) > { > return(Property); > @@ -84,16 +93,14 @@ > { > PLIST_ENTRY ListEntry; > PPROPERTY Property; > - int i, Count = Window->PropListItems; > - > - ListEntry = Window->PropListHead.Flink; > - for (i = 0; i < Count; i++ ) > - { > - Property = CONTAINING_RECORD(ListEntry, PROPERTY, PropListEntry); > - ListEntry = ListEntry->Flink; > - RemoveEntryList(&Property->PropListEntry); > - UserHeapFree(Property); > - Window->PropListItems--; > + > + while (!IsListEmpty(&Window->PropListHead)) > + { > + ListEntry = Window->PropListHead.Flink; > + Property = CONTAINING_RECORD(ListEntry, PROPERTY, PropListEntry); > + RemoveEntryList(&Property->PropListEntry); > + UserHeapFree(Property); > + Window->PropListItems--; > } > return; > } > >

1 0

Re: [ros-dev] Video of our ReactOS presentation online
by Daniel Reimer 25 Sep '14

25 Sep '14

As PDF in Foxit Reader. But yeah ^^ Von Samsung Mobile gesendet <div>-------- Ursprüngliche Nachricht --------</div><div>Von: Hermès BÉLUSCA - MAÏTO <hermes.belusca(a)sfr.fr> </div><div>Datum:24.09.2014 20:13 (GMT+01:00) </div><div>An: 'ReactOS Development List' <ros-dev(a)reactos.org> </div><div>Cc: </div><div>Betreff: Re: [ros-dev] Video of our ReactOS presentation online </div><div> </div>Also, were you actually running your powerpoint presentation *in* ROS ?! :D De : Ros-dev [mailto:ros-dev-bounces@reactos.org] De la part de Hermès BÉLUSCA - MAÏTO Envoyé : mercredi 24 septembre 2014 19:37 À : 'ReactOS Development List' Objet : Re: [ros-dev] Video of our ReactOS presentation online Wow !! 43 minuten of video ^^ H. De : Ros-dev [mailto:ros-dev-bounces@reactos.org] De la part de Colin Finck Envoyé : mardi 23 septembre 2014 22:17 À : ros-dev(a)reactos.org Objet : [ros-dev] Video of our ReactOS presentation online Hi all, As the question usually arises: The video of Daniel's and my ReactOS presentation at Kieler Linux Tage is online: http://youtu.be/oQsKzW_Rx3k Do whatever you want with it ;) This is probably the first ever ReactOS presentation held using ReactOS itself! And it worked like a charm! We also met an author of German news site heise.de there, who wants to publish an article about the current state ReactOS soon. Cheers, Colin

1 0

Status Meeting (September 2014)
by Aleksey Bragin 24 Sep '14

24 Sep '14

Hello, Let me invite you to the monthly status meeting taking place 25th of September, 19:00 UTC. If there are any proposals regarding moving the meeting date/time - please send them today. IRC service will only be started shortly before the meeting. Your participation passwords and server address will be emailed to you shortly before the meeting starts, and they are going to be different once again as they are not stored in any database. Hopefully it's not much of inconvenience. If someone still is not getting passwords sent before a meeting - please email Pierre before the meeting started to get one. Please send agenda proposals to me before the meeting, so that we can start with a proposed agenda. Proposed agenda points so far: - Agile missing in Jira (looks like an incompatible version) - new on-demand builders (Clang, VC, x64, arm, branch, patch) - testbot on a win 2003 machine Let me know if any of those is already resolved. Thanks! Regards, Aleksey Bragin

2 1

Re: [ros-dev] [ros-diffs] [jgardou] 64176: [GDI32] - Fix up values got from win32k in GetOutlineTextMetrics and do not fail if the provided buffersize is only sizeof(OUTLINETEXTMETRICW). CORE-8507 #resolve
by Timo Kreuzer 17 Sep '14

17 Sep '14

Am 17.09.2014 11:54, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Wed Sep 17 09:54:14 2014 > New Revision: 64176 > > URL: http://svn.reactos.org/svn/reactos?rev=64176&view=rev > Log: > [GDI32] > - Fix up values got from win32k in GetOutlineTextMetrics and do not fail if the provided buffersize is only sizeof(OUTLINETEXTMETRICW). > CORE-8507 #resolve > > Modified: > trunk/reactos/win32ss/gdi/gdi32/objects/font.c > > Modified: trunk/reactos/win32ss/gdi/gdi32/objects/font.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/gdi32/objects/… > ============================================================================== > --- trunk/reactos/win32ss/gdi/gdi32/objects/font.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/gdi32/objects/font.c [iso-8859-1] Wed Sep 17 09:54:14 2014 > @@ -9,8 +9,19 @@ > > #include <precomp.h> > > +#include <math.h> > + > #define NDEBUG > #include <debug.h> > + > +/* Rounds a floating point number to integer. The world-to-viewport > + * transformation process is done in floating point internally. This function > + * is then used to round these coordinates to integer values. > + */ > +static __inline INT GDI_ROUND(FLOAT val) > +{ > + return (int)floor(val + 0.5); > +} roundf() is the appropriate function here. The older MS crt headers don't have the *round*() functions, but VS 2013 headers seem to have them (according MSDN). I propose adding them inside some #ifdef, instead of reimplementing them in different places. For the other functions: strange coding style. Is this taken from wine?

2 1

Topics for next meeting
by Timo Kreuzer 16 Sep '14

16 Sep '14

Hi, I'd like to propose some topics for the next meeting: - Agile missing in Jira (looks like an incompatible version) - new on-demand builders (Clang, VC, x64, arm, branch, patch) - testbot on a win 2003 machine Timo

3 2

Re: [ros-dev] [ros-diffs] [akhaldi] 64151: [XDK][DDK] * Handle the rest of cases about the order of pragma and symbol declaration.
by Jérôme Gardou 14 Sep '14

14 Sep '14

This breaks KDGDB compilation (and most probable KDCOM too if one would want to compile it using GCC) drivers/base/kdgdb/gdb_send.c:77: référence indéfinie vers « __imp__KdDebuggerNotPresent » Le 14/09/2014 17:49, akhaldi(a)svn.reactos.org a écrit : > Author: akhaldi > Date: Sun Sep 14 15:49:35 2014 > New Revision: 64151 > > URL: http://svn.reactos.org/svn/reactos?rev=64151&view=rev > Log: > [XDK][DDK] > * Handle the rest of cases about the order of pragma and symbol declaration. > > Modified: > trunk/reactos/include/ddk/ntddk.h > trunk/reactos/include/ddk/ntifs.h > trunk/reactos/include/ddk/wdm.h > trunk/reactos/include/xdk/fsrtlfuncs.h > trunk/reactos/include/xdk/haltypes.h > trunk/reactos/include/xdk/kdfuncs.h > trunk/reactos/include/xdk/ketypes.h > trunk/reactos/include/xdk/mmtypes.h > trunk/reactos/include/xdk/ntifs.template.h > > Modified: trunk/reactos/include/ddk/ntddk.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/ddk/ntddk.h?rev=64… > ============================================================================== > --- trunk/reactos/include/ddk/ntddk.h [iso-8859-1] (original) > +++ trunk/reactos/include/ddk/ntddk.h [iso-8859-1] Sun Sep 14 15:49:35 2014 > @@ -1670,8 +1670,8 @@ > extern HAL_DISPATCH HalDispatchTable; > #define HALDISPATCH (&HalDispatchTable) > #else > +__CREATE_NTOS_DATA_IMPORT_ALIAS(HalDispatchTable) > extern PHAL_DISPATCH HalDispatchTable; > -__CREATE_NTOS_DATA_IMPORT_ALIAS(HalDispatchTable) > #define HALDISPATCH HalDispatchTable > #endif > > > Modified: trunk/reactos/include/ddk/ntifs.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/ddk/ntifs.h?rev=64… > ============================================================================== > --- trunk/reactos/include/ddk/ntifs.h [iso-8859-1] (original) > +++ trunk/reactos/include/ddk/ntifs.h [iso-8859-1] Sun Sep 14 15:49:35 2014 > @@ -8396,8 +8396,8 @@ > extern const UCHAR * const FsRtlLegalAnsiCharacterArray; > #define LEGAL_ANSI_CHARACTER_ARRAY FsRtlLegalAnsiCharacterArray > #else > +__CREATE_NTOS_DATA_IMPORT_ALIAS(FsRtlLegalAnsiCharacterArray) > extern const UCHAR * const *FsRtlLegalAnsiCharacterArray; > -__CREATE_NTOS_DATA_IMPORT_ALIAS(FsRtlLegalAnsiCharacterArray) > #define LEGAL_ANSI_CHARACTER_ARRAY (*FsRtlLegalAnsiCharacterArray) > #endif > > @@ -10993,8 +10993,8 @@ > extern PUSHORT NlsOemLeadByteInfo; > #define NLS_OEM_LEAD_BYTE_INFO NlsOemLeadByteInfo > #else > +__CREATE_NTOS_DATA_IMPORT_ALIAS(NlsOemLeadByteInfo) > extern PUSHORT *NlsOemLeadByteInfo; > -__CREATE_NTOS_DATA_IMPORT_ALIAS(NlsOemLeadByteInfo) > #define NLS_OEM_LEAD_BYTE_INFO (*NlsOemLeadByteInfo) > #endif > > > Modified: trunk/reactos/include/ddk/wdm.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/ddk/wdm.h?rev=6415… > ============================================================================== > --- trunk/reactos/include/ddk/wdm.h [iso-8859-1] (original) > +++ trunk/reactos/include/ddk/wdm.h [iso-8859-1] Sun Sep 14 15:49:35 2014 > @@ -1661,8 +1661,8 @@ > #elif (NTDDI_VERSION >= NTDDI_WINXP) > extern NTSYSAPI CCHAR KeNumberProcessors; > #else > +__CREATE_NTOS_DATA_IMPORT_ALIAS(KeNumberProcessors) > extern PCCHAR KeNumberProcessors; > -__CREATE_NTOS_DATA_IMPORT_ALIAS(KeNumberProcessors) > #endif > > > @@ -1815,8 +1815,8 @@ > } MM_SYSTEMSIZE; > > #ifndef _NTSYSTEM_ > +__CREATE_NTOS_DATA_IMPORT_ALIAS(Mm64BitPhysicalAddress) > extern PBOOLEAN Mm64BitPhysicalAddress; > -__CREATE_NTOS_DATA_IMPORT_ALIAS(Mm64BitPhysicalAddress) > #endif > extern NTKERNELAPI PVOID MmBadPointer; > > > Modified: trunk/reactos/include/xdk/fsrtlfuncs.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/xdk/fsrtlfuncs.h?r… > ============================================================================== > --- trunk/reactos/include/xdk/fsrtlfuncs.h [iso-8859-1] (original) > +++ trunk/reactos/include/xdk/fsrtlfuncs.h [iso-8859-1] Sun Sep 14 15:49:35 2014 > @@ -1584,8 +1584,8 @@ > extern const UCHAR * const FsRtlLegalAnsiCharacterArray; > #define LEGAL_ANSI_CHARACTER_ARRAY FsRtlLegalAnsiCharacterArray > #else > +__CREATE_NTOS_DATA_IMPORT_ALIAS(FsRtlLegalAnsiCharacterArray) > extern const UCHAR * const *FsRtlLegalAnsiCharacterArray; > -__CREATE_NTOS_DATA_IMPORT_ALIAS(FsRtlLegalAnsiCharacterArray) > #define LEGAL_ANSI_CHARACTER_ARRAY (*FsRtlLegalAnsiCharacterArray) > #endif > > > Modified: trunk/reactos/include/xdk/haltypes.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/xdk/haltypes.h?rev… > ============================================================================== > --- trunk/reactos/include/xdk/haltypes.h [iso-8859-1] (original) > +++ trunk/reactos/include/xdk/haltypes.h [iso-8859-1] Sun Sep 14 15:49:35 2014 > @@ -273,8 +273,8 @@ > extern HAL_DISPATCH HalDispatchTable; > #define HALDISPATCH (&HalDispatchTable) > #else > +__CREATE_NTOS_DATA_IMPORT_ALIAS(HalDispatchTable) > extern PHAL_DISPATCH HalDispatchTable; > -__CREATE_NTOS_DATA_IMPORT_ALIAS(HalDispatchTable) > #define HALDISPATCH HalDispatchTable > #endif > > > Modified: trunk/reactos/include/xdk/kdfuncs.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/xdk/kdfuncs.h?rev=… > ============================================================================== > --- trunk/reactos/include/xdk/kdfuncs.h [iso-8859-1] (original) > +++ trunk/reactos/include/xdk/kdfuncs.h [iso-8859-1] Sun Sep 14 15:49:35 2014 > @@ -125,11 +125,11 @@ > extern BOOLEAN KdDebuggerNotPresent; > #define KD_DEBUGGER_NOT_PRESENT KdDebuggerNotPresent > #else > +__CREATE_NTOS_DATA_IMPORT_ALIAS(KdDebuggerEnabled) > extern BOOLEAN *KdDebuggerEnabled; > -__CREATE_NTOS_DATA_IMPORT_ALIAS(KdDebuggerEnabled) > #define KD_DEBUGGER_ENABLED (*KdDebuggerEnabled) > +__CREATE_NTOS_DATA_IMPORT_ALIAS(KdDebuggerNotPresent) > extern BOOLEAN *KdDebuggerNotPresent; > -__CREATE_NTOS_DATA_IMPORT_ALIAS(KdDebuggerNotPresent) > #define KD_DEBUGGER_NOT_PRESENT (*KdDebuggerNotPresent) > #endif > > > Modified: trunk/reactos/include/xdk/ketypes.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/xdk/ketypes.h?rev=… > ============================================================================== > --- trunk/reactos/include/xdk/ketypes.h [iso-8859-1] (original) > +++ trunk/reactos/include/xdk/ketypes.h [iso-8859-1] Sun Sep 14 15:49:35 2014 > @@ -986,8 +986,8 @@ > #elif (NTDDI_VERSION >= NTDDI_WINXP) > extern NTSYSAPI CCHAR KeNumberProcessors; > #else > +__CREATE_NTOS_DATA_IMPORT_ALIAS(KeNumberProcessors) > extern PCCHAR KeNumberProcessors; > -__CREATE_NTOS_DATA_IMPORT_ALIAS(KeNumberProcessors) > #endif > > $endif (_WDMDDK_) > > Modified: trunk/reactos/include/xdk/mmtypes.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/xdk/mmtypes.h?rev=… > ============================================================================== > --- trunk/reactos/include/xdk/mmtypes.h [iso-8859-1] (original) > +++ trunk/reactos/include/xdk/mmtypes.h [iso-8859-1] Sun Sep 14 15:49:35 2014 > @@ -148,8 +148,8 @@ > } MM_SYSTEMSIZE; > > #ifndef _NTSYSTEM_ > +__CREATE_NTOS_DATA_IMPORT_ALIAS(Mm64BitPhysicalAddress) > extern PBOOLEAN Mm64BitPhysicalAddress; > -__CREATE_NTOS_DATA_IMPORT_ALIAS(Mm64BitPhysicalAddress) > #endif > extern NTKERNELAPI PVOID MmBadPointer; > > > Modified: trunk/reactos/include/xdk/ntifs.template.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/xdk/ntifs.template… > ============================================================================== > --- trunk/reactos/include/xdk/ntifs.template.h [iso-8859-1] (original) > +++ trunk/reactos/include/xdk/ntifs.template.h [iso-8859-1] Sun Sep 14 15:49:35 2014 > @@ -1128,8 +1128,8 @@ > extern PUSHORT NlsOemLeadByteInfo; > #define NLS_OEM_LEAD_BYTE_INFO NlsOemLeadByteInfo > #else > +__CREATE_NTOS_DATA_IMPORT_ALIAS(NlsOemLeadByteInfo) > extern PUSHORT *NlsOemLeadByteInfo; > -__CREATE_NTOS_DATA_IMPORT_ALIAS(NlsOemLeadByteInfo) > #define NLS_OEM_LEAD_BYTE_INFO (*NlsOemLeadByteInfo) > #endif > > >

1 0

Re: [ros-dev] [ros-diffs] [jgardou] 64121: [KDGDB] - introduce KDGDB, a KDCOM-like DLL, wrapping the KD protocol and the GDB remote protocol together. It is not fully functional, but for now it permits source-level debuggin...
by Timo Kreuzer 13 Sep '14

13 Sep '14

Awesome stuff! Am 11.09.2014 22:55, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Thu Sep 11 20:55:42 2014 > New Revision: 64121 > > URL: http://svn.reactos.org/svn/reactos?rev=64121&view=rev > Log: > [KDGDB] > - introduce KDGDB, a KDCOM-like DLL, wrapping the KD protocol and the GDB remote protocol together. > It is not fully functional, but for now it permits source-level debugging in some modules. More will be added as I feel the need and find the time to work a bit more on it. (That is, unless an angel comes and resume the work) > To use it, set GDB and _WINKD_ to TRUE in your CMakeCache.txt. Using separate debug symbols is also a good idea. > >

5 11

Re: [ros-dev] [ros-diffs] [jgardou] 64127: [KDGDB] - Add a callback mechanism permitting to "simulate" KD send <-> receive loop without having to actually communicate to GDB - Use that to update the program counter when con...
by Timo Kreuzer 12 Sep '14

12 Sep '14

while(1); is not really a good solution. It should be something that is visible in GDB. But I fear that a KeBugCheck() won't work here, since it will rely on a working KD connection. Maybe a KD_ASSERT() macro, that calls KdAssert() on failure or something, resets the GDB connection somehow, issues a debug print and then halts. Am 12.09.2014 22:23, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Fri Sep 12 20:23:08 2014 > New Revision: 64127 > > URL: http://svn.reactos.org/svn/reactos?rev=64127&view=rev > Log: > [KDGDB] > - Add a callback mechanism permitting to "simulate" KD send <-> receive loop without having to actually communicate to GDB > - Use that to update the program counter when cont'ing a breakpoint > Now cont'ing an assertion failure is possible, since we actually get beyond the int 3 instruction > > Modified: > trunk/reactos/drivers/base/kdgdb/gdb_input.c > trunk/reactos/drivers/base/kdgdb/kdgdb.h > trunk/reactos/drivers/base/kdgdb/kdpacket.c > > +) > +{ > + DBGKD_MANIPULATE_STATE64* State = (DBGKD_MANIPULATE_STATE64*)MessageHeader->Buffer; > + > + /* We just confirm that all went well */ > + if ((PacketType != PACKET_TYPE_KD_STATE_MANIPULATE) > + || (State->ApiNumber != DbgKdSetContextApi) > + || (State->ReturnStatus != STATUS_SUCCESS)) > + { > + /* Should we bugcheck ? */ > + while (1); > + } > +} > + > +static > +KDSTATUS > +SetContext( > + _Out_ DBGKD_MANIPULATE_STATE64* State, > + _Out_ PSTRING MessageData, > + _Out_ PULONG MessageLength, > + _Inout_ PKD_CONTEXT KdContext, > + _In_opt_ KDP_MANIPULATESTATE_HANDLER ManipulateStateHandler > +) > +{ > + State->ApiNumber = DbgKdSetContextApi; > + State->Processor = CurrentStateChange.Processor; > + State->ReturnStatus = STATUS_SUCCESS; > + State->ProcessorLevel = CurrentStateChange.ProcessorLevel; > + MessageData->Length = sizeof(CurrentContext); > + > + if (MessageData->MaximumLength < sizeof(CurrentContext)) > + { > + while (1); > + } > + >

2 1

Re: [ros-dev] [ros-diffs] [tkreuzer] 64078: [PSEH] - On clang builds we need to do the return twice trick, since we don't have asm goto, which would allow us to specify labels in the code where we can branch to on an except...
by Thomas Faber 12 Sep '14

12 Sep '14

On 2014-09-07 23:40, tkreuzer(a)svn.reactos.org wrote: > --- trunk/reactos/lib/pseh/i386/pseh3_i386.S [iso-8859-1] (original) > +++ trunk/reactos/lib/pseh/i386/pseh3_i386.S [iso-8859-1] Sun Sep 7 21:40:07 2014 > @@ -30,6 +30,10 @@ > mov [eax + SEH3_REGISTRATION_FRAME_Esi], esi > mov [eax + SEH3_REGISTRATION_FRAME_Edi], edi > > + /* Safe the return address */ > + mov ebx, [esp] > + mov [eax + SEH3_REGISTRATION_FRAME_ReturnAddress], ebx > + > .global __SEH3$_RegisterFrameWithStackLayout > __SEH3$_RegisterFrameWithStackLayout: > I think we need to restore ebx before returning? I don't see us telling the compiler that it was clobbered anywhere.

1 0

Re: [ros-dev] [ros-diffs] [akhaldi] 64113: [GLU32] * Link with mingwex. * Allow multiple definitions at link time because longjmp exists in both our msvcrt and mingwex. CORE-8516
by Timo Kreuzer 11 Sep '14

11 Sep '14

Are you sure that we will link to the correct one? I doubt that the one from mingwex is compatible. Am 11.09.2014 12:13, schrieb akhaldi(a)svn.reactos.org: > Author: akhaldi > Date: Thu Sep 11 10:13:05 2014 > New Revision: 64113 > > URL: http://svn.reactos.org/svn/reactos?rev=64113&view=rev > Log: > [GLU32] > * Link with mingwex. > * Allow multiple definitions at link time because longjmp exists in both our msvcrt and mingwex. > CORE-8516 > > Modified: > trunk/reactos/dll/opengl/glu32/CMakeLists.txt > > Modified: trunk/reactos/dll/opengl/glu32/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/opengl/glu32/CMakeList… > ============================================================================== > --- trunk/reactos/dll/opengl/glu32/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/dll/opengl/glu32/CMakeLists.txt [iso-8859-1] Thu Sep 11 10:13:05 2014 > @@ -114,6 +114,11 @@ > > if(NOT MSVC) > add_target_compile_flags(glu32 "-Wno-write-strings -Wno-unused-but-set-variable") > + if(CMAKE_C_COMPILER_ID STREQUAL "Clang") > + target_link_libraries(glu32 mingwex) > + #FIXME: longjmp exists in both our msvcrt and mingwex > + add_target_link_flags(glu32 "-Wl,--allow-multiple-definition") > + endif() > endif() > > add_importlibs(glu32 opengl32 gdi32 msvcrt kernel32 ntdll) > > >

1 0

Re: [ros-dev] [ros-diffs] [akhaldi] 64094: [CMAKE/CLANG] * Globally link mingwex for C modules. CORE-8516
by Jérôme Gardou 09 Sep '14

09 Sep '14

Hey Amine Is there any reason to not use our own mingwex build ? Le 09/09/2014 20:11, akhaldi(a)svn.reactos.org a écrit : > Author: akhaldi > Date: Tue Sep 9 18:11:10 2014 > New Revision: 64094 > > URL: http://svn.reactos.org/svn/reactos?rev=64094&view=rev > Log: > [CMAKE/CLANG] > * Globally link mingwex for C modules. > CORE-8516 > > Modified: > trunk/reactos/toolchain-clang.cmake > > Modified: trunk/reactos/toolchain-clang.cmake > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/toolchain-clang.cmake?rev=… > ============================================================================== > --- trunk/reactos/toolchain-clang.cmake [iso-8859-1] (original) > +++ trunk/reactos/toolchain-clang.cmake [iso-8859-1] Tue Sep 9 18:11:10 2014 > @@ -56,7 +56,7 @@ > set(CMAKE_ASM_CREATE_STATIC_LIBRARY ${CMAKE_C_CREATE_STATIC_LIBRARY}) > > # Don't link with anything by default unless we say so > -set(CMAKE_C_STANDARD_LIBRARIES "-lgcc" CACHE STRING "Standard C Libraries") > +set(CMAKE_C_STANDARD_LIBRARIES "-lmingwex -lgcc" CACHE STRING "Standard C Libraries") > > #MARK_AS_ADVANCED(CLEAR CMAKE_CXX_STANDARD_LIBRARIES) > set(CMAKE_CXX_STANDARD_LIBRARIES "-lgcc" CACHE STRING "Standard C++ Libraries") > >

1 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 64078: [PSEH] - On clang builds we need to do the return twice trick, since we don't have asm goto, which would allow us to specify labels in the code where we can branch to on an except...
by Thomas Faber 08 Sep '14

08 Sep '14

Making the member conditional but writing to it unconditionally seems like it would overflow the stack variable on GCC? On 2014-09-07 23:40, tkreuzer(a)svn.reactos.org wrote: > +#ifdef __clang__ > + void *ReturnAddress; > #endif > + /* Safe the return address */ > + mov ebx, [esp] > + mov [eax + SEH3_REGISTRATION_FRAME_ReturnAddress], ebx

2 1

Re: [ros-dev] [ros-diffs] [jgardou] 64022: [SECUR32] - Update spec file [SCHANNEL] - Update stubs list Please blame binutils
by Timo Kreuzer 01 Sep '14

01 Sep '14

Am 01.09.2014 14:21, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Mon Sep 1 12:21:16 2014 > New Revision: 64022 > > URL: http://svn.reactos.org/svn/reactos?rev=64022&view=rev > Log: > [SECUR32] > - Update spec file > [SCHANNEL] > - Update stubs list > Please blame binutils > > Modified: > trunk/reactos/dll/win32/schannel/schannel.spec > trunk/reactos/dll/win32/schannel/schannel_wine.c > trunk/reactos/dll/win32/schannel/stubs.c > trunk/reactos/dll/win32/secur32/secur32.spec > > Modified: trunk/reactos/dll/win32/schannel/schannel.spec > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/schannel/schanne… > ============================================================================== > --- trunk/reactos/dll/win32/schannel/schannel.spec [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/schannel/schannel.spec [iso-8859-1] Mon Sep 1 12:21:16 2014 > @@ -15,14 +15,14 @@ > @ stdcall InitSecurityInterfaceW() schan_InitSecurityInterfaceW > @ stdcall InitializeSecurityContextA(ptr ptr str long long long ptr long ptr ptr ptr ptr) schan_InitializeSecurityContextA > @ stdcall InitializeSecurityContextW(ptr ptr wstr long long long ptr long ptr ptr ptr ptr) schan_InitializeSecurityContextW > -@ stdcall MakeSignature(ptr long ptr long) secur32.MakeSignature > +@ stdcall MakeSignature(ptr long ptr long) schan_MakeSignature > @ stub OpenSslPerformanceData > @ stdcall QueryContextAttributesA(ptr long ptr) schan_QueryContextAttributesA > @ stdcall QueryContextAttributesW(ptr long ptr) schan_QueryContextAttributesW > -@ stdcall QuerySecurityPackageInfoA(str ptr) secur32.QuerySecurityPackageInfoA > -@ stdcall QuerySecurityPackageInfoW(wstr ptr) secur32.QuerySecurityPackageInfoW > -@ stdcall RevertSecurityContext(ptr) secur32.RevertSecurityContext > -@ stdcall SealMessage(ptr long ptr long) secur32.SealMessage > +@ stdcall QuerySecurityPackageInfoA(str ptr) schan_QuerySecurityPackageInfoA > +@ stdcall QuerySecurityPackageInfoW(wstr ptr) schan_QuerySecurityPackageInfoW > +@ stdcall RevertSecurityContext(ptr) schan_RevertSecurityContext > +@ stdcall SealMessage(ptr long ptr long) schan_EncryptMessage > @ stdcall SpLsaModeInitialize(long ptr ptr ptr) > @ stdcall SpUserModeInitialize(long ptr ptr ptr) > @ stub SslCrackCertificate > @@ -33,5 +33,5 @@ > @ stub SslGenerateRandomBits > @ stub SslGetMaximumKeySize > @ stub SslLoadCertificate > -@ stdcall UnsealMessage(ptr ptr long ptr) secur32.UnsealMessage > -@ stdcall VerifySignature(ptr ptr long ptr) secur32.VerifySignature > +@ stdcall UnsealMessage(ptr ptr long ptr) schan_DecryptMessage > +@ stdcall VerifySignature(ptr ptr long ptr) schan_VerifySignature This change is not correct. The following functions from schannel are forwarded to secur32: MakeSignature, QueryContextAttributesA/W, QuerySecurityPackageInfoA/W, RevertSecurityContext, SealMessage, UnsealMessage, VerifySignature Timo

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 64017: [BOOTVID] - Synchronize correctly arm/bootdata.c with i386, as it was done previously. - Code formatting: whitespace fixes, add braces/brackets and spaces where needed; comments s...
by Timo Kreuzer 01 Sep '14

01 Sep '14

Am 01.09.2014 01:00, schrieb hbelusca(a)svn.reactos.org: > Author: hbelusca > Date: Sun Aug 31 23:00:29 2014 > New Revision: 64017 > > URL: http://svn.reactos.org/svn/reactos?rev=64017&view=rev > Log: > [BOOTVID] > - Synchronize correctly arm/bootdata.c with i386, as it was done previously. Why is that file duplicated at all, if the contents are identical?

2 1

Re: [ros-dev] [ros-diffs] [tfaber] 63953: [FASTFAT] - Do not use direct I/O since it limits read/write operations to 64 MB CORE-8410 #resolve
by cameron.gutman＠reactos.org 27 Aug '14

27 Aug '14

This seems strange. I understand that NT 5.x has a limitation of 64 MB MDLs on x86, but direct I/O was designed for exactly this case of large I/O operations. Has anyone verified that 2k3 doesn’t do MDL chaining for direct I/O when the transfer is larger than a single MDL can hold? Also aren’t there changes to the IRP dispatch routines required to cope with not having an Irp->MdlAddress pointer anymore? Cameron From: tfaber(a)svn.reactos.org Sent: ‎Tuesday‎, ‎August‎ ‎26‎, ‎2014 ‎6‎:‎41‎ ‎AM To: ros-diffs(a)reactos.org Author: tfaber Date: Tue Aug 26 13:41:57 2014 New Revision: 63953 URL: http://svn.reactos.org/svn/reactos?rev=63953&view=rev Log: [FASTFAT] - Do not use direct I/O since it limits read/write operations to 64 MB CORE-8410 #resolve Modified: trunk/reactos/drivers/filesystems/fastfat/fsctl.c Modified: trunk/reactos/drivers/filesystems/fastfat/fsctl.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfa… ============================================================================== --- trunk/reactos/drivers/filesystems/fastfat/fsctl.c [iso-8859-1] (original) +++ trunk/reactos/drivers/filesystems/fastfat/fsctl.c [iso-8859-1] Tue Aug 26 13:41:57 2014 @@ -442,8 +442,7 @@ goto ByeBye; } - DeviceObject->Flags = DeviceObject->Flags | DO_DIRECT_IO; - DeviceExt = (PVOID) DeviceObject->DeviceExtension; + DeviceExt = DeviceObject->DeviceExtension; RtlZeroMemory(DeviceExt, ROUND_UP(sizeof(DEVICE_EXTENSION), sizeof(ULONG)) + sizeof(HASHENTRY*) * HashTableSize); DeviceExt->FcbHashTable = (HASHENTRY**)((ULONG_PTR)DeviceExt + ROUND_UP(sizeof(DEVICE_EXTENSION), sizeof(ULONG))); DeviceExt->HashTableSize = HashTableSize;

2 1

mplay translation
by Javier Agustìn Fernàndez Arroyo 26 Aug '14

26 Aug '14

hello folks, i have just updated the spanish translatiuon of mplay. Its here: https://jira.reactos.org/browse/CORE-8470 Enjoy! :)

1 0

Re: [ros-dev] [ros-diffs] [tfaber] 63928: [FASTFAT] - Properly handle errors in CcInitializeCacheMap, CcCopyRead and CcCopyWrite CORE-8410
by Jérôme Gardou 25 Aug '14

25 Aug '14

Hey Thomas I think that you want to use _SEH2_YIELD in a few places here, that is, unless we want to completely ditch pseh2 in favor of pseh3 ;-) Regards Jérôme Le 24/08/2014 05:28, tfaber(a)svn.reactos.org a écrit : > Author: tfaber > Date: Sun Aug 24 03:28:01 2014 > New Revision: 63928 > > URL: http://svn.reactos.org/svn/reactos?rev=63928&view=rev > Log: > [FASTFAT] > - Properly handle errors in CcInitializeCacheMap, CcCopyRead and CcCopyWrite > CORE-8410 > > Modified: > trunk/reactos/drivers/filesystems/fastfat/CMakeLists.txt > trunk/reactos/drivers/filesystems/fastfat/fcb.c > trunk/reactos/drivers/filesystems/fastfat/fsctl.c > trunk/reactos/drivers/filesystems/fastfat/rw.c > trunk/reactos/drivers/filesystems/fastfat/vfat.h > > Modified: trunk/reactos/drivers/filesystems/fastfat/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfa… > ============================================================================== > --- trunk/reactos/drivers/filesystems/fastfat/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/fastfat/CMakeLists.txt [iso-8859-1] Sun Aug 24 03:28:01 2014 > @@ -26,6 +26,7 @@ > add_library(fastfat SHARED ${SOURCE} vfatfs.rc) > > set_module_type(fastfat kernelmodedriver) > +target_link_libraries(fastfat ${PSEH_LIB}) > add_importlibs(fastfat ntoskrnl hal) > > add_pch(fastfat vfat.h SOURCE) > > Modified: trunk/reactos/drivers/filesystems/fastfat/fcb.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfa… > ============================================================================== > --- trunk/reactos/drivers/filesystems/fastfat/fcb.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/fastfat/fcb.c [iso-8859-1] Sun Aug 24 03:28:01 2014 > @@ -340,12 +340,14 @@ > { > PFILE_OBJECT fileObject; > PVFATCCB newCCB; > + NTSTATUS status; > > fileObject = IoCreateStreamFileObject (NULL, vcb->StorageDevice); > > newCCB = ExAllocateFromNPagedLookasideList(&VfatGlobalData->CcbLookasideList); > if (newCCB == NULL) > { > + ObDereferenceObject(fileObject); > return STATUS_INSUFFICIENT_RESOURCES; > } > RtlZeroMemory(newCCB, sizeof (VFATCCB)); > @@ -356,11 +358,24 @@ > fcb->FileObject = fileObject; > fcb->RefCount++; > > - CcInitializeCacheMap(fileObject, > - (PCC_FILE_SIZES)(&fcb->RFCB.AllocationSize), > - TRUE, > - &VfatGlobalData->CacheMgrCallbacks, > - fcb); > + _SEH2_TRY > + { > + CcInitializeCacheMap(fileObject, > + (PCC_FILE_SIZES)(&fcb->RFCB.AllocationSize), > + TRUE, > + &VfatGlobalData->CacheMgrCallbacks, > + fcb); > + } > + _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > + { > + status = _SEH2_GetExceptionCode(); > + fcb->RefCount--; > + fcb->FileObject = NULL; > + ExFreeToNPagedLookasideList(&VfatGlobalData->CcbLookasideList, newCCB); > + ObDereferenceObject(fileObject); > + return status; > + } > + _SEH2_END; > > fcb->Flags |= FCB_CACHE_INITIALIZED; > return STATUS_SUCCESS; > > Modified: trunk/reactos/drivers/filesystems/fastfat/fsctl.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfa… > ============================================================================== > --- trunk/reactos/drivers/filesystems/fastfat/fsctl.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/fastfat/fsctl.c [iso-8859-1] Sun Aug 24 03:28:01 2014 > @@ -550,11 +550,20 @@ > Fcb->RFCB.ValidDataLength = Fcb->RFCB.FileSize; > Fcb->RFCB.AllocationSize = Fcb->RFCB.FileSize; > > - CcInitializeCacheMap(DeviceExt->FATFileObject, > - (PCC_FILE_SIZES)(&Fcb->RFCB.AllocationSize), > - TRUE, > - &VfatGlobalData->CacheMgrCallbacks, > - Fcb); > + _SEH2_TRY > + { > + CcInitializeCacheMap(DeviceExt->FATFileObject, > + (PCC_FILE_SIZES)(&Fcb->RFCB.AllocationSize), > + TRUE, > + &VfatGlobalData->CacheMgrCallbacks, > + Fcb); > + } > + _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > + { > + Status = _SEH2_GetExceptionCode(); > + goto ByeBye; > + } > + _SEH2_END; > > DeviceExt->LastAvailableCluster = 2; > ExInitializeResourceLite(&DeviceExt->FatResource); > > Modified: trunk/reactos/drivers/filesystems/fastfat/rw.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfa… > ============================================================================== > --- trunk/reactos/drivers/filesystems/fastfat/rw.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/fastfat/rw.c [iso-8859-1] Sun Aug 24 03:28:01 2014 > @@ -673,22 +673,35 @@ > Status = /*STATUS_END_OF_FILE*/STATUS_SUCCESS; > } > > - if (IrpContext->FileObject->PrivateCacheMap == NULL) > - { > - CcInitializeCacheMap(IrpContext->FileObject, > - (PCC_FILE_SIZES)(&Fcb->RFCB.AllocationSize), > - FALSE, > - &(VfatGlobalData->CacheMgrCallbacks), > - Fcb); > - } > - > - if (!CcCopyRead(IrpContext->FileObject, &ByteOffset, Length, > - (BOOLEAN)(IrpContext->Flags & IRPCONTEXT_CANWAIT), Buffer, > - &IrpContext->Irp->IoStatus)) > - { > - Status = STATUS_PENDING; > - goto ByeBye; > - } > + _SEH2_TRY > + { > + if (IrpContext->FileObject->PrivateCacheMap == NULL) > + { > + CcInitializeCacheMap(IrpContext->FileObject, > + (PCC_FILE_SIZES)(&Fcb->RFCB.AllocationSize), > + FALSE, > + &(VfatGlobalData->CacheMgrCallbacks), > + Fcb); > + } > + > + if (!CcCopyRead(IrpContext->FileObject, > + &ByteOffset, > + Length, > + (IrpContext->Flags & IRPCONTEXT_CANWAIT) != 0, > + Buffer, > + &IrpContext->Irp->IoStatus)) > + { > + ASSERT((IrpContext->Flags & IRPCONTEXT_CANWAIT) == 0); > + Status = STATUS_PENDING; > + goto ByeBye; > + } > + } > + _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > + { > + Status = _SEH2_GetExceptionCode(); > + goto ByeBye; > + } > + _SEH2_END; > > if (!NT_SUCCESS(IrpContext->Irp->IoStatus.Status)) > { > @@ -947,30 +960,42 @@ > { > // cached write > > - if (IrpContext->FileObject->PrivateCacheMap == NULL) > - { > - CcInitializeCacheMap(IrpContext->FileObject, > - (PCC_FILE_SIZES)(&Fcb->RFCB.AllocationSize), > - FALSE, > - &VfatGlobalData->CacheMgrCallbacks, > - Fcb); > - } > - > - if (ByteOffset.QuadPart > OldFileSize.QuadPart) > - { > - CcZeroData(IrpContext->FileObject, &OldFileSize, &ByteOffset, TRUE); > - } > - > - if (CcCopyWrite(IrpContext->FileObject, &ByteOffset, Length, > - 1 /*IrpContext->Flags & IRPCONTEXT_CANWAIT*/, Buffer)) > - { > - IrpContext->Irp->IoStatus.Information = Length; > - Status = STATUS_SUCCESS; > - } > - else > - { > - Status = STATUS_UNSUCCESSFUL; > - } > + _SEH2_TRY > + { > + if (IrpContext->FileObject->PrivateCacheMap == NULL) > + { > + CcInitializeCacheMap(IrpContext->FileObject, > + (PCC_FILE_SIZES)(&Fcb->RFCB.AllocationSize), > + FALSE, > + &VfatGlobalData->CacheMgrCallbacks, > + Fcb); > + } > + > + if (ByteOffset.QuadPart > OldFileSize.QuadPart) > + { > + CcZeroData(IrpContext->FileObject, &OldFileSize, &ByteOffset, TRUE); > + } > + > + if (CcCopyWrite(IrpContext->FileObject, > + &ByteOffset, > + Length, > + TRUE /*(IrpContext->Flags & IRPCONTEXT_CANWAIT) != 0*/, > + Buffer)) > + { > + IrpContext->Irp->IoStatus.Information = Length; > + Status = STATUS_SUCCESS; > + } > + else > + { > + ASSERT(FALSE /*(IrpContext->Flags & IRPCONTEXT_CANWAIT) == 0*/); > + Status = STATUS_UNSUCCESSFUL; > + } > + } > + _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > + { > + Status = _SEH2_GetExceptionCode(); > + } > + _SEH2_END; > } > else > { > > Modified: trunk/reactos/drivers/filesystems/fastfat/vfat.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfa… > ============================================================================== > --- trunk/reactos/drivers/filesystems/fastfat/vfat.h [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/fastfat/vfat.h [iso-8859-1] Sun Aug 24 03:28:01 2014 > @@ -4,6 +4,7 @@ > #include <ntifs.h> > #include <ntdddisk.h> > #include <dos.h> > +#include <pseh/pseh2.h> > > #define USE_ROS_CC_AND_FS > > >

2 1

Re: [ros-dev] [ros-diffs] [jgardou] 63933: [WIN32K] - Enable commented freetype call: set font face size and coordinate transformation matrix Patch by Huw Campbell, reviewed by a gazillion of people. CORE-4657 #resolve #com...
by Thomas Faber 25 Aug '14

25 Aug '14

On 2014-08-24 15:28, jgardou(a)svn.reactos.org wrote: > -// FT_Set_Pixel_Sizes(ft_face, > -// TextObj->logfont.elfEnumLogfontEx.elfLogFont.lfWidth, > + FT_Set_Pixel_Sizes(ft_face, > + TextObj->logfont.elfEnumLogfontEx.elfLogFont.lfWidth, The abs() was added in the second version of the patch because this way it breaks tests. See https://jira.reactos.org/browse/CORE-4657?focusedCommentId=60379&page=com.a…

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 63940: [MPLAY32] Implement a single-window mode for videos. Patch by Ricardo Hanke. TO ALL TRANSLATORS: Update the translations! CORE-7910 #resolve #comment Committed, thanks!
by Thomas Faber 25 Aug '14

25 Aug '14

On 2014-08-24 17:40, hbelusca(a)svn.reactos.org wrote: > + mciSendCommand(wDeviceId, MCI_PUT, MCI_DGV_PUT_DESTINATION | MCI_DGV_RECT | MCI_WAIT, (DWORD)&mciPut); A DWORD cannot fit a pointer. This function takes DWORD_PTR.

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 63885: [KERNEL32] OpenConsoleW was implemented :P [CONSOLE.CPL][CONSRV] Create all the fonts needed at console startup, and then just select what's needed when fonts attributes need to b...
by Thomas Faber 14 Aug '14

14 Aug '14

On 2014-08-14 22:10, hbelusca(a)svn.reactos.org wrote: > + if (FaceName != GuiData->GuiInfo.FaceName) > + { > + SIZE_T Length = min(wcslen(FaceName) + 1, LF_FACESIZE); // wcsnlen > + wcsncpy(GuiData->GuiInfo.FaceName, FaceName, LF_FACESIZE); > + GuiData->GuiInfo.FaceName[Length] = L'\0'; // NULL-terminate > + } Buffer overflow. You mean [Length - 1]

1 0

On the server outage
by Colin Finck 12 Aug '14

12 Aug '14

Dear all, As you've certainly noticed, one of our main servers providing the www.reactos.org website along with JIRA and FishEye was down yesterday. Problems began yesterday around 13:00 UTC and lasted till some minutes ago. This has happened due to a severe hardware failure on the hypervisor machine serving the affected VMs. Our hosting provider needed two attempts to find and replace the failed hardware. Finally, the crash has caused one database table to get corrupted. This one was repaired just now. No data has been lost though. All services should be up again now. If you still notice anything not working, please report to me. We're sorry for the caused inconveniences! Best regards, -- Colin Finck System & Network Administrator ReactOS Deutschland e.V.

1 1

Introducing ReactOS development accounts
by Colin Finck 10 Aug '14

10 Aug '14

TL;DR ===== Your SVN account == "ReactOS development account", because it will be used for more services than just SVN. You can now change the password on your own at https://lam.reactos.org Hi all, I've been trying to centralize our user accounts for some time now and finally have something to show. Your known SVN credentials have been imported into an LDAP-based user directory now. This gives us the ability to easily plug various services for developers into the directory: SVN, BuildBot, the participant list for meetings, especially the upcoming services like Mumble, development VMs and file sharing. You can view your account details and change your password on your own now. Just visit https://lam.reactos.org to do so. The E-Mail address shown there will be used e.g. for sending meeting invitations. As we all want the migration to go flawlessy, I've set up a temporary SVN repository at svn://svn.reactos.org/sasltest This should work just like our "reactos" repository: If you have write access there, you have write access in "sasltest" as well. It already works well for me and my SVN client, but I want confirmations from others too. Please do so by committing some junk into sasltest :) We have some members, who don't have SVN write access but participate in the monthly meetings. They will shortly receive an E-Mail with their account details. That doesn't give you SVN write access though, it's just for participating in the meetings for now :P I'll keep you informed when we finally plug our main repositories into the LDAP database. Note that this doesn't change anything with the ReactOS Website accounts and IServ mail accounts. Former ones will always be in a separate database as everybody can sign up there. Cheers, Colin

2 1

Re: [ros-dev] [ros-diffs] [dgorbachev] 63823: [NTOSKRNL][PSEH3] - Add inline asm dependencies to fix undefined reference errors when building with link-time optimization. - Improve formatting. - No functional changes.
by Timo Kreuzer 07 Aug '14

07 Aug '14

Am 07.08.2014 01:10, schrieb dgorbachev(a)svn.reactos.org: > - : "m" (*(_TrylevelFrame)), "m" (*(_DataTable)), "c"(__builtin_alloca(0)) \ > + : "m" (*(_TrylevelFrame)), "m" (*(_DataTable)), "c" (__builtin_alloca(0)), "p" (_SEH3$_RegisterFrameWithNonVolatiles) \ What's this? Was that intentional? Timo

2 1

Re: [ros-dev] [ros-diffs] [hbelusca] 63803: [KERNEL32] Add a bunch of missing _SEH_YIELD in 'return' clues in _SEH_TRY clauses. [KERNEL32][CONSRV] Make kernel32 / winsrv console CSR structures Win2k3-compliant for Read/Writ...
by Thomas Faber 04 Aug '14

04 Aug '14

On 2014-08-04 18:25, hbelusca(a)svn.reactos.org wrote: > [KERNEL32] > Add a bunch of missing _SEH_YIELD in 'return' clues in _SEH_TRY clauses. That should be pointless with PSEH3. I believe Timo has in fact been removing them.

1 0

Status Meeting (July 2014)
by Aleksey Bragin 31 Jul '14

31 Jul '14

Hello, Let me invite you to the monthly status meeting taking place tomorrow, 31st of July, 19:00 UTC. If there are any proposals regarding moving the meeting date/time - please send them today. IRC service will only be started shortly before the meeting. Your participation passwords and server address will be emailed to you shortly before the meeting starts, and they are going to be different once again as they are not stored in any database. Hopefully it's not much of inconvenience. If someone still is not getting passwords sent before a meeting - please email Pierre before the meeting started to get one. Please send agenda proposals to me before the meeting, so that we can start with a proposed agenda. Also all developers, please, may I so kindly ask you to prepare a very brief one-two lines message containing two things: 1. What you did since the previous meeting 2. What you are going to do in the coming month This is needed to understand who is working on what, to plan things, etc. Prepare that in advance! Everyone will have max 1 minute! Regards, Aleksey Bragin

4 3

Fezile server down
by Colin Finck 31 Jul '14

31 Jul '14

Hi all, Fezile, one of our servers in Sweden, unexpectedly disappeared after a reboot today. Unfortunately, this is one of our older servers without an IPMI module, so we have to wait till it's rebooted manually. I'll keep you informed when this is done. The server outage affects the following services: * iso.reactos.org * doxygen.reactos.org * cppcheck.reactos.org * VMware Player Test slave * VMware Player Patchbot We apologize for the inconveniences! If you have any idea where we can still get a suitable IPMI module for these servers, we would be highly interested! The needed models are ASUS ASMB3 and Tyan M3291. Best regards, Colin Finck

4 7

Re: [ros-dev] [ros-diffs] [dreimer] 63785: [CARDS] Replace the old ugly 16 color cards with better looking ones. (From: http://www.united3dartists.com/forum/viewtopic.php?f=31&t=954) Remove 10 of 12 backgrounds and add some...
by Colin Finck 31 Jul '14

31 Jul '14

Daniel, do you have a written permission to put these third-party files under LGPL? Which is essentially what you're doing when adding the files to our cards.dll. Same goes for the Bavarian cards and decks. I doubt they have been put in the public domain.. We already needed to "fix" cards.dll once for not using GPLed cards, let's not repeat this again. - Colin

2 3

Re: [ros-dev] [ros-diffs] [jgardou] 63784: [NDK] - Make the MMWSLE structure multi-arch aware
by Timo Kreuzer 30 Jul '14

30 Jul '14

That name seems slightly misleading (PFN is usually associated with physical ranges, this is a virtual range). Maybe something like MM_VPN_BITS_SIZE would be better. If it is not used anywhere else, I'd just use an #ifdef _WIN64 ... (assuming it's the same for all 32 bit and the same for all 64 bit architectures) Am 30.07.2014 15:11, schrieb jgardou(a)svn.reactos.org: > +#define MM_PAGE_FRAME_NUMBER_SIZE 52

1 0

Re: [ros-dev] [ros-diffs] [jgardou] 63731: [WIN32K] - Correctly use the Clip, Meta, Rao, API and Vis Regions in DCs - Update the DC clipping object on demand each time a blt is performed - Reduce the number of region alloca...
by Timo Kreuzer 24 Jul '14

24 Jul '14

Great patch, but next time please seperate formatting from actual code changes, since it's barely possible to see what exactly has changed and what is only changed indentation. (Says the guy who often enough has mixed this himself *cough*) Am 23.07.2014 18:05, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Wed Jul 23 16:05:47 2014 > New Revision: 63731 > > URL: http://svn.reactos.org/svn/reactos?rev=63731&view=rev > Log: > [WIN32K] > - Correctly use the Clip, Meta, Rao, API and Vis Regions in DCs > - Update the DC clipping object on demand each time a blt is performed > - Reduce the number of region allocated with handles when it's not needed > This commit fixes numerous bugs regarding clipping, most notably SetDIBitsToDevice overlapping foreground windows > CORE-8353 #resolve #comment There are still a few quirks in winetests which will get fixed in a next commit > CORE-7628 #comment should be fixed in rev 63731, please confirm. > > Modified: > trunk/reactos/win32ss/gdi/ntgdi/arc.c > trunk/reactos/win32ss/gdi/ntgdi/bitblt.c > trunk/reactos/win32ss/gdi/ntgdi/cliprgn.c > trunk/reactos/win32ss/gdi/ntgdi/cliprgn.h > trunk/reactos/win32ss/gdi/ntgdi/dc.h > trunk/reactos/win32ss/gdi/ntgdi/dclife.c > trunk/reactos/win32ss/gdi/ntgdi/dcobjs.c > trunk/reactos/win32ss/gdi/ntgdi/dcstate.c > trunk/reactos/win32ss/gdi/ntgdi/dcutil.c > trunk/reactos/win32ss/gdi/ntgdi/dibobj.c > trunk/reactos/win32ss/gdi/ntgdi/fillshap.c > trunk/reactos/win32ss/gdi/ntgdi/freetype.c > trunk/reactos/win32ss/gdi/ntgdi/line.c > trunk/reactos/win32ss/gdi/ntgdi/path.c > trunk/reactos/win32ss/gdi/ntgdi/region.c > trunk/reactos/win32ss/gdi/ntgdi/region.h > trunk/reactos/win32ss/user/ntuser/cursoricon.c > trunk/reactos/win32ss/user/ntuser/cursoricon_new.c > trunk/reactos/win32ss/user/ntuser/dce.h > trunk/reactos/win32ss/user/ntuser/windc.c > > Modified: trunk/reactos/win32ss/gdi/ntgdi/arc.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/arc.c?re… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/arc.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/arc.c [iso-8859-1] Wed Jul 23 16:05:47 2014 > @@ -335,8 +335,7 @@ > > worker.l = dwStartAngle; > worker1.l = dwSweepAngle; > - DC_vPrepareDCsForBlit(pDC, pDC->rosdc.CombinedClip->rclBounds, > - NULL, pDC->rosdc.CombinedClip->rclBounds); > + DC_vPrepareDCsForBlit(pDC, NULL, NULL, NULL); > if (pDC->pdcattr->ulDirty_ & (DIRTY_FILL | DC_BRUSH_DIRTY)) > DC_vUpdateFillBrush(pDC); > if (pDC->pdcattr->ulDirty_ & (DIRTY_LINE | DC_PEN_DIRTY)) > @@ -381,8 +380,7 @@ > return TRUE; > } > > - DC_vPrepareDCsForBlit(dc, dc->rosdc.CombinedClip->rclBounds, > - NULL, dc->rosdc.CombinedClip->rclBounds); > + DC_vPrepareDCsForBlit(dc, NULL, NULL, NULL); > > if (dc->pdcattr->ulDirty_ & (DIRTY_FILL | DC_BRUSH_DIRTY)) > DC_vUpdateFillBrush(dc); > > Modified: trunk/reactos/win32ss/gdi/ntgdi/bitblt.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/bitblt.c… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/bitblt.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/bitblt.c [iso-8859-1] Wed Jul 23 16:05:47 2014 > @@ -107,7 +107,7 @@ > > /* Prepare DCs for blit */ > TRACE("Preparing DCs for blit\n"); > - DC_vPrepareDCsForBlit(DCDest, DestRect, DCSrc, SourceRect); > + DC_vPrepareDCsForBlit(DCDest, &DestRect, DCSrc, &SourceRect); > > /* Determine surfaces to be used in the bitblt */ > BitmapDest = DCDest->dclevel.pSurface; > @@ -268,7 +268,7 @@ > rcSrc.bottom += DCSrc->ptlDCOrig.y; > > /* Prepare for blit */ > - DC_vPrepareDCsForBlit(DCDest, rcDest, DCSrc, rcSrc); > + DC_vPrepareDCsForBlit(DCDest, &rcDest, DCSrc, &rcSrc); > > BitmapDest = DCDest->dclevel.pSurface; > if (!BitmapDest) > @@ -456,7 +456,7 @@ > } > > /* Prepare blit */ > - DC_vPrepareDCsForBlit(DCDest, DestRect, DCSrc, SourceRect); > + DC_vPrepareDCsForBlit(DCDest, &DestRect, DCSrc, &SourceRect); > > if (pdcattr->ulDirty_ & (DIRTY_FILL | DC_BRUSH_DIRTY)) > DC_vUpdateFillBrush(DCDest); > @@ -647,7 +647,7 @@ > BrushOrigin.y = 0; > > /* Only prepare Source and Dest, hdcMask represents a DIB */ > - DC_vPrepareDCsForBlit(DCDest, DestRect, DCSrc, SourceRect); > + DC_vPrepareDCsForBlit(DCDest, &DestRect, DCSrc, &SourceRect); > > if (pdcattr->ulDirty_ & (DIRTY_FILL | DC_BRUSH_DIRTY)) > DC_vUpdateFillBrush(DCDest); > @@ -826,7 +826,7 @@ > BrushOrigin.y = pbrush->ptOrigin.y + pdc->ptlDCOrig.y; > #endif > > - DC_vPrepareDCsForBlit(pdc, DestRect, NULL, DestRect); > + DC_vPrepareDCsForBlit(pdc, &DestRect, NULL, NULL); > > psurf = pdc->dclevel.pSurface; > > > Modified: trunk/reactos/win32ss/gdi/ntgdi/cliprgn.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/cliprgn.… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/cliprgn.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/cliprgn.c [iso-8859-1] Wed Jul 23 16:05:47 2014 > @@ -11,164 +11,102 @@ > #define NDEBUG > #include <debug.h> > > -int FASTCALL > -CLIPPING_UpdateGCRegion(DC* Dc) > -{ > - PROSRGNDATA CombinedRegion; > - //HRGN hRgnVis; > - PREGION prgnClip, prgnGCClip; > - > - /* Would prefer this, but the rest of the code sucks... */ > - //ASSERT(Dc->rosdc.hGCClipRgn); > - //ASSERT(Dc->rosdc.hClipRgn); > - ASSERT(Dc->prgnVis); > - //hRgnVis = Dc->prgnVis->BaseObject.hHmgr; > - > - if (Dc->rosdc.hGCClipRgn == NULL) > - Dc->rosdc.hGCClipRgn = IntSysCreateRectRgn(0, 0, 0, 0); > - > - prgnGCClip = REGION_LockRgn(Dc->rosdc.hGCClipRgn); > - ASSERT(prgnGCClip); > - > - if (Dc->rosdc.hClipRgn == NULL) > - IntGdiCombineRgn(prgnGCClip, Dc->prgnVis, NULL, RGN_COPY); > - else > - { > - prgnClip = REGION_LockRgn(Dc->rosdc.hClipRgn); // FIXME: Locking order, ugh! > - IntGdiCombineRgn(prgnGCClip, Dc->prgnVis, prgnClip, RGN_AND); > - REGION_UnlockRgn(prgnClip); > - } > - REGION_UnlockRgn(prgnGCClip); > - > - NtGdiOffsetRgn(Dc->rosdc.hGCClipRgn, Dc->ptlDCOrig.x, Dc->ptlDCOrig.y); > - > - if((CombinedRegion = RGNOBJAPI_Lock(Dc->rosdc.hGCClipRgn, NULL))) > - { > - CLIPOBJ *CombinedClip; > - > - CombinedClip = IntEngCreateClipRegion(CombinedRegion->rdh.nCount, > - CombinedRegion->Buffer, > - &CombinedRegion->rdh.rcBound); > - > - RGNOBJAPI_Unlock(CombinedRegion); > - > - if ( !CombinedClip ) > - { > - DPRINT1("IntEngCreateClipRegion() failed\n"); > - return ERROR; > - } > - > - if(Dc->rosdc.CombinedClip != NULL) > - IntEngDeleteClipRegion(Dc->rosdc.CombinedClip); > - > - Dc->rosdc.CombinedClip = CombinedClip ; > - } > - > - return NtGdiOffsetRgn(Dc->rosdc.hGCClipRgn, -Dc->ptlDCOrig.x, -Dc->ptlDCOrig.y); > -} > - > -INT FASTCALL > -GdiSelectVisRgn(HDC hdc, HRGN hrgn) > -{ > - int retval; > - DC *dc; > - PREGION prgn; > - > - if (!hrgn) > - { > - EngSetLastError(ERROR_INVALID_PARAMETER); > - return ERROR; > - } > - if (!(dc = DC_LockDc(hdc))) > - { > - EngSetLastError(ERROR_INVALID_HANDLE); > - return ERROR; > - } > - > - dc->fs &= ~DC_FLAG_DIRTY_RAO; > - > - ASSERT (dc->prgnVis != NULL); > - > - prgn = RGNOBJAPI_Lock(hrgn, NULL); > - retval = prgn ? IntGdiCombineRgn(dc->prgnVis, prgn, NULL, RGN_COPY) : ERROR; > - RGNOBJAPI_Unlock(prgn); > - if ( retval != ERROR ) > - { > +VOID > +FASTCALL > +GdiSelectVisRgn( > + HDC hdc, > + PREGION prgn) > +{ > + DC *dc; > + > + if (!(dc = DC_LockDc(hdc))) > + { > + EngSetLastError(ERROR_INVALID_HANDLE); > + return; > + } > + > + dc->fs |= DC_FLAG_DIRTY_RAO; > + > + ASSERT(dc->prgnVis != NULL); > + ASSERT(prgn != NULL); > + > + IntGdiCombineRgn(dc->prgnVis, prgn, NULL, RGN_COPY); > IntGdiOffsetRgn(dc->prgnVis, -dc->ptlDCOrig.x, -dc->ptlDCOrig.y); > - CLIPPING_UpdateGCRegion(dc); > - } > - DC_UnlockDc(dc); > - > - return retval; > -} > - > - > -int FASTCALL GdiExtSelectClipRgn(PDC dc, > - HRGN hrgn, > - int fnMode) > -{ > - // dc->fs &= ~DC_FLAG_DIRTY_RAO; > - > - if (!hrgn) > - { > - if (fnMode == RGN_COPY) > - { > - if (dc->rosdc.hClipRgn != NULL) > - { > - GreDeleteObject(dc->rosdc.hClipRgn); > - dc->rosdc.hClipRgn = NULL; > - } > - } > - else > - { > - EngSetLastError(ERROR_INVALID_PARAMETER); > - return ERROR; > - } > - } > - else > - { > - if (!dc->rosdc.hClipRgn) > - { > - RECTL rect; > - if(dc->prgnVis) > - { > + > + DC_UnlockDc(dc); > +} > + > + > +int > +FASTCALL > +IntGdiExtSelectClipRgn( > + PDC dc, > + PREGION prgn, > + int fnMode) > +{ > + if (!prgn) > + { > + if (fnMode == RGN_COPY) > + { > + if (dc->dclevel.prgnClip != NULL) > + { > + REGION_Delete(dc->dclevel.prgnClip); > + dc->dclevel.prgnClip = NULL; > + dc->fs |= DC_FLAG_DIRTY_RAO; > + } > + return SIMPLEREGION; > + } > + else > + { > + EngSetLastError(ERROR_INVALID_PARAMETER); > + return ERROR; > + } > + } > + > + if (!dc->dclevel.prgnClip) > + { > + RECTL rect; > + > REGION_GetRgnBox(dc->prgnVis, &rect); > - dc->rosdc.hClipRgn = IntSysCreateRectRgnIndirect(&rect); > - } > - else > - { > - dc->rosdc.hClipRgn = IntSysCreateRectRgn(0, 0, 0, 0); > - } > - } > + dc->dclevel.prgnClip = IntSysCreateRectpRgnIndirect(&rect); > + } > + > + dc->fs |= DC_FLAG_DIRTY_RAO; > + > if(fnMode == RGN_COPY) > - { > - NtGdiCombineRgn(dc->rosdc.hClipRgn, hrgn, 0, fnMode); > - } > - else > - NtGdiCombineRgn(dc->rosdc.hClipRgn, dc->rosdc.hClipRgn, hrgn, fnMode); > - } > - > - return CLIPPING_UpdateGCRegion(dc); > -} > - > - > -int APIENTRY NtGdiExtSelectClipRgn(HDC hDC, > - HRGN hrgn, > - int fnMode) > -{ > - int retval; > - DC *dc; > - > - if (!(dc = DC_LockDc(hDC))) > - { > - EngSetLastError(ERROR_INVALID_HANDLE); > - return ERROR; > - } > - > - retval = GdiExtSelectClipRgn ( dc, hrgn, fnMode ); > - > - DC_UnlockDc(dc); > - return retval; > + return IntGdiCombineRgn(dc->dclevel.prgnClip, prgn, 0, fnMode); > + > + return IntGdiCombineRgn(dc->dclevel.prgnClip, dc->dclevel.prgnClip, prgn, fnMode); > +} > + > + > +int > +APIENTRY > +NtGdiExtSelectClipRgn( > + HDC hDC, > + HRGN hrgn, > + int fnMode) > +{ > + int retval; > + DC *dc; > + PREGION prgn; > + > + if (!(dc = DC_LockDc(hDC))) > + { > + EngSetLastError(ERROR_INVALID_HANDLE); > + return ERROR; > + } > + > + prgn = REGION_LockRgn(hrgn); > + > + /* IntGdiExtSelectClipRgn takes care of checking for NULL region */ > + retval = IntGdiExtSelectClipRgn(dc, prgn, fnMode); > + > + if (prgn) > + REGION_UnlockRgn(prgn); > + > + DC_UnlockDc(dc); > + return retval; > } > > INT FASTCALL > @@ -177,7 +115,6 @@ > INT retval; > PDC dc; > PROSRGNDATA pRgnNew, pRgn = NULL; > - BOOL Unlock = FALSE; // Small HACK > > if (!(dc = DC_LockDc(hDC))) > { > @@ -193,10 +130,9 @@ > { > pRgn = dc->dclevel.prgnMeta; > } > - else if (dc->rosdc.hClipRgn) > + else if (dc->dclevel.prgnClip) // CLIPRGN > { > - Unlock = TRUE ; > - pRgn = REGION_LockRgn(dc->rosdc.hClipRgn); // CLIPRGN > + pRgn = dc->dclevel.prgnClip; > } > > if (pRgn) > @@ -206,7 +142,6 @@ > if (!pRgnNew) > { > DC_UnlockDc(dc); > - if(Unlock) REGION_UnlockRgn(pRgn); > return ERROR; > } > > @@ -217,12 +152,11 @@ > REGION_Delete(pRgnNew); > > DC_UnlockDc(dc); > - if(Unlock) REGION_UnlockRgn(pRgn); > return retval; > } > > retval = REGION_GetRgnBox(dc->prgnVis, rc); > - IntDPtoLP(dc, (LPPOINT)rc, 2); > + > DC_UnlockDc(dc); > > return retval; > @@ -265,53 +199,49 @@ > int RightRect, > int BottomRect) > { > - INT Result; > - RECTL Rect; > - PREGION prgnNew, prgnClip; > - PDC dc = DC_LockDc(hDC); > - > - if (!dc) > - { > - EngSetLastError(ERROR_INVALID_HANDLE); > - return ERROR; > - } > - > - Rect.left = LeftRect; > - Rect.top = TopRect; > - Rect.right = RightRect; > - Rect.bottom = BottomRect; > - > - IntLPtoDP(dc, (LPPOINT)&Rect, 2); > - > - prgnNew = IntSysCreateRectpRgnIndirect(&Rect); > - if (!prgnNew) > - { > - Result = ERROR; > - } > - else > - { > - if (!dc->rosdc.hClipRgn) > - { > - dc->rosdc.hClipRgn = IntSysCreateRectRgn(0, 0, 0, 0); > - prgnClip = REGION_LockRgn(dc->rosdc.hClipRgn); > - IntGdiCombineRgn(prgnClip, dc->prgnVis, prgnNew, RGN_DIFF); > - REGION_UnlockRgn(prgnClip); > - Result = SIMPLEREGION; > - } > - else > - { > - prgnClip = REGION_LockRgn(dc->rosdc.hClipRgn); > - Result = IntGdiCombineRgn(prgnClip, prgnClip, prgnNew, RGN_DIFF); > - REGION_UnlockRgn(prgnClip); > - } > - REGION_Delete(prgnNew); > - } > - if (Result != ERROR) > - CLIPPING_UpdateGCRegion(dc); > - > - DC_UnlockDc(dc); > - > - return Result; > + INT Result; > + RECTL Rect; > + PREGION prgnNew; > + PDC dc = DC_LockDc(hDC); > + > + if (!dc) > + { > + EngSetLastError(ERROR_INVALID_HANDLE); > + return ERROR; > + } > + > + Rect.left = LeftRect; > + Rect.top = TopRect; > + Rect.right = RightRect; > + Rect.bottom = BottomRect; > + > + IntLPtoDP(dc, (LPPOINT)&Rect, 2); > + > + prgnNew = IntSysCreateRectpRgnIndirect(&Rect); > + if (!prgnNew) > + { > + Result = ERROR; > + } > + else > + { > + if (!dc->dclevel.prgnClip) > + { > + dc->dclevel.prgnClip = IntSysCreateRectpRgn(0, 0, 0, 0); > + IntGdiCombineRgn(dc->dclevel.prgnClip, dc->prgnVis, prgnNew, RGN_DIFF); > + Result = SIMPLEREGION; > + } > + else > + { > + Result = IntGdiCombineRgn(dc->dclevel.prgnClip, dc->dclevel.prgnClip, prgnNew, RGN_DIFF); > + } > + REGION_Delete(prgnNew); > + } > + if (Result != ERROR) > + dc->fs |= DC_FLAG_DIRTY_RAO; > + > + DC_UnlockDc(dc); > + > + return Result; > } > > int APIENTRY NtGdiIntersectClipRect(HDC hDC, > @@ -320,200 +250,191 @@ > int RightRect, > int BottomRect) > { > - INT Result; > - RECTL Rect; > - HRGN NewRgn; > - PDC dc = DC_LockDc(hDC); > - > - DPRINT("NtGdiIntersectClipRect(%p, %d,%d-%d,%d)\n", > - hDC, LeftRect, TopRect, RightRect, BottomRect); > - > - if (!dc) > - { > - EngSetLastError(ERROR_INVALID_HANDLE); > - return ERROR; > - } > - > - Rect.left = LeftRect; > - Rect.top = TopRect; > - Rect.right = RightRect; > - Rect.bottom = BottomRect; > - > - IntLPtoDP(dc, (LPPOINT)&Rect, 2); > - > - NewRgn = IntSysCreateRectRgnIndirect(&Rect); > - if (!NewRgn) > - { > - Result = ERROR; > - } > - else if (!dc->rosdc.hClipRgn) > - { > - dc->rosdc.hClipRgn = NewRgn; > - Result = SIMPLEREGION; > - } > - else > - { > - Result = NtGdiCombineRgn(dc->rosdc.hClipRgn, dc->rosdc.hClipRgn, NewRgn, RGN_AND); > - GreDeleteObject(NewRgn); > - } > - if (Result != ERROR) > - CLIPPING_UpdateGCRegion(dc); > - > - DC_UnlockDc(dc); > - > - return Result; > + INT Result; > + RECTL Rect; > + PREGION pNewRgn; > + PDC dc = DC_LockDc(hDC); > + > + DPRINT("NtGdiIntersectClipRect(%p, %d,%d-%d,%d)\n", > + hDC, LeftRect, TopRect, RightRect, BottomRect); > + > + if (!dc) > + { > + EngSetLastError(ERROR_INVALID_HANDLE); > + return ERROR; > + } > + > + Rect.left = LeftRect; > + Rect.top = TopRect; > + Rect.right = RightRect; > + Rect.bottom = BottomRect; > + > + IntLPtoDP(dc, (LPPOINT)&Rect, 2); > + > + pNewRgn = IntSysCreateRectpRgnIndirect(&Rect); > + if (!pNewRgn) > + { > + Result = ERROR; > + } > + else if (!dc->dclevel.prgnClip) > + { > + dc->dclevel.prgnClip = pNewRgn; > + Result = SIMPLEREGION; > + } > + else > + { > + Result = IntGdiCombineRgn(dc->dclevel.prgnClip, dc->dclevel.prgnClip, pNewRgn, RGN_AND); > + REGION_Delete(pNewRgn); > + } > + if (Result != ERROR) > + dc->fs |= DC_FLAG_DIRTY_RAO; > + > + DC_UnlockDc(dc); > + > + return Result; > } > > int APIENTRY NtGdiOffsetClipRgn(HDC hDC, > int XOffset, > int YOffset) > { > - INT Result; > - DC *dc; > - > - if(!(dc = DC_LockDc(hDC))) > - { > - EngSetLastError(ERROR_INVALID_HANDLE); > - return ERROR; > - } > - > - if(dc->rosdc.hClipRgn != NULL) > - { > - Result = NtGdiOffsetRgn(dc->rosdc.hClipRgn, > - XOffset, > - YOffset); > - CLIPPING_UpdateGCRegion(dc); > - } > - else > - { > - Result = NULLREGION; > - } > - > - DC_UnlockDc(dc); > - return Result; > + INT Result; > + DC *dc; > + > + if(!(dc = DC_LockDc(hDC))) > + { > + EngSetLastError(ERROR_INVALID_HANDLE); > + return ERROR; > + } > + > + if(dc->dclevel.prgnClip != NULL) > + { > + Result = IntGdiOffsetRgn(dc->dclevel.prgnClip, > + XOffset, > + YOffset); > + dc->fs |= DC_FLAG_DIRTY_RAO; > + } > + else > + { > + Result = NULLREGION; > + } > + > + DC_UnlockDc(dc); > + return Result; > } > > BOOL APIENTRY NtGdiPtVisible(HDC hDC, > int X, > int Y) > { > - HRGN rgn; > - DC *dc; > - > - if(!(dc = DC_LockDc(hDC))) > - { > - EngSetLastError(ERROR_INVALID_HANDLE); > - return FALSE; > - } > - > - rgn = dc->rosdc.hGCClipRgn; > - DC_UnlockDc(dc); > - > - return (rgn ? NtGdiPtInRegion(rgn, X, Y) : FALSE); > -} > - > -BOOL APIENTRY NtGdiRectVisible(HDC hDC, > - LPRECT UnsafeRect) > -{ > - NTSTATUS Status = STATUS_SUCCESS; > - PROSRGNDATA Rgn; > - PDC dc = DC_LockDc(hDC); > - BOOL Result = FALSE; > - RECTL Rect; > - > - if (!dc) > - { > - EngSetLastError(ERROR_INVALID_HANDLE); > - return FALSE; > - } > - > - _SEH2_TRY > - { > - ProbeForRead(UnsafeRect, > + BOOL ret = FALSE; > + PDC dc; > + > + if(!(dc = DC_LockDc(hDC))) > + { > + EngSetLastError(ERROR_INVALID_HANDLE); > + return FALSE; > + } > + > + if (dc->prgnRao) > + { > + POINT pt = {X, Y}; > + IntLPtoDP(dc, &pt, 1); > + ret = REGION_PtInRegion(dc->prgnRao, pt.x, pt.y); > + } > + > + DC_UnlockDc(dc); > + > + return ret; > +} > + > +BOOL > +APIENTRY > +NtGdiRectVisible( > + HDC hDC, > + LPRECT UnsafeRect) > +{ > + NTSTATUS Status = STATUS_SUCCESS; > + PDC dc = DC_LockDc(hDC); > + BOOL Result = FALSE; > + RECTL Rect; > + > + if (!dc) > + { > + EngSetLastError(ERROR_INVALID_HANDLE); > + return FALSE; > + } > + > + _SEH2_TRY > + { > + ProbeForRead(UnsafeRect, > sizeof(RECT), > 1); > - Rect = *UnsafeRect; > - } > - _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > - { > - Status = _SEH2_GetExceptionCode(); > - } > - _SEH2_END; > - > - if(!NT_SUCCESS(Status)) > - { > - DC_UnlockDc(dc); > - SetLastNtError(Status); > - return FALSE; > - } > - > - if (dc->rosdc.hGCClipRgn) > - { > - if((Rgn = (PROSRGNDATA)RGNOBJAPI_Lock(dc->rosdc.hGCClipRgn, NULL))) > - { > + Rect = *UnsafeRect; > + } > + _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > + { > + Status = _SEH2_GetExceptionCode(); > + } > + _SEH2_END; > + > + if(!NT_SUCCESS(Status)) > + { > + DC_UnlockDc(dc); > + SetLastNtError(Status); > + return FALSE; > + } > + > + if (dc->fs & DC_FLAG_DIRTY_RAO) > + CLIPPING_UpdateGCRegion(dc); > + > + if (dc->prgnRao) > + { > IntLPtoDP(dc, (LPPOINT)&Rect, 2); > - Result = REGION_RectInRegion(Rgn, &Rect); > - RGNOBJAPI_Unlock(Rgn); > - } > - } > - DC_UnlockDc(dc); > - > - return Result; > + Result = REGION_RectInRegion(dc->prgnRao, &Rect); > + } > + DC_UnlockDc(dc); > + > + return Result; > } > > int > FASTCALL > IntGdiSetMetaRgn(PDC pDC) > { > - INT Ret = ERROR; > - PROSRGNDATA TempRgn; > - > - if ( pDC->dclevel.prgnMeta ) > - { > - if ( pDC->dclevel.prgnClip ) > - { > - TempRgn = IntSysCreateRectpRgn(0,0,0,0); > - if (TempRgn) > - { > - Ret = IntGdiCombineRgn( TempRgn, > - pDC->dclevel.prgnMeta, > - pDC->dclevel.prgnClip, > - RGN_AND); > - if ( Ret ) > - { > - GDIOBJ_vDereferenceObject(&pDC->dclevel.prgnMeta->BaseObject); > - if (!((PROSRGNDATA)pDC->dclevel.prgnMeta)->BaseObject.ulShareCount) > - REGION_Delete(pDC->dclevel.prgnMeta); > - > - pDC->dclevel.prgnMeta = TempRgn; > - > - GDIOBJ_vDereferenceObject(&pDC->dclevel.prgnClip->BaseObject); > - if (!((PROSRGNDATA)pDC->dclevel.prgnClip)->BaseObject.ulShareCount) > - REGION_Delete(pDC->dclevel.prgnClip); > - > - pDC->dclevel.prgnClip = NULL; > - > - IntGdiReleaseRaoRgn(pDC); > - } > - else > - REGION_Delete(TempRgn); > - } > - } > - else > - Ret = REGION_Complexity(pDC->dclevel.prgnMeta); > - } > - else > - { > - if ( pDC->dclevel.prgnClip ) > - { > - Ret = REGION_Complexity(pDC->dclevel.prgnClip); > - pDC->dclevel.prgnMeta = pDC->dclevel.prgnClip; > - pDC->dclevel.prgnClip = NULL; > - } > - else > - Ret = SIMPLEREGION; > - } > - return Ret; > + INT Ret = ERROR; > + > + if ( pDC->dclevel.prgnMeta ) > + { > + if ( pDC->dclevel.prgnClip ) > + { > + Ret = IntGdiCombineRgn(pDC->dclevel.prgnMeta, pDC->dclevel.prgnMeta, pDC->dclevel.prgnClip, RGN_AND); > + if (Ret != ERROR) > + { > + REGION_Delete(pDC->dclevel.prgnClip); > + pDC->dclevel.prgnClip = NULL; > + IntGdiReleaseRaoRgn(pDC); > + } > + } > + else > + Ret = REGION_Complexity(pDC->dclevel.prgnMeta); > + } > + else > + { > + if ( pDC->dclevel.prgnClip ) > + { > + Ret = REGION_Complexity(pDC->dclevel.prgnClip); > + pDC->dclevel.prgnMeta = pDC->dclevel.prgnClip; > + pDC->dclevel.prgnClip = NULL; > + } > + else > + Ret = SIMPLEREGION; > + } > + > + if (Ret != ERROR) > + pDC->fs |= DC_FLAG_DIRTY_RAO; > + > + return Ret; > } > > > @@ -533,88 +454,95 @@ > return Ret; > } > > -INT FASTCALL > -NEW_CLIPPING_UpdateGCRegion(PDC pDC) > -{ > - CLIPOBJ * co; > - > - /* Must have VisRgn set to a valid state! */ > - ASSERT (pDC->prgnVis); > - > -// FIXME: this seems to be broken! > - > - if (pDC->prgnAPI) > - { > - REGION_Delete(pDC->prgnAPI); > - pDC->prgnAPI = IntSysCreateRectpRgn(0,0,0,0); > - } > - > - if (pDC->prgnRao) > - { > - REGION_Delete(pDC->prgnRao); > - pDC->prgnRao = IntSysCreateRectpRgn(0,0,0,0); > - } > - > - if (!pDC->prgnRao) > - { > - return ERROR; > - } > - > - if (pDC->dclevel.prgnMeta && pDC->dclevel.prgnClip) > - { > - IntGdiCombineRgn( pDC->prgnAPI, > - pDC->dclevel.prgnClip, > - pDC->dclevel.prgnMeta, > - RGN_AND); > - } > - else > - { > - if (pDC->dclevel.prgnClip) > - { > - IntGdiCombineRgn( pDC->prgnAPI, > - pDC->dclevel.prgnClip, > - NULL, > - RGN_COPY); > - } > - else if (pDC->dclevel.prgnMeta) > - { > - IntGdiCombineRgn( pDC->prgnAPI, > - pDC->dclevel.prgnMeta, > - NULL, > - RGN_COPY); > - } > - } > - > - IntGdiCombineRgn( pDC->prgnRao, > - pDC->prgnVis, > - pDC->prgnAPI, > - RGN_AND); > - > - RtlCopyMemory(&pDC->erclClip, > +VOID > +FASTCALL > +CLIPPING_UpdateGCRegion(PDC pDC) > +{ > + CLIPOBJ * co; > + > + /* Must have VisRgn set to a valid state! */ > + ASSERT (pDC->prgnVis); > + > + if (pDC->prgnAPI) > + { > + REGION_Delete(pDC->prgnAPI); > + pDC->prgnAPI = NULL; > + } > + > + if (pDC->prgnRao) > + REGION_Delete(pDC->prgnRao); > + > + pDC->prgnRao = IntSysCreateRectpRgn(0,0,0,0); > + > + ASSERT(pDC->prgnRao); > + > + if (pDC->dclevel.prgnMeta || pDC->dclevel.prgnClip) > + { > + pDC->prgnAPI = IntSysCreateRectpRgn(0,0,0,0); > + if (!pDC->dclevel.prgnMeta) > + { > + IntGdiCombineRgn(pDC->prgnAPI, > + pDC->dclevel.prgnClip, > + NULL, > + RGN_COPY); > + } > + else if (!pDC->dclevel.prgnClip) > + { > + IntGdiCombineRgn(pDC->prgnAPI, > + pDC->dclevel.prgnMeta, > + NULL, > + RGN_COPY); > + } > + else > + { > + IntGdiCombineRgn(pDC->prgnAPI, > + pDC->dclevel.prgnClip, > + pDC->dclevel.prgnMeta, > + RGN_AND); > + } > + } > + > + if (pDC->prgnAPI) > + { > + IntGdiCombineRgn(pDC->prgnRao, > + pDC->prgnVis, > + pDC->prgnAPI, > + RGN_AND); > + } > + else > + { > + IntGdiCombineRgn(pDC->prgnRao, > + pDC->prgnVis, > + NULL, > + RGN_COPY); > + } > + > + > + IntGdiOffsetRgn(pDC->prgnRao, pDC->ptlDCOrig.x, pDC->ptlDCOrig.y); > + > + RtlCopyMemory(&pDC->erclClip, > &pDC->prgnRao->rdh.rcBound, > sizeof(RECTL)); > > - pDC->fs &= ~DC_FLAG_DIRTY_RAO; > - > - IntGdiOffsetRgn(pDC->prgnRao, pDC->ptlDCOrig.x, pDC->ptlDCOrig.y); > - > - // pDC->co should be used. Example, CLIPOBJ_cEnumStart uses XCLIPOBJ to build > - // the rects from region objects rects in pClipRgn->Buffer. > - // With pDC->co.pClipRgn->Buffer, > - // pDC->co.pClipRgn = pDC->prgnRao ? pDC->prgnRao : pDC->prgnVis; > - > - co = IntEngCreateClipRegion(pDC->prgnRao->rdh.nCount, > - pDC->prgnRao->Buffer, > - &pDC->erclClip); > - if (co) > - { > - if (pDC->rosdc.CombinedClip != NULL) > - IntEngDeleteClipRegion(pDC->rosdc.CombinedClip); > - > - pDC->rosdc.CombinedClip = co; > - } > - > - return IntGdiOffsetRgn(pDC->prgnRao, -pDC->ptlDCOrig.x, -pDC->ptlDCOrig.y); > + pDC->fs &= ~DC_FLAG_DIRTY_RAO; > + > + // pDC->co should be used. Example, CLIPOBJ_cEnumStart uses XCLIPOBJ to build > + // the rects from region objects rects in pClipRgn->Buffer. > + // With pDC->co.pClipRgn->Buffer, > + // pDC->co.pClipRgn = pDC->prgnRao ? pDC->prgnRao : pDC->prgnVis; > + > + co = IntEngCreateClipRegion(pDC->prgnRao->rdh.nCount, > + pDC->prgnRao->Buffer, > + &pDC->erclClip); > + if (co) > + { > + if (pDC->rosdc.CombinedClip != NULL) > + IntEngDeleteClipRegion(pDC->rosdc.CombinedClip); > + > + pDC->rosdc.CombinedClip = co; > + } > + > + IntGdiOffsetRgn(pDC->prgnRao, -pDC->ptlDCOrig.x, -pDC->ptlDCOrig.y); > } > > /* EOF */ > > Modified: trunk/reactos/win32ss/gdi/ntgdi/cliprgn.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/cliprgn.… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/cliprgn.h [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/cliprgn.h [iso-8859-1] Wed Jul 23 16:05:47 2014 > @@ -1,6 +1,6 @@ > #pragma once > > INT FASTCALL GdiGetClipBox(HDC hDC, RECTL *rc); > -INT FASTCALL GdiSelectVisRgn(HDC hdc, HRGN hrgn); > -INT FASTCALL GdiExtSelectClipRgn (PDC dc, HRGN hrgn, int fnMode); > -int FASTCALL CLIPPING_UpdateGCRegion(DC* Dc); > +VOID FASTCALL GdiSelectVisRgn(HDC hdc, PREGION prgn); > +INT FASTCALL IntGdiExtSelectClipRgn (PDC dc, PREGION prgn, int fnMode); > +VOID FASTCALL CLIPPING_UpdateGCRegion(DC* Dc); > > Modified: trunk/reactos/win32ss/gdi/ntgdi/dc.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/dc.h?rev… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/dc.h [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/dc.h [iso-8859-1] Wed Jul 23 16:05:47 2014 > @@ -48,9 +48,6 @@ > > typedef struct _ROS_DC_INFO > { > - HRGN hClipRgn; /* Clip region (may be 0) */ > - HRGN hGCClipRgn; /* GC clip region (ClipRgn AND VisRgn) */ > - > CLIPOBJ *CombinedClip; > } ROS_DC_INFO; > > @@ -199,9 +196,9 @@ > > BOOL FASTCALL DC_InvertXform(const XFORM *xformSrc, XFORM *xformDest); > VOID FASTCALL DC_vUpdateViewportExt(PDC pdc); > -VOID FASTCALL DC_vCopyState(PDC pdcSrc, PDC pdcDst, BOOL to); > +VOID FASTCALL DC_vCopyState(PDC pdcSrc, PDC pdcDst, BOOL To); > VOID FASTCALL DC_vFinishBlit(PDC pdc1, PDC pdc2); > -VOID FASTCALL DC_vPrepareDCsForBlit(PDC pdc1, RECT rc1, PDC pdc2, RECT rc2); > +VOID FASTCALL DC_vPrepareDCsForBlit(PDC pdcDest, const RECT* rcDest, PDC pdcSrc, const RECT* rcSrc); > > VOID NTAPI DC_vRestoreDC(IN PDC pdc, INT iSaveLevel); > > > Modified: trunk/reactos/win32ss/gdi/ntgdi/dclife.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/dclife.c… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/dclife.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/dclife.c [iso-8859-1] Wed Jul 23 16:05:47 2014 > @@ -95,22 +95,11 @@ > void > DC_InitHack(PDC pdc) > { > - HRGN hVisRgn; > - > TextIntRealizeFont(pdc->pdcattr->hlfntNew,NULL); > pdc->pdcattr->iCS_CP = ftGdiGetTextCharsetInfo(pdc,NULL,0); > > /* This should never fail */ > ASSERT(pdc->dclevel.ppal); > - > - /* Select regions */ > - pdc->rosdc.hClipRgn = NULL; > - pdc->rosdc.hGCClipRgn = NULL; > - > - hVisRgn = IntSysCreateRectRgn(0, 0, 1, 1); > - ASSERT(hVisRgn); > - GdiSelectVisRgn(pdc->BaseObject.hHmgr, hVisRgn); > - GreDeleteObject(hVisRgn); > } > > VOID > @@ -170,7 +159,7 @@ > pdc->erclBoundsApp.right = 0x00007ffc; // FIXME > pdc->erclBoundsApp.bottom = 0x00000333; // FIXME > pdc->erclClip = pdc->erclBounds; > -// pdc->co > + pdc->co = gxcoTrivial; > > pdc->fs |= DC_SYNCHRONIZEACCESS | DC_ACCUM_APP | DC_PERMANANT | DC_DISPLAY; > } > @@ -185,7 +174,7 @@ > pdc->erclBounds.bottom = 0; > pdc->erclBoundsApp = pdc->erclBounds; > pdc->erclClip = pdc->erclWindow; > - //pdc->co = NULL > + pdc->co = gxcoTrivial; > } > > //pdc->dcattr.VisRectRegion: > @@ -237,6 +226,8 @@ > /* Setup regions */ > pdc->prgnAPI = NULL; > pdc->prgnRao = NULL; > + pdc->dclevel.prgnClip = NULL; > + pdc->dclevel.prgnMeta = NULL; > /* Allocate a Vis region */ > pdc->prgnVis = IntSysCreateRectpRgn(0, 0, pdc->dclevel.sizl.cx, pdc->dclevel.sizl.cy); > ASSERT(pdc->prgnVis); > @@ -372,17 +363,17 @@ > LFONT_ShareUnlockFont(pdc->dclevel.plfnt); > > /* Free regions */ > - if (pdc->rosdc.hClipRgn && GreIsHandleValid(pdc->rosdc.hClipRgn)) > - GreDeleteObject(pdc->rosdc.hClipRgn); > + if (pdc->dclevel.prgnClip) > + REGION_Delete(pdc->dclevel.prgnClip); > + if (pdc->dclevel.prgnMeta) > + REGION_Delete(pdc->dclevel.prgnMeta); > if (pdc->prgnVis) > - { > REGION_Delete(pdc->prgnVis); > - } > - if (pdc->rosdc.hGCClipRgn && GreIsHandleValid(pdc->rosdc.hGCClipRgn)) > - { > - GreDeleteObject(pdc->rosdc.hGCClipRgn); > - } > - if (NULL != pdc->rosdc.CombinedClip) > + if (pdc->prgnRao) > + REGION_Delete(pdc->prgnRao); > + if (pdc->prgnAPI) > + REGION_Delete(pdc->prgnAPI); > + if (pdc->rosdc.CombinedClip) > IntEngDeleteClipRegion(pdc->rosdc.CombinedClip); > > PATH_Delete(pdc->dclevel.hPath); > @@ -397,17 +388,6 @@ > NTAPI > DC_vSetOwner(PDC pdc, ULONG ulOwner) > { > - > - if (pdc->rosdc.hClipRgn) > - { > - IntGdiSetRegionOwner(pdc->rosdc.hClipRgn, ulOwner); > - } > - > - if (pdc->rosdc.hGCClipRgn) > - { > - IntGdiSetRegionOwner(pdc->rosdc.hGCClipRgn, ulOwner); > - } > - > if (pdc->dclevel.hPath) > { > GreSetObjectOwner(pdc->dclevel.hPath, ulOwner); > @@ -466,7 +446,7 @@ > void > DC_vUpdateDC(PDC pdc) > { > - HRGN hVisRgn ; > + // PREGION VisRgn ; > PPDEVOBJ ppdev = pdc->ppdev ; > > pdc->dhpdev = ppdev->dhpdev; > @@ -475,10 +455,12 @@ > pdc->dclevel.pSurface = PDEVOBJ_pSurface(ppdev); > > PDEVOBJ_sizl(pdc->ppdev, &pdc->dclevel.sizl); > - hVisRgn = NtGdiCreateRectRgn(0, 0, pdc->dclevel.sizl.cx, pdc->dclevel.sizl.cy); > - ASSERT(hVisRgn); > - GdiSelectVisRgn(pdc->BaseObject.hHmgr, hVisRgn); > - GreDeleteObject(hVisRgn); > +#if 0 > + VisRgn = IntSysCreateRectpRgn(0, 0, pdc->dclevel.sizl.cx, pdc->dclevel.sizl.cy); > + ASSERT(VisRgn); > + GdiSelectVisRgn(pdc->BaseObject.hHmgr, VisRgn); > + REGION_Delete(VisRgn); > +#endif > > pdc->flGraphicsCaps = ppdev->devinfo.flGraphicsCaps; > pdc->flGraphicsCaps2 = ppdev->devinfo.flGraphicsCaps2; > @@ -492,75 +474,106 @@ > * from where we take pixels. */ > VOID > FASTCALL > -DC_vPrepareDCsForBlit(PDC pdc1, > - RECT rc1, > - PDC pdc2, > - RECT rc2) > +DC_vPrepareDCsForBlit( > + PDC pdcDest, > + const RECT* rcDest, > + PDC pdcSrc, > + const RECT* rcSrc) > { > PDC pdcFirst, pdcSecond; > - PRECT prcFirst, prcSecond; > + const RECT *prcFirst, *prcSecond; > > /* Update brushes */ > - if (pdc1->pdcattr->ulDirty_ & (DIRTY_FILL | DC_BRUSH_DIRTY)) > - DC_vUpdateFillBrush(pdc1); > - if (pdc1->pdcattr->ulDirty_ & (DIRTY_LINE | DC_PEN_DIRTY)) > - DC_vUpdateLineBrush(pdc1); > - if(pdc1->pdcattr->ulDirty_ & DIRTY_TEXT) > - DC_vUpdateTextBrush(pdc1); > + if (pdcDest->pdcattr->ulDirty_ & (DIRTY_FILL | DC_BRUSH_DIRTY)) > + DC_vUpdateFillBrush(pdcDest); > + if (pdcDest->pdcattr->ulDirty_ & (DIRTY_LINE | DC_PEN_DIRTY)) > + DC_vUpdateLineBrush(pdcDest); > + if(pdcDest->pdcattr->ulDirty_ & DIRTY_TEXT) > + DC_vUpdateTextBrush(pdcDest); > > /* Lock them in good order */ > - if(pdc2) > - { > - if((ULONG_PTR)pdc1->ppdev->hsemDevLock >= (ULONG_PTR)pdc2->ppdev->hsemDevLock) > - { > - pdcFirst = pdc1; > - prcFirst = &rc1; > - pdcSecond = pdc2; > - prcSecond = &rc2; > + if(pdcSrc) > + { > + if((ULONG_PTR)pdcDest->ppdev->hsemDevLock >= (ULONG_PTR)pdcSrc->ppdev->hsemDevLock) > + { > + pdcFirst = pdcDest; > + prcFirst = rcDest; > + pdcSecond = pdcSrc; > + prcSecond = rcSrc; > } > else > { > - pdcFirst = pdc2; > - prcFirst = &rc2; > - pdcSecond = pdc1; > - prcSecond = &rc1; > + pdcFirst = pdcSrc; > + prcFirst = rcSrc; > + pdcSecond = pdcDest; > + prcSecond = rcDest; > } > } > else > { > - pdcFirst = pdc1 ; > - prcFirst = &rc1; > + pdcFirst = pdcDest ; > + prcFirst = rcDest; > pdcSecond = NULL; > prcSecond = NULL; > } > > - if(pdcFirst && pdcFirst->dctype == DCTYPE_DIRECT) > + /* Update clipping of dest DC if needed */ > + if (pdcDest->dctype == DCTYPE_DIRECT) > + { > + DCE* dce = DceGetDceFromDC(pdcDest->BaseObject.hHmgr); > + if (dce) > + DceUpdateVisRgn(dce, dce->pwndOrg, dce->DCXFlags); > + } > + > + if (pdcDest->fs & DC_FLAG_DIRTY_RAO) > + CLIPPING_UpdateGCRegion(pdcDest); > + > + /* Lock and update first DC */ > + if(pdcFirst->dctype == DCTYPE_DIRECT) > { > EngAcquireSemaphore(pdcFirst->ppdev->hsemDevLock); > - MouseSafetyOnDrawStart(pdcFirst->ppdev, > - prcFirst->left, > - prcFirst->top, > - prcFirst->right, > - prcFirst->bottom) ; > /* Update surface if needed */ > if(pdcFirst->ppdev->pSurface != pdcFirst->dclevel.pSurface) > { > DC_vUpdateDC(pdcFirst); > } > } > - if(pdcSecond && pdcSecond->dctype == DCTYPE_DIRECT) > + > + if(pdcFirst->dctype == DCTYPE_DIRECT) > + { > + if (!prcFirst) > + prcFirst = &pdcFirst->erclClip; > + > + MouseSafetyOnDrawStart(pdcFirst->ppdev, > + prcFirst->left, > + prcFirst->top, > + prcFirst->right, > + prcFirst->bottom) ; > + } > + > + if (!pdcSecond) > + return; > + > + /* Lock and update second DC */ > + if(pdcSecond->dctype == DCTYPE_DIRECT) > { > EngAcquireSemaphore(pdcSecond->ppdev->hsemDevLock); > - MouseSafetyOnDrawStart(pdcSecond->ppdev, > - prcSecond->left, > - prcSecond->top, > - prcSecond->right, > - prcSecond->bottom) ; > /* Update surface if needed */ > if(pdcSecond->ppdev->pSurface != pdcSecond->dclevel.pSurface) > { > DC_vUpdateDC(pdcSecond); > } > + } > + > + if(pdcSecond->dctype == DCTYPE_DIRECT) > + { > + if (!prcSecond) > + prcSecond = &pdcSecond->erclClip; > + MouseSafetyOnDrawStart(pdcSecond->ppdev, > + prcSecond->left, > + prcSecond->top, > + prcSecond->right, > + prcSecond->bottom) ; > } > } > > > Modified: trunk/reactos/win32ss/gdi/ntgdi/dcobjs.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/dcobjs.c… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/dcobjs.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/dcobjs.c [iso-8859-1] Wed Jul 23 16:05:47 2014 > @@ -330,7 +330,7 @@ > PDC pdc; > HBITMAP hbmpOld; > PSURFACE psurfNew, psurfOld; > - HRGN hVisRgn; > + PREGION VisRgn; > HDC hdcOld; > ULONG cBitsPixel; > ASSERT_NOGDILOCKS(); > @@ -452,15 +452,15 @@ > pdc->pdcattr->ulDirty_ |= DIRTY_FILL | DIRTY_LINE; > > /* FIXME: Improve by using a region without a handle and selecting it */ > - hVisRgn = IntSysCreateRectRgn( 0, > + VisRgn = IntSysCreateRectpRgn( 0, > 0, > pdc->dclevel.sizl.cx, > pdc->dclevel.sizl.cy); > > - if (hVisRgn) > - { > - GdiSelectVisRgn(hdc, hVisRgn); > - GreDeleteObject(hVisRgn); > + if (VisRgn) > + { > + GdiSelectVisRgn(hdc, VisRgn); > + REGION_Delete(VisRgn); > } > > /* Unlock the DC */ > @@ -509,7 +509,10 @@ > /* Construct a region from the path */ > else if (PATH_PathToRegion(pPath, pdcattr->jFillMode, &hrgnPath)) > { > - success = GdiExtSelectClipRgn(pdc, hrgnPath, Mode) != ERROR; > + PREGION prgnPath = REGION_LockRgn(hrgnPath); > + ASSERT(prgnPath); > + success = IntGdiExtSelectClipRgn(pdc, prgnPath, Mode) != ERROR; > + REGION_UnlockRgn(prgnPath); > GreDeleteObject( hrgnPath ); > > /* Empty the path */ > @@ -693,9 +696,7 @@ > { > INT ret = 0; > PDC pdc; > - HRGN hrgnSrc = NULL; > PREGION prgnSrc = NULL; > - POINTL ptlOrg; > > pdc = DC_LockDc(hdc); > if (!pdc) > @@ -707,8 +708,7 @@ > switch (iCode) > { > case CLIPRGN: > - hrgnSrc = pdc->rosdc.hClipRgn; > -// if (pdc->dclevel.prgnClip) prgnSrc = pdc->dclevel.prgnClip; > + prgnSrc = pdc->dclevel.prgnClip; > break; > > case METARGN: > @@ -716,14 +716,15 @@ > break; > > case APIRGN: > + if (pdc->fs & DC_FLAG_DIRTY_RAO) > + CLIPPING_UpdateGCRegion(pdc); > if (pdc->prgnAPI) > { > prgnSrc = pdc->prgnAPI; > } > -// else if (pdc->dclevel.prgnClip) prgnSrc = pdc->dclevel.prgnClip; > - else if (pdc->rosdc.hClipRgn) > + else if (pdc->dclevel.prgnClip) > { > - hrgnSrc = pdc->rosdc.hClipRgn; > + prgnSrc = pdc->dclevel.prgnClip; > } > else if (pdc->dclevel.prgnMeta) > { > @@ -739,26 +740,18 @@ > break; > } > > - if (hrgnSrc) > - { > - ret = NtGdiCombineRgn(hrgnDest, hrgnSrc, 0, RGN_COPY) == ERROR ? -1 : 1; > - } > - else if (prgnSrc) > + if (prgnSrc) > { > PREGION prgnDest = REGION_LockRgn(hrgnDest); > if (prgnDest) > { > ret = IntGdiCombineRgn(prgnDest, prgnSrc, 0, RGN_COPY) == ERROR ? -1 : 1; > + if ((ret == 1) && (iCode == SYSRGN)) > + IntGdiOffsetRgn(prgnDest, pdc->ptlDCOrig.x, pdc->ptlDCOrig.y); > REGION_UnlockRgn(prgnDest); > } > else > ret = -1; > - } > - > - if (iCode == SYSRGN) > - { > - ptlOrg = pdc->ptlDCOrig; > - NtGdiOffsetRgn(hrgnDest, ptlOrg.x, ptlOrg.y ); > } > > DC_UnlockDc(pdc); > > Modified: trunk/reactos/win32ss/gdi/ntgdi/dcstate.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/dcstate.… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/dcstate.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/dcstate.c [iso-8859-1] Wed Jul 23 16:05:47 2014 > @@ -51,23 +51,26 @@ > pdcDst->dclevel.plfnt = pdcSrc->dclevel.plfnt; > > /* Get/SetDCState() don't change hVisRgn field ("Undoc. Windows" p.559). */ > - if (To) // Copy "To" SaveDC state. > - { > - if (pdcSrc->rosdc.hClipRgn) > - { > - pdcDst->rosdc.hClipRgn = IntSysCreateRectRgn(0, 0, 0, 0); > - NtGdiCombineRgn(pdcDst->rosdc.hClipRgn, pdcSrc->rosdc.hClipRgn, 0, RGN_COPY); > - } > - // FIXME: Handle prgnMeta! > - } > - else // Copy "!To" RestoreDC state. > - { /* The VisRectRegion field needs to be set to a valid state */ > - GdiExtSelectClipRgn(pdcDst, pdcSrc->rosdc.hClipRgn, RGN_COPY); > - } > -} > - > - > -BOOL FASTCALL > + if (!To) > + { > + IntGdiExtSelectClipRgn(pdcDst, pdcSrc->dclevel.prgnClip, RGN_COPY); > + if (pdcDst->dclevel.prgnMeta) > + { > + REGION_Delete(pdcDst->dclevel.prgnMeta); > + pdcDst->dclevel.prgnMeta = NULL; > + } > + if (pdcSrc->dclevel.prgnMeta) > + { > + pdcDst->dclevel.prgnMeta = IntSysCreateRectpRgn(0, 0, 0, 0); > + IntGdiCombineRgn(pdcDst->dclevel.prgnMeta, pdcSrc->dclevel.prgnMeta, NULL, RGN_COPY); > + } > + pdcDst->fs |= DC_FLAG_DIRTY_RAO; > + } > +} > + > + > +BOOL > +FASTCALL > IntGdiCleanDC(HDC hDC) > { > PDC dc; > @@ -87,6 +90,16 @@ > DC_vUpdateTextBrush(dc); > } > > + /* DC_vCopyState frees the Clip rgn and the Meta rgn. Take care of the other ones > + * There is no need to clear prgnVis, as UserGetDC updates it immediately. */ > + if (dc->prgnRao) > + REGION_Delete(dc->prgnRao); > + if (dc->prgnAPI) > + REGION_Delete(dc->prgnAPI); > + dc->prgnRao = dc->prgnAPI = NULL; > + > + dc->fs |= DC_FLAG_DIRTY_RAO; > + > DC_UnlockDc(dc); > > return TRUE; > @@ -272,7 +285,7 @@ > GDIOBJ_vSetObjectOwner(&pdcSave->BaseObject, GDI_OBJ_HMGR_PUBLIC); > > /* Copy the current state */ > - DC_vCopyState(pdc, pdcSave, TRUE); > + DC_vCopyState(pdc, pdcSave, FALSE); > > /* Only memory DC's change their surface */ > if (pdc->dctype == DCTYPE_MEMORY) > > Modified: trunk/reactos/win32ss/gdi/ntgdi/dcutil.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/dcutil.c… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/dcutil.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/dcutil.c [iso-8859-1] Wed Jul 23 16:05:47 2014 > @@ -367,7 +367,7 @@ > } > else if (Flags & DCHF_VALIDATEVISRGN || 0 == Flags) > { > - dc->fs &= ~DC_FLAG_DIRTY_RAO; > + //dc->fs &= ~DC_FLAG_DIRTY_RAO; > } > > DC_UnlockDc(dc); > > Modified: trunk/reactos/win32ss/gdi/ntgdi/dibobj.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/dibobj.c… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/dibobj.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/dibobj.c [iso-8859-1] Wed Jul 23 16:05:47 2014 > @@ -502,7 +502,7 @@ > } > > /* This is actually a blit */ > - DC_vPrepareDCsForBlit(pDC, rcDest, NULL, rcDest); > + DC_vPrepareDCsForBlit(pDC, &rcDest, NULL, NULL); > pSurf = pDC->dclevel.pSurface; > if (!pSurf) > { > @@ -1184,7 +1184,7 @@ > } > > /* Prepare DC for blit */ > - DC_vPrepareDCsForBlit(pdc, rcDst, NULL, rcSrc); > + DC_vPrepareDCsForBlit(pdc, &rcDst, NULL, NULL); > > psurfDst = pdc->dclevel.pSurface; > > > Modified: trunk/reactos/win32ss/gdi/ntgdi/fillshap.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/fillshap… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/fillshap.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/fillshap.c [iso-8859-1] Wed Jul 23 16:05:47 2014 > @@ -307,7 +307,7 @@ > tmpFillBrushObj.ptOrigin.x += dc->ptlDCOrig.x; > tmpFillBrushObj.ptOrigin.y += dc->ptlDCOrig.y; > > - DC_vPrepareDCsForBlit(dc, RectBounds, NULL, RectBounds); > + DC_vPrepareDCsForBlit(dc, &RectBounds, NULL, NULL); > > ret = IntFillEllipse( dc, > CenterX - RadiusX, > @@ -480,8 +480,7 @@ > return TRUE; > } > > - DC_vPrepareDCsForBlit(dc, dc->rosdc.CombinedClip->rclBounds, > - NULL, dc->rosdc.CombinedClip->rclBounds); > + DC_vPrepareDCsForBlit(dc, NULL, NULL, NULL); > > if (dc->pdcattr->ulDirty_ & (DIRTY_FILL | DC_BRUSH_DIRTY)) > DC_vUpdateFillBrush(dc); > @@ -567,7 +566,7 @@ > DestRect.bottom--; > } > > - DC_vPrepareDCsForBlit(dc, DestRect, NULL, DestRect); > + DC_vPrepareDCsForBlit(dc, &DestRect, NULL, NULL); > > if (pdcattr->ulDirty_ & (DIRTY_FILL | DC_BRUSH_DIRTY)) > DC_vUpdateFillBrush(dc); > @@ -796,7 +795,7 @@ > else > { > > - DC_vPrepareDCsForBlit(dc, RectBounds, NULL, RectBounds); > + DC_vPrepareDCsForBlit(dc, &RectBounds, NULL, NULL); > > RtlCopyMemory(&brushTemp, pbrFill, sizeof(brushTemp)); > brushTemp.ptOrigin.x += RectBounds.left - Left; > @@ -962,9 +961,9 @@ > > EXLATEOBJ_vInitialize(&exlo, &gpalRGB, psurf->ppal, 0, 0, 0); > > + DC_vPrepareDCsForBlit(pdc, &rclExtent, NULL, NULL); > + > ASSERT(pdc->rosdc.CombinedClip); > - > - DC_vPrepareDCsForBlit(pdc, rclExtent, NULL, rclExtent); > > bRet = IntEngGradientFill(&psurf->SurfObj, > pdc->rosdc.CombinedClip, > @@ -1091,6 +1090,13 @@ > return TRUE; > } > > + psurf = dc->dclevel.pSurface; > + if (!psurf) > + { > + Ret = FALSE; > + goto cleanup; > + } > + > pdcattr = dc->pdcattr; > > if (pdcattr->ulDirty_ & (DIRTY_FILL | DC_BRUSH_DIRTY)) > @@ -1103,20 +1109,18 @@ > Pt.y = YStart; > IntLPtoDP(dc, (LPPOINT)&Pt, 1); > > - Ret = NtGdiPtInRegion(dc->rosdc.hGCClipRgn, Pt.x, Pt.y); > - if (Ret) > - IntGdiGetRgnBox(dc->rosdc.hGCClipRgn,(LPRECT)&DestRect); > + if (dc->prgnRao) > + { > + Ret = REGION_PtInRegion(dc->prgnRao, Pt.x, Pt.y); > + if (Ret) > + REGION_GetRgnBox(dc->prgnRao ,(LPRECT)&DestRect); > + else > + goto cleanup; > + } > else > - goto cleanup; > - > - DC_vPrepareDCsForBlit(dc, DestRect, NULL, DestRect); > - > - psurf = dc->dclevel.pSurface; > - if (!psurf) > - { > - Ret = FALSE; > - goto cleanup; > - } > + RECTL_vSetRect(&DestRect, 0, psurf->SurfObj.sizlBitmap.cx, 0, psurf->SurfObj.sizlBitmap.cy); > + > + DC_vPrepareDCsForBlit(dc, &DestRect, NULL, NULL); > > EXLATEOBJ_vInitialize(&exlo, &gpalRGB, psurf->ppal, 0, 0xffffff, 0); > > @@ -1127,10 +1131,11 @@ > ConvColor = XLATEOBJ_iXlate(&exlo.xlo, Color); > Ret = DIB_XXBPP_FloodFillSolid(&psurf->SurfObj, &dc->eboFill.BrushObject, &DestRect, &Pt, ConvColor, FillType); > > + DC_vFinishBlit(dc, NULL); > + > EXLATEOBJ_vCleanup(&exlo); > > cleanup: > - DC_vFinishBlit(dc, NULL); > DC_UnlockDc(dc); > return Ret; > } > > Modified: trunk/reactos/win32ss/gdi/ntgdi/freetype.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/freetype… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/freetype.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/freetype.c [iso-8859-1] Wed Jul 23 16:05:47 2014 > @@ -3212,7 +3212,7 @@ > LONGLONG TextLeft, RealXStart; > ULONG TextTop, previous, BackgroundLeft; > FT_Bool use_kerning; > - RECTL DestRect, MaskRect, DummyRect = {0, 0, 0, 0}; > + RECTL DestRect, MaskRect; > POINTL SourcePoint, BrushOrigin; > HBITMAP HSourceGlyph; > SURFOBJ *SourceGlyphSurf; > @@ -3308,7 +3308,7 @@ > DestRect.right += dc->ptlDCOrig.x; > DestRect.bottom += dc->ptlDCOrig.y; > > - DC_vPrepareDCsForBlit(dc, DestRect, NULL, DestRect); > + DC_vPrepareDCsForBlit(dc, &DestRect, NULL, NULL); > > if (pdcattr->ulDirty_ & DIRTY_BACKGROUND) > DC_vUpdateBackgroundBrush(dc); > @@ -3502,7 +3502,7 @@ > BackgroundLeft = (RealXStart + 32) >> 6; > > /* Lock blit with a dummy rect */ > - DC_vPrepareDCsForBlit(dc, DummyRect, NULL, DummyRect); > + DC_vPrepareDCsForBlit(dc, NULL, NULL, NULL); > > psurf = dc->dclevel.pSurface ; > if(!psurf) psurf = psurfDefaultBitmap; > > Modified: trunk/reactos/win32ss/gdi/ntgdi/line.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/line.c?r… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/line.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/line.c [iso-8859-1] Wed Jul 23 16:05:47 2014 > @@ -257,8 +257,7 @@ > if (PATH_IsPathOpen(dc->dclevel)) > return PATH_Polyline(dc, pt, Count); > > - DC_vPrepareDCsForBlit(dc, dc->rosdc.CombinedClip->rclBounds, > - NULL, dc->rosdc.CombinedClip->rclBounds); > + DC_vPrepareDCsForBlit(dc, NULL, NULL, NULL); > > if (pdcattr->ulDirty_ & (DIRTY_FILL | DC_BRUSH_DIRTY)) > DC_vUpdateFillBrush(dc); > @@ -411,7 +410,7 @@ > rcLockRect.right += dc->ptlDCOrig.x; > rcLockRect.bottom += dc->ptlDCOrig.y; > > - DC_vPrepareDCsForBlit(dc, rcLockRect, NULL, rcLockRect); > + DC_vPrepareDCsForBlit(dc, &rcLockRect, NULL, NULL); > > if (dc->pdcattr->ulDirty_ & (DIRTY_LINE | DC_PEN_DIRTY)) > DC_vUpdateLineBrush(dc); > > Modified: trunk/reactos/win32ss/gdi/ntgdi/path.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/path.c?r… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/path.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/path.c [iso-8859-1] Wed Jul 23 16:05:47 2014 > @@ -2511,8 +2511,7 @@ > return FALSE; > } > > - DC_vPrepareDCsForBlit(dc, dc->rosdc.CombinedClip->rclBounds, > - NULL, dc->rosdc.CombinedClip->rclBounds); > + DC_vPrepareDCsForBlit(dc, NULL, NULL, NULL); > > pdcattr = dc->pdcattr; > > @@ -2777,8 +2776,7 @@ > return FALSE; > } > > - DC_vPrepareDCsForBlit(pDc, pDc->rosdc.CombinedClip->rclBounds, > - NULL, pDc->rosdc.CombinedClip->rclBounds); > + DC_vPrepareDCsForBlit(pDc, NULL, NULL, NULL); > > pdcattr = pDc->pdcattr; > > @@ -2822,8 +2820,7 @@ > return FALSE; > } > > - DC_vPrepareDCsForBlit(pDc, pDc->rosdc.CombinedClip->rclBounds, > - NULL, pDc->rosdc.CombinedClip->rclBounds); > + DC_vPrepareDCsForBlit(pDc, NULL, NULL, NULL); > > pdcattr = pDc->pdcattr; > > > Modified: trunk/reactos/win32ss/gdi/ntgdi/region.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/region.c… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/region.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/region.c [iso-8859-1] Wed Jul 23 16:05:47 2014 > @@ -2300,11 +2300,13 @@ > VOID FASTCALL > IntGdiReleaseRaoRgn(PDC pDC) > { > - INT Index = GDI_HANDLE_GET_INDEX(pDC->BaseObject.hHmgr); > - PGDI_TABLE_ENTRY Entry = &GdiHandleTable->Entries[Index]; > - pDC->fs |= DC_FLAG_DIRTY_RAO; > - Entry->Flags |= GDI_ENTRY_VALIDATE_VIS; > - RECTL_vSetEmptyRect(&pDC->erclClip); > + INT Index = GDI_HANDLE_GET_INDEX(pDC->BaseObject.hHmgr); > + PGDI_TABLE_ENTRY Entry = &GdiHandleTable->Entries[Index]; > + pDC->fs |= DC_FLAG_DIRTY_RAO; > + Entry->Flags |= GDI_ENTRY_VALIDATE_VIS; > + RECTL_vSetEmptyRect(&pDC->erclClip); > + REGION_Delete(pDC->prgnRao); > + pDC->prgnRao = NULL; > } > > VOID FASTCALL > @@ -2503,14 +2505,15 @@ > return FALSE; > } > > - NtGdiCombineRgn(tmpVisRgn, tmpVisRgn, dc->rosdc.hGCClipRgn, RGN_AND); > - > visrgn = RGNOBJAPI_Lock(tmpVisRgn, NULL); > if (visrgn == NULL) > { > GreDeleteObject(tmpVisRgn); > return FALSE; > } > + > + if (dc->prgnRao) > + IntGdiCombineRgn(visrgn, visrgn, dc->prgnRao, RGN_AND); > > ClipRegion = IntEngCreateClipRegion(visrgn->rdh.nCount, > visrgn->Buffer, > @@ -2533,6 +2536,29 @@ > > // Fill the region > return bRet; > +} > + > +BOOL > +FASTCALL > +REGION_PtInRegion( > + PREGION prgn, > + INT X, > + INT Y) > +{ > + ULONG i; > + PRECT r; > + > + if (prgn->rdh.nCount > 0 && INRECT(prgn->rdh.rcBound, X, Y)) > + { > + r = prgn->Buffer; > + for (i = 0; i < prgn->rdh.nCount; i++) > + { > + if (INRECT(r[i], X, Y)) > + return TRUE; > + } > + } > + > + return FALSE; > } > > BOOL > @@ -3861,27 +3887,19 @@ > INT Y > ) > { > - PROSRGNDATA rgn; > - ULONG i; > - PRECTL r; > - > - if (!(rgn = RGNOBJAPI_Lock(hRgn, NULL) ) ) > + PREGION prgn; > + BOOL ret; > + > + if (!(prgn = RGNOBJAPI_Lock(hRgn, NULL) ) ) > return FALSE; > > - if (rgn->rdh.nCount > 0 && INRECT(rgn->rdh.rcBound, X, Y)) > - { > - r = rgn->Buffer; > - for (i = 0; i < rgn->rdh.nCount; i++) > - { > - if (INRECT(*r, X, Y)) > - { > - RGNOBJAPI_Unlock(rgn); > - return TRUE; > - } > - r++; > - } > - } > - RGNOBJAPI_Unlock(rgn); > + ret = REGION_PtInRegion(prgn, X, Y); > + > + RGNOBJAPI_Unlock(prgn); > + return ret; > + > + > + RGNOBJAPI_Unlock(prgn); > return FALSE; > } > > > Modified: trunk/reactos/win32ss/gdi/ntgdi/region.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/region.h… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/region.h [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/region.h [iso-8859-1] Wed Jul 23 16:05:47 2014 > @@ -27,6 +27,7 @@ > VOID FASTCALL REGION_UnionRectWithRgn(ROSRGNDATA *rgn, const RECTL *rect); > INT FASTCALL REGION_GetRgnBox(PROSRGNDATA Rgn, RECTL *pRect); > BOOL FASTCALL REGION_RectInRegion(PROSRGNDATA Rgn, const RECTL *rc); > +BOOL FASTCALL REGION_PtInRegion(PREGION, INT, INT); > BOOL FASTCALL REGION_CropAndOffsetRegion(PROSRGNDATA rgnDst, PROSRGNDATA rgnSrc, const RECTL *rect, const POINT *off); > VOID FASTCALL REGION_SetRectRgn(PROSRGNDATA pRgn, INT LeftRect, INT TopRect, INT RightRect, INT BottomRect); > VOID NTAPI REGION_vCleanup(PVOID ObjectBody); > > Modified: trunk/reactos/win32ss/user/ntuser/cursoricon.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/cursor… > ============================================================================== > --- trunk/reactos/win32ss/user/ntuser/cursoricon.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/user/ntuser/cursoricon.c [iso-8859-1] Wed Jul 23 16:05:47 2014 > @@ -1287,7 +1287,7 @@ > RECTL_vOffsetRect(&rcDest, pdc->ptlDCOrig.x, pdc->ptlDCOrig.y); > > /* Prepare the underlying surface */ > - DC_vPrepareDCsForBlit(pdc, rcDest, NULL, rcDest); > + DC_vPrepareDCsForBlit(pdc, &rcDest, NULL, NULL); > > /* Get the clip object */ > pdcClipObj = pdc->rosdc.CombinedClip; > @@ -1472,7 +1472,7 @@ > RECTL_vOffsetRect(&rcDest, pdc->ptlDCOrig.x, pdc->ptlDCOrig.y); > > /* Prepare the underlying surface */ > - DC_vPrepareDCsForBlit(pdc, rcDest, NULL, rcDest); > + DC_vPrepareDCsForBlit(pdc, &rcDest, NULL, NULL); > > /* Get the clip object */ > pdcClipObj = pdc->rosdc.CombinedClip; > > Modified: trunk/reactos/win32ss/user/ntuser/cursoricon_new.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/cursor… > ============================================================================== > --- trunk/reactos/win32ss/user/ntuser/cursoricon_new.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/user/ntuser/cursoricon_new.c [iso-8859-1] Wed Jul 23 16:05:47 2014 > @@ -1195,7 +1195,7 @@ > RECTL_vOffsetRect(&rcDest, pdc->ptlDCOrig.x, pdc->ptlDCOrig.y); > > /* Prepare the underlying surface */ > - DC_vPrepareDCsForBlit(pdc, rcDest, NULL, rcDest); > + DC_vPrepareDCsForBlit(pdc, &rcDest, NULL, NULL); > > /* We now have our destination surface and rectangle */ > psurfDest = pdc->dclevel.pSurface; > > Modified: trunk/reactos/win32ss/user/ntuser/dce.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/dce.h?… > ============================================================================== > --- trunk/reactos/win32ss/user/ntuser/dce.h [iso-8859-1] (original) > +++ trunk/reactos/win32ss/user/ntuser/dce.h [iso-8859-1] Wed Jul 23 16:05:47 2014 > @@ -51,3 +51,5 @@ > HWND FASTCALL UserGethWnd(HDC,PWNDOBJ*); > void FASTCALL DceFreeWindowDCE(PWND); > void FASTCALL DceFreeThreadDCE(PTHREADINFO); > +VOID FASTCALL DceUpdateVisRgn(DCE *Dce, PWND Window, ULONG Flags); > +DCE* FASTCALL DceGetDceFromDC(HDC hdc); > > Modified: trunk/reactos/win32ss/user/ntuser/windc.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/windc.… > ============================================================================== > --- trunk/reactos/win32ss/user/ntuser/windc.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/user/ntuser/windc.c [iso-8859-1] Wed Jul 23 16:05:47 2014 > @@ -46,21 +46,47 @@ > return IntGdiCreateDC(&DriverName, NULL, NULL, NULL, FALSE); > } > > +/* Returns the DCE pointer from the HDC handle */ > +DCE* > +FASTCALL > +DceGetDceFromDC(HDC hdc) > +{ > + LIST_ENTRY* Entry = LEDce.Flink; > + DCE* dce; > + > + while (Entry != &LEDce) > + { > + dce = CONTAINING_RECORD(Entry, DCE, List); > + if (dce->hDC == hdc) > + return dce; > + Entry = Entry->Flink; > + } > + > + return NULL; > +} > + > static > -HRGN FASTCALL > +PREGION FASTCALL > DceGetVisRgn(PWND Window, ULONG Flags, HWND hWndChild, ULONG CFlags) > { > - HRGN VisRgn; > - > - VisRgn = VIS_ComputeVisibleRegion( Window, > - 0 == (Flags & DCX_WINDOW), > - 0 != (Flags & DCX_CLIPCHILDREN), > - 0 != (Flags & DCX_CLIPSIBLINGS)); > - > - if (VisRgn == NULL) > - VisRgn = IntSysCreateRectRgn(0, 0, 0, 0); > - > - return VisRgn; > + PREGION RetRgn; > + HRGN hVisRgn; > + hVisRgn = VIS_ComputeVisibleRegion( Window, > + 0 == (Flags & DCX_WINDOW), > + 0 != (Flags & DCX_CLIPCHILDREN), > + 0 != (Flags & DCX_CLIPSIBLINGS)); > + > + RetRgn = IntSysCreateRectpRgn(0, 0, 0, 0); > + > + if (hVisRgn != NULL) > + { > + PREGION VisRgn = REGION_LockRgn(hVisRgn); > + IntGdiCombineRgn(RetRgn, VisRgn, NULL, RGN_COPY); > + REGION_UnlockRgn(VisRgn); > + GreDeleteObject(hVisRgn); > + } > + > + return RetRgn; > } > > PDCE FASTCALL > @@ -150,6 +176,7 @@ > dc->ptlDCOrig.y = Window->rcClient.top; > } > } > + dc->fs |= DC_FLAG_DIRTY_RAO; > DC_UnlockDc(dc); > } > > @@ -175,10 +202,11 @@ > IntGdiSetHookFlags(Dce->hDC, DCHF_INVALIDATEVISRGN); > } > > -static VOID FASTCALL > +VOID > +FASTCALL > DceUpdateVisRgn(DCE *Dce, PWND Window, ULONG Flags) > { > - HANDLE hRgnVisible = NULL; > + PREGION RgnVisible = NULL; > ULONG DcxFlags; > PWND DesktopWindow; > > @@ -189,7 +217,7 @@ > Parent = Window->spwndParent; > if(!Parent) > { > - hRgnVisible = NULL; > + RgnVisible = NULL; > goto noparent; > } > > @@ -202,23 +230,23 @@ > { > DcxFlags = Flags & ~(DCX_CLIPSIBLINGS | DCX_CLIPCHILDREN | DCX_WINDOW); > } > - hRgnVisible = DceGetVisRgn(Parent, DcxFlags, Window->head.h, Flags); > + RgnVisible = DceGetVisRgn(Parent, DcxFlags, Window->head.h, Flags); > } > else if (Window == NULL) > { > DesktopWindow = UserGetWindowObject(IntGetDesktopWindow()); > if (NULL != DesktopWindow) > { > - hRgnVisible = IntSysCreateRectRgnIndirect(&DesktopWindow->rcWindow); > + RgnVisible = IntSysCreateRectpRgnIndirect(&DesktopWindow->rcWindow); > } > else > { > - hRgnVisible = NULL; > + RgnVisible = NULL; > } > } > else > { > - hRgnVisible = DceGetVisRgn(Window, Flags, 0, 0); > + RgnVisible = DceGetVisRgn(Window, Flags, 0, 0); > } > > noparent: > @@ -226,33 +254,37 @@ > { > if(Dce->hrgnClip != NULL) > { > - NtGdiCombineRgn(hRgnVisible, hRgnVisible, Dce->hrgnClip, RGN_AND); > + PREGION RgnClip = REGION_LockRgn(Dce->hrgnClip); > + IntGdiCombineRgn(RgnVisible, RgnVisible, RgnClip, RGN_AND); > + REGION_UnlockRgn(RgnClip); > } > else > { > - if(hRgnVisible != NULL) > - { > - GreDeleteObject(hRgnVisible); > - } > - hRgnVisible = IntSysCreateRectRgn(0, 0, 0, 0); > - } > - } > - else if (Flags & DCX_EXCLUDERGN && Dce->hrgnClip != NULL) > - { > - NtGdiCombineRgn(hRgnVisible, hRgnVisible, Dce->hrgnClip, RGN_DIFF); > + if(RgnVisible != NULL) > + { > + REGION_Delete(RgnVisible); > + } > + RgnVisible = IntSysCreateRectpRgn(0, 0, 0, 0); > + } > + } > + else if ((Flags & DCX_EXCLUDERGN) && Dce->hrgnClip != NULL) > + { > + PREGION RgnClip = REGION_LockRgn(Dce->hrgnClip); > + IntGdiCombineRgn(RgnVisible, RgnVisible, RgnClip, RGN_DIFF); > + REGION_UnlockRgn(RgnClip); > } > > Dce->DCXFlags &= ~DCX_DCEDIRTY; > - GdiSelectVisRgn(Dce->hDC, hRgnVisible); > + GdiSelectVisRgn(Dce->hDC, RgnVisible); > > if (VerifyWnd(Window)) // Window maybe dead by this time before finishing the DCE release. > { > IntEngWindowChanged(Window, WOC_RGN_CLIENT); > } > > - if (hRgnVisible != NULL) > - { > - GreDeleteObject(hRgnVisible); > + if (RgnVisible != NULL) > + { > + REGION_Delete(RgnVisible); > } > } > > @@ -889,10 +921,10 @@ > dc->ptlDCOrig.y = CurrentWindow->rcClient.top; > } > > - if (NULL != dc->rosdc.hClipRgn) > + if (NULL != dc->dclevel.prgnClip) > { > - NtGdiOffsetRgn(dc->rosdc.hClipRgn, DeltaX, DeltaY); > - CLIPPING_UpdateGCRegion(dc); > + IntGdiOffsetRgn(dc->dclevel.prgnClip, DeltaX, DeltaY); > + dc->fs |= DC_FLAG_DIRTY_RAO; > } > if (NULL != pDCE->hrgnClip) > { > > >

1 0

Re: [ros-dev] [ros-diffs] [ekohl] 63713: [BOOTDATA] Add / enable NLS settings for Arabic, Azeri, Kyrgyz, Latvian, Tatar and Uzbek. CORE-8348 #resolve
by Hermès BÉLUSCA - MAÏTO 13 Jul '14

13 Jul '14

Hello Eric, Are those changes (mentioned below) necessary for NLS settings ? Cheers, Hermès. ------------------------------------------------------------- Author: ekohl Date: Sun Jul 13 16:40:44 2014 New Revision: 63713 URL: http://svn.reactos.org/svn/reactos?rev=63713&view=rev Log: [BOOTDATA] Add / enable NLS settings for Arabic, Azeri, Kyrgyz, Latvian, Tatar and Uzbek. CORE-8348 #resolve Modified: trunk/reactos/boot/bootdata/hivesys.inf Modified: trunk/reactos/boot/bootdata/hivesys.inf URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/hivesys.inf?r ev=63713&r1=63712&r2=63713&view=diff ============================================================================ == --- trunk/reactos/boot/bootdata/hivesys.inf [iso-8859-1] (original) +++ trunk/reactos/boot/bootdata/hivesys.inf [iso-8859-1] Sun Jul 13 16:40:44 2014 [...] ; PNP Root device HKLM,"SYSTEM\CurrentControlSet\Enum\HTREE\ROOT\0","",0x00000000,"" + +HKLM,"SYSTEM\CurrentControlSet\Hardware Profiles",,0x00000012 +HKLM,"SYSTEM\CurrentControlSet\Hardware Profiles\0000",,0x00000012 +HKLM,"SYSTEM\CurrentControlSet\Hardware Profiles\0000\Software",,0x00000012 +HKLM,"SYSTEM\CurrentControlSet\Hardware Profiles\0000\System",,0x00000012 ; Afd driver HKLM,"SYSTEM\CurrentControlSet\Services\Afd","ErrorControl",0x00010001,0x000 00001 @@ -1963,7 +2003,7 @@ HKLM,"SYSTEM\Setup","SystemSetupInProgress",0x00010001,0x00000001 ; Debug channels -;HKLM,"SYSTEM\CurrentControlSet\Control\Session Manager\Environment","DEBUGCHANNEL",0x00020000,"+ole,+rpc" +HKLM,"SYSTEM\CurrentControlSet\Control\Session Manager\Environment","DEBUGCHANNEL",0x00020000,"+sam,+netapi32,+msports,+dev mgr" ; Winsrv configuration HKLM,"SYSTEM\CurrentControlSet\Control\PriorityControl",,0x00000012

2 1

Re: [ros-dev] [ros-diffs] [jgardou] 63700: [NTOSKRNL] - Use ZwSetValueKey instead of NtSetValueKey - Properly probe and copy parameters when NtSetValueKey is called from UMode CORE-7738 #resolve #comment fixed in r63700
by Alex Ionescu 10 Jul '14

10 Jul '14

Calling Nt in those functions was by design, and is how Windows does it as well. I can explain Nt vs Zw (for the 100th time) as needed, but for now, I'd kindly ask for a revert please. Second, the new code does not conform to formatting and style guidelines. Please fix the code before comitting. Best regards, Alex Ionescu On Tue, Jul 8, 2014 at 11:42 AM, <jgardou(a)svn.reactos.org> wrote: > Author: jgardou > Date: Tue Jul 8 18:42:20 2014 > New Revision: 63700 > > URL: http://svn.reactos.org/svn/reactos?rev=63700&view=rev > Log: > [NTOSKRNL] > - Use ZwSetValueKey instead of NtSetValueKey > - Properly probe and copy parameters when NtSetValueKey is called from > UMode > CORE-7738 #resolve #comment fixed in r63700 > > Modified: > trunk/reactos/ntoskrnl/config/cmconfig.c > trunk/reactos/ntoskrnl/config/cmsysini.c > trunk/reactos/ntoskrnl/config/i386/cmhardwr.c > trunk/reactos/ntoskrnl/config/ntapi.c > trunk/reactos/ntoskrnl/config/powerpc/cmhardwr.c > trunk/reactos/ntoskrnl/ex/init.c > trunk/reactos/ntoskrnl/io/iomgr/bootlog.c > > Modified: trunk/reactos/ntoskrnl/config/cmconfig.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/config/cmconfig.c… > > ============================================================================== > --- trunk/reactos/ntoskrnl/config/cmconfig.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/config/cmconfig.c [iso-8859-1] Tue Jul 8 > 18:42:20 2014 > @@ -97,7 +97,7 @@ > > /* Setup the component information key */ > RtlInitUnicodeString(&ValueName, L"Component Information"); > - Status = NtSetValueKey(KeyHandle, > + Status = ZwSetValueKey(KeyHandle, > &ValueName, > 0, > REG_BINARY, > @@ -124,7 +124,7 @@ > if (NT_SUCCESS(Status)) > { > /* Save the identifier in the registry */ > - Status = NtSetValueKey(KeyHandle, > + Status = ZwSetValueKey(KeyHandle, > &ValueName, > 0, > REG_SZ, > @@ -178,7 +178,7 @@ > CmpConfigurationData->BusNumber = BusNumber; > > /* Save the actual data */ > - Status = NtSetValueKey(KeyHandle, > + Status = ZwSetValueKey(KeyHandle, > &ValueName, > 0, > REG_FULL_RESOURCE_DESCRIPTOR, > > Modified: trunk/reactos/ntoskrnl/config/cmsysini.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/config/cmsysini.c… > > ============================================================================== > --- trunk/reactos/ntoskrnl/config/cmsysini.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/config/cmsysini.c [iso-8859-1] Tue Jul 8 > 18:42:20 2014 > @@ -416,7 +416,7 @@ > > /* Key opened, now write to the key */ > RtlInitUnicodeString(&KeyName, L"SystemStartOptions"); > - Status = NtSetValueKey(KeyHandle, > + Status = ZwSetValueKey(KeyHandle, > &KeyName, > 0, > REG_SZ, > @@ -427,7 +427,7 @@ > /* Setup value name for system boot device in ARC format */ > RtlInitUnicodeString(&KeyName, L"SystemBootDevice"); > RtlCreateUnicodeStringFromAsciiz(&ValueName, > LoaderBlock->ArcBootDeviceName); > - Status = NtSetValueKey(KeyHandle, > + Status = ZwSetValueKey(KeyHandle, > &KeyName, > 0, > REG_SZ, > @@ -474,7 +474,7 @@ > OBJ_CASE_INSENSITIVE, > NULL, > NULL); > - Status = NtOpenKey(&SelectHandle, KEY_READ, &ObjectAttributes); > + Status = ZwOpenKey(&SelectHandle, KEY_READ, &ObjectAttributes); > if (!NT_SUCCESS(Status)) > { > /* ReactOS Hack: Hard-code current to 001 for SetupLdr */ > @@ -488,16 +488,17 @@ > OBJ_CASE_INSENSITIVE, > NULL, > NULL); > - Status = NtCreateKey(&KeyHandle, > + Status = ZwCreateKey(&KeyHandle, > KEY_ALL_ACCESS, > &ObjectAttributes, > 0, > NULL, > 0, > &Disposition); > - if (!NT_SUCCESS(Status)) return Status; > - > - /* Don't need the handle */ > + if (!NT_SUCCESS(Status)) > + return Status; > + > + /* We don't need the handle */ > ZwClose(KeyHandle); > > /* Use hard-coded setting */ > @@ -533,7 +534,7 @@ > OBJ_CASE_INSENSITIVE, > NULL, > NULL); > - Status = NtCreateKey(&KeyHandle, > + Status = ZwCreateKey(&KeyHandle, > KEY_CREATE_LINK, > &ObjectAttributes, > 0, > @@ -557,7 +558,7 @@ > Status = RtlAnsiStringToUnicodeString(&KeyName, &TempString, FALSE); > > /* Set the value */ > - Status = NtSetValueKey(KeyHandle, > + Status = ZwSetValueKey(KeyHandle, > &CmSymbolicLinkValueName, > 0, > REG_LINK, > @@ -572,7 +573,7 @@ > KeyHandle, > NULL); > Status = NtOpenKey(&ConfigHandle, KEY_READ, &ObjectAttributes); > - NtClose(KeyHandle); > + ZwClose(KeyHandle); > > /* Check if we don't have one */ > if (!NT_SUCCESS(Status)) > @@ -689,7 +690,7 @@ > ASSERT(STATUS_SUCCESS == Status); > > /* Set it */ > - Status = NtSetValueKey(KeyHandle, > + Status = ZwSetValueKey(KeyHandle, > &CmSymbolicLinkValueName, > 0, > REG_LINK, > @@ -2180,7 +2181,7 @@ > RtlInitUnicodeString(&ValueData, > Buffer); > > - NtSetValueKey(CurrentVersionKeyHandle, > + ZwSetValueKey(CurrentVersionKeyHandle, > &ValueName, > 0, > REG_SZ, > > Modified: trunk/reactos/ntoskrnl/config/i386/cmhardwr.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/config/i386/cmhar… > > ============================================================================== > --- trunk/reactos/ntoskrnl/config/i386/cmhardwr.c [iso-8859-1] > (original) > +++ trunk/reactos/ntoskrnl/config/i386/cmhardwr.c [iso-8859-1] Tue > Jul 8 18:42:20 2014 > @@ -268,7 +268,7 @@ > > /* Set the value */ > RtlInitUnicodeString(&ValueName, L"PhysicalAddressExtension"); > - NtSetValueKey(KeyHandle, > + ZwSetValueKey(KeyHandle, > &ValueName, > 0, > REG_DWORD, > @@ -463,7 +463,7 @@ > > /* Add it to the registry */ > RtlInitUnicodeString(&ValueName, > L"ProcessorNameString"); > - Status = NtSetValueKey(KeyHandle, > + Status = ZwSetValueKey(KeyHandle, > &ValueName, > 0, > REG_SZ, > @@ -486,7 +486,7 @@ > > /* Add it to the registry */ > RtlInitUnicodeString(&ValueName, L"VendorIdentifier"); > - Status = NtSetValueKey(KeyHandle, > + Status = ZwSetValueKey(KeyHandle, > &ValueName, > 0, > REG_SZ, > @@ -502,7 +502,7 @@ > { > /* Add them to the registry */ > RtlInitUnicodeString(&ValueName, L"FeatureSet"); > - Status = NtSetValueKey(KeyHandle, > + Status = ZwSetValueKey(KeyHandle, > &ValueName, > 0, > REG_DWORD, > @@ -515,7 +515,7 @@ > { > /* Add it to the registry */ > RtlInitUnicodeString(&ValueName, L"~MHz"); > - Status = NtSetValueKey(KeyHandle, > + Status = ZwSetValueKey(KeyHandle, > &ValueName, > 0, > REG_DWORD, > @@ -528,7 +528,7 @@ > { > /* Add it to the registry */ > RtlInitUnicodeString(&ValueName, L"Update Signature"); > - Status = NtSetValueKey(KeyHandle, > + Status = ZwSetValueKey(KeyHandle, > &ValueName, > 0, > REG_BINARY, > @@ -621,7 +621,7 @@ > > /* Write the date into the registry */ > RtlInitUnicodeString(&ValueName, L"SystemBiosDate"); > - Status = NtSetValueKey(SystemHandle, > + Status = ZwSetValueKey(SystemHandle, > &ValueName, > 0, > REG_SZ, > @@ -643,7 +643,7 @@ > if (NT_SUCCESS(Status)) > { > /* Save it to the registry */ > - Status = NtSetValueKey(BiosHandle, > + Status = ZwSetValueKey(BiosHandle, > &ValueName, > 0, > REG_SZ, > @@ -703,7 +703,7 @@ > > /* Write the BIOS Version to the registry */ > RtlInitUnicodeString(&ValueName, L"SystemBiosVersion"); > - Status = NtSetValueKey(SystemHandle, > + Status = ZwSetValueKey(SystemHandle, > &ValueName, > 0, > REG_MULTI_SZ, > @@ -746,7 +746,7 @@ > > /* Write the date into the registry */ > RtlInitUnicodeString(&ValueName, L"VideoBiosDate"); > - Status = NtSetValueKey(SystemHandle, > + Status = ZwSetValueKey(SystemHandle, > &ValueName, > 0, > REG_SZ, > @@ -801,7 +801,7 @@ > > /* Write the BIOS Version to the registry */ > RtlInitUnicodeString(&ValueName, L"VideoBiosVersion"); > - Status = NtSetValueKey(SystemHandle, > + Status = ZwSetValueKey(SystemHandle, > &ValueName, > 0, > REG_MULTI_SZ, > > Modified: trunk/reactos/ntoskrnl/config/ntapi.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/config/ntapi.c?re… > > ============================================================================== > --- trunk/reactos/ntoskrnl/config/ntapi.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/config/ntapi.c [iso-8859-1] Tue Jul 8 > 18:42:20 2014 > @@ -33,7 +33,10 @@ > CM_PARSE_CONTEXT ParseContext = {0}; > HANDLE Handle; > PAGED_CODE(); > - DPRINT("NtCreateKey(OB name %wZ)\n", ObjectAttributes->ObjectName); > + > + DPRINT("NtCreateKey(Path: %wZ, Root %x, Access: %x, CreateOptions > %x)\n", > + ObjectAttributes->ObjectName, ObjectAttributes->RootDirectory, > + DesiredAccess, CreateOptions); > > /* Check for user-mode caller */ > if (PreviousMode != KernelMode) > @@ -60,7 +63,8 @@ > sizeof(OBJECT_ATTRIBUTES), > sizeof(ULONG)); > > - if (Disposition) ProbeForWriteUlong(Disposition); > + if (Disposition) > + ProbeForWriteUlong(Disposition); > } > _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > { > @@ -101,6 +105,8 @@ > } > _SEH2_END; > > + DPRINT("Returning handle %x, Status %x.\n", Handle, Status); > + > /* Return status */ > return Status; > } > @@ -116,7 +122,8 @@ > NTSTATUS Status; > KPROCESSOR_MODE PreviousMode = ExGetPreviousMode(); > PAGED_CODE(); > - DPRINT("NtOpenKey(OB 0x%wZ)\n", ObjectAttributes->ObjectName); > + DPRINT("NtOpenKey(Path: %wZ, Root %x, Access: %x)\n", > + ObjectAttributes->ObjectName, > ObjectAttributes->RootDirectory, DesiredAccess); > > /* Check for user-mode caller */ > if (PreviousMode != KernelMode) > @@ -166,6 +173,8 @@ > _SEH2_END; > } > > + DPRINT("Returning handle %x, Status %x.\n", Handle, Status); > + > /* Return status */ > return Status; > } > @@ -301,6 +310,7 @@ > > /* Dereference and return status */ > ObDereferenceObject(KeyObject); > + DPRINT("Returning status %x.\n", Status); > return Status; > } > > @@ -604,14 +614,52 @@ > IN PVOID Data, > IN ULONG DataSize) > { > - NTSTATUS Status; > - PCM_KEY_BODY KeyObject; > + NTSTATUS Status = STATUS_SUCCESS; > + PCM_KEY_BODY KeyObject = NULL; > REG_SET_VALUE_KEY_INFORMATION SetValueKeyInfo; > REG_POST_OPERATION_INFORMATION PostOperationInfo; > - UNICODE_STRING ValueNameCopy = *ValueName; > + UNICODE_STRING ValueNameCopy; > + KPROCESSOR_MODE PreviousMode; > + > PAGED_CODE(); > + > + PreviousMode = ExGetPreviousMode(); > + > + if (Data && !DataSize) > + return STATUS_INVALID_PARAMETER; > + > + /* Probe and copy the data */ > + if ((PreviousMode != KernelMode) && Data) > + { > + PVOID DataCopy = ExAllocatePoolWithTag(PagedPool, DataSize, > TAG_CM); > + if (!DataCopy) > + return STATUS_NO_MEMORY; > + _SEH2_TRY > + { > + ProbeForRead(Data, DataSize, 1); > + RtlCopyMemory(DataCopy, Data, DataSize); > + } > + _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > + { > + Status = _SEH2_GetExceptionCode(); > + } > + _SEH2_END; > + > + if (!NT_SUCCESS(Status)) > + { > + ExFreePoolWithTag(DataCopy, TAG_CM); > + return Status; > + } > + Data = DataCopy; > + } > + > + /* Capture the string */ > + Status = ProbeAndCaptureUnicodeString(&ValueNameCopy, PreviousMode, > ValueName); > + if (!NT_SUCCESS(Status)) > + goto end; > + > DPRINT("NtSetValueKey() KH 0x%p, VN '%wZ', TI %x, T %lu, DS %lu\n", > - KeyHandle, ValueName, TitleIndex, Type, DataSize); > + KeyHandle, &ValueNameCopy, TitleIndex, Type, DataSize); > > /* Verify that the handle is valid and is a registry key */ > Status = ObReferenceObjectByHandle(KeyHandle, > @@ -620,7 +668,8 @@ > ExGetPreviousMode(), > (PVOID*)&KeyObject, > NULL); > - if (!NT_SUCCESS(Status)) return Status; > + if (!NT_SUCCESS(Status)) > + goto end; > > /* Make sure the name is aligned, not too long, and the data under > 4GB */ > if ( (ValueNameCopy.Length > 32767) || > @@ -628,8 +677,8 @@ > (DataSize > 0x80000000)) > { > /* Fail */ > - ObDereferenceObject(KeyObject); > - return STATUS_INVALID_PARAMETER; > + Status = STATUS_INVALID_PARAMETER; > + goto end; > } > > /* Ignore any null characters at the end */ > @@ -644,14 +693,14 @@ > if (KeyObject->KeyControlBlock->ExtFlags & CM_KCB_READ_ONLY_KEY) > { > /* Fail */ > - ObDereferenceObject(KeyObject); > - return STATUS_ACCESS_DENIED; > + Status = STATUS_ACCESS_DENIED; > + goto end; > } > > /* Setup callback */ > PostOperationInfo.Object = (PVOID)KeyObject; > SetValueKeyInfo.Object = (PVOID)KeyObject; > - SetValueKeyInfo.ValueName = ValueName; > + SetValueKeyInfo.ValueName = &ValueNameCopy; > SetValueKeyInfo.TitleIndex = TitleIndex; > SetValueKeyInfo.Type = Type; > SetValueKeyInfo.Data = Data; > @@ -673,8 +722,13 @@ > PostOperationInfo.Status = Status; > CmiCallRegisteredCallbacks(RegNtPostSetValueKey, &PostOperationInfo); > > +end: > /* Dereference and return status */ > - ObDereferenceObject(KeyObject); > + if (KeyObject) > + ObDereferenceObject(KeyObject); > + ReleaseCapturedUnicodeString(&ValueNameCopy, PreviousMode); > + if ((PreviousMode != KernelMode) && Data) > + ExFreePoolWithTag(Data, TAG_CM); > return Status; > } > > > Modified: trunk/reactos/ntoskrnl/config/powerpc/cmhardwr.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/config/powerpc/cm… > > ============================================================================== > --- trunk/reactos/ntoskrnl/config/powerpc/cmhardwr.c [iso-8859-1] > (original) > +++ trunk/reactos/ntoskrnl/config/powerpc/cmhardwr.c [iso-8859-1] Tue > Jul 8 18:42:20 2014 > @@ -267,7 +267,7 @@ > > /* Set the value */ > RtlInitUnicodeString(&ValueName, L"PhysicalAddressExtension"); > - NtSetValueKey(KeyHandle, > + ZwSetValueKey(KeyHandle, > &ValueName, > 0, > REG_DWORD, > @@ -465,7 +465,7 @@ > > /* Add it to the registry */ > RtlInitUnicodeString(&ValueName, > L"ProcessorNameString"); > - Status = NtSetValueKey(KeyHandle, > + Status = ZwSetValueKey(KeyHandle, > &ValueName, > 0, > REG_SZ, > @@ -488,7 +488,7 @@ > > /* Add it to the registry */ > RtlInitUnicodeString(&ValueName, L"VendorIdentifier"); > - Status = NtSetValueKey(KeyHandle, > + Status = ZwSetValueKey(KeyHandle, > &ValueName, > 0, > REG_SZ, > @@ -504,7 +504,7 @@ > { > /* Add them to the registry */ > RtlInitUnicodeString(&ValueName, L"FeatureSet"); > - Status = NtSetValueKey(KeyHandle, > + Status = ZwSetValueKey(KeyHandle, > &ValueName, > 0, > REG_DWORD, > @@ -517,7 +517,7 @@ > { > /* Add it to the registry */ > RtlInitUnicodeString(&ValueName, L"~MHz"); > - Status = NtSetValueKey(KeyHandle, > + Status = ZwSetValueKey(KeyHandle, > &ValueName, > 0, > REG_DWORD, > @@ -530,7 +530,7 @@ > { > /* Add it to the registry */ > RtlInitUnicodeString(&ValueName, L"Update Signature"); > - Status = NtSetValueKey(KeyHandle, > + Status = ZwSetValueKey(KeyHandle, > &ValueName, > 0, > REG_BINARY, > @@ -623,7 +623,7 @@ > > /* Write the date into the registry */ > RtlInitUnicodeString(&ValueName, L"SystemBiosDate"); > - Status = NtSetValueKey(SystemHandle, > + Status = ZwSetValueKey(SystemHandle, > &ValueName, > 0, > REG_SZ, > @@ -645,7 +645,7 @@ > if (NT_SUCCESS(Status)) > { > /* Save it to the registry */ > - Status = NtSetValueKey(BiosHandle, > + Status = ZwSetValueKey(BiosHandle, > &ValueName, > 0, > REG_SZ, > @@ -705,7 +705,7 @@ > > /* Write the BIOS Version to the registry */ > RtlInitUnicodeString(&ValueName, L"SystemBiosVersion"); > - Status = NtSetValueKey(SystemHandle, > + Status = ZwSetValueKey(SystemHandle, > &ValueName, > 0, > REG_MULTI_SZ, > @@ -749,7 +749,7 @@ > > /* Write the date into the registry */ > RtlInitUnicodeString(&ValueName, L"VideoBiosDate"); > - Status = NtSetValueKey(SystemHandle, > + Status = ZwSetValueKey(SystemHandle, > &ValueName, > 0, > REG_SZ, > @@ -804,7 +804,7 @@ > > /* Write the BIOS Version to the registry */ > RtlInitUnicodeString(&ValueName, L"VideoBiosVersion"); > - Status = NtSetValueKey(SystemHandle, > + Status = ZwSetValueKey(SystemHandle, > &ValueName, > 0, > REG_MULTI_SZ, > > Modified: trunk/reactos/ntoskrnl/ex/init.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ex/init.c?rev=637… > > ============================================================================== > --- trunk/reactos/ntoskrnl/ex/init.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ex/init.c [iso-8859-1] Tue Jul 8 18:42:20 > 2014 > @@ -1853,7 +1853,7 @@ > { > /* Write the safe boot type */ > RtlInitUnicodeString(&KeyName, L"OptionValue"); > - NtSetValueKey(OptionHandle, > + ZwSetValueKey(OptionHandle, > &KeyName, > 0, > REG_DWORD, > @@ -1866,7 +1866,7 @@ > /* Remember this for later */ > Disposition = TRUE; > RtlInitUnicodeString(&KeyName, L"UseAlternateShell"); > - NtSetValueKey(OptionHandle, > + ZwSetValueKey(OptionHandle, > &KeyName, > 0, > REG_DWORD, > > Modified: trunk/reactos/ntoskrnl/io/iomgr/bootlog.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/iomgr/bootlog.… > > ============================================================================== > --- trunk/reactos/ntoskrnl/io/iomgr/bootlog.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/io/iomgr/bootlog.c [iso-8859-1] Tue Jul 8 > 18:42:20 2014 > @@ -135,7 +135,7 @@ > > if (!NT_SUCCESS(Status)) > { > - DPRINT1("NtSetValueKey() failed (Status %lx)\n", Status); > + DPRINT1("ZwSetValueKey() failed (Status %lx)\n", Status); > } > else > { > > >

6 6

ReactOS featured in RedUsers
by victor martinez 10 Jul '14

10 Jul '14

Hi guys! Good news! ReactOS has been featured in RedUsers, one of the best southamerican IT blogs. http://www.redusers.com/noticias/entrevista-reactos-clon-windows-open-sourc… Of course it has spread fast as powder around all blogs there: http://goo.gl/BovDKU Hopefuly tomorrow I will have the Shop online and running (we can't miss the strike!) with my account or the German one, whatever happens first. Cool USBs ReactOS Community Special Edition! You can't miss it! Best regards, Victor

1 0

Status Meeting (June/July 2014)
by Aleksey Bragin 04 Jul '14

04 Jul '14

Hello, Let me invite you to the monthly status meeting taking place next Thursday, 3rd of July, 19:00 UTC. The meeting is one week off from the classic scheme due to various reasons (previous meeting was too close, and, you know, Germany - USA on Thursday). IRC service will only be started shortly before the meeting. Your participation passwords and server address will be emailed to you shortly before the meeting starts, and they are going to be different once again as they are not stored in any database. Hopefully it's not much of inconvenience. If someone still is not getting passwords sent before a meeting - please email Pierre before the meeting started to get one. Please send agenda proposals to me before the meeting, so that we can start with a proposed agenda. Also all developers, please, may I so kindly ask you to prepare a very brief one-two lines message containing two things: 1. What you did since the previous meeting 2. What you are going to do in the coming month This is needed to understand who is working on what, to plan things, etc. Thanks, I hope it's not that much to ask for. Prepare that in advance! Everyone will have max 1 minute! Regards, Aleksey Bragin

6 6

Re: [ros-dev] [ros-diffs] [hbelusca] 63610: [WIN32K] There is a bug in win32k (who would have thought that?) that consists in holding a winstation spinlock while running PAGED_CODE MmCopyToCaller function, when building the...
by Alex Ionescu 27 Jun '14

27 Jun '14

Win32k.sys is supposed to use MmPageEntireDriver, as such, it should run 100% at passive only. Best regards, Alex Ionescu On Tue, Jun 17, 2014 at 10:01 PM, <hbelusca(a)svn.reactos.org> wrote: > Author: hbelusca > Date: Tue Jun 17 20:01:23 2014 > New Revision: 63610 > > URL: http://svn.reactos.org/svn/reactos?rev=63610&view=rev > Log: > [WIN32K] > There is a bug in win32k (who would have thought that?) that consists in > holding a winstation spinlock while running PAGED_CODE MmCopyToCaller > function, when building the list of desktops of a given window station (the > bug is easily triggerable when calling EnumDesktopsW). Since this lock is > never used in anyplace but in this function, which, by the way, is just a > reader function that fills user buffer, I consider that it is safe to > remove this lock. However I want approval from win32k specialists. Hence I > just disable the code with a define USE_WINSTA_LOCK. If this lock is really > needed, please rewrite the BuildDesktopNameList function !! Otherwise > remove this lock and the associated code !! > This is a blocker for the shutdown code. > > Modified: > trunk/reactos/win32ss/user/ntuser/winsta.c > trunk/reactos/win32ss/user/ntuser/winsta.h > > Modified: trunk/reactos/win32ss/user/ntuser/winsta.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/winsta… > > ============================================================================== > --- trunk/reactos/win32ss/user/ntuser/winsta.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/user/ntuser/winsta.c [iso-8859-1] Tue Jun 17 > 20:01:23 2014 > @@ -451,7 +451,9 @@ > /* Initialize the window station */ > RtlZeroMemory(WindowStationObject, sizeof(WINSTATION_OBJECT)); > > +#ifdef USE_WINSTA_LOCK > KeInitializeSpinLock(&WindowStationObject->Lock); > +#endif > InitializeListHead(&WindowStationObject->DesktopListHead); > Status = RtlCreateAtomTable(37, &WindowStationObject->AtomTable); > WindowStationObject->Name = WindowStationName; > @@ -1203,7 +1205,9 @@ > { > NTSTATUS Status; > PWINSTATION_OBJECT WindowStation; > +#ifdef USE_WINSTA_LOCK > KIRQL OldLevel; > +#endif > PLIST_ENTRY DesktopEntry; > PDESKTOP DesktopObject; > DWORD EntryCount; > @@ -1220,7 +1224,9 @@ > return Status; > } > > +#ifdef USE_WINSTA_LOCK > KeAcquireSpinLock(&WindowStation->Lock, &OldLevel); > +#endif > > /* > * Count the required size of buffer. > @@ -1242,7 +1248,9 @@ > Status = MmCopyToCaller(pRequiredSize, &ReturnLength, > sizeof(ULONG)); > if (! NT_SUCCESS(Status)) > { > +#ifdef USE_WINSTA_LOCK > KeReleaseSpinLock(&WindowStation->Lock, OldLevel); > +#endif > ObDereferenceObject(WindowStation); > return STATUS_BUFFER_TOO_SMALL; > } > @@ -1253,7 +1261,9 @@ > */ > if (dwSize < ReturnLength) > { > +#ifdef USE_WINSTA_LOCK > KeReleaseSpinLock(&WindowStation->Lock, OldLevel); > +#endif > ObDereferenceObject(WindowStation); > return STATUS_BUFFER_TOO_SMALL; > } > @@ -1264,7 +1274,9 @@ > Status = MmCopyToCaller(lpBuffer, &EntryCount, sizeof(DWORD)); > if (! NT_SUCCESS(Status)) > { > +#ifdef USE_WINSTA_LOCK > KeReleaseSpinLock(&WindowStation->Lock, OldLevel); > +#endif > ObDereferenceObject(WindowStation); > return Status; > } > @@ -1280,7 +1292,9 @@ > Status = MmCopyToCaller(lpBuffer, DesktopName.Buffer, > DesktopName.Length); > if (! NT_SUCCESS(Status)) > { > +#ifdef USE_WINSTA_LOCK > KeReleaseSpinLock(&WindowStation->Lock, OldLevel); > +#endif > ObDereferenceObject(WindowStation); > return Status; > } > @@ -1288,7 +1302,9 @@ > Status = MmCopyToCaller(lpBuffer, &NullWchar, sizeof(WCHAR)); > if (! NT_SUCCESS(Status)) > { > +#ifdef USE_WINSTA_LOCK > KeReleaseSpinLock(&WindowStation->Lock, OldLevel); > +#endif > ObDereferenceObject(WindowStation); > return Status; > } > @@ -1298,7 +1314,9 @@ > /* > * Clean up > */ > +#ifdef USE_WINSTA_LOCK > KeReleaseSpinLock(&WindowStation->Lock, OldLevel); > +#endif > ObDereferenceObject(WindowStation); > > return STATUS_SUCCESS; > > Modified: trunk/reactos/win32ss/user/ntuser/winsta.h > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/winsta… > > ============================================================================== > --- trunk/reactos/win32ss/user/ntuser/winsta.h [iso-8859-1] (original) > +++ trunk/reactos/win32ss/user/ntuser/winsta.h [iso-8859-1] Tue Jun 17 > 20:01:23 2014 > @@ -7,11 +7,16 @@ > #define WSS_LOCKED (1) > #define WSS_NOINTERACTIVE (2) > > +// Uncomment for using WinSta spinlock > +// #define USE_WINSTA_LOCK > + > typedef struct _WINSTATION_OBJECT > { > DWORD dwSessionId; > > +#ifdef USE_WINSTA_LOCK > KSPIN_LOCK Lock; > +#endif > UNICODE_STRING Name; > LIST_ENTRY DesktopListHead; > PRTL_ATOM_TABLE AtomTable; > > >

3 5

Jira comments
by Hermès BÉLUSCA - MAÏTO 27 Jun '14

27 Jun '14

Hey guys ! It seems that suddently Jira SVN comments work again. How is it possible? H.

3 3

[CONSRV] Ensure szMenuStringBack is NULL terminated to prevent possible buffer overread and fix char to wchar_t assignment.
by Vyronas Tsingaras 25 Jun '14

25 Jun '14

Is this patch acceptable? Please kindly explain any possible mistakes.

2 1

Re: [ros-dev] [ros-diffs] [jgardou] 63642: [SETUPAPI_APITEST] - Add a test that shows that SetupDiGetClassDevsExW doesn't fail on non-existing GUID
by Timo Kreuzer 25 Jun '14

25 Jun '14

1 0

CRT changes
by Ged Murphy 19 Jun '14

19 Jun '14

Some interesting changes are coming to the CRT which the VS builds will need to prepare for. The obvious one is the %s/%S format changes http://blogs.msdn.com/b/vcblog/archive/2014/06/18/crt-features-fixes-and-bre aking-changes-in-visual-studio-14-ctp1.aspx Ged.

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 63610: [WIN32K] There is a bug in win32k (who would have thought that?) that consists in holding a winstation spinlock while running PAGED_CODE MmCopyToCaller function, when building the...
by Timo Kreuzer 18 Jun '14

18 Jun '14

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 63599: [TASKMGR]: Use the EndTask API to kill tasks.
by Pierre Schweitzer 16 Jun '14

16 Jun '14

On 15/06/2014 19:47, hbelusca(a)svn.reactos.org wrote: > + /* Trick: on Windows, pressing the CTRL key forces the task to be ended */ > + BOOL ForceEndTask = !!(GetKeyState(VK_CONTROL) & 0x8000); > + Was it really meant to be '!!'? -- Pierre Schweitzer<pierre at reactos.org> System Administrator ReactOS Foundation

4 4

Re: [ros-dev] Upgrade complete
by Alexander Rechitskiy 15 Jun '14

15 Jun '14

All is down! > Fixed. > > On 15/06/2014 00:56, Alexander Rechitskiy wrote: > >> https://code.reactos.org/ does NOT work >> 15.06.2014, 02:40, "Pierre Schweitzer" <pierre(a)reactos.org>: >>> As a side note, upgrade to Fisheye 3.4.4 didn't fix ONLINE-461 (which was the >>> main reason behind the upgrade). >>> >>> On 15/06/2014 00:36, Zachary Gorden wrote: >>>> Fisheye was upgraded successfully, Jira went off the rails and took us >>>> about three hours to recover from. Please report any data loss as we had to >>>> restore from backups. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Ros-dev mailing list >>>> Ros-dev(a)reactos.org <mailto:Ros-dev@reactos.org> >>>> http://www.reactos.org/mailman/listinfo/ros-dev >>> >>> >>> -- >>> Pierre Schweitzer<pierre at reactos.org> >>> System Administrator >>> ReactOS Foundation >>> , >>> >>> _______________________________________________ >>> Ros-dev mailing list >>> Ros-dev(a)reactos.org <mailto:Ros-dev@reactos.org> >>> http://www.reactos.org/mailman/listinfo/ros-dev >>> >> -- >> Best regards, >> >> _______________________________________________ >> Ros-dev mailing list >> Ros-dev(a)reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev > > -- > Pierre Schweitzer<pierre at reactos.org> > System Administrator > ReactOS Foundation -- -- Best regards,

1 0

Upgrade complete
by Zachary Gorden 14 Jun '14

14 Jun '14

Fisheye was upgraded successfully, Jira went off the rails and took us about three hours to recover from. Please report any data loss as we had to restore from backups.

3 3

Fisheye and Jira going down
by Zachary Gorden 14 Jun '14

14 Jun '14

We'll be doing an upgrade of Fisheye and hopefully Jira, so expect downtime until the all clear is given.

1 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 63520: [MCISEQ] Silence a warning [CMAKE] Get rid of -Wtype-limits, it's noisy, it doesn't provide any reasonable benefit and it's almost impossible to "fix" these warnings without huge ...
by Thomas Faber 14 Jun '14

14 Jun '14

This helps find logic errors, mostly where the programmer thought the variable was signed but it's actually unsigned, e.g. if (ret < 0) for a function that returns (ULONG)-1. I also don't see how the fix would be complicated in most cases. (x <= 0) becomes (x == 0), (x < 0) becomes (x == (ULONG)-1) or whatever (after a logic review). I know that it'll be problematic if resulting from a macro... but I think it's worth finding a workaround for those cases. Most of the warnings I remember from our code base though (especially ntoskrnl) didn't involve macros and were actually cases of questionable logic... although maybe I recall incorrectly. On 2014-05-31 23:26, tkreuzer(a)svn.reactos.org wrote: > [CMAKE] Get rid of -Wtype-limits, it's noisy, it doesn't provide any reasonable benefit and it's almost impossible to "fix" these warnings without huge haxxory.

2 2

Status Meeting (May 2014)
by Aleksey Bragin 05 Jun '14

05 Jun '14

Hello, Let me invite you to the monthly status meeting taking place first Thursday of this month, 5th of June, 19:00 UTC. And this date is very close to now! The meeting was rescheduled from the usual date because of my trips and my illness. Sorry about that. IRC service will only be started shortly before the meeting. Your participation passwords and server address will be emailed to you shortly before the meeting starts, and they are going to be different once again as they are not stored in any database. Hopefully it's not much of inconvenience. If someone still is not getting passwords sent before a meeting - please email Pierre before the meeting started to get one. Please send agenda proposals to me before the meeting, so that we can start with a proposed agenda. However the most demanded topic is ReactOS fundraising campaign and its outcome :-) Also all developers, please, may I so kindly ask you to prepare a very brief one-two lines message containing two things: 1. What you did since the previous meeting 2. What you are going to do in the coming month This is needed to understand who is working on what, to plan things, etc. Thanks, I hope it's not that much to ask for. Regards, Aleksey Bragin

3 2

Instanciate TAP device for Virtualisation
by Maxime Daniel 05 Jun '14

05 Jun '14

Hi, I'm working on network virtualization support in ReactOS. At this time, PoC works but I reach a point where I need a solution that would allow to add and remove TAP (TAP-Win32 from OpenVPN for exemple) Network Devices from kernel space, without user intervention. The problem right now is that there seems to be impossible in ReactOS to have a proper way or tips and tricks to add/remove TAP devices without rebooting the system. What should be fixed/edit to instanciate of TAP device on the fly on the current implementation (r63193) ? Thanks -- Daniel Maxime Linux version 3.6.9-maxux64 (emy) (gcc version 4.7.3 (Gentoo 4.7.3-r1 p1.4, pie-0.5.5) ) #3 SMP PREEMPT Wed Feb 19 16:40:22 CET 2014 17:15:01 up 1 day, 1:44, 1 user, load average: 0.29, 0.28, 0.35

3 4

Re: [ros-dev] [ros-diffs] [hbelusca] 63506: [NTOS:CM] Replace a hardcoded value with something more readable.
by Timo Kreuzer 31 May '14

31 May '14

Am 30.05.2014 23:47, schrieb hbelusca(a)svn.reactos.org: > Author: hbelusca > Date: Fri May 30 21:47:22 2014 > New Revision: 63506 > > URL: http://svn.reactos.org/svn/reactos?rev=63506&view=rev > Log: > [NTOS:CM] > Replace a hardcoded value with something more readable. > - RootKey->Type = '20yk'; > + RootKey->Type = CM_KEY_BODY_TYPE; > RootKey->NotifyBlock = NULL; > +// > +#define CM_KEY_BODY_TYPE 0x6B793032 Why not '20yk' ? This hex constant looks fishy.

2 1

Re: [ros-dev] [ros-diffs] [tkreuzer] 63388: [NTOSKRNL] Fix ending address calculation for the commit path in NtAllocateVirtualMemory like done for the reserve path in r63356. Add a comment about a Windows kernel bug, which ...
by Thomas Faber 30 May '14

30 May '14

On 2014-05-20 23:11, tkreuzer(a)svn.reactos.org wrote: > --- trunk/reactos/ntoskrnl/mm/ARM3/virtual.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/mm/ARM3/virtual.c [iso-8859-1] Tue May 20 21:11:43 2014 > @@ -4593,8 +4593,8 @@ > // on the user input, and then compute the actual region size once all the > // alignments have been done. > // > + EndingAddress = (((ULONG_PTR)PBaseAddress + PRegionSize - 1) | (PAGE_SIZE - 1)); > StartingAddress = (ULONG_PTR)PAGE_ALIGN(PBaseAddress); > - EndingAddress = (((ULONG_PTR)PBaseAddress + PRegionSize - 1) | (PAGE_SIZE - 1)); > PRegionSize = EndingAddress - StartingAddress + 1; > > // Can you explain this a bit? I don't see any logic change.

1 0

SVN r63496
by Eric Kohl 29 May '14

29 May '14

>[LSASRV] > >- Just run again the loop if LsarOpenAccount call failed (that also >avoids a call to LsarClose on a NULL handle, that is trapped by the >kdbg if one enabled "set condition * first always"). > >- Free the memory and the opened handles before returning in case of >failure of LsapAddPrivilegeToTokenPrivileges. Maybe this cleaning step >can be done more elegantly. > >Eric, can you please review that? It should be good I think. The change is OK!

1 0

Re: [ros-dev] [ros-diffs] [akhaldi] 63480: [CMAKE] * Convert the hives from UTF-8 to UTF16 as part of the build process. CORE-7703 CORE-8221
by Thomas Faber 28 May '14

28 May '14

The savior, as always. Thank you! On 2014-05-27 21:42, akhaldi(a)svn.reactos.org wrote: > Author: akhaldi > Date: Tue May 27 19:42:15 2014 > New Revision: 63480 > > URL: http://svn.reactos.org/svn/reactos?rev=63480&view=rev > Log: > [CMAKE] > * Convert the hives from UTF-8 to UTF16 as part of the build process. > CORE-7703 > CORE-8221 > > Modified: > trunk/reactos/boot/bootdata/CMakeLists.txt > trunk/reactos/boot/bootdata/hivecls.inf (contents, props changed) > trunk/reactos/boot/bootdata/hivedef.inf (contents, props changed) > trunk/reactos/boot/bootdata/hivesft.inf (contents, props changed) > trunk/reactos/boot/bootdata/hivesys.inf > trunk/reactos/cmake/CMakeMacros.cmake > > [This mail would be too long, it was shortened to contain the URLs only.] > > Modified: trunk/reactos/boot/bootdata/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/CMakeLists.t… > > Modified: trunk/reactos/boot/bootdata/hivecls.inf > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/hivecls.inf?… > > Modified: trunk/reactos/boot/bootdata/hivedef.inf > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/hivedef.inf?… > > Modified: trunk/reactos/boot/bootdata/hivesft.inf > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/hivesft.inf?… > > Modified: trunk/reactos/boot/bootdata/hivesys.inf > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/hivesys.inf?… > > Modified: trunk/reactos/cmake/CMakeMacros.cmake > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/cmake/CMakeMacros.cmake?re… > >

1 0

Re: [ros-dev] [ros-diffs] [cwittich] 63452: [bootdata] convert hivecls.inf and hivedef.inf to UTF16LE fixes CORE-7614
by Thomas Faber 26 May '14

26 May '14

This is not the right solution. SVN has terrible UTF-16 handling so we should not convert these back to UTF-16. https://jira.reactos.org/browse/CORE-7703 https://jira.reactos.org/browse/CORE-8221 On 2014-05-25 22:17, cwittich(a)svn.reactos.org wrote: > Author: cwittich > Date: Sun May 25 20:17:25 2014 > New Revision: 63452 > > URL: http://svn.reactos.org/svn/reactos?rev=63452&view=rev > Log: > [bootdata] > convert hivecls.inf and hivedef.inf to UTF16LE > fixes CORE-7614 > > Modified: > trunk/reactos/boot/bootdata/hivecls.inf (contents, props changed) > trunk/reactos/boot/bootdata/hivedef.inf (contents, props changed) >

5 4

Regarding recent FAT32 partition handling work by Eric
by Caemyr 26 May '14

26 May '14

I would like to applaud Eric for his outstanding work with ROS partition handling, which we are able to experience since recently. Eric himself had tested this code including GParted, but i`ve that is not all. 7z is able to read FAT partition image files, but this didn't work at all. Right now i was able to open up ROS vmdk image, created by ReactOS itself and view/extract anything of its contents. I cannot express enough how handy this is going to be, allowing to access ROS vm hard disk contents without the pesky hdd mounting (which never really work reliably for me), transferring anything out of the vm by LAN/Internet or booting other VM with those HDDs co-mounted. Simply I cannot thank you enough for your work. Pic included as proof. -- With best regards Caemyr

2 1

Re: [ros-dev] [ros-diffs] [cwittich] 63423: [shell32] revert one line of r63414
by Thomas Faber 24 May '14

24 May '14

> --- trunk/reactos/dll/win32/shell32/shlexec.cpp [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/shell32/shlexec.cpp [iso-8859-1] Fri May 23 17:14:39 2014 > @@ -459,7 +459,7 @@ > startup.dwFlags = STARTF_USESHOWWINDOW; > startup.wShowWindow = psei->nShow; > dwCreationFlags = CREATE_UNICODE_ENVIRONMENT; > - if (!(psei->fMask & SEE_MASK_NO_CONSOLE)) > + if (psei->fMask & SEE_MASK_NO_CONSOLE) > dwCreationFlags |= CREATE_NEW_CONSOLE; > startup.lpTitle = (LPWSTR)(psei->fMask & (SEE_MASK_HASLINKNAME | SEE_MASK_HASTITLE) ? psei->lpClass : NULL); This is the opposite of what the documentation says?

2 2

Re: [ros-dev] [ros-diffs] [akhaldi] 63353: [CMAKE/MSVC] * Define _ALLOW_KEYWORD_MACROS to get the news MSVC toolchain to allow us to redefine inline (it became a keyword). Reported by David Quintana.
by Thomas Faber 24 May '14

24 May '14

Hrm, why not just limit the define to C instead? On 2014-05-18 16:39, akhaldi(a)svn.reactos.org wrote: > Author: akhaldi > Date: Sun May 18 14:39:03 2014 > New Revision: 63353 > > URL: http://svn.reactos.org/svn/reactos?rev=63353&view=rev > Log: > [CMAKE/MSVC] > * Define _ALLOW_KEYWORD_MACROS to get the news MSVC toolchain to allow us to redefine inline (it became a keyword). Reported by David Quintana. > > Modified: > trunk/reactos/CMakeLists.txt > > Modified: trunk/reactos/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/CMakeLists.txt?rev=63353&r… > ============================================================================== > --- trunk/reactos/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/CMakeLists.txt [iso-8859-1] Sun May 18 14:39:03 2014 > @@ -62,6 +62,9 @@ > if(MSVC) > if(ARCH STREQUAL "i386") > add_definitions(/D_X86_ /DWIN32 /D_WINDOWS) > + endif() > + if(MSVC_VERSION GREATER 1799) > + add_definitions(/D_ALLOW_KEYWORD_MACROS) > endif() > add_definitions(/Dinline=__inline) > else() > >

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 63398: [USETUP] - Fix a bit the translation of yesterday; - Use TEXT_PADDING_BIG instead of hardcoding 3 spaces in the status messages.
by Pierre Schweitzer 21 May '14

21 May '14

On 05/21/2014 02:23 PM, hbelusca(a)svn.reactos.org wrote: > Author: hbelusca > Date: Wed May 21 12:23:04 2014 > New Revision: 63398 > > URL: http://svn.reactos.org/svn/reactos?rev=63398&view=rev > Log: > [USETUP] > - Fix a bit the translation of yesterday; > - Use TEXT_PADDING_BIG instead of hardcoding 3 spaces in the status messages. > > Modified: > trunk/reactos/base/setup/usetup/lang/fr-FR.h > > Modified: trunk/reactos/base/setup/usetup/lang/fr-FR.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/setup/usetup/lang/fr-… > ============================================================================== > --- trunk/reactos/base/setup/usetup/lang/fr-FR.h [iso-8859-1] (original) > +++ trunk/reactos/base/setup/usetup/lang/fr-FR.h [iso-8859-1] Wed May 21 12:23:04 2014 > @@ -642,8 +642,8 @@ > { > 0, > 0, > - " Veuillez attendre ...", > - TEXT_TYPE_STATUS, > + "Veuillez attendre ...", > + TEXT_TYPE_STATUS | TEXT_PADDING_BIG > }, > { > 0, It would be better to have "Veuillez patienter..." "Attendre" sounds so weird in that context. > @@ -850,8 +850,8 @@ > { > 0, > 0, > - " Patienter...", > - TEXT_TYPE_STATUS > + "Patienter...", > + TEXT_TYPE_STATUS | TEXT_PADDING_BIG > }, > { > 0, Here, it's likely to be "Patientez..." (to be checked though). -- Pierre Schweitzer <pierre(a)reactos.org> System Administrator ReactOS Foundation

2 1

New Patchbot is ready
by Colin Finck 21 May '14

21 May '14

The new Linux-based Patchbot is finally live. Do whatever you want with it.

1 0

Re: [ros-dev] [ros-diffs] [ekohl] 63330: [NTOSKRNL] Partial revert of r63326! The correct partition numbers cause boot failures.
by Alex Ionescu 20 May '14

20 May '14

Lol so maybe you should think twice next time you see "FIXFIX REACTOS HACK" like I originally wrote it ;-) Best regards, Alex Ionescu On Sat, May 17, 2014 at 4:42 PM, <ekohl(a)svn.reactos.org> wrote: > Author: ekohl > Date: Sat May 17 14:42:28 2014 > New Revision: 63330 > > URL: http://svn.reactos.org/svn/reactos?rev=63330&view=rev > Log: > [NTOSKRNL] > Partial revert of r63326! The correct partition numbers cause boot failures. > > Modified: > trunk/reactos/ntoskrnl/fstub/disksup.c > > Modified: trunk/reactos/ntoskrnl/fstub/disksup.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/fstub/disksup.c?r… > ============================================================================== > --- trunk/reactos/ntoskrnl/fstub/disksup.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/fstub/disksup.c [iso-8859-1] Sat May 17 14:42:28 2014 > @@ -1655,7 +1655,9 @@ > UInt32x32To64(GET_PARTITION_LENGTH(PartitionDescriptor), > SectorSize); > > - PartitionInfo->PartitionNumber = (!IsContainerPartition(PartitionType)) ? i : 0; > + // BUGBUGBUG: The correct partition numbers seem to cause boot failures!!! > +// PartitionInfo->PartitionNumber = (!IsContainerPartition(PartitionType)) ? i : 0; > + PartitionInfo->PartitionNumber = i + 1; > } > else > { > >

2 1

libusb-win32 - can we use it?
by Alexander Rechitskiy 20 May '14

20 May '14

http://sourceforge.net/apps/trac/libusb-win32/wiki -- Best regards, Alexander Rechitskiy

3 3

Re: [ros-dev] [ros-diffs] [ekohl] 63326: [NTOSKRNL] xHalIoReadPartitionTable: Only used non-container partition entries have a non-zero partition number.
by Pierre Schweitzer 17 May '14

17 May '14

Hey Eric, This fix unfortunately broke trunk. Our four testbots are red. Have a look here, for instance: http://build.reactos.org/builders/Linux_AMD64_1%20KVM-Test/builds/6442/step… Cheers, Pierre On 17/05/2014 14:55, ekohl(a)svn.reactos.org wrote: > Author: ekohl > Date: Sat May 17 12:55:06 2014 > New Revision: 63326 > > URL: http://svn.reactos.org/svn/reactos?rev=63326&view=rev > Log: > [NTOSKRNL] > xHalIoReadPartitionTable: Only used non-container partition entries have a non-zero partition number. > > Modified: > trunk/reactos/ntoskrnl/fstub/disksup.c > > Modified: trunk/reactos/ntoskrnl/fstub/disksup.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/fstub/disksup.c?r… > ============================================================================== > --- trunk/reactos/ntoskrnl/fstub/disksup.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/fstub/disksup.c [iso-8859-1] Sat May 17 12:55:06 2014 > @@ -1655,8 +1655,7 @@ > UInt32x32To64(GET_PARTITION_LENGTH(PartitionDescriptor), > SectorSize); > > - /* FIXME: REACTOS HACK */ > - PartitionInfo->PartitionNumber = i + 1; > + PartitionInfo->PartitionNumber = (!IsContainerPartition(PartitionType)) ? i : 0; > } > else > { > @@ -1667,7 +1666,6 @@ > PartitionInfo->PartitionLength.QuadPart = 0; > PartitionInfo->HiddenSectors = 0; > > - /* FIXME: REACTOS HACK */ > PartitionInfo->PartitionNumber = 0; > } > } > > -- Pierre Schweitzer<pierre at reactos.org> System Administrator ReactOS Foundation

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 63135: Arch, please do not mix up ANSI vs. UNICODE string functions, do you?
by Aleksey Bragin 17 May '14

17 May '14

Speaking of that (1000s time), the proper way would be to convert everything to UNICODE. It would help. Regards, Aleksey Bragin On 03.05.2014 21:24, hbelusca(a)svn.reactos.org wrote: > Author: hbelusca > Date: Sat May 3 17:24:22 2014 > New Revision: 63135 > > URL: http://svn.reactos.org/svn/reactos?rev=63135&view=rev > Log: > Arch, please do not mix up ANSI vs. UNICODE string functions, do you? > > Modified: > trunk/reactos/base/applications/network/ftp/cmds.c > > Modified: trunk/reactos/base/applications/network/ftp/cmds.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/network/… > ============================================================================== > --- trunk/reactos/base/applications/network/ftp/cmds.c [iso-8859-1] (original) > +++ trunk/reactos/base/applications/network/ftp/cmds.c [iso-8859-1] Sat May 3 17:24:22 2014 > @@ -1303,13 +1303,13 @@ > > if (argc > 1) > { > - strncat(CmdLine, " /C", MAX_PATH - wcslen(Cmdline) - 1); > + strncat(CmdLine, " /C", MAX_PATH - strlen(Cmdline) - 1); > } > > for (i=1; i<argc; i++) > { > - strncat(CmdLine, " ", MAX_PATH - wsclen(Cmdline) - 1); > - strncat(CmdLine, argv[i], MAX_PATH - wsclen(Cmdline) -1); > + strncat(CmdLine, " ", MAX_PATH - strlen(Cmdline) - 1); > + strncat(CmdLine, argv[i], MAX_PATH - strlen(Cmdline) -1); > } > > StartupInfo.cb = sizeof( StartupInfo ); > >

3 2

ReactOS' defragger "Fraginator" history
by Hermès BÉLUSCA - MAÏTO 13 May '14

13 May '14

Hi everybody! During some little maintenance of rosapps I was doing during some work pause, I wanted to know from where we found our still unused (until someone programs the defragmentation API :P) defragger called Fraginator. Since it doesnt contain any information about his initial author I tried to check into the SVN log, and I found that it was added in our codebase in 2006 by Ged: see the commit log http://svn.reactos.org/svn/reactos?view=revision <http://svn.reactos.org/svn/reactos?view=revision&revision=21411> &revision=21411 ; notice that the committer mentioned that [Fraginator] is pretty hard to come by on the net now. Nevertheless nothing is said about his author. However (!!) googling at fraginator defragger, I fell on this webpage, certainly written by the actual Fraginator author: http://blog.getpaint.net/2012/03/28/college-adventures-in-open-source-fragin ator-edition/ . In this blog entry you have the story of the Fraginator defragger! (if someone can add an entry, he/shes welcome). Nice reading! Hermès.

1 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 63247: [DDK/XDK/NTOSKRNL/DRIVERS] Fix incompatible definition of a number of NTOSKRNL data imports. These imports are declared in MS DDK in a way that is usually not how you would declar...
by Thomas Faber 12 May '14

12 May '14

Woohoo, thanks! Questions/comments inline. On 2014-05-12 01:11, tkreuzer(a)svn.reactos.org wrote: > --- trunk/reactos/include/ddk/ntifs.h [iso-8859-1] (original) > +++ trunk/reactos/include/ddk/ntifs.h [iso-8859-1] Sun May 11 23:11:16 2014 > @@ -870,11 +870,11 @@ > (NTAPI *PRTL_FREE_STRING_ROUTINE)( > _In_ __drv_freesMem(Mem) _Post_invalid_ PVOID Buffer); > > -extern const PRTL_ALLOCATE_STRING_ROUTINE RtlAllocateStringRoutine; > -extern const PRTL_FREE_STRING_ROUTINE RtlFreeStringRoutine; > +extern NTKERNELAPI const PRTL_ALLOCATE_STRING_ROUTINE RtlAllocateStringRoutine; > +extern NTKERNELAPI const PRTL_FREE_STRING_ROUTINE RtlFreeStringRoutine; > > #if _WIN32_WINNT >= 0x0600 > -extern const PRTL_REALLOCATE_STRING_ROUTINE RtlReallocateStringRoutine; > +extern NTKERNELAPI const PRTL_REALLOCATE_STRING_ROUTINE RtlReallocateStringRoutine; > #endif > > _Function_class_(RTL_HEAP_COMMIT_ROUTINE) Do you have any idea what RtlAllocateStringRoutine and friends are? They don't seem to exist. (NDK defines them for user mode btw, without dllimport) > Modified: trunk/reactos/include/ddk/wdm.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/ddk/wdm.h?rev=6324… > ============================================================================== > --- trunk/reactos/include/ddk/wdm.h [iso-8859-1] (original) > +++ trunk/reactos/include/ddk/wdm.h [iso-8859-1] Sun May 11 23:11:16 2014 > @@ -82,10 +85,13 @@ > #endif > > /* For ReactOS */ > -#if !defined(_NTOSKRNL_) && !defined(_BLDR_) > +#if !defined(_NTOSKRNL_) && !defined(_BLDR_) && !defined(_NTSYSTEM_) > #define NTKERNELAPI DECLSPEC_IMPORT > #else > #define NTKERNELAPI > +#ifndef _NTSYSTEM_ > +#define _NTSYSTEM_ > +#endif > #endif > > #if defined(_X86_) && !defined(_NTHAL_) We should probably switch to using _NTSYSTEM_ instead of _NTOSKRNL_ at some point? > @@ -129,6 +135,29 @@ > #define ALLOC_DATA_PRAGMA 1 > #endif > > +#endif /* _MSC_VER */ > + > +/* These macros are used to create aliases for imported data. We need to do > + this to have declarations that are compatible with MS DDK */ > +#ifdef _M_IX86 > +#define __SYMBOL(_Name) "_"#_Name > +#define __IMPORTSYMBOL(_Name) "__imp__"#_Name > +#define __IMPORTNAME(_Name) _imp__##_Name > +#else > +#define __SYMBOL(_Name) #_Name > +#define __IMPORTSYMBOL(_Name) "__imp_"#_Name > +#define __IMPORTNAME(_Name) __imp_##_Name > +#endif > +#ifdef _MSC_VER > +#define __CREATE_NTOS_DATA_IMPORT_ALIAS(_Name) \ > + __pragma(comment(linker, "/alternatename:"__SYMBOL(_Name) "=" __IMPORTSYMBOL(_Name))) > +#else /* !_MSC_VER */ > +#ifndef __STRINGIFY > +#define __STRINGIFY(_exp) #_exp > +#endif > +#define _Pragma_redifine_extname(_Name, _Target) _Pragma(__STRINGIFY(redefine_extname _Name _Target)) > +#define __CREATE_NTOS_DATA_IMPORT_ALIAS(_Name) \ > + _Pragma_redifine_extname(_Name,__IMPORTNAME(_Name)) > #endif > > #if defined(_WIN64) s/redifine/redefine/ > --- trunk/reactos/ntoskrnl/kd64/kdapi.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/kd64/kdapi.c [iso-8859-1] Sun May 11 23:11:16 2014 > @@ -1903,9 +1903,7 @@ > > /* We are disabled now */ > KdDebuggerEnabled = FALSE; > -#undef KdDebuggerEnabled > SharedUserData->KdDebuggerEnabled = FALSE; > -#define KdDebuggerEnabled _KdDebuggerEnabled > } > } Should this not use KD_DEBUGGER_ENABLED? (same in kdinit.c)

2 1

Re: [ros-dev] [ros-diffs] [cwittich] 63225: [comctl32] Notify the parent on a return key press. fixes return key in device manager
by Hermès BÉLUSCA - MAÏTO 11 May '14

11 May '14

Hi Christoph ! Are you sure that before committing this fix in Wine code, you: 1- made a patch to wine's code, 2- sent it to them, and 3- checked that they merged too in their code base? Because otherwise your fix here might be lost in the next Wine code sync... Cheers, Hermès. -----Message d'origine----- Author: cwittich Date: Sun May 11 05:04:56 2014 New Revision: 63225 URL: http://svn.reactos.org/svn/reactos?rev=63225&view=rev Log: [comctl32] Notify the parent on a return key press. fixes return key in device manager Modified: trunk/reactos/dll/win32/comctl32/treeview.c Modified: trunk/reactos/dll/win32/comctl32/treeview.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/comctl32/treeview .c?rev=63225&r1=63224&r2=63225&view=diff ============================================================================ == --- trunk/reactos/dll/win32/comctl32/treeview.c [iso-8859-1] (original) +++ trunk/reactos/dll/win32/comctl32/treeview.c [iso-8859-1] Sun May 11 05:04:56 2014 @@ -5242,6 +5242,10 @@ newSelection = TREEVIEW_GetNextListItem(infoPtr, prevItem); break; + case VK_RETURN: + TREEVIEW_SendSimpleNotify(infoPtr, NM_RETURN); + break; + case VK_HOME: newSelection = infoPtr->root->firstChild; break;

1 1

Re: [ros-dev] [ros-diffs] [hbelusca] 63202: [RPCRT4] Detect whether we are connecting to a pipe on the local machine and use the \\.\ prefix instead of the full machine name. This patch modifies ReactOS-specific code (that ...
by Timo Kreuzer 10 May '14

10 May '14

Am 09.05.2014 03:57, schrieb hbelusca(a)svn.reactos.org: > Author: hbelusca > Date: Fri May 9 01:57:43 2014 > New Revision: 63202 > > URL: http://svn.reactos.org/svn/reactos?rev=63202&view=rev > Log: > [RPCRT4] > Detect whether we are connecting to a pipe on the local machine and use the \\.\ prefix instead of the full machine name. > This patch modifies ReactOS-specific code (that was introduced by Eric in revision 53630) (Wine still supports only local pipes), so I also update our rpcrt4_ros.diff file accordingly, r63201 with respect to the latest Wine 1.7.17 rpcrt4 code. > Modified: trunk/reactos/dll/win32/rpcrt4/rpcrt4_ros.diff > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/rpcrt4/rpcrt4_ro… > ============================================================================== > [...] > > +diff -prudN .\wine\dlls\rpcrt4/msvc.S .\reactos\dll\win32\rpcrt4/msvc.S > +--- .\wine\dlls\rpcrt4/msvc.S 1970-01-01 01:00:00.000000000 +0100 > ++++ .\reactos\dll\win32\rpcrt4/msvc.S 2012-02-14 21:27:35.943001900 +0100 > +@@ -0,0 +1,146 @@ > > +diff -prudN .\wine\dlls\rpcrt4/precomp.h .\reactos\dll\win32\rpcrt4/precomp.h > +--- .\wine\dlls\rpcrt4/precomp.h 1970-01-01 01:00:00.000000000 +0100 > ++++ .\reactos\dll\win32\rpcrt4/precomp.h 2014-03-14 01:43:22.357516600 +0100 > > +diff -prudN .\wine\dlls\rpcrt4/unix_func.c .\reactos\dll\win32\rpcrt4/unix_func.c > +--- .\wine\dlls\rpcrt4/unix_func.c 1970-01-01 01:00:00.000000000 +0100 > ++++ .\reactos\dll\win32\rpcrt4/unix_func.c 2013-01-25 00:19:53.278052800 +0100 Why add these to the diff?

2 1

r58367 - Fix a bug in StartupWindowThread
by Aleksey Bragin 02 May '14

02 May '14

Hi, http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msgina/gui.c?r1=… Is there a point in that DuplicateHandle call? "When SetThreadDesktop is called the system closes the desktop handle when needed so we have to create a new handle because this handle may still be in use by winlogon" Sorry, I re-read that comment a few times and still can't understand. I take it that SetThreadDesktop closes the old handle which was set before. And it may, for some reason, be used by winlogon. Shouldn't that be a place to fix, rather than the hack in r58367? And why is the SetThreadDesktop(OldDesk) is removed by this revision? Regards, Aleksey Bragin

1 0

Re: [ros-dev] [ros-diffs] [dquintana] 63044: [RSHELL] [SHELL32] * Move the IID_NULL_PPV_ARG macro to the shobj_undoc header, next to the (also ros-specific) IID_PPV_ARG macro, so that it can be used elsewhere. [SHELL32] * M...
by Thomas Faber 29 Apr '14

29 Apr '14

On 2014-04-29 13:14, dquintana(a)svn.reactos.org wrote: > [SHELL32] > * Make use of IID_NULL_PPV_ARG in all the calls to GetUIObjectOf, and fix one instance of mismatched riid/pointer. I don't see that mismatch. What am I missing? ;)

2 1

Re: [ros-dev] [ros-diffs] [tfaber] 63030: [FIND] - Avoid printf on a non-format string. Spotted by Víctor - Remove broken pseudo-TCHAR usage CORE-8112 #resolve
by Timo Kreuzer 29 Apr '14

29 Apr '14

Am 28.04.2014 10:06, schrieb tfaber(a)svn.reactos.org: > @@ -235,9 +235,9 @@ > } > else > { > - LoadString(GetModuleHandle(NULL), IDS_CANNOT_OPEN, (LPTSTR)lpMessage, 4096); > - CharToOem(lpMessage, lpMessage); > - fprintf (stderr, lpMessage, > + LoadString (GetModuleHandle (NULL), IDS_CANNOT_OPEN, szMessage, sizeof(szMessage) / sizeof(szMessage[0])); > + CharToOemA (szMessage, szMessage); > + fprintf (stderr, szMessage, > finddata.name); > } LoadString -> LoadStringA? Also, shouldn't we go unicode?

1 0

Re: [ros-dev] [ros-diffs] [tfaber] 63032: [NETCFGX] - Use correct parent key instead of an uninitialized handle in INetCfgComponentControl_fnApplyRegistryChanges CORE-8115 #resolve
by Thomas Faber 28 Apr '14

28 Apr '14

Uh, this is missing the "Patch by Víctor Martínez" part, sorry. On 2014-04-28 10:27, tfaber(a)svn.reactos.org wrote: > Author: tfaber > Date: Mon Apr 28 08:27:57 2014 > New Revision: 63032 > > URL: http://svn.reactos.org/svn/reactos?rev=63032&view=rev > Log: > [NETCFGX] > - Use correct parent key instead of an uninitialized handle in INetCfgComponentControl_fnApplyRegistryChanges > CORE-8115 #resolve > > Modified: > trunk/reactos/dll/win32/netcfgx/tcpipconf_notify.c > > Modified: trunk/reactos/dll/win32/netcfgx/tcpipconf_notify.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/netcfgx/tcpipcon… > ============================================================================== > --- trunk/reactos/dll/win32/netcfgx/tcpipconf_notify.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/netcfgx/tcpipconf_notify.c [iso-8859-1] Mon Apr 28 08:27:57 2014 > @@ -3141,7 +3141,7 @@ > //MessageBoxW(NULL, L"INetCfgComponentControl_fnApplyRegistryChanges", NULL, MB_OK); > > > - if (RegCreateKeyExW(hKey, L"SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters", 0, NULL, 0, KEY_WRITE, NULL, &hKey, NULL) == ERROR_SUCCESS) > + if (RegCreateKeyExW(HKEY_LOCAL_MACHINE, L"SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters", 0, NULL, 0, KEY_WRITE, NULL, &hKey, NULL) == ERROR_SUCCESS) > { > if (pCurrentConfig->pDNS) > { > >

2 1

Re: [ros-dev] [ros-diffs] [jimtabor] 63027: [Win32k] - Moved to new menu structures, synced in wine code and started first phase to server side. Resulting that more tests are running and failing less. Unplugged ntuser bad f...
by Thomas Faber 28 Apr '14

28 Apr '14

Jim, this introduced a new warning: win32ss/user/user32/windows/menu.c:1952:14: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits] Thanks. On 2014-04-28 08:40, jimtabor(a)svn.reactos.org wrote: > Author: jimtabor > Date: Mon Apr 28 03:55:23 2014 > New Revision: 63027 > > URL: http://svn.reactos.org/svn/reactos?rev=63027&view=rev > Log: > [Win32k] > - Moved to new menu structures, synced in wine code and started first phase to server side. Resulting that more tests are running and failing less. Unplugged ntuser bad functions. > - See CORE-5605, CORE-7447, CORE-7967, CORE-8098 and CORE-8107 > > Modified: > trunk/reactos/win32ss/include/ntuser.h > trunk/reactos/win32ss/user/ntuser/accelerator.c > trunk/reactos/win32ss/user/ntuser/menu.c > trunk/reactos/win32ss/user/ntuser/menu.h > trunk/reactos/win32ss/user/ntuser/object.c > trunk/reactos/win32ss/user/ntuser/simplecall.c > trunk/reactos/win32ss/user/ntuser/userfuncs.h > trunk/reactos/win32ss/user/ntuser/window.c > trunk/reactos/win32ss/user/user32/windows/menu.c > > [This mail would be too long, it was shortened to contain the URLs only.] > > Modified: trunk/reactos/win32ss/include/ntuser.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/include/ntuser.h?r… > > Modified: trunk/reactos/win32ss/user/ntuser/accelerator.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/accele… > > Modified: trunk/reactos/win32ss/user/ntuser/menu.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/menu.c… > > Modified: trunk/reactos/win32ss/user/ntuser/menu.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/menu.h… > > Modified: trunk/reactos/win32ss/user/ntuser/object.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/object… > > Modified: trunk/reactos/win32ss/user/ntuser/simplecall.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/simple… > > Modified: trunk/reactos/win32ss/user/ntuser/userfuncs.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/userfu… > > Modified: trunk/reactos/win32ss/user/ntuser/window.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/window… > > Modified: trunk/reactos/win32ss/user/user32/windows/menu.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/user32/window… > >

1 0

WebOS and ReactOS
by Alexander Rechitskiy 25 Apr '14

25 Apr '14

Let's bring up the webOS topic again. There is an interesting idea to port Nyx portability layer to Win32 and thus make Open webOS running in ReactOS/Windows. Nice user interface would be a benefit! http://www.openwebosproject.org/docs/architecture#.U1l8Uvl_vTo -- Best regards, Alexander Reachitskiy

2 1

Status Meeting (April 2014)
by Aleksey Bragin 24 Apr '14

24 Apr '14

Hello, Let me invite you to the monthly status meeting taking place last Thursday of this month, 24th of April, 19:00 UTC. And this date is very close to now! IRC service will only be started shortly before the meeting. Your participation passwords and server address will be emailed to you shortly before the meeting starts, and they are going to be different once again as they are not stored in any database. Hopefully it's not much of inconvenience. If someone still is not getting passwords sent before a meeting - please email Pierre before the meeting started to get one. Please send agenda proposals to me before the meeting, so that we can start with a proposed agenda. Regards, Aleksey Bragin

2 1

Re: [ros-dev] [ros-diffs] [akhaldi] 62898: [PSDK] * Add missing MAXLONGLONG definition.
by Timo Kreuzer 24 Apr '14

24 Apr '14

Am 22.04.2014 23:43, schrieb akhaldi(a)svn.reactos.org: > Author: akhaldi > Date: Tue Apr 22 21:43:39 2014 > New Revision: 62898 > > URL: http://svn.reactos.org/svn/reactos?rev=62898&view=rev > Log: > [PSDK] > * Add missing MAXLONGLONG definition. > > Modified: > trunk/reactos/include/psdk/winnt.h > > Modified: trunk/reactos/include/psdk/winnt.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/psdk/winnt.h?rev=6… > ============================================================================== > --- trunk/reactos/include/psdk/winnt.h [iso-8859-1] (original) > +++ trunk/reactos/include/psdk/winnt.h [iso-8859-1] Tue Apr 22 21:43:39 2014 > @@ -1480,6 +1480,7 @@ > #define MAXBYTE 0xff > #define MAXWORD 0xffff > #define MAXDWORD 0xffffffff > +#define MAXLONGLONG (((LONGLONG)0x7fffffff << 32) | 0xffffffff) > #define PROCESSOR_INTEL_386 386 > #define PROCESSOR_INTEL_486 486 > #define PROCESSOR_INTEL_PENTIUM 586 > > > Why not use 0x7FFFFFFFFFFFFFFFLL ?

1 0

Re: [ros-dev] [ros-diffs] [aandrejevic] 62892: [NTVDM] Quit when ntvdm becomes the last process attached to the console.
by Thomas Faber 23 Apr '14

23 Apr '14

On 2014-04-22 22:46, aandrejevic(a)svn.reactos.org wrote: > --- branches/ntvdm/subsystems/ntvdm/ntvdm.c [iso-8859-1] (original) > +++ branches/ntvdm/subsystems/ntvdm/ntvdm.c [iso-8859-1] Tue Apr 22 20:46:50 2014 > @@ -196,6 +197,11 @@ > EmulatorInterrupt(0x23); > break; > } > + case CTRL_LAST_CLOSE_EVENT: > + { > + if (CommandThread) TerminateThread(CommandThread, 0); > + break; > + } > default: > { > /* Stop the VDM if the user logs out or closes the console */ Wasn't there an event to tell that thread to exit? Using TerminateThread like this feels icky.

2 1

Re: [ros-dev] [ros-diffs] [pschweitzer] 62779: [CDFS] Convert FCB pathname from simple buffer to unicode string. Please carefully review if I missed something
by Pierre Schweitzer 20 Apr '14

20 Apr '14

Hey! That's indeed a typo! Can someone commit a fix? I can't before Monday evening. Thanks! Pierre -------- Message original -------- Objet : Re: [ros-dev] [ros-diffs] [pschweitzer] 62779: [CDFS] Convert FCB pathname from simple buffer to unicode string. Please carefully review if I missed something De : Alexander Andrejevic <theflash(a)sdf.lonestar.org> À : ReactOS Development List <ros-dev(a)reactos.org> Cc : Hi, Correct me if I'm wrong, but the original version didn't modify the string length. Are you sure that should be "=" and not "=="? Regards, Alex On Sat, Apr 19, 2014 at 09:31:44AM +0200, Thomas Faber wrote: > On 2014-04-18 23:40, pschweitzer(a)svn.reactos.org wrote: > > --- trunk/reactos/drivers/filesystems/cdfs/fcb.c [iso-8859-1] (original) > > +++ trunk/reactos/drivers/filesystems/cdfs/fcb.c [iso-8859-1] Fri Apr 18 21:40:02 2014 > > @@ -129,7 +131,7 @@ > > BOOLEAN > > CdfsFCBIsRoot(PFCB Fcb) > > { > > - return(wcscmp(Fcb->PathName, L"\\") == 0); > > + return (Fcb->PathName.Length = sizeof(WCHAR) && Fcb->PathName.Buffer[0] == L'\\'); > > } > > == > > > > Generally I'm seeing a lot of manual work where > RtlInitEmptyUnicodeString and RtlCopyUnicodeString could be used. > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev -- Alexander Andrejevic <theflash(a)sdf.lonestar.org> SDF Public Access UNIX System - http://sdf.lonestar.org _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev

3 2

Re: [ros-dev] [ros-diffs] [pschweitzer] 62779: [CDFS] Convert FCB pathname from simple buffer to unicode string. Please carefully review if I missed something
by Thomas Faber 19 Apr '14

19 Apr '14

On 2014-04-18 23:40, pschweitzer(a)svn.reactos.org wrote: > --- trunk/reactos/drivers/filesystems/cdfs/fcb.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/cdfs/fcb.c [iso-8859-1] Fri Apr 18 21:40:02 2014 > @@ -129,7 +131,7 @@ > BOOLEAN > CdfsFCBIsRoot(PFCB Fcb) > { > - return(wcscmp(Fcb->PathName, L"\\") == 0); > + return (Fcb->PathName.Length = sizeof(WCHAR) && Fcb->PathName.Buffer[0] == L'\\'); > } == Generally I'm seeing a lot of manual work where RtlInitEmptyUnicodeString and RtlCopyUnicodeString could be used.

3 2

Re: [ros-dev] [ros-bugs] [jira] (ONLINE-446) "Prove you are a human" game is hidden by AdBlock
by Richard Campbell 17 Apr '14

17 Apr '14

I couldn't resist. As a publisher...maybe you shouldn't run ad block eh? :) On Thu, Apr 17, 2014 at 12:09 AM, Sergey Bugaev (JIRA) <noreply(a)reactos.org>wrote: > > [ > http://jira.reactos.org/browse/ONLINE-446?page=com.atlassian.jira.plugin.sy…] > > Sergey Bugaev resolved ONLINE-446. > ---------------------------------- > > Resolution: Cannot Reproduce > > > "Prove you are a human" game is hidden by AdBlock > > ------------------------------------------------- > > > > Key: ONLINE-446 > > URL: http://jira.reactos.org/browse/ONLINE-446 > > Project: ReactOS Online Service > > Issue Type: Improvement > > Reporter: Sergey Bugaev > > Assignee: Aleksey Bragin > > > > https://www.reactos.org/user/register (use incognito mode or just log > out to see the issue) > > There is a game to prove you are a human. > > However if you are using AdBlock ( > https://chrome.google.com/webstore/detail/adblock/gighmmpiobklfepjocnamgkkb…, > the most popular Chrome extension with more than 15 million users) the game > is not visible, so newcomer can't register. > > The error message is "You didn't pass the game", which is not very > informative in that case. > > Should be something like "You didn't pass the game, try disabling > AdBlock to see it". The best solution would be making the game visible > anyway. > > Tested in Google Chrome > > -- > This message is automatically generated by JIRA. > If you think it was sent incorrectly, please contact your JIRA > administrators > For more information on JIRA, see: http://www.atlassian.com/software/jira > > _______________________________________________ > Ros-bugs mailing list > Ros-bugs(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-bugs >

2 1

Heartbleed issue on the ReactOS infrastructure
by Pierre Schweitzer 09 Apr '14

09 Apr '14

Dear all, In case you don't use SSL/TLS on our infrastructure (web sites - drupal, jira, fisheye), skip reading (and reconsider your choices about such non-usage). As you may (should?) have heard recently, OpenSSL has suffered a critical security vulnerability (CVE-2014-0160), known as Heartbleed Bug (http://heartbleed.com/). Most of our services were using an affected release of OpenSSL, with heartbeat feature activated. Be it, mails services, web services (Drupal, Jira). We reacted quickly passed the public announcement, and the availability of the fix to apply it on our infrastructure to limit the risks. Anyway, this might have been enough (actually, the issue has been here for two years!) to allow potentials attackers to, for instance, steal our SSL private keys. So, we took the decision to renew all our certificates and private keys to guarantee safe infrastructure usage. Due to the nature of the security issue, we don't know what may have been compromised in the infrastructure and in the user database. Hence our drastic measures. What does it mean for you? It means that your account information (username + password) might have been compromised, and your account itself could have been compromised (cookie stealth with the attack). We highly recommend you to change your passwords and check that everything is fine on your account. I shall remind you that password change can take up to 6h to propagate to Fisheye & Jira. As a side note, we enabled a while ago Perfect Forward Secrecy on our infrastructure that should ensure that even if our private keys leaked, your past communications (so, login on the infrastructure, for instance) can't be deciphered. Unless your session ticket leaked as well... We are really sorry for the caused inconvenience. I'm available by email or on IRC to answer your questions and clear your doubts. With my best regards, -- Pierre Schweitzer<pierre at reactos.org> System Administrator ReactOS Foundation

1 0

Short announce: My Serial port-on-MMIO implementation works - allowing debug logging on laptops
by Minas Abrahamyan 07 Apr '14

07 Apr '14

Hi all, With this few words I would like to share the joyous event of MMIO-based serial port implementation has finally worked for me. This is the equivalent of earlycon serial port implementation in Linux with some extension (so now it is even better then Linux one) Some work yet is needed to be done to transform the work into the normal patch, but the good news is it is working, and still doesn't require PNPmanager for work, i.e. it starts very early in kernel and writes kernel log messages. I use ExpressCard 34 extension board Serial RS232 port, on laptop, but think it will work fro PC Cards too (former name PCMCIA). ==Importance: Touching the hardware== For the more developers we need more working PC models ( Real Hardware) Almost all modern PCs are laptops with PCIe bus (the rest are desktops) (but few of them able to boot the ReactOS) Modern serial ports are recommended to use /often use MMIO-based data transfer instead of former I/O ports. So now possibility appears to debug these new computers and force the ReactOS to work on this important part of new PCs. Thanks for attention -Minas Abrahamyan PS Curious note: for catching the debug logs I use the (small and cheap) soap box-sized microcontroller board with LCD (ready-unit), and I call it "ReactOS debug logger" appliance. It doesn't take space and doesn't produce any noise

3 4

Re: [ros-dev] [ros-diffs] [pschweitzer] 62675: [CHARMAP] Use rather wcsncpy(). A bit less safe, but at least, data are copied till possible
by Timo Kreuzer 07 Apr '14

07 Apr '14

I don't really see the reason here. Whether using the secure function or not is is a question of whether we need null-termination or not. If we need it the secure function will do the right thing. If we do not need null-termination the non-secure function does the right thing and the secure function would not add any security, but simply do the wrong thing. MSDN says about the lfFaceName member of the LOGFONT structure "A null-terminated string that specifies the typeface name of the font. " So we want it to be null-terminated and adding one more character does not add anything useful, but will result in a broken structure. Another difference is that the non-secure function pads the destination array with nulls, the secure function does - afaik - not. If that is the reason, I'd prefer zeroing it out before copying the string. Am 06.04.2014 22:20, schrieb pschweitzer(a)svn.reactos.org: > Author: pschweitzer > Date: Sun Apr 6 20:20:39 2014 > New Revision: 62675 > > URL: http://svn.reactos.org/svn/reactos?rev=62675&view=rev > Log: > [CHARMAP] > Use rather wcsncpy(). A bit less safe, but at least, data are copied till possible > > Modified: > trunk/reactos/base/applications/charmap/lrgcell.c > trunk/reactos/base/applications/charmap/map.c > > Modified: trunk/reactos/base/applications/charmap/lrgcell.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/charmap/… > ============================================================================== > --- trunk/reactos/base/applications/charmap/lrgcell.c [iso-8859-1] (original) > +++ trunk/reactos/base/applications/charmap/lrgcell.c [iso-8859-1] Sun Apr 6 20:20:39 2014 > @@ -48,9 +48,9 @@ > hdc); > > lf.lfCharSet = DEFAULT_CHARSET; > - wcscpy_s(lf.lfFaceName, > - sizeof(lf.lfFaceName) / sizeof(lf.lfFaceName[0]), > - lpFontName); > + wcsncpy(lf.lfFaceName, > + lpFontName, > + sizeof(lf.lfFaceName) / sizeof(lf.lfFaceName[0])); > > hFont = CreateFontIndirectW(&lf); > > > Modified: trunk/reactos/base/applications/charmap/map.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/charmap/… > ============================================================================== > --- trunk/reactos/base/applications/charmap/map.c [iso-8859-1] (original) > +++ trunk/reactos/base/applications/charmap/map.c [iso-8859-1] Sun Apr 6 20:20:39 2014 > @@ -228,9 +228,9 @@ > ReleaseDC(infoPtr->hMapWnd, hdc); > > infoPtr->CurrentFont.lfCharSet = DEFAULT_CHARSET; > - wcscpy_s(infoPtr->CurrentFont.lfFaceName, > - sizeof(infoPtr->CurrentFont.lfFaceName) / sizeof(infoPtr->CurrentFont.lfFaceName[0]), > - lpFontName); > + wcsncpy(infoPtr->CurrentFont.lfFaceName, > + lpFontName, > + sizeof(infoPtr->CurrentFont.lfFaceName) / sizeof(infoPtr->CurrentFont.lfFaceName[0])); > > infoPtr->hFont = CreateFontIndirectW(&infoPtr->CurrentFont); > > > >

3 3

Re: [ros-dev] [ros-diffs] [khornicek] 62665: [MAIN] - fix a copypasta - fix a possible buffer overrun (x5) - fix a negative array index access
by Thomas Faber 06 Apr '14

06 Apr '14

You guys should consider replacing that stuff with strsafe functions while you're at it ;) On 2014-04-06 18:45, khornicek(a)svn.reactos.org wrote: > Author: khornicek > Date: Sun Apr 6 16:45:21 2014 > New Revision: 62665 > > URL: http://svn.reactos.org/svn/reactos?rev=62665&view=rev > Log: > [MAIN] > - fix a copypasta > - fix a possible buffer overrun (x5) > - fix a negative array index access > > Modified: > trunk/reactos/dll/cpl/main/mouse.c > > Modified: trunk/reactos/dll/cpl/main/mouse.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/cpl/main/mouse.c?rev=6… > ============================================================================== > --- trunk/reactos/dll/cpl/main/mouse.c [iso-8859-1] (original) > +++ trunk/reactos/dll/cpl/main/mouse.c [iso-8859-1] Sun Apr 6 16:45:21 2014 > @@ -499,7 +499,7 @@ > /* Remove quotation marks */ > if (szTempData[0] == _T('"')) > { > - lpStart = szValueData + 1; > + lpStart = szTempData + 1; > szTempData[_tcslen(szTempData) - 1] = 0; > } > else > @@ -1022,9 +1022,9 @@ > static VOID > LoadInitialCursorScheme(HWND hwndDlg) > { > - TCHAR szSchemeName[256]; > - TCHAR szSystemScheme[256]; > - TCHAR szCursorPath[256]; > + TCHAR szSchemeName[MAX_PATH]; > + TCHAR szSystemScheme[MAX_PATH]; > + TCHAR szCursorPath[MAX_PATH]; > HKEY hCursorKey; > LONG lError; > DWORD dwDataSize; > @@ -1057,7 +1057,7 @@ > > if (dwSchemeSource != 0) > { > - dwDataSize = 256 * sizeof(TCHAR); > + dwDataSize = MAX_PATH * sizeof(TCHAR); > lError = RegQueryValueEx(hCursorKey, > NULL, > NULL, > @@ -1101,8 +1101,8 @@ > else if (dwSchemeSource == 2) > { > LoadString(hApplet, IDS_SYSTEM_SCHEME, szSystemScheme, MAX_PATH); > - _tcscat(szSchemeName, _T(" ")); > - _tcscat(szSchemeName, szSystemScheme); > + _tcsncat(szSchemeName, _T(" "), MAX_PATH - _tcslen(szSchemeName)); > + _tcsncat(szSchemeName, szSystemScheme, MAX_PATH - _tcslen(szSchemeName)); > } > > /* Search and select the curent scheme name from the scheme list */ > @@ -1276,6 +1276,10 @@ > { > case LBN_SELCHANGE: > nSel = SendMessage((HWND)lParam, LB_GETCURSEL, 0, 0); > + > + if(nSel == LB_ERR) > + break; > + > SendDlgItemMessage(hwndDlg, IDC_IMAGE_CURRENT_CURSOR, STM_SETIMAGE, IMAGE_CURSOR, > (LPARAM)g_CursorData[nSel].hCursor); > EnableWindow(GetDlgItem(hwndDlg,IDC_BUTTON_USE_DEFAULT_CURSOR), > >

2 1

Re: [ros-dev] [ros-diffs] [hbelusca] 62662: [NTDLL_APITEST]: Add braces and remove an unneeded trace.
by Thomas Faber 06 Apr '14

06 Apr '14

This will make any failure messages in the loop useless, since you won't know which test they're about. Just because the tests are succeeding now doesn't mean they always will. On 2014-04-06 17:51, hbelusca(a)svn.reactos.org wrote: > @@ -188,7 +190,6 @@ > > for (i = 0; i < TestCount; i++) > { > - trace("i = %d\n", i); > switch (TestCases[i].PrefixType) > { > case PrefixNone: > >

2 2

Re: [ros-dev] [ros-diffs] [dgorbachev] 62598: [BUGCODES] - Add an error message for Proprietary Software Execution Prevention feature supported by recent CPUs. - TODO: Implement this feature in the kernel.‏
by Pierre Schweitzer 01 Apr '14

01 Apr '14

Nice one :-). I thought you'd commit your ReactOS 1.0 patch today! Beware though, you're sitting BUGCODE_NDIS_DRIVER. Regards, -- Pierre Schweitzer <pierre(a)reactos.org> System Administrator ReactOS Foundation

4 3

Re: [ros-dev] [ros-builds] Linux_AMD64_2 VMWPlayer-Test: build failed
by Pierre Schweitzer 01 Apr '14

01 Apr '14

Working on DB server atm (hence the fails). Results will be properly submitted later on. Ignore failed shell errors for the next hour. Sorry about that. On 04/01/2014 11:24 AM, buildbot(a)reactos.org wrote: > The Buildbot has detected a failed build on builder Linux_AMD64_2 VMWPlayer-Test while building ReactOS. > Full details are available at: > http://build.reactos.org/builders/Linux_AMD64_2%20VMWPlayer-Test/builds/3636 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Linux_AMD64_2 > > Build Reason: Triggerable(Linux_AMD64_1 KVM-Test Trigger) > Build Source Stamp: 62598 > Blamelist: > > BUILD FAILED: failed shell > > sincerely, > -The Buildbot > > > > -- Pierre Schweitzer <pierre(a)reactos.org> System Administrator ReactOS Foundation

1 0

Installing driver without reboot
by Maxime Daniel 28 Mar '14

28 Mar '14

Hi, Is it possible to install a driver (virtual network interface) witout reboot the system ? I tried TAP interface (installation with devcon: devcon install inf-file tap0901) but the interface is only loaded during the next reboot (same for a ndis sample from DDK) Is there a way to load a driver interface with a true plug'n'play mechanism ? -- Daniel Maxime Linux version 3.6.9-maxux64 (emy) (gcc version 4.7.3 (Gentoo 4.7.3-r1 p1.4, pie-0.5.5) ) #3 SMP PREEMPT Wed Feb 19 16:40:22 CET 2014 16:33:29 up 24 days, 8 min, 1 user, load average: 0.31, 0.68, 0.72

1 0

Re: [ros-dev] Installing and running ReactOS on modern hardware
by Thomas Mueller 28 Mar '14

28 Mar '14

from "David Quintana (gigaherz)" <gigaherz(a)gmail.com>: > [-- Type: multipart/alternative, Encoding: 7bit, Size: 5.8K --] > Content-Type: multipart/alternative; boundary=001a1135f7ac55c1ca04f557713d > Content-Type: text/plain; charset=UTF-8 > First of all, I'm not an expert when it comes to what ReactOS supports in > terms of real hardware. > I believe (someone will correct me if I'm wrong), that ReactOS is not > currently able to boot from USB, and in fact, will fail to boot at all if > an incompatible USB controller (which is most of them, I think?) is > present. Burning a CD-ROM with the setup or livecd images, and possibly > disabling the USB controllers from your bios config, may give you better > results. > I'm assuming that your intention is to try ReactOS in real hardware, > otherwise it would be better advised to just use VMware, VirtualBox, or > QEMU, as those work mostly out of the box. > Ideally, your real-hardware testing platform should have a serial port, and > this serial port should be connected to another computer with a serial > port, by using a null-modem cable. This way you could see debug messages > through the serial port, and interact with the remote debugger driver when > (more than if) it crashes. > ReactOS currently only supports FAT32, because it's a simple driver that > does not need advanced features of the storage system. As the storage stack > improves, it will be possible to attempt using more complex drivers. We > already have an EXT2 driver, but last I heard it was not stable enough to > be able to boot from it. > That's all I know. If it's not enough, maybe someone with more experience > can add to it. Thanks for response, but surely one-part plain text would be better than multipart/alternative? I could try commands such as drivemap in GRUB 2, but then ReactOS would be lost when trying to boot. Would MS-Windows drivers work in ReactOS when running from within VirtualBox or QEMU? I don't really want to try ReactOS on the same disk with FreeBSD and Linux installations that I want to keep intact, might be too hazardous. I don't have any serial ports but have serial headers on motherboard, could conceivably make a serial port. FreeDOS can boot from USB stick thanks to recognition by the BIOS/UEFI. I really would want to install ReactOS to something rewritable; having to burn a new CD for every little change is too much. With ReactOS being far from ready for production use, I figure I would have to make frequent changes/adjustments. I downloaded the installation iso for ReactOS 0.3.15, burned to CD, but that failed to boot. I believe Linux and *BSD are far more flexible in where they can install to than MS-Windows or OS/2. I hope ReactOS could rise above such Windows booting limitations. I ran OS/2 from 16-bit 1.3 in 1990 or 1991 to OS/2 Warp 4 in the single-digit days of April 2001. Then following a crash, on the next boot, CHKDSK, which ran automatically on the uncleanly-dismounted file system, ran amok and trashed everything on the hard drive. I was never again able to boot OS/2 after that. Now Linux and FreeBSD capabilities seem to far surpass OS/2 and its successor eComStation. Tom

2 4

Status Meeting (March 2014)
by Aleksey Bragin 27 Mar '14

27 Mar '14

Hello, Let me invite you to the monthly status meeting taking place last Thursday of this month, 27th of March, 19:00 UTC. Put that into your calendars so you don't forget. IRC service will only be started shortly before the meeting. Your participation passwords and server address will be emailed to you shortly before the meeting starts, and they are going to be different once again as they are not stored in any database. Hopefully it's not much of inconvenience. If someone still is not getting passwords sent before a meeting - please email Pierre before the meeting started to get one. Please send agenda proposals to me. Regards, Aleksey Bragin

2 1

ndis netvmini adapter
by Maxime Daniel 27 Mar '14

27 Mar '14

Hi, I'm trying to compile and test the netvmini ndis 5 adapter code from WDK, at first to understand how it works, then to modify it for another purpose. At this time I: - put the code on driver/network/dd/netvmini and adapted CMakeLists - put the inf on media/inf and adapted CMakeLists - fixed the code, it builds - add an entry to hivesys.inf to load the driver at boot The driver is well displayed during boot, debug message appears (the DriverEntry), on NtObj, the driver is visible and it appears on "Non Plug and Play" on device manager. Now, I don't know exactly what to do with it. How can I call the driver and add an adapter ? The userland tool given with the code works (I needed to comment some functions and add _DEV_BROADCAST_HANDLE struct by hand, it seems to not be implemented on dbt.h). When I run the userland tools, it fails with EnumDevices. Some help ? Thanks

2 1

Resuscitating MSVC 2008 builds (at least) for testing purposes only :P
by Hermès BÉLUSCA - MAÏTO 26 Mar '14

26 Mar '14

Because I was recently shocked (if I may say :D) that, for building a 2003-class operating system, we need 2010+ tools, I was wondering whether it was still possible to build ReactOS with MSVC 2008 and 2005. Ive created a task for that in Jira: http://jira.reactos.org/browse/CORE-8023 . After application of the configure.cmd patch that I give in the report, plus few tweaks in two headers (and adding some stdint.h in the correct directory for MSVC, needed for compiling host-tools, because this file is not included in default MSVC installation until MSVC 2010+), I was able to build a full bootcd and livecd (see the details in the abovementioned report, basically it currently builds with MSVC 2008 but not 2005). However there happens an interesting thing: the [boot|live]cd boots (freeldr seems to work and load the kernel and drivers), but after that, the kernel (debugged in WinDbg) hangs indefinitely here: Windows Server 2003 Kernel Version 3790 UP Checked x86 compatible Built by: 20140326-r62565 Machine Name: Kernel base = 0x80400000 PsLoadedModuleList = 0x005fcf88 System Uptime: not available (f:\ros_vs_test\ntoskrnl\ke\i386\cpu.c:494) Supported CPU features : KF_V86_VIS KF_RDTSC KF_CR4 KF_CMOV KF_GLOBAL_PAGE KF_LARGE_PAGE KF_MTRR KF_CMPXCHG8B KF_MMX KF_WORKING_PTE KF_PAT KF_FXSR KF_FAST_SYSCALL KF_XMMI KF_XMMI64 KF_NX_BIT (f:\ros_vs_test\ntoskrnl\ke\i386\cpu.c:801) Prefetch Cache: 64 bytes L2 Cache: 0 bytes L2 Cache Line: 64 bytes L2 Cache Associativity: 0 <_hangs_forever_here_> If some of you have an idea what *might* happen there, Im all ears! Cheers, Hermès.

2 1

Need assistance on bug 7965
by Alexander Varnin 26 Mar '14

26 Mar '14

Hello, dear developers! Sorry if I am doing something wrong, but I am not sure, if everyone who may help would be notified by JIRA. I made some bug hunting on CORE-7965 and now need some assistance in finding way to fix it. I have posted the results in my last comment on JIRA: http://jira.reactos.org/browse/CORE-7965?focusedCommentId=57456&page=com.at… In short: a bug is related to some interprocess virtual address transmission that is leading to access attempt on unallocated virtual memory, that finally crashes ReactOS.

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 62562: [EXT2] try_return() == try_return(S) with nothing in S . The code sometimes use it. Shut up MSVC warning C4003: not enough actual parameters for macro 'try_return'.
by Thomas Faber 26 Mar '14

26 Mar '14

That's illegal, macros can't be overloaded. drivers/filesystems/ext2/inc/ext2fsd.h:64:0: warning: "try_return" redefined [enabled by default] You could try #define try_return(...) { __VA_ARGS__; goto try_exit; } If that doesn't do it, it might simply need a separate macro (I'm not sure to what extent this is third party code though) (also if these were the last instances of that -- and I think so --, we might want to make 4003 an error) On 2014-03-24 23:20, hbelusca(a)svn.reactos.org wrote: > Author: hbelusca > Date: Mon Mar 24 22:20:52 2014 > New Revision: 62562 > > URL: http://svn.reactos.org/svn/reactos?rev=62562&view=rev > Log: > [EXT2] > try_return() == try_return(S) with nothing in S . The code sometimes use it. > Shut up MSVC warning C4003: not enough actual parameters for macro 'try_return'. > > Modified: > trunk/reactos/drivers/filesystems/ext2/inc/ext2fsd.h > > Modified: trunk/reactos/drivers/filesystems/ext2/inc/ext2fsd.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/ext2/i… > ============================================================================== > --- trunk/reactos/drivers/filesystems/ext2/inc/ext2fsd.h [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/ext2/inc/ext2fsd.h [iso-8859-1] Mon Mar 24 22:20:52 2014 > @@ -60,6 +60,7 @@ > extern Ext2Data Ext2GlobalData; > > // try-finally simulation > +#define try_return() { goto try_exit; } > #define try_return(S) { S; goto try_exit; } > #define try_return1(S) { S; goto try_exit1; } > #define try_return2(S) { S; goto try_exit2; } > >

3 5

Installing and running ReactOS on modern hardware
by Thomas Mueller 24 Mar '14

24 Mar '14

I would like to build and install ReactOS from source but may be strapped for where to install it. I have USB sticks, 3 TB SATA hard drives, and 3 TB USB 3.0 hard drive. Hard drives are GPT-partitioned, which ReactOS apparently doesn't support. I have some old IDE hard drives which I access with USB 2.0 enclosure: 1271 MB and 40 GB. I also have an old 341 MB IDE hard drive that I can't read through USB 2.0 enclosure. I could compile from Linux or FreeBSD with ROSBE, could do further builds that way or with Wine and MinGW under Linux or FreeBSD. I don't want to do heavy compiling on USB stick if I can avoid it. I believe the only file system ReactOS currently supports is FAT16 or FAT32, which limits possible partition size compared to NTFS or Linux or BSD file systems. Can I install to USB stick, 4GB or 8 GB, and are there any other possibilities with my hardware? Tom

2 1

What's happening to the build bots??
by Hermès BÉLUSCA - MAÏTO 21 Mar '14

21 Mar '14

Hi all! Since some time now, most of our build bots are unavailable (see http://build.reactos.org/builders , the ones maintained by Olaf). What is happening to them? I sent him a mail but no answer so far I have received. We *need* those bots! , and especially the patch-bot that I am waiting for, because I have two big patches in my local wc that need to be tested and I cannot proceed further for now (and surely other have too, according to some recent Jira reports). Please fix them asap. if possible :D Cheers, Hermès

1 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 62480: [PSDK] winternl.h: Fix RtlLookupAtomInAtomTable prototype (should be sent to wine? not sure)
by Thomas Faber 20 Mar '14

20 Mar '14

This is intentional, their RTL_ATOM_TABLE is already a pointer: /* Wine doesn't implement atom table as NT does: * - in NT, atom tables are user space tables, which ntdll directly accesses * - on Wine, (even local) atom tables are wineserver objects, hence a HANDLE */ typedef struct atom_table *RTL_ATOM_TABLE, **PRTL_ATOM_TABLE; So that would need to be changed consistently. (also, winternl.h should be used by Wine code only, so shouldn't affect us -- since we have NDK to use instead) On 2014-03-11 23:48, tkreuzer(a)svn.reactos.org wrote: > Author: tkreuzer > Date: Tue Mar 11 22:48:04 2014 > New Revision: 62480 > > URL: http://svn.reactos.org/svn/reactos?rev=62480&view=rev > Log: > [PSDK] > winternl.h: Fix RtlLookupAtomInAtomTable prototype (should be sent to wine? not sure) > > Modified: > trunk/reactos/include/psdk/winternl.h > > Modified: trunk/reactos/include/psdk/winternl.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/psdk/winternl.h?re… > ============================================================================== > --- trunk/reactos/include/psdk/winternl.h [iso-8859-1] (original) > +++ trunk/reactos/include/psdk/winternl.h [iso-8859-1] Tue Mar 11 22:48:04 2014 > @@ -632,7 +632,7 @@ > FileFsMaximumInformation > } FS_INFORMATION_CLASS, *PFS_INFORMATION_CLASS; > > -typedef enum _KEY_INFORMATION_CLASS { > +typedef enum _KEY_INFORMATION_CLASS { > KeyBasicInformation = 0, > KeyNodeInformation = 1, > KeyFullInformation = 2, > @@ -2244,7 +2244,7 @@ > DWORD WINAPI RtlLengthSid(PSID); > NTSTATUS WINAPI RtlLocalTimeToSystemTime(const LARGE_INTEGER*,PLARGE_INTEGER); > BOOLEAN WINAPI RtlLockHeap(HANDLE); > -NTSTATUS WINAPI RtlLookupAtomInAtomTable(RTL_ATOM_TABLE,const WCHAR*,RTL_ATOM*); > +NTSTATUS WINAPI RtlLookupAtomInAtomTable(RTL_ATOM_TABLE*,const WCHAR*,RTL_ATOM*); > > NTSTATUS WINAPI RtlMakeSelfRelativeSD(PSECURITY_DESCRIPTOR,PSECURITY_DESCRIPTOR,LPDWORD); > void WINAPI RtlMapGenericMask(PACCESS_MASK,const GENERIC_MAPPING*); > >

2 1

Thoughts on Kickstarter
by Ólafur Arason 17 Mar '14

17 Mar '14

Hi, I've been following the project for years and I've even used explorer implementation on Windows. I also went to the Montreal event. I'm a linux user so I won't be a full time user any time soon. What I think would make a really good Kickstarter, having watched the Thorium Core progress: Developers Delight: What ReactOS or Thorium D has going for it is fully debugable and fundamental understanding of how Windows works. Microsoft has Visual Studio Online but it's pretty bad, at least at the moment it's a mess to set up. Having a way to run your MinGW-w64 projects, possible compile them. Having support for Clang msvc implementation. And last and not the least is the Visual Studio, which of course is the hardest. Even without that it's going to be really solid. An extra plus is being able to make Windows Embedded development stack running, because Trimble are really tied to that. Also Delphi and what ever other development you can think of. Having git support with CI type workflow is going to be great and with kernel level debug reports what could be better. The MingGW-w64 is going to great for all the open source software developers that need something to develop windows software without touching windows. You should talk with OpenShot they were having problems with that kind of development. This is going to be a double benefit for you guys, not only will it provide you with information about what people are using and what bugs are in your system but also provide a lot of foss software on your platform. Embedded dreams: Now that XP is through people need an embedded version, Windows Embedded isn't it, because it has a really weird api. Vista isn't really there or 7 so, where is your chance. Banks are paying Microsoft to extend XP for their ATMs but not every one can afford it. Enter Thorium E, for all those kiosks and POS. You have greater control so you can build a kit for Embedded user where they decide what's going to be included and what comes up, like not having a screen saver, virus software, IE, only allowing one or two exe files to run and only certain dlls. This would also be perfect to make single use virtual images with only one program running. If you need any help with making the video or with the campaign I would love to help. Regards, Olaf

1 0

[CORE-7969] A week later
by Minas Abrahamyan 15 Mar '14

15 Mar '14

Hi developers, Passed a week after I provided a ready for review and apply patch, a simplest solution for simplest bug. Could anyone review, test, and apply it? https://jira.reactos.org/browse/CORE-7969 Thanks

2 1

ReactOS needs to be self-hostable!
by Hermès BÉLUSCA - MAÏTO 15 Mar '14

15 Mar '14

Hi all ! ReactOS severely needs to be self-hostable for many reasons, one of it because it could allow people who only have Linux to be able to program / debug ReactOS with Windows tools (e.g. we have some people here and there complaining that they cannot use powerful debugging programs for debugging ReactOS (e.g. WinDbg and so on with MSVC builds of ReactOS) and therefore restrain themselves in using the Goode Olde GCC + DPRINT method, because they are running only on Linux). Something more personal is that I really want to program ReactOS on itself (in a VM) when it becomes self-hostable. But there are *only* few steps remaining before ReactOS can really be in such situation !! Ive already tested RosBE on it and I was able to download and configure a build. But there *are still* problems. Here is my setup on a VM: main HDD of letter drive C: with ReactOS, second HDD of letter drive D: with ROS source code in D:\rossrc, third HDD of letter drive E: with build output files in E:\rosbuild . After having successfully configured a build in the usual way (E:\rosbuild> D:\rossrc\configure.cmd), I first tried to compile the host-tools (cd host-tools && ninja). The first thing that Ive noticed is that doing so retriggered a configure, then the compilation as wanted. I retried again, and again it reconfigured the build before actually rebuilding the host-tools. The same phenomenon appears then when trying to build ReactOS proper. After analyzing produced files by the configuration step and comparing with a clean build on windows 2k3, it became clear that few files were missing, because obviously not generated: E:\rosbuild\host-tools\CMakeFiles\2.8.10.2-ReactOS\CMakeCCompiler.cmake and CMakeCXXCompiler.cmake . The other .cmake files that should also be present here (CMakeRCCompiler.cmake and CMakeSystem.cmake) as well as two .bin files and two subdirectories where present (and contain the same things). I was suggesting it might be a problem with the command-line interpreter, so I changed our cmd.exe with the one of windows 2000 (not win2k3, because the latter makes extra calls to some security APIs of advapi32 not implemented on ReactOS before running .bat / .cmd files, and it fails), but nothing changed, the files were not still present. After having enabled extra debug output of cmake (that is called when configuring a build) by adding the flags --debug-output --trace (without quotes) in the cmake calls in configure.cmd (and after redirecting console stdout + stderr to a file when retrigerring a clean configuration), doing that on ReactOS *and* on win2k3 for comparison purposes, I saw that, at some point, some cmake flags concerning compiler recognition (à la: CMAKE_GCC_EXISTS for example) werent set to TRUE or FALSE, but were kept empty. So Im wondering whether it is actually some issue, either concerning our C runtime library (e.g. some called sprintf-like function fails or whatever) is buggy and something fails, OR, something file-system related. Concerning file-system, you know that we have LOTS of kernel32:file winetests failing, about problems for deleting files, recreating (or just creating) them, and so on Maybe for some reason cmake fails to create those CMake(C/CXX)Compiler.cmake files for the same reason one of the kernel32:file tests fail ? I dont know, this previous point being speculative since I didnt test anything regarding that. Therefore it would be very nice *to see you all* trying to uncover where this bug comes from so that you can *finally* declare ReactOS self-hostable before, maybe, the next release !! Cheers, Hermès

2 2

Re: [ros-dev] [ros-diffs] [fireball] 62477: [NTOS] - Remove unneeded macro by David Welch in 2002 and me in 2003.
by Timo Kreuzer 11 Mar '14

11 Mar '14

Good sart, but I'm going to outperform this cleanup approach a bit... ;-) Am 11.03.2014 19:46, schrieb fireball(a)svn.reactos.org: > Author: fireball > Date: Tue Mar 11 18:46:32 2014 > New Revision: 62477 > > URL: http://svn.reactos.org/svn/reactos?rev=62477&view=rev > Log: > [NTOS] > - Remove unneeded macro by David Welch in 2002 and me in 2003. > > Modified: > trunk/reactos/ntoskrnl/mm/i386/page.c > > Modified: trunk/reactos/ntoskrnl/mm/i386/page.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/i386/page.c?re… > ============================================================================== > --- trunk/reactos/ntoskrnl/mm/i386/page.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/mm/i386/page.c [iso-8859-1] Tue Mar 11 18:46:32 2014 > @@ -40,22 +40,10 @@ > #define PA_ACCESSED (1 << PA_BIT_ACCESSED) > #define PA_GLOBAL (1 << PA_BIT_GLOBAL) > > -#define HYPERSPACE (0xc0400000) > -#define IS_HYPERSPACE(v) (((ULONG)(v) >= HYPERSPACE && (ULONG)(v) < HYPERSPACE + 0x400000)) > +#define IS_HYPERSPACE(v) (((ULONG)(v) >= HYPER_SPACE && (ULONG)(v) <= HYPER_SPACE_END)) > > #define PTE_TO_PFN(X) ((X) >> PAGE_SHIFT) > #define PFN_TO_PTE(X) ((X) << PAGE_SHIFT) > - > -#if defined(__GNUC__) > -#define PTE_TO_PAGE(X) ((LARGE_INTEGER)(LONGLONG)(PAGE_MASK(X))) > -#else > -__inline LARGE_INTEGER PTE_TO_PAGE(ULONG npage) > -{ > - LARGE_INTEGER dummy; > - dummy.QuadPart = (LONGLONG)(PAGE_MASK(npage)); > - return dummy; > -} > -#endif > > const > ULONG > > >

1 0

Valve has publushed Direct3D -> OpenGL translation layer
by Alexander Rechitskiy 11 Mar '14

11 Mar '14

Valve has publushed Direct3D -> OpenGL translation layer with BSD like license https://github.com/ValveSoftware/ToGL Taken directly from the DOTA2 source tree; supports: Limited subset of Direct3D 9.0c Bytecode-level HLSL -> GLSL translator Some SM3 support: Multiple Render Targets, no Vertex Texture Fetch This most likely won't build by itself and is provided as-is and completely unsupported. Feel free to use it for your reference, incorporate it into your projects or send us modifications. Be wary that some parts are hardcoded to match Source Engine behavior; see CentroidMaskFromName() and ShadowDepthSamplerMaskFromName() in dxabstract.cpp. Please refer to the LICENSE file for more information. -- Best regards Alexander Rechitskiy

1 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 62442: [NTOSKRNL] - Implement FsRtlNotifyFilterReportChange - Implement FsRtlNotifyUpdateBuffer - Implement FsRtlCancelNotify - Implement FsRtlNotifyGetLastPartOffset - Fix implementa...
by Timo Kreuzer 08 Mar '14

08 Mar '14

See inline... Am 07.03.2014 20:33, schrieb pschweitzer(a)svn.reactos.org: > [...] > + /* Update user buffer with the change that occured > + * First copy parent name if any > + * Then copy target name, there's always one > + * And finally, copy stream name if any > + * If these names aren't unicode, then convert first > + */ > + _SEH2_TRY > + { > + OutputBuffer->NextEntryOffset = 0; > + OutputBuffer->Action = Action; > + OutputBuffer->FileNameLength = DataLength - sizeof(FILE_NOTIFY_INFORMATION); > + if (IsUnicode) > + { > + if (ParentName->Length) > + { > + RtlCopyMemory(OutputBuffer->FileName, ParentName->Buffer, ParentName->Length); > + OutputBuffer->FileName[ParentName->Length / sizeof(WCHAR)] = L'\\'; > + AlreadyWritten = ParentName->Length + sizeof(WCHAR); > + } > + RtlCopyMemory(OutputBuffer->FileName + AlreadyWritten, TargetName->Buffer, TargetName->Length); OutputBuffer->FileName is a WCHAR array, AlreadyWritten is a count of bytes, the pointer arithmetic is wrong here. > + if (StreamName) > + { > + AlreadyWritten += TargetName->Length; > + OutputBuffer->FileName[AlreadyWritten / sizeof(WCHAR)] = L':'; > + RtlCopyMemory(OutputBuffer->FileName + AlreadyWritten + sizeof(WCHAR), > + StreamName->Buffer, StreamName->Length); see above > + } > + } > + else > + { > + if (!ParentName->Length) > + { > + ASSERT(StreamName); > + RtlCopyMemory(OutputBuffer->FileName, StreamName->Buffer, StreamName->Length); > + } > + else > + { > + RtlOemToUnicodeN(OutputBuffer->FileName, OutputBuffer->FileNameLength, > + &ResultSize, ParentName->Buffer, > + ParentName->Length); > + OutputBuffer->FileName[ResultSize / sizeof(WCHAR)] = L'\\'; > + AlreadyWritten = ResultSize + sizeof(WCHAR); > + > + RtlOemToUnicodeN(OutputBuffer->FileName + AlreadyWritten, > + OutputBuffer->FileNameLength, &ResultSize, > + TargetName->Buffer, TargetName->Length); see above > + > + if (StreamName) > + { > + AlreadyWritten += ResultSize; > + OutputBuffer->FileName[AlreadyWritten / sizeof(WCHAR)] = L':'; > + RtlOemToUnicodeN(OutputBuffer->FileName + AlreadyWritten + sizeof(WCHAR), > + OutputBuffer->FileNameLength, &ResultSize, > + StreamName->Buffer, StreamName->Length); see above > [...] > + > + /* Look for target name & construct it, if required */ > + if (TargetName.Buffer) > + { > + TargetNameLength = TargetName.Length; The TargetNameLength vatiable is completely redundant > [...] > + > + /* Get the position where we can put our data (aligned!) */ > + AlignedDataLength = ROUND_UP(NotifyChange->DataLength, sizeof(ULONG)); > + /* If it's higher than buffer length, then, bail out without outputing */ > + if (DataLength > NumberOfBytes || AlignedDataLength + DataLength > NumberOfBytes) > + { > + NotifyChange->Flags |= NOTIFY_IMMEDIATELY; > + } > + else > + { > + OutputBuffer = 0; > + FileNotifyInfo = 0; Use NULL

1 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 62442: [NTOSKRNL] - Implement FsRtlNotifyFilterReportChange - Implement FsRtlNotifyUpdateBuffer - Implement FsRtlCancelNotify - Implement FsRtlNotifyGetLastPartOffset - Fix implementa...
by Jérôme Gardou 07 Mar '14

07 Mar '14

Awesomeness, in its purest art. Le 07.03.2014 20:33, pschweitzer(a)svn.reactos.org a écrit : > Author: pschweitzer > Date: Fri Mar 7 19:33:38 2014 > New Revision: 62442 > > URL: http://svn.reactos.org/svn/reactos?rev=62442&view=rev > Log: > [NTOSKRNL] > - Implement FsRtlNotifyFilterReportChange > - Implement FsRtlNotifyUpdateBuffer > - Implement FsRtlCancelNotify > - Implement FsRtlNotifyGetLastPartOffset > - Fix implementation of FsRtlNotifyFilterChangeDirectory > > This finishes the implementation of file system notifications inside the kernel. > Data are properly returned to the caller on changes. > > CORE-2582 > > Modified: > trunk/reactos/ntoskrnl/fsrtl/notify.c > trunk/reactos/ntoskrnl/include/internal/fsrtl.h > > Modified: trunk/reactos/ntoskrnl/fsrtl/notify.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/fsrtl/notify.c?re… > ============================================================================== > --- trunk/reactos/ntoskrnl/fsrtl/notify.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/fsrtl/notify.c [iso-8859-1] Fri Mar 7 19:33:38 2014 > @@ -12,6 +12,55 @@ > #define NDEBUG > #include <debug.h> > > +/* INLINED FUNCTIONS *********************************************************/ > + > +/* > + * @implemented > + */ > +FORCEINLINE > +VOID > +FsRtlNotifyAcquireFastMutex(IN PREAL_NOTIFY_SYNC RealNotifySync) > +{ > + ULONG_PTR CurrentThread = (ULONG_PTR)KeGetCurrentThread(); > + > + /* Only acquire fast mutex if it's not already acquired by the current thread */ > + if (RealNotifySync->OwningThread != CurrentThread) > + { > + ExAcquireFastMutexUnsafe(&(RealNotifySync->FastMutex)); > + RealNotifySync->OwningThread = CurrentThread; > + } > + /* Whatever the case, keep trace of the attempt to acquire fast mutex */ > + RealNotifySync->OwnerCount++; > +} > + > +/* > + * @implemented > + */ > +FORCEINLINE > +VOID > +FsRtlNotifyReleaseFastMutex(IN PREAL_NOTIFY_SYNC RealNotifySync) > +{ > + RealNotifySync->OwnerCount--; > + /* Release the fast mutex only if no other instance needs it */ > + if (!RealNotifySync->OwnerCount) > + { > + ExReleaseFastMutexUnsafe(&(RealNotifySync->FastMutex)); > + RealNotifySync->OwningThread = (ULONG_PTR)0; > + } > +} > + > +#define FsRtlNotifyGetLastPartOffset(FullLen, TargLen, Type, Chr) \ > + for (FullPosition = 0; FullPosition < FullLen; ++FullPosition) \ > + if (((Type)NotifyChange->FullDirectoryName->Buffer)[FullPosition] == Chr) \ > + ++FullNumberOfParts; \ > + for (LastPartOffset = 0; LastPartOffset < TargLen; ++LastPartOffset) { \ > + if ( ((Type)TargetDirectory.Buffer)[LastPartOffset] == Chr) { \ > + ++TargetNumberOfParts; \ > + if (TargetNumberOfParts == FullNumberOfParts) \ > + break; \ > + } \ > + } > + > /* PRIVATE FUNCTIONS *********************************************************/ > > VOID > @@ -22,13 +71,161 @@ > FsRtlNotifySetCancelRoutine(IN PIRP Irp, > IN PNOTIFY_CHANGE NotifyChange OPTIONAL); > > +/* > + * @implemented > + */ > VOID > NTAPI > FsRtlCancelNotify(IN PDEVICE_OBJECT DeviceObject, > IN PIRP Irp) > { > + PVOID Buffer; > + PIRP NotifyIrp; > + ULONG BufferLength; > + PIO_STACK_LOCATION Stack; > + PNOTIFY_CHANGE NotifyChange; > + PREAL_NOTIFY_SYNC RealNotifySync; > + PSECURITY_SUBJECT_CONTEXT SubjectContext = NULL; > + > + /* Get the NOTIFY_CHANGE struct and reset it */ > + NotifyChange = (PNOTIFY_CHANGE)Irp->IoStatus.Information; > + Irp->IoStatus.Information = 0; > + /* Reset the cancel routine */ > + IoSetCancelRoutine(Irp, NULL); > + /* And release lock */ > IoReleaseCancelSpinLock(Irp->CancelIrql); > - UNIMPLEMENTED; > + /* Get REAL_NOTIFY_SYNC struct */ > + RealNotifySync = NotifyChange->NotifySync; > + > + FsRtlNotifyAcquireFastMutex(RealNotifySync); > + > + _SEH2_TRY > + { > + /* Remove the IRP from the notifications list and mark it pending */ > + RemoveEntryList(&(Irp->Tail.Overlay.ListEntry)); > + IoMarkIrpPending(Irp); > + > + /* Now, the tricky part - let's find a buffer big enough to hold the return data */ > + if (NotifyChange->Buffer && NotifyChange->AllocatedBuffer == NULL && > + ((Irp->MdlAddress && MmGetSystemAddressForMdl(Irp->MdlAddress) == NotifyChange->Buffer) || > + NotifyChange->Buffer == Irp->AssociatedIrp.SystemBuffer)) > + { > + /* Assume we didn't find any */ > + Buffer = NULL; > + BufferLength = 0; > + > + /* If we don't have IRPs, check if current buffer is big enough */ > + if (IsListEmpty(&NotifyChange->NotifyIrps)) > + { > + if (NotifyChange->BufferLength >= NotifyChange->DataLength) > + { > + BufferLength = NotifyChange->BufferLength; > + } > + } > + else > + { > + /* Otherwise, try to look at next IRP available */ > + NotifyIrp = CONTAINING_RECORD(NotifyChange->NotifyIrps.Flink, IRP, Tail.Overlay.ListEntry); > + Stack = IoGetCurrentIrpStackLocation(NotifyIrp); > + > + /* If its buffer is big enough, get it */ > + if (Stack->Parameters.NotifyDirectory.Length >= NotifyChange->BufferLength) > + { > + /* Is it MDL? */ > + if (NotifyIrp->AssociatedIrp.SystemBuffer == NULL) > + { > + if (NotifyIrp->MdlAddress != NULL) > + { > + Buffer = MmGetSystemAddressForMdl(NotifyIrp->MdlAddress); > + } > + } > + else > + { > + Buffer = NotifyIrp->AssociatedIrp.MasterIrp; > + } > + > + /* Backup our accepted buffer length */ > + BufferLength = Stack->Parameters.NotifyDirectory.Length; > + if (BufferLength > NotifyChange->BufferLength) > + { > + BufferLength = NotifyChange->BufferLength; > + } > + } > + } > + > + /* At that point, we *may* have a buffer */ > + > + /* If it has null length, then note that we won't use it */ > + if (BufferLength == 0) > + { > + NotifyChange->Flags |= NOTIFY_IMMEDIATELY; > + } > + else > + { > + /* If we have a buffer length, but no buffer then allocate one */ > + if (Buffer == NULL) > + { > + PsChargePoolQuota(NotifyChange->OwningProcess, PagedPool, BufferLength); > + Buffer = ExAllocatePoolWithTag(PagedPool | POOL_RAISE_IF_ALLOCATION_FAILURE, BufferLength, 'NrSF'); > + NotifyChange->AllocatedBuffer = Buffer; > + } > + > + /* Copy data in that buffer */ > + RtlCopyMemory(Buffer, NotifyChange->Buffer, NotifyChange->DataLength); > + NotifyChange->ThisBufferLength = BufferLength; > + NotifyChange->Buffer = Buffer; > + } > + > + /* If we don't have valide buffer, ensure everything is 0-ed out */ > + if (NotifyChange->Flags & NOTIFY_IMMEDIATELY) > + { > + NotifyChange->Buffer = 0; > + NotifyChange->AllocatedBuffer = 0; > + NotifyChange->LastEntry = 0; > + NotifyChange->DataLength = 0; > + NotifyChange->ThisBufferLength = 0; > + } > + } > + > + /* It's now time to complete - data are ready */ > + > + /* Set appropriate status and complete */ > + Irp->IoStatus.Status = STATUS_CANCELLED; > + IofCompleteRequest(Irp, EVENT_INCREMENT); > + > + /* If that notification isn't referenced any longer, drop it */ > + if (!InterlockedDecrement((PLONG)&(NotifyChange->ReferenceCount))) > + { > + /* If it had an allocated buffer, delete */ > + if (NotifyChange->AllocatedBuffer) > + { > + PsReturnProcessPagedPoolQuota(NotifyChange->OwningProcess, NotifyChange->ThisBufferLength); > + ExFreePoolWithTag(NotifyChange->AllocatedBuffer, 'NrSF'); > + } > + > + /* In case of full name, remember subject context for later deletion */ > + if (NotifyChange->FullDirectoryName) > + { > + SubjectContext = NotifyChange->SubjectContext; > + } > + > + /* We mustn't have ANY change left anymore */ > + ASSERT(NotifyChange->NotifyList.Flink == NULL); > + ExFreePoolWithTag(NotifyChange, 0); > + } > + } > + _SEH2_FINALLY > + { > + FsRtlNotifyReleaseFastMutex(RealNotifySync); > + > + /* If the subject security context was captured, release and free it */ > + if (SubjectContext) > + { > + SeReleaseSubjectContext(SubjectContext); > + ExFreePool(SubjectContext); > + } > + } > + _SEH2_END; > } > > /* > @@ -58,6 +255,9 @@ > } > } > > +/* > + *@implemented > + */ > PNOTIFY_CHANGE > FsRtlIsNotifyOnList(IN PLIST_ENTRY NotifyList, > IN PVOID FsContext) > @@ -81,22 +281,6 @@ > } > } > return NULL; > -} > - > -FORCEINLINE > -VOID > -FsRtlNotifyAcquireFastMutex(IN PREAL_NOTIFY_SYNC RealNotifySync) > -{ > - ULONG_PTR CurrentThread = (ULONG_PTR)KeGetCurrentThread(); > - > - /* Only acquire fast mutex if it's not already acquired by the current thread */ > - if (RealNotifySync->OwningThread != CurrentThread) > - { > - ExAcquireFastMutexUnsafe(&(RealNotifySync->FastMutex)); > - RealNotifySync->OwningThread = CurrentThread; > - } > - /* Whatever the case, keep trace of the attempt to acquire fast mutex */ > - RealNotifySync->OwnerCount++; > } > > /* > @@ -216,7 +400,7 @@ > > DataLength = NotifyChange->DataLength; > > - NotifyChange->Flags &= (INVALIDATE_BUFFERS | WATCH_TREE); > + NotifyChange->Flags &= (NOTIFY_IMMEDIATELY | WATCH_TREE); > NotifyChange->DataLength = 0; > NotifyChange->LastEntry = 0; > > @@ -233,19 +417,6 @@ > } > } > > -FORCEINLINE > -VOID > -FsRtlNotifyReleaseFastMutex(IN PREAL_NOTIFY_SYNC RealNotifySync) > -{ > - RealNotifySync->OwnerCount--; > - /* Release the fast mutex only if no other instance needs it */ > - if (!RealNotifySync->OwnerCount) > - { > - ExReleaseFastMutexUnsafe(&(RealNotifySync->FastMutex)); > - RealNotifySync->OwningThread = (ULONG_PTR)0; > - } > -} > - > /* > * @implemented > */ > @@ -293,6 +464,91 @@ > > /* Return that we didn't removed cancel routine */ > return FALSE; > +} > + > +/* > + * @implemented > + */ > +BOOLEAN > +FsRtlNotifyUpdateBuffer(OUT PFILE_NOTIFY_INFORMATION OutputBuffer, > + IN ULONG Action, > + IN PSTRING ParentName, > + IN PSTRING TargetName, > + IN PSTRING StreamName, > + IN BOOLEAN IsUnicode, > + IN ULONG DataLength) > +{ > + /* Unless there's an issue with buffers, there's no reason to fail */ > + BOOLEAN Succeed = TRUE; > + ULONG AlreadyWritten = 0, ResultSize; > + > + PAGED_CODE(); > + > + /* Update user buffer with the change that occured > + * First copy parent name if any > + * Then copy target name, there's always one > + * And finally, copy stream name if any > + * If these names aren't unicode, then convert first > + */ > + _SEH2_TRY > + { > + OutputBuffer->NextEntryOffset = 0; > + OutputBuffer->Action = Action; > + OutputBuffer->FileNameLength = DataLength - sizeof(FILE_NOTIFY_INFORMATION); > + if (IsUnicode) > + { > + if (ParentName->Length) > + { > + RtlCopyMemory(OutputBuffer->FileName, ParentName->Buffer, ParentName->Length); > + OutputBuffer->FileName[ParentName->Length / sizeof(WCHAR)] = L'\\'; > + AlreadyWritten = ParentName->Length + sizeof(WCHAR); > + } > + RtlCopyMemory(OutputBuffer->FileName + AlreadyWritten, TargetName->Buffer, TargetName->Length); > + if (StreamName) > + { > + AlreadyWritten += TargetName->Length; > + OutputBuffer->FileName[AlreadyWritten / sizeof(WCHAR)] = L':'; > + RtlCopyMemory(OutputBuffer->FileName + AlreadyWritten + sizeof(WCHAR), > + StreamName->Buffer, StreamName->Length); > + } > + } > + else > + { > + if (!ParentName->Length) > + { > + ASSERT(StreamName); > + RtlCopyMemory(OutputBuffer->FileName, StreamName->Buffer, StreamName->Length); > + } > + else > + { > + RtlOemToUnicodeN(OutputBuffer->FileName, OutputBuffer->FileNameLength, > + &ResultSize, ParentName->Buffer, > + ParentName->Length); > + OutputBuffer->FileName[ResultSize / sizeof(WCHAR)] = L'\\'; > + AlreadyWritten = ResultSize + sizeof(WCHAR); > + > + RtlOemToUnicodeN(OutputBuffer->FileName + AlreadyWritten, > + OutputBuffer->FileNameLength, &ResultSize, > + TargetName->Buffer, TargetName->Length); > + > + if (StreamName) > + { > + AlreadyWritten += ResultSize; > + OutputBuffer->FileName[AlreadyWritten / sizeof(WCHAR)] = L':'; > + RtlOemToUnicodeN(OutputBuffer->FileName + AlreadyWritten + sizeof(WCHAR), > + OutputBuffer->FileNameLength, &ResultSize, > + StreamName->Buffer, StreamName->Length); > + } > + } > + } > + } > + _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > + { > + Succeed = FALSE; > + } > + _SEH2_END; > + > + return Succeed; > } > > /* PUBLIC FUNCTIONS **********************************************************/ > @@ -445,7 +701,7 @@ > > /*++ > * @name FsRtlNotifyFilterChangeDirectory > - * @unimplemented > + * @implemented > * > * FILLME > * > @@ -559,16 +815,16 @@ > NotifyIrp->IoStatus.Status = STATUS_DELETE_PENDING; > IoCompleteRequest(NotifyIrp, EVENT_INCREMENT); > } > - /* Complete if there is directory enumeration and no buffer available any more */ > - if ((NotifyChange->Flags & INVALIDATE_BUFFERS) && (NotifyChange->Flags & ENUMERATE_DIR)) > - { > - NotifyChange->Flags &= ~INVALIDATE_BUFFERS; > + /* Complete now if asked to (and not asked to notify later on) */ > + if ((NotifyChange->Flags & NOTIFY_IMMEDIATELY) && !(NotifyChange->Flags & NOTIFY_LATER)) > + { > + NotifyChange->Flags &= ~NOTIFY_IMMEDIATELY; > IoMarkIrpPending(NotifyIrp); > NotifyIrp->IoStatus.Status = STATUS_NOTIFY_ENUM_DIR; > IoCompleteRequest(NotifyIrp, EVENT_INCREMENT); > } > - /* If no data yet, or directory enumeration, handle */ > - else if (NotifyChange->DataLength == 0 || (NotifyChange->Flags & ENUMERATE_DIR)) > + /* If no data yet, or asked to notify later on, handle */ > + else if (NotifyChange->DataLength == 0 || (NotifyChange->Flags & NOTIFY_LATER)) > { > goto HandleIRP; > } > @@ -612,20 +868,13 @@ > else > { > /* If it can't contain WCHAR, it's ANSI */ > - if (FullDirectoryName->Length < sizeof(WCHAR)) > + if (FullDirectoryName->Length < sizeof(WCHAR) || ((CHAR*)FullDirectoryName->Buffer)[1] != 0) > { > NotifyChange->CharacterSize = sizeof(CHAR); > } > - /* First char is \, so in unicode, right part is 0 > - * whereas in ANSI it contains next char > - */ > - else if (((CHAR*)FullDirectoryName->Buffer)[1] == 0) > + else > { > NotifyChange->CharacterSize = sizeof(WCHAR); > - } > - else > - { > - NotifyChange->CharacterSize = sizeof(CHAR); > } > > /* Now, check is user is willing to watch root */ > @@ -668,7 +917,7 @@ > FsRtlNotifyReleaseFastMutex(RealNotifySync); > > /* If the subject security context was captured and there's no notify */ > - if (SubjectContext && (!NotifyChange || FullDirectoryName)) > + if (SubjectContext && (!NotifyChange || NotifyChange->FullDirectoryName)) > { > SeReleaseSubjectContext(SubjectContext); > ExFreePool(SubjectContext); > @@ -679,7 +928,7 @@ > > /*++ > * @name FsRtlNotifyFilterReportChange > - * @unimplemented > + * @implemented > * > * FILLME > * > @@ -731,7 +980,437 @@ > IN PVOID TargetContext, > IN PVOID FilterContext) > { > - KeBugCheck(FILE_SYSTEM); > + PIRP Irp; > + PVOID OutputBuffer; > + USHORT FullPosition; > + PLIST_ENTRY NextEntry; > + PIO_STACK_LOCATION Stack; > + PNOTIFY_CHANGE NotifyChange; > + PREAL_NOTIFY_SYNC RealNotifySync; > + PFILE_NOTIFY_INFORMATION FileNotifyInfo; > + BOOLEAN IsStream, IsParent, PoolQuotaCharged; > + STRING TargetDirectory, TargetName, ParentName, IntNormalizedParentName; > + ULONG NumberOfBytes, TargetNumberOfParts, FullNumberOfParts, LastPartOffset, ParentNameOffset, ParentNameLength; > + ULONG DataLength, TargetNameLength, AlignedDataLength; > + > + TargetDirectory.Length = 0; > + TargetDirectory.MaximumLength = 0; > + TargetDirectory.Buffer = NULL; > + TargetName.Length = 0; > + TargetName.MaximumLength = 0; > + TargetName.Buffer = NULL; > + ParentName.Length = 0; > + ParentName.MaximumLength = 0; > + ParentName.Buffer = NULL; > + IsStream = FALSE; > + > + PAGED_CODE(); > + > + DPRINT("FsRtlNotifyFilterReportChange(%p, %p, %p, %u, %p, %p, %p, %x, %x, %p, %p)\n", > + NotifySync, NotifyList, FullTargetName, TargetNameOffset, StreamName, NormalizedParentName, > + FilterMatch, Action, TargetContext, FilterContext); > + > + /* We need offset in name */ > + if (!TargetNameOffset && FullTargetName) > + { > + return; > + } > + > + /* Get real structure hidden behind the opaque pointer */ > + RealNotifySync = (PREAL_NOTIFY_SYNC)NotifySync; > + /* Acquire lock - will be released in finally block */ > + FsRtlNotifyAcquireFastMutex(RealNotifySync); > + _SEH2_TRY > + { > + /* Browse all the registered notifications we have */ > + for (NextEntry = NotifyList->Flink; NextEntry != NotifyList; > + NextEntry = NextEntry->Flink) > + { > + /* Try to find an entry matching our change */ > + NotifyChange = CONTAINING_RECORD(NextEntry, NOTIFY_CHANGE, NotifyList); > + if (FullTargetName != NULL) > + { > + ASSERT(NotifyChange->FullDirectoryName != NULL); > + if (!NotifyChange->FullDirectoryName->Length) > + { > + continue; > + } > + > + if (!(FilterMatch & NotifyChange->CompletionFilter)) > + { > + continue; > + } > + > + /* If no normalized name provided, construct it from full target name */ > + if (NormalizedParentName == NULL) > + { > + IntNormalizedParentName.Buffer = FullTargetName->Buffer; > + if (TargetNameOffset != NotifyChange->CharacterSize) > + { > + IntNormalizedParentName.MaximumLength = > + IntNormalizedParentName.Length = TargetNameOffset - NotifyChange->CharacterSize; > + } > + else > + { > + IntNormalizedParentName.MaximumLength = > + IntNormalizedParentName.Length = TargetNameOffset; > + } > + NormalizedParentName = &IntNormalizedParentName; > + } > + > + /* heh? Watched directory bigger than changed file? */ > + if (NormalizedParentName->Length < NotifyChange->FullDirectoryName->Length) > + { > + continue; > + } > + > + /* Same len => parent */ > + if (NormalizedParentName->Length == NotifyChange->FullDirectoryName->Length) > + { > + IsParent = TRUE; > + } > + /* If not, then, we have to be watching the tree, otherwise we don't have to report such changes */ > + else if (!(NotifyChange->Flags & WATCH_TREE)) > + { > + continue; > + } > + /* And finally, we've to check we're properly \-terminated */ > + else > + { > + if (!(NotifyChange->Flags & WATCH_ROOT)) > + { > + if (NotifyChange->CharacterSize == sizeof(CHAR)) > + { > + if (((PSTR)NormalizedParentName->Buffer)[NotifyChange->FullDirectoryName->Length] != '\\') > + { > + continue; > + } > + } > + else > + { > + if (((PWSTR)NormalizedParentName->Buffer)[NotifyChange->FullDirectoryName->Length / sizeof (WCHAR)] != L'\\') > + { > + continue; > + } > + } > + } > + > + IsParent = FALSE; > + } > + > + /* If len matches, then check that both name are equal */ > + if (!RtlEqualMemory(NormalizedParentName->Buffer, NotifyChange->FullDirectoryName->Buffer, > + NotifyChange->FullDirectoryName->Length)) > + { > + continue; > + } > + > + /* Call traverse callback (only if we have to traverse ;-)) */ > + if (!IsParent > + && NotifyChange->TraverseCallback != NULL > + && !NotifyChange->TraverseCallback(NotifyChange->FsContext, > + TargetContext, > + NotifyChange->SubjectContext)) > + { > + continue; > + } > + > + /* And then, filter callback if provided */ > + if (NotifyChange->FilterCallback != NULL > + && FilterContext != NULL > + && !NotifyChange->FilterCallback(NotifyChange->FsContext, FilterContext)) > + { > + continue; > + } > + } > + /* We have a stream! */ > + else > + { > + ASSERT(NotifyChange->FullDirectoryName == NULL); > + if (TargetContext != NotifyChange->SubjectContext) > + { > + continue; > + } > + > + ParentName.Buffer = NULL; > + ParentName.Length = 0; > + IsStream = TRUE; > + IsParent = FALSE; > + } > + > + /* If we don't have to notify immediately, prepare for output */ > + if (!(NotifyChange->Flags & NOTIFY_IMMEDIATELY)) > + { > + /* If we have something to output... */ > + if (NotifyChange->BufferLength) > + { > + /* Get size of the output */ > + NumberOfBytes = 0; > + Irp = NULL; > + if (!NotifyChange->ThisBufferLength) > + { > + if (IsListEmpty(&NotifyChange->NotifyIrps)) > + { > + NumberOfBytes = NotifyChange->BufferLength; > + } > + else > + { > + Irp = CONTAINING_RECORD(NotifyChange->NotifyIrps.Flink, IRP, Tail.Overlay.ListEntry); > + Stack = IoGetCurrentIrpStackLocation(Irp); > + NumberOfBytes = Stack->Parameters.NotifyDirectory.Length; > + } > + } > + else > + { > + NumberOfBytes = NotifyChange->ThisBufferLength; > + } > + > + /* If we're matching parent, we don't care about parent (redundant) */ > + if (IsParent) > + { > + ParentName.Length = 0; > + } > + else > + { > + /* If we don't deal with streams, some more work is required */ > + if (!IsStream) > + { > + if (NotifyChange->Flags & WATCH_ROOT || > + (NormalizedParentName->Buffer != FullTargetName->Buffer)) > + { > + /* Construct TargetDirectory if we don't have it yet */ > + if (TargetDirectory.Buffer == NULL) > + { > + TargetDirectory.Buffer = FullTargetName->Buffer; > + TargetDirectory.Length = TargetNameOffset; > + if (TargetNameOffset != NotifyChange->CharacterSize) > + { > + TargetDirectory.Length = TargetNameOffset - NotifyChange->CharacterSize; > + } > + TargetDirectory.MaximumLength = TargetDirectory.Length; > + } > + /* Now, we start looking for matching parts (unless we watch root) */ > + TargetNumberOfParts = 0; > + if (!(NotifyChange->Flags & WATCH_ROOT)) > + { > + FullNumberOfParts = 1; > + if (NotifyChange->CharacterSize == sizeof(CHAR)) > + { > + FsRtlNotifyGetLastPartOffset(NotifyChange->FullDirectoryName->Length, > + TargetDirectory.Length, PSTR, '\\'); > + } > + else > + { > + FsRtlNotifyGetLastPartOffset(NotifyChange->FullDirectoryName->Length / sizeof(WCHAR), > + TargetDirectory.Length / sizeof(WCHAR), PWSTR, L'\\'); > + LastPartOffset *= NotifyChange->CharacterSize; > + } > + } > + > + /* Then, we can construct proper parent name */ > + ParentNameOffset = NotifyChange->CharacterSize + LastPartOffset; > + ParentName.Buffer = &TargetDirectory.Buffer[ParentNameOffset]; > + ParentNameLength = TargetDirectory.Length; > + } > + else > + { > + /* Construct parent name even for streams */ > + ParentName.Buffer = &NormalizedParentName->Buffer[NotifyChange->FullDirectoryName->Length] + NotifyChange->CharacterSize; > + ParentNameLength = NormalizedParentName->Length - NotifyChange->FullDirectoryName->Length; > + ParentNameOffset = NotifyChange->CharacterSize; > + } > + ParentNameLength -= ParentNameOffset; > + ParentName.Length = ParentNameLength; > + ParentName.MaximumLength = ParentNameLength; > + } > + } > + > + /* Start to count amount of data to write, we've first the structure itself */ > + DataLength = FIELD_OFFSET(FILE_NOTIFY_INFORMATION, FileName); > + > + /* If stream, we'll just append stream name */ > + if (IsStream) > + { > + ASSERT(StreamName != NULL); > + DataLength += StreamName->Length; > + } > + else > + { > + /* If not parent, we've to append parent name */ > + if (!IsParent) > + { > + if (NotifyChange->CharacterSize == sizeof(CHAR)) > + { > + DataLength += RtlOemStringToCountedUnicodeSize(&ParentName); > + } > + else > + { > + DataLength += ParentName.Length; > + } > + DataLength += sizeof(WCHAR); > + } > + > + /* Look for target name & construct it, if required */ > + if (TargetName.Buffer) > + { > + TargetNameLength = TargetName.Length; > + } > + else > + { > + TargetName.Buffer = &FullTargetName->Buffer[TargetNameOffset]; > + TargetNameLength = FullTargetName->Length - TargetNameOffset; > + TargetName.Length = TargetNameLength; > + TargetName.MaximumLength = TargetNameLength; > + } > + > + /* Then, we will append it as well */ > + if (NotifyChange->CharacterSize == sizeof(CHAR)) > + { > + DataLength += RtlOemStringToCountedUnicodeSize(&TargetName); > + } > + else > + { > + DataLength += TargetName.Length; > + } > + > + /* If we also had a stream name, then we can append it as well */ > + if (StreamName != NULL) > + { > + if (NotifyChange->CharacterSize == sizeof(WCHAR)) > + { > + DataLength += StreamName->Length + sizeof(WCHAR); > + } > + else > + { > + DataLength = DataLength + RtlOemStringToCountedUnicodeSize(&TargetName) + sizeof(CHAR); > + } > + } > + } > + > + /* Get the position where we can put our data (aligned!) */ > + AlignedDataLength = ROUND_UP(NotifyChange->DataLength, sizeof(ULONG)); > + /* If it's higher than buffer length, then, bail out without outputing */ > + if (DataLength > NumberOfBytes || AlignedDataLength + DataLength > NumberOfBytes) > + { > + NotifyChange->Flags |= NOTIFY_IMMEDIATELY; > + } > + else > + { > + OutputBuffer = 0; > + FileNotifyInfo = 0; > + /* If we already had a buffer, update last entry position */ > + if (NotifyChange->Buffer != NULL) > + { > + FileNotifyInfo = (PVOID)((ULONG_PTR)NotifyChange->Buffer + NotifyChange->LastEntry); > + FileNotifyInfo->NextEntryOffset = AlignedDataLength - NotifyChange->LastEntry; > + NotifyChange->LastEntry = AlignedDataLength; > + /* And get our output buffer */ > + OutputBuffer = (PVOID)((ULONG_PTR)NotifyChange->Buffer + AlignedDataLength); > + } > + /* If we hadn't buffer, try to find one */ > + else if (Irp != NULL) > + { > + if (Irp->AssociatedIrp.SystemBuffer != NULL) > + { > + OutputBuffer = Irp->AssociatedIrp.SystemBuffer; > + } > + else if (Irp->MdlAddress != NULL) > + { > + OutputBuffer = MmGetSystemAddressForMdl(Irp->MdlAddress); > + } > + > + NotifyChange->Buffer = OutputBuffer; > + NotifyChange->ThisBufferLength = NumberOfBytes; > + } > + > + /* If we couldn't find one, then allocate one */ > + if (NotifyChange->Buffer == NULL) > + { > + PoolQuotaCharged = FALSE; > + _SEH2_TRY > + { > + PsChargePoolQuota(NotifyChange->OwningProcess, PagedPool, NumberOfBytes); > + PoolQuotaCharged = TRUE; > + OutputBuffer = ExAllocatePoolWithTag(PagedPool | POOL_RAISE_IF_ALLOCATION_FAILURE, > + NumberOfBytes, 'NrSF'); > + NotifyChange->Buffer = OutputBuffer; > + NotifyChange->AllocatedBuffer = OutputBuffer; > + } > + /* If something went wrong during allocation, notify immediately instead of outputing */ > + _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > + { > + if (PoolQuotaCharged) > + { > + PsReturnProcessPagedPoolQuota(NotifyChange->OwningProcess, NumberOfBytes); > + } > + NotifyChange->Flags |= NOTIFY_IMMEDIATELY; > + } > + _SEH2_END; > + } > + > + /* Finally, if we have a buffer, fill it in! */ > + if (OutputBuffer != NULL) > + { > + if (FsRtlNotifyUpdateBuffer((FILE_NOTIFY_INFORMATION *)OutputBuffer, > + Action, &ParentName, &TargetName, > + StreamName, NotifyChange->CharacterSize == sizeof(WCHAR), > + DataLength)) > + { > + NotifyChange->DataLength = DataLength + AlignedDataLength; > + } > + /* If it failed, notify immediately */ > + else > + { > + NotifyChange->Flags |= NOTIFY_IMMEDIATELY; > + } > + } > + } > + > + /* If we have to notify right now (something went wrong?) */ > + if (NotifyChange->Flags & NOTIFY_IMMEDIATELY) > + { > + /* Ensure that all our buffers are NULL */ > + if (NotifyChange->Buffer != NULL) > + { > + if (NotifyChange->AllocatedBuffer != NULL) > + { > + PsReturnProcessPagedPoolQuota(NotifyChange->OwningProcess, NotifyChange->ThisBufferLength); > + ExFreePoolWithTag(NotifyChange->AllocatedBuffer, 'NrSF'); > + } > + > + NotifyChange->Buffer = NULL; > + NotifyChange->AllocatedBuffer = NULL; > + NotifyChange->LastEntry = 0; > + NotifyChange->DataLength = 0; > + NotifyChange->ThisBufferLength = 0; > + } > + } > + } > + } > + > + /* If asking for old name in case of a rename, notify later on, > + * so that we can wait for new name. > + * http://msdn.microsoft.com/en-us/library/dn392331.aspx > + */ > + if (Action == FILE_ACTION_RENAMED_OLD_NAME) > + { > + NotifyChange->Flags |= NOTIFY_LATER; > + } > + else > + { > + NotifyChange->Flags &= ~NOTIFY_LATER; > + if (!IsListEmpty(&NotifyChange->NotifyIrps)) > + { > + FsRtlNotifyCompleteIrpList(NotifyChange, STATUS_SUCCESS); > + } > + } > + } > + } > + _SEH2_FINALLY > + { > + FsRtlNotifyReleaseFastMutex(RealNotifySync); > + } > + _SEH2_END; > } > > /*++ > > Modified: trunk/reactos/ntoskrnl/include/internal/fsrtl.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/internal/… > ============================================================================== > --- trunk/reactos/ntoskrnl/include/internal/fsrtl.h [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/include/internal/fsrtl.h [iso-8859-1] Fri Mar 7 19:33:38 2014 > @@ -53,9 +53,9 @@ > // Notifications flags > // > #define WATCH_TREE 0x01 > -#define INVALIDATE_BUFFERS 0x02 > +#define NOTIFY_IMMEDIATELY 0x02 > #define CLEANUP_IN_PROCESS 0x04 > -#define ENUMERATE_DIR 0x08 > +#define NOTIFY_LATER 0x08 > #define WATCH_ROOT 0x10 > #define DELETE_IN_PROCESS 0x20 > > >

2 1

NDIS NdisIMRegisterLayeredMiniport
by Maxime Daniel 07 Mar '14

07 Mar '14

Hello, I need to use NDIS NdisIMRegisterLayeredMiniport functions to provide a virtual ethernet card. I read the documentation on MSDN and it seems that this functions is required to build an adapter without physical link (eg, with no hardware IRQ). The problem is that this function is not implemented yet on reactos (svn rev. 62083). Is someone can tell me if it's implementable or if there is an alternative to build a virtual ethernet adapter with current implementation of NDIS. Thanks. -- Daniel Maxime Linux version 3.6.9-maxux64 (emy) (gcc version 4.7.3 (Gentoo 4.7.3-r1 p1.4, pie-0.5.5) ) #3 SMP PREEMPT Wed Feb 19 16:40:22 CET 2014 14:02:53 up 1 day, 21:38, 1 user, load average: 0.17, 0.26, 0.23

2 2

Re: [ros-dev] [ros-diffs] [hbelusca] 62419: [APITESTS:kernel32] Be more specific about which last error we expect.
by Timo Kreuzer 05 Mar '14

05 Mar '14

IIRC, we have something like ok_lasterror() Am 05.03.2014 02:53, schrieb hbelusca(a)svn.reactos.org: > Author: hbelusca > Date: Wed Mar 5 01:53:46 2014 > New Revision: 62419 > > URL: http://svn.reactos.org/svn/reactos?rev=62419&view=rev > Log: > [APITESTS:kernel32] > Be more specific about which last error we expect. > > Modified: > trunk/rostests/apitests/kernel32/dosdev.c > > Modified: trunk/rostests/apitests/kernel32/dosdev.c > URL: http://svn.reactos.org/svn/reactos/trunk/rostests/apitests/kernel32/dosdev.… > ============================================================================== > --- trunk/rostests/apitests/kernel32/dosdev.c [iso-8859-1] (original) > +++ trunk/rostests/apitests/kernel32/dosdev.c [iso-8859-1] Wed Mar 5 01:53:46 2014 > @@ -137,7 +137,7 @@ > ok(Result, "Failed to subst drive\n"); > DriveType1 = GetDriveTypeA(SUBST_DRIVE_WITH_TRAILING_PATH_SEPERATOR); > ok(DriveType1 != SystemDriveType, "subst drive types match when it shouldn't\n"); > - ok(GetLastError() == ERROR_FILE_NOT_FOUND, "GetLastError() reports unexpected error code\n"); > + ok(GetLastError() == ERROR_FILE_NOT_FOUND, "Wrong last error. Expected %lu, got %lu\n", (DWORD)(ERROR_FILE_NOT_FOUND), GetLastError()); > dwMaskCur = GetLogicalDrives(); > ok(dwMaskCur != dwMaskPrev, "Drive masks match when it shouldn't\n"); > ok((dwMaskCur & (1 << (SUBST_DRIVE_LETTER - 'A'))), "Drive bit is not set\n"); > @@ -168,7 +168,7 @@ > ok(Result, "Failed to subst drive\n"); > DriveType1 = GetDriveTypeA(SUBST_DRIVE_WITH_TRAILING_PATH_SEPERATOR); > ok(DriveType1 != SystemDriveType, "subst drive types match when it shouldn't\n"); > - ok(GetLastError() == ERROR_FILE_NOT_FOUND, "GetLastError() reports unexpected error code\n"); > + ok(GetLastError() == ERROR_FILE_NOT_FOUND, "Wrong last error. Expected %lu, got %lu\n", (DWORD)(ERROR_FILE_NOT_FOUND), GetLastError()); > dwMaskCur = GetLogicalDrives(); > ok(dwMaskCur != dwMaskPrev, "Drive masks match when it shouldn't\n"); > ok((dwMaskCur & (1 << (SUBST_DRIVE_LETTER - 'A'))), "Drive bit is not set\n"); > @@ -203,7 +203,7 @@ > ok(Result, "Failed to subst drive\n"); > DriveType1 = GetDriveTypeA(SUBST_DRIVE_WITH_TRAILING_PATH_SEPERATOR); > ok(DriveType1 != SystemDriveType, "subst drive types match when it shouldn't\n"); > - ok(GetLastError() == ERROR_FILE_NOT_FOUND, "GetLastError() reports unexpected error code\n"); > + ok(GetLastError() == ERROR_FILE_NOT_FOUND, "Wrong last error. Expected %lu, got %lu\n", (DWORD)(ERROR_FILE_NOT_FOUND), GetLastError()); > dwMaskCur = GetLogicalDrives(); > ok(dwMaskCur != dwMaskPrev, "Drive masks match when it shouldn't\n"); > ok((dwMaskCur & (1 << (SUBST_DRIVE_LETTER - 'A'))), "Drive bit is not set\n"); > @@ -266,7 +266,7 @@ > ok((dwMaskCur & (1 << (SUBST_DRIVE_LETTER - 'A'))), "Drive bit is not set\n"); > hnd = FindFirstFileA(SUBST_DRIVE_SEARCH, &Data); > ok(hnd == INVALID_HANDLE_VALUE, "Opened subst drive when it should fail\n"); > - ok(GetLastError() == ERROR_INVALID_NAME, "GetLastError() reports unexpected error code\n"); > + ok(GetLastError() == ERROR_INVALID_NAME, "Wrong last error. Expected %lu, got %lu\n", (DWORD)(ERROR_INVALID_NAME), GetLastError()); > if (hnd) FindClose(hnd); > Result = DefineDosDeviceA(DDD_REMOVE_DEFINITION, SUBST_DRIVE, NULL); > ok(Result, "Failed to remove subst drive using NULL Target name\n"); > @@ -313,7 +313,7 @@ > ok(Result, "Failed to subst drive\n"); > DriveType1 = GetDriveTypeA(SUBST_DRIVE_WITH_TRAILING_PATH_SEPERATOR); > ok(DriveType1 != SystemDriveType, "subst drive types match when it shouldn't\n"); > - ok(GetLastError() == ERROR_FILE_NOT_FOUND, "GetLastError() reports unexpected error code\n"); > + ok(GetLastError() == ERROR_FILE_NOT_FOUND, "Wrong last error. Expected %lu, got %lu\n", (DWORD)(ERROR_FILE_NOT_FOUND), GetLastError()); > dwMaskCur = GetLogicalDrives(); > ok(dwMaskCur != dwMaskPrev, "Drive masks match when it shouldn't\n"); > ok((dwMaskCur & (1 << (SUBST_DRIVE_LETTER - 'A'))), "Drive bit is not set\n"); > @@ -333,7 +333,7 @@ > ok(Result, "Failed to subst drive\n"); > DriveType1 = GetDriveTypeA(SUBST_DRIVE_WITH_TRAILING_PATH_SEPERATOR); > ok(DriveType1 != SystemDriveType, "subst drive types match when it shouldn't\n"); > - ok(GetLastError() == ERROR_FILE_NOT_FOUND, "GetLastError() reports unexpected error code\n"); > + ok(GetLastError() == ERROR_FILE_NOT_FOUND, "Wrong last error. Expected %lu, got %lu\n", (DWORD)(ERROR_FILE_NOT_FOUND), GetLastError()); > dwMaskCur = GetLogicalDrives(); > ok(dwMaskCur != dwMaskPrev, "Drive masks match when it shouldn't\n"); > ok((dwMaskCur & (1 << (SUBST_DRIVE_LETTER - 'A'))), "Drive bit is not set\n"); > @@ -362,7 +362,7 @@ > ok(Result, "Failed to subst drive\n"); > Result = QueryDosDeviceA(SUBST_DRIVE, Buffer, 0); > ok(!Result, "Should fail as the buffer passed is supposed to be small\n"); > - ok(GetLastError() == ERROR_INSUFFICIENT_BUFFER, "GetLastError() reports unexpected error code\n"); > + ok(GetLastError() == ERROR_INSUFFICIENT_BUFFER, "Wrong last error. Expected %lu, got %lu\n", (DWORD)(ERROR_INSUFFICIENT_BUFFER), GetLastError()); > Result = QueryDosDeviceA(SUBST_DRIVE, Buffer, MAX_PATH); > ok(Result, "failed to get target path\n"); > ok(_strnicmp(Buffer, "\\??\\", 4) == 0, "The target returned does have correct prefix set\n"); > @@ -374,7 +374,7 @@ > /* This will try to retrieve all existing MS-DOS device names */ > Result = QueryDosDeviceA(NULL, Buffer, 0); > ok(!Result, "Should fail as the buffer passed is supposed to be small\n"); > - ok(GetLastError() == ERROR_INSUFFICIENT_BUFFER, "GetLastError() reports unexpected error code\n"); > + ok(GetLastError() == ERROR_INSUFFICIENT_BUFFER, "Wrong last error. Expected %lu, got %lu\n", (DWORD)(ERROR_INSUFFICIENT_BUFFER), GetLastError()); > } > > START_TEST(dosdev) > > >

2 1

About hotpatchable dlls on ReactOS
by Hermès BÉLUSCA - MAÏTO 02 Mar '14

02 Mar '14

Hi guys ! It seems to appear that some games need standard APIs hotpatchable, in the sense of MS: few extra bytes present in the prologue of the functions that allow somebody to detour the API. I knew that this feature was useful for windows updates, but what I didnt know is that there are other programs that use it: see this answer from James on the Epic Win! forum thread: http://www.reactos.org/forum/viewtopic.php?f=2 <http://www.reactos.org/forum/viewtopic.php?f=2&t=10972&p=106823#p106814> &t=10972&p=106823#p106814 , and the following post is something that Ive found about this subject, and the fact that Wine already have done something about that. So my question: should we support/create hotpatchable images (of the standard dlls and maybe ?? exes) in ReactOS ? Is it already done ? If not, what needs to be added ? It seems that MSVC and GCC handle that a bit differently. Cheers, Hermès BÉLUSCA - MAÏTO

4 6

jira account
by Alexander Varnin 01 Mar '14

01 Mar '14

Hello! I have registered on main site, because I want to login to JIRA, but JIRA says now that my login is incorrect. Does it need some time to make JIRA accout accessible after registration? Or I need to do some actions? Do I need to request account for JIRA separately?

5 7

Short Testman downtime tomorrow
by Colin Finck 28 Feb '14

28 Feb '14

Hi all, In the process of improving the performance of our website and finally getting rid of old.reactos.org, I'm moving away the Testman database to a new VM tomorrow. This will cause a short downtime, in which you're unable to browse Testman results or submit new ones. Even if something goes wrong during that process, the downtime shouldn't last longer than 2 hours. With best regards, Colin

1 0

Status Meeting (February 2014)
by Aleksey Bragin 27 Feb '14

27 Feb '14

Hello, Let me invite you to the monthly status meeting taking place last Thursday of this month, 27th of February, 19:00 UTC. Put that into your calendars so you don't forget. And that's in two days! IRC service will only be started shortly before the meeting. Your participation passwords and server address will be emailed to you shortly before the meeting starts, and they are going to be different once again as they are not stored in any database. Hopefully it's not much of inconvenience. If someone still is not getting passwords sent before a meeting - please email Pierre before the meeting started to get one. The agenda will be posted shortly before the meeting, suggestions are welcome (send them to me shortly before the meeting starts). Regards, Aleksey Bragin

2 1

Fwd: [ReactOS Deutschland e.V.] Your organization application has been rejected.
by Amine Khaldi 24 Feb '14

24 Feb '14

-------- Original Message -------- Subject: [ReactOS Deutschland e.V.] Your organization application has been rejected. Date: Mon, 24 Feb 2014 18:40:28 +0000 From: no-reply(a)google-melange.appspotmail.com To: amine.khaldi(a)reactos.org Thank you for submitting ReactOS Deutschland e.V.'s application to Google Summer of Code 2014. Unfortunately, we were unable to accept your organization's application at this time. Every year we receive many more applications than we are able to accommodate, and we would encourage you to reapply for future instances of the program. If you would like some general feedback on why your organization was not accepted, please consider attending the IRC meeting in #gsoc on Freenode on Friday, 28 February, 2014 at 16:00 UTC. Please note that the feedback meeting will be limited to the first 50 organizations to queue up (queuing in the channel will begin at 15:30 UTC). Best regards,

2 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev