- Ros-dev - ReactOS.org

Automated tests on Real HardWare + USB-trunk tests
by Jan Blomqvist Kinander 07 Feb '12

07 Feb '12

It is time to get automated tests made on real hardware up and running. I have started a project to get ReactOS to run on a FUJITSU SIEMENS ESPRIMO E5925 (wich already installs and runs from CD and HDD) however, to get automated tests going we need to be able to script stuff and feed it with iso:s, this I have planned to do with Intel AMT / vPro technology. ( http://en.wikipedia.org/wiki/Intel_Active_Management_Technology ). The goal is to have all builds tested on real HW and to get ReactOS to be a usable system for real HW to be able to kill as many bugs as possible and make different HW setups to work. This will be unnecessary before we go beta in the future. I have a bunch of debug lists from this actual HW, made and added links to them below, some of them are from the USB-trunk branch. IDE-r: http://dl.dropbox.com/u/37916523/ESPRIMO%20E5925%20capture.txt http://dl.dropbox.com/u/37916523/ESPRIMO%20E5925%20capture02.txt USB-trunk Real HW debug dumps: http://dl.dropbox.com/u/37916523/ESPRIMO%20E5925%20capture%20USB01.txt http://dl.dropbox.com/u/37916523/ESPRIMO%20E5925%20capture%20USB02.txt http://dl.dropbox.com/u/37916523/ESPRIMO%20E5925%20capture%20USB03.txt http://dl.dropbox.com/u/37916523/ESPRIMO%20E5925%20capture%20USB04.txt http://dl.dropbox.com/u/37916523/ESPRIMO%20E5925%20capture%20USB05.txt http://dl.dropbox.com/u/37916523/ESPRIMO%20E5925%20capture%20USB06.txt http://dl.dropbox.com/u/37916523/ESPRIMO%20E5925%20capture%20USB06a.txt http://dl.dropbox.com/u/37916523/Compaq%20EVO%20D51s%20capture%20USB01.txt http://dl.dropbox.com/u/37916523/AMD%20VIA%20capture%20USB01.txt ________________________________________________ Jan Blomqvist Kinander (Jaix Bly) Tel: +46 472 269932, Fax: +46 472 260980 Cell: +46 704 283980, E-Mail: jan.blomqvist(a)reactos.org

4 5

Re: [ros-dev] [ros-diffs] [janderwald] 55447: [DISK_NEW] - Fix compilation of new disk driver - Patch by Alex Ionescu
by Jérôme Gardou 06 Feb '12

06 Feb '12

Le 06/02/2012 07:50, janderwald(a)svn.reactos.org a écrit : > > +if(ARCH MATCHES i386) > + add_target_compile_flags(disk "-mrtd -fno-builtin -Wno-unused-variable -Wno-pointer-sign") > +endif() > + > Hey! Those look very GCC centric. The corresponding flag for MSVC to -mrtd would be /Gz. As for other flags, I'm unsure of what -fno-builtin would correspond to, and others are only for warnings. Cheers. Jérôme.

2 2

Buildbot update
by caemyr＠myopera.com 05 Feb '12

05 Feb '12

Few changes you might find important: - WDK builder has been added to scheduler. All trunk revisions are from now on built on both gcc and wdk. - Cameron-requested USB builder is added as well. This one, connected to usb-bringup-trunk branch, is triggered manually from web interface. All builds are stored on diablo, so team-members with ftp accounts on it can access the builds just as all other ones. Please contact me if one needs an account. Enjoy -- With best regards Caemyr

1 0

0.3.14 RC2
by Zachary Gorden 05 Feb '12

05 Feb '12

A second RC for 0.3.14 has been posted here: http://sourceforge.net/projects/reactos/files/ReactOS/0.3.14/0.3.14-RC2.iso… The main purpose of this RC is to see whether the hack Cameron Gutman provided works around the memory manager issue causing hangs while copying mshtml.dll during installation. Due to problems with the wallpapers, a livecd will not be built at this time. Z98

1 0

Re: [ros-dev] FreeRDP 1.0 Released
by Raymond Hoang 03 Feb '12

03 Feb '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 No, the Apache License isn't compatible with GPLv2, but it's compatible with GPLv3 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPKys0AAoJEOb7MMS0s1Vr6u0H/irIogS+rc59Q+8RUVS48OyA 6bPFeyGM//egEWmERvLOl4CBRe9DsPQiGhFzxOeo79khwA6lWhWD+bO5hOGuWpCZ GaKD5Ejy5kXf3ksDBH39/taYRCJo5z84aKEujncvKBhWSMFEVKGOADVopV/X1v8y bj9OrVJJzuUDZJw/uBkZFmbTLdGAPIAv/Z8+5qfsiUJnD/lWGN+9n+by/08shpG7 7fJW7OJu+z0j/VTxNwsP6cGlgLSOFONlMHrjBHLMd9wLqdN3FwnxOlkgwAch8lj+ XXVGcv5P1diubQt/Foy+clRYUWBL9xfbClBLU7+V+mdE6n3ssLYI7MZnbCR5LIw= =4MHl -----END PGP SIGNATURE-----

1 0

Monthly meeting - skipping another meeting this month
by Aleksey Bragin 02 Feb '12

02 Feb '12

Hello, we just had a monthly meeting in the beginning of January, so I don't see much of a reason to do another one at our usual date (and there are no urgent questions required for decision). Next meeting is going to happen in the end of February as scheduled. WBR, Aleksey.

12 21

Re: [ros-dev] [project-tools] Revision 1363: [ROSBE-UNIX] Implement support for pre-build & post-build hook scripts in RosBE-Unix.
by Colin Finck 01 Feb '12

01 Feb '12

pschweitzer(a)svn.reactos.org wrote: > touch boot/bootdata/packages/reactos.dff.in We can't put this one-liner into the CMakeLists.txt file? execute_process should do the job if there is no "touch" command in CMake itself. Your change makes RosBE depend on a very specific file in a very specific path of the source tree (=> tree change only possible with an updated RosBE). In addition, these hooks separate the build logic between CMake and RosBE and pave the way for even more source tree dependent changes in RosBE. I like to avoid this. - Colin

4 4

Re: [ros-dev] [ros-diffs] [zguo] 55331: Change version string to release header for rbuild. Next time we release, do this in the cmake file.
by Colin Finck 31 Jan '12

31 Jan '12

zguo(a)svn.reactos.org wrote: > Change version string to release header for rbuild. Next time we > release, do this in the cmake file. Don't forget the actual version number in the very same file ;-) Apart from this, please also check the SVN log of svn://svn.reactos.org/reactos/tags/ReactOS-0.3.13. I recall some regular changes for each release, which haven't been documented on the Wiki (e.g. RApps shortcut on the desktop). - Colin

2 2

RosBE-Unix 2.0-RC3
by Pierre Schweitzer 22 Jan '12

22 Jan '12

Hi, a third release candidate of RosBE-Unix 2.0 is now available on http://svn.reactos.org/RosBE-Temp/. Compared to second RC, it only comes with changes to the installation script (letting you define more precisely how you want to build it). Once installed, it is the same RosBE that RC2. Unless major issues are found in this RC3, this will be the last RC before release. Regards, Pierre

1 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 55017: [RTL] - Reimplement RtlSetCurrentDirectory_U. This fixes bugs & implements references count - Fix the FIXME in RtlpDosPathNameToRelativeNtPathName_Ustr by incrementing referenc...
by Pierre Schweitzer 20 Jan '12

20 Jan '12

Hi, forgot to say in commit message that it also implements RtlReleaseRelativeName Regards, Pierre

1 0

0.3.14 RC Testing
by Zachary Gorden 19 Jan '12

19 Jan '12

0.3.14 has been branched and a test ISO built. The developers request that testers test the "golden" applications to determine if there are any regressions. Details can be found here: http://www.reactos.org/wiki/Testing_Central

1 1

Proposal for FF support drop
by Pierre Schweitzer 18 Jan '12

18 Jan '12

Hi, with this mail, I propose we drop support for FireFox > 2 releases in rapps. The motivation is crystal clear: with their new release plan, they are releasing too often, and they don't maintain old links nor they provide a symbolic link to latest version. So, FireFox links in rapps are too often dead. So, they require a constant attention we can't offer (we have other cats to fry!). So, let's drop these multiple versions from rapps, and let just our 2.0. This will let users install a web browser and then install the browser they like using it. Anyone against this proposal? Otherwise, I'll drop all those links in a week. Regards, Pierre

11 25

Re: [ros-dev] [ros-diffs] [ion] 54990: Fix boot. The fact this fixes it should worry about the state of CSRSS...
by Timo Kreuzer 18 Jan '12

18 Jan '12

That reminds me of my attempt to fix this mess. I gave up, when almost every change of a structure size broke boot. Obviously there is code that relies on certain structure sizes, independent from the actual structure definitions, but I didn't find where there was. Good luck ;-) Am 17.01.2012 18:42, schrieb ion(a)svn.reactos.org: > Author: ion > Date: Tue Jan 17 17:42:47 2012 > New Revision: 54990 > > URL: http://svn.reactos.org/svn/reactos?rev=54990&view=rev > Log: > Fix boot. The fact this fixes it should worry about the state of CSRSS... ... > Modified: trunk/reactos/include/reactos/subsys/csrss/csrss.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/reactos/subsys/csr… > ============================================================================== > --- trunk/reactos/include/reactos/subsys/csrss/csrss.h [iso-8859-1] (original) > +++ trunk/reactos/include/reactos/subsys/csrss/csrss.h [iso-8859-1] Tue Jan 17 17:42:47 2012 > @@ -51,6 +51,7 @@ > > typedef struct > { > +#if 0 > // > // NT-type structure (BASE_CREATEPROCESS_MSG) > // > @@ -65,6 +66,7 @@ > PVOID PebAddressNative; > ULONG PebAddressWow64; > USHORT ProcessorArchitecture; > +#endif > // > // ReactOS Data > // > > >

1 0

December 2011 meeting minutes
by Jérôme Gardou 17 Jan '12

17 Jan '12

Hello everybody. You will find attached to this e-mail the minutes for the meeting of 2011. A topic as also been opened on the ReactOS forum :http://reactos.org/forum/viewtopic.php?f=2&t=10352 <http://reactos.org/forum/viewtopic.php?f=2&t=10352> I'm deeply sorry for the delay. Regards. Jérôme

4 3

RosBE-Unix 2.0-RC2
by Pierre Schweitzer 15 Jan '12

15 Jan '12

Hi, a second release candidate of RosBE-Unix 2.0 is now available on http://svn.reactos.org/RosBE-Temp/. Compared to first RC, it comes with CMake 2.8.7 (with Jérôme's patches), and binutils 2.22 (patched as well). Please try this BE and report any issues you may encounter. This will help us to fix everything for the CMake switch. If you're still lost in the use of CMake, have a look to the following page: http://www.reactos.org/wiki/CMake To sum it up: $ ./configure.sh $ (cd output-i386-MinGW/host-tools; makex) $ (cd reactos; makex) Regards, Pierre

4 4

0.PI branching
by Aleksey Bragin 14 Jan '12

14 Jan '12

Hi, as the results of the trunk testing depict, there are no major problems/regressions (compared to the previous release). Thus I propose to branch the 0.3.14 release. Any comments, motivated objections? If not, then branching will be done on Monday, 18th of December 2011. WBR, Aleksey Bragin.

13 36

Compiling problem on Ubuntu11
by Fan Zhang 13 Jan '12

13 Jan '12

Hi all, I'm trying to compiling the latest ReactOS on ubuntu. However, I met some problems(I can build it on Windows successfully). Could you help me to have a look? The following is what I did: 1. Get the latest cdoe from SVN, svn co svn://svn.reactos.org/reactos/trunk/reactos/ 2. Install MinGW64, sudo apt-get install gcc-ming-w64 3. modify Makefile, ROS_PREFIX = i686-w64-mingw32 4. compiling error is as below: ------------------------------------------------------------------------------------------------------- marvin@marvin-VirtualBox:~/reactos/src/latest/reactos$ make [CC] dll/win32/aclui/sidcache.c dll/win32/aclui/sidcache.c: In function ‘LookupSidInformation’: dll/win32/aclui/sidcache.c:216:11: error: variable ‘SidLength’ set but not used [-Werror=unused-but-set-variable] cc1: all warnings being treated as errors make: *** [obj-i386/dll/win32/aclui/sidcache_aclui.o] Error 1 ------------------------------------------------------------------------------------------------------- My questions are: 1. Which version of MinGW on linux did you use? 2. How to control compiling program to build Rlease and Debug version? Thanks. Marvin

4 5

Fwd: [ros-priv] Status of the usb-bringup Branch
by Colin Finck 08 Jan '12

08 Jan '12

Forwarding this with Johannes' consent: -------- Original Message -------- Subject: [ros-priv] Status of the usb-bringup Branch Date: Sat, 07 Jan 2012 16:21:24 +0100 From: Johannes Anderwald <janderwald(a)reactos.org> To: ReactOS developers private list <ros-priv(a)reactos.org> Hi Folks! For those who are interested in the status of the usb-bringup branch, here is a short summary of the current state, implemented features and required work to have it working in ReactOS. === USB Core Status === 1. There are 2 USB specifications for the USB 1.1 standard. Devices which are used in this standard are mice / keyboards etc OHCI (Open Host Controller Interface Standard) - All transfers types are implemented (bulk, iso, control, interrupt) UHCI (Universal Host Controller Interface Standard) - Totaly missing. Though it should be do-able to use ohci driver as a base and use Haiku driver[2] 2. EHCI (Enhanced Host Controller Interface) - Implemented transfer types: bulk & control. Interrupt & Isochronous transfers are not implemented. Due to the missing transfer types, devices who utilize those transfer types will not be available 3.) USBHUB - driver for managing port and hubs - Implementation state is unknown - michel martin has more information on that === USB Mass Storage Support Status === USB Mass Storage is implemented in usbstor driver and is fully working. Tested in WinXP + USBEHCI + USBSTOR. Mass storage support requires bulk and control transfers, which are implemented in USBEHCI === HID Status === The HID framework is built on 5 drivers 1. HIDUSB - this is the interface driver for the USB bus. Currently supported devices are mice. Basic keyboard support should also work currently 2. HIDCLASS - this is the class driver for HIDUSB and others. Functionality for mice & keyboard is implemented, though support for sending output reports is not implemented 3. MOUHID - mouse function driver for usb hid standard - Fully implemented and working 4. KBDHID - keyboard function driver for the hid standard - 90 % implemented, needs KbdHid_InsertScanCodes implemented for keyboard scan code dispatching to kbdclass and led status indicator support (which requires sending output reports) 5. HIDPARSE - driver for parsing report descriptors - functionality implemented for mice, keyboard support needs HidParser_TranslateUsage fully implemented for modifier state (caps lock, num lock, scroll lock) === What works and not === 1. Mouse support has been tested in WinXP with ReactOS USBOHCI + HIDUSB + HIDCLASS + MOUHID + HIDPARSE and is working. The USB + HID stack does not work in ReactOS at the moment, appears to be a problem with win32k, which only opens the first mice (\\Device\\PointerClass0) [...] 2. Basic Keyboard support need a 2/3 functions but probably suffer from the same bugs which affect HID mice support 3. Usb Mass storage support - Needs mountmgr / partmgr driver implemented. Will also need mountvol and other missing PnP stuff ============ As I will be working on my master thesis the next few months, I`ll have no time to focus on the usb or any ReactOS related development. If anybody wants to work on the usb branch, I`m very happy with it. Feel free to change anything, or rewrite evrything :) I`ll available via my reactos email address if any questions come up. kind regards, Johannes Links: [1] svn://svn.reactos.org/reactos/branches/usb-bringup [2] http://cgit.haiku-os.org/haiku/tree/src/add-ons/kernel/busses/usb/uhci.cpp _______________________________________________ Ros-priv mailing list Ros-priv(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-priv

1 0

Re: [ros-dev] [ros-diffs] [cgutman] 54875: [NDISUIO] - Use the correct IOCTL input buffer [WLANCONF] - Fix parameters to IOCTL_NDISUIO_QUERY_BINDING - Wlanconf is ready for testing with a real WLAN adapter (for anyone who w...
by Cameron Gutman 08 Jan '12

08 Jan '12

On Jan 8, 2012, at 1:08 AM, cgutman(a)svn.reactos.org wrote: > - Run "wlanconf -s <SSID>" to connect to an unencrypted wireless network > - Run "wlanconf -s <SSID> -w <WEP key>" to connect to a WEP encrypted wireless network (WPA not supported) > "wlanconf -s" does a network scan and lists networks in range. "wlanconf -c <SSID>" connects to a network. Sorry for the mixup. If anyone does get around to testing this, please report results to me. Regards, Cameron

1 0

Re: [ros-dev] [ros-diffs] [fireball] 54833: [NTOS] - Cast to actually returned types not just PVOID.
by Timo Kreuzer 07 Jan '12

07 Jan '12

Hi, what's the point of this change? IMO it's just ugly when we start casting from PVOID everywhere. Timo Am 04.01.2012 13:22, schrieb fireball(a)svn.reactos.org: > Author: fireball > Date: Wed Jan 4 12:22:38 2012 > New Revision: 54833 > > URL: http://svn.reactos.org/svn/reactos?rev=54833&view=rev > Log: > [NTOS] > - Cast to actually returned types not just PVOID. > > Modified: > trunk/reactos/ntoskrnl/include/internal/lpc_x.h > > Modified: trunk/reactos/ntoskrnl/include/internal/lpc_x.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/internal/… > ============================================================================== > --- trunk/reactos/ntoskrnl/include/internal/lpc_x.h [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/include/internal/lpc_x.h [iso-8859-1] Wed Jan 4 12:22:38 2012 > @@ -103,7 +103,7 @@ > > /* Allocate a message from the port zone while holding the lock */ > KeAcquireGuardedMutex(&LpcpLock); > - Message = ExAllocateFromPagedLookasideList(&LpcpMessagesLookaside); > + Message = (PLPCP_MESSAGE)ExAllocateFromPagedLookasideList(&LpcpMessagesLookaside); > if (!Message) >

2 1

Re: [ros-dev] COM Monitor
by Love Nystrom 06 Jan '12

06 Jan '12

Happy New Year to you all. Holidays fade away and I celebrate by submitting this tool. Patches are filed as Bugzilla #6802 (not a bug duh.. ;) http://www.reactos.org/bugzilla/show_bug.cgi?id=6802 ComMon is a simple COM port monitor utility to capture debug strings. It is meant to be used with com0com or a null modem cable. Usage and technical descriptions are in the ReadMe file. I currently build ComMon with VC6 and gcc (i.e RosBE). I see no reason it should not build with any MSVS or MinGW as well. Project files for MSVC6 and Code::Blocks, plus rbuild files, are included. Any questions.. contact me by email or ask right here. Best Regards Love

1 0

Release and monthly meeting plans
by Aleksey Bragin 05 Jan '12

05 Jan '12

Hi, due to expressed concerns about 0.PI release, there is no need to hurry and the release is being moved to January 2012. Regarding the monthly meeting, last thursday of this month turns out to be 29th of December, which obviously makes some people unable to attend. Preliminary date for the next meeting is 5th of January, and it depends on how many of our team could attend at that date. WBR, Aleksey Bragin.

2 1

Merry Christmas!!
by Javier Agustìn Fernàndez Arroyo 02 Jan '12

02 Jan '12

hey!! this is to wish ReactOS community a big and fun night !! Cheers!

4 4

Re: [ros-dev] [ros-diffs] [jgardou] 54793: [NEWINFLIB] - use _snwprintf instead of swprintf (MSVC is not compliant with standard here)
by Thomas Faber 31 Dec '11

31 Dec '11

Hey, On 2011-12-31 15:33, jgardou(a)svn.reactos.org wrote: > Author: jgardou > Date: Sat Dec 31 14:33:35 2011 > New Revision: 54793 > > URL: http://svn.reactos.org/svn/reactos?rev=54793&view=rev > Log: > [NEWINFLIB] > - use _snwprintf instead of swprintf (MSVC is not compliant with standard here) since _snwprintf seems unavailable on Unix, perhaps -D_CRT_NON_CONFORMING_SWPRINTFS would be an appropriate solution? That should cause VS2010 (2008 seems to have the version without a length) to use the non-standard no-length version just like GCC. That [1] gets rid of the warnings for me. Regards (and a happy new year :p), Tom [1] http://pastebin.com/4XU2SCXR

2 1

Revision 54745: cgutman
by caemyr＠myopera.com 24 Dec '11

24 Dec '11

This revision has caused a strange issue with both testbots. At kernel32:console crash, when testbot restarts vm, the test suite seems to begin right from the start, instead of next kernel32 test group. It happens subsequently whenever testbot reaches console test and crashes, leading to an ugly loop. -- With best regards Caemyr

2 1

FileZilla FTP Client
by Love Nystrom 19 Dec '11

19 Dec '11

Piece of good news too.. FileZilla FTP Client 3.5.2 (latest) installs and runs with flying colors by the looks of it. Would suggest it's added to the Rapps list :D (http://filezilla-project.org/download.php) Best Regards // Love On 2011-12-10 19.00, ros-dev-request(a)reactos.org wrote: > Send Ros-dev mailing list submissions to > ros-dev(a)reactos.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.reactos.org/mailman/listinfo/ros-dev > or, via email, send a message with subject or body 'help' to > ros-dev-request(a)reactos.org > > You can reach the person managing the list at > ros-dev-owner(a)reactos.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Ros-dev digest..." > > > Today's Topics: > > 1. Re: Invisible dialogs (Love Nystrom) > 2. Re: Invisible dialogs (Giannis Adamopoulos) > 3. Re: Invisible dialogs (James Tabor) > 4. Re: Invisible dialogs (James Tabor) > 5. Re: Missing RtlSetUnhandledExceptionFilter (Love Nystrom) > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev

4 3

Apps regressions in 0.3.14 vs. 0.3.13
by Aleksey Bragin 19 Dec '11

19 Dec '11

I did a brief comparison of wiki pages for 0.3.13 and 0.3.14 and found out at least the following apps which worked in 0.3.13 but does not work in 0.3.14 RC (aka trunk, we'll set exact revision soon): AbiWord Irfanview Opera 9.64 Python - bug #5767 SMPlayer 0.6.9 VB5 Runtime I will try to go through the list and see what are the problems. Everyone is welcome to do the same and distribute the workforce on fixing those issues. Certainly, on the positive side, there are "green" fields in the new test results which were previously "red" in 0.3.13, so user-visible progress definitely exists, we just need to make sure it's continuously going better and better, without steps backward. WBR, Aleksey Bragin.

3 3

Re: [ros-dev] COM Monitor
by Love Nystrom 18 Dec '11

18 Dec '11

Hi, Thanks for the pointer. I think other testers (devs too?) may find it useful, so it would be convenient to put it in ROS codebase. I'll file a patch with usage and technical description shortly. Best Regards // Love On 2011-12-17 19.00, ros-dev-request(a)reactos.org wrote: > Subject: > Re: [ros-dev] COM Monitor > From: > caemyr(a)myopera.com > Date: > Fri, 16 Dec 2011 23:44:29 +0100 > > To: > "ReactOS Development List" <ros-dev(a)reactos.org> > > > Hiya > > I think it depends what do you want to do with it. If you want it in ROS codebase (not necessarily in trunk, but still on svn) you should post a patch to bugzilla, with some info on how it works. > > Best regards >

1 0

Report broken link http://www.reactos.org/doxygen and http://doxygen.reactos.org/dev.html
by Qian Hong 18 Dec '11

18 Dec '11

Hello, http://www.reactos.org/doxygen is referenced by http://www.reactos.org/zh/index.html, but it is broken. also http://doxygen.reactos.org/dev.html is broken, which is referenced by http://doxygen.reactos.org Best wishes. -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/

2 2

Re: [ros-dev] Ros-dev Digest, Vol 88, Issue 13
by Dimas FranK 17 Dec '11

17 Dec '11

After installing boot screen does not show the image debug.log (ntoskrnl\kd\kdio.c:172) --------------------------------------------------------------- (ntoskrnl\kd\kdio.c:173) ReactOS 0.3.13 (Build 20110828-rUNKNOWN) (ntoskrnl\mm\mminit.c:243) 0x80000000 - 0x81000000 Boot Loaded Image (ntoskrnl\mm\mminit.c:247) 0xB0000000 - 0xB0900000 PFN Database (ntoskrnl\mm\mminit.c:251) 0xB0900000 - 0xB38B0000 ARM³ Non Paged Pool (ntoskrnl\mm\mminit.c:255) 0xBC000000 - 0xBD000000 System View Space (ntoskrnl\mm\mminit.c:259) 0xBD000000 - 0xC0000000 Session Space (ntoskrnl\mm\mminit.c:262) 0xC0000000 - 0xC0300000 Page Tables (ntoskrnl\mm\mminit.c:265) 0xC0300000 - 0xC0400000 Page Directories (ntoskrnl\mm\mminit.c:268) 0xC0400000 - 0xC0800000 Hyperspace (ntoskrnl\mm\mminit.c:272) 0xE1000000 - 0xF2400000 ARM³ Paged Pool (ntoskrnl\mm\mminit.c:275) 0xF2400000 - 0xF7BE0000 System PTE Space (ntoskrnl\mm\mminit.c:278) 0xF7BE0000 - 0xFFBE0000 Non Paged Pool Expansion PTE Space (hal\halx86\generic\legacy\bussupp.c:591) Your machine has a PCI-to-PCI or CardBUS Bridge. PCI devices may fail! (hal\halx86\generic\legacy\bussupp.c:620) Found parent bus (indicating PCI Bridge). PCI devices may fail! ====== PCI BUS HARDWARE DETECTION ======= 00:00.0 RAM memory [0500]: MCP78S [GeForce 8200] Memory Con [10de:0754] (rev a2) Subsystem: Unknown [1019:2646] Flags: bus master, 66MHz, latency 0 00:01.0 ISA bridge [0601]: MCP78S [GeForce 8200] LPC Bridge [10de:075c] (rev a2) Subsystem: Unknown [1019:2646] Flags: bus master, 66MHz, latency 0 I/O ports at 2f00 [size=256] 00:01.1 SMBus [0c05]: nVidia Corporation MCP78S [GeForce 8200] SMBus [10de:0752] (rev a1) Subsystem: Unknown [1019:2646] Flags: 66MHz, latency 0, IRQ 10 I/O ports at 2900 [size=256] I/O ports at 2d00 [size=256] I/O ports at 2e00 [size=512] Device is using IRQ 10! ISA Cards using that IRQ may fail! 00:01.2 RAM memory [0500]: MCP78S [GeForce 8200] Memory Con [10de:0751] (rev a1) Subsystem: Unknown [1019:2646] Flags: 66MHz, latency 0 00:01.3 Co-processor [0b40]: MCP78S [GeForce 8200] Co-Process [10de:0753] (rev a2) Subsystem: Unknown [1019:2646] Flags: bus master, 66MHz, latency 0, IRQ 11 Memory at f8e80000 (32-bit, non-prefetchable) [size=512K] Device is using IRQ 11! ISA Cards using that IRQ may fail! 00:01.4 RAM memory [0500]: MCP78S [GeForce 8200] Memory Con [10de:0568] (rev a1) Subsystem: Unknown [1019:2646] Flags: 66MHz, latency 0 00:02.0 USB Controller [0c03]: MCP78S [GeForce 8200] OHCI USB 1 [10de:077b] (rev a1) Subsystem: Unknown [1019:2646] Flags: bus master, 66MHz, latency 0, IRQ 15 Memory at f8e7f000 (32-bit, non-prefetchable) [size=4K] Device is using IRQ 15! ISA Cards using that IRQ may fail! Device is an OHCI (USB) PCI Expansion Card. Turn off Legacy USB in your BIOS! 00:02.1 USB Controller [0c03]: MCP78S [GeForce 8200] EHCI USB 2 [10de:077c] (rev a1) Subsystem: Unknown [1019:2646] Flags: bus master, 66MHz, latency 0, IRQ 10 Memory at f8e7ec00 (32-bit, non-prefetchable) [size=1K] Device is using IRQ 10! ISA Cards using that IRQ may fail! 00:04.0 USB Controller [0c03]: MCP78S [GeForce 8200] OHCI USB 1 [10de:077d] (rev a1) Subsystem: Unknown [1019:2646] Flags: bus master, 66MHz, latency 0, IRQ 10 Memory at f8e7d000 (32-bit, non-prefetchable) [size=4K] Device is using IRQ 10! ISA Cards using that IRQ may fail! Device is an OHCI (USB) PCI Expansion Card. Turn off Legacy USB in your BIOS! 00:04.1 USB Controller [0c03]: MCP78S [GeForce 8200] EHCI USB 2 [10de:077e] (rev a1) Subsystem: Unknown [1019:2646] Flags: bus master, 66MHz, latency 0, IRQ 11 Memory at f8e7e800 (32-bit, non-prefetchable) [size=2K] Device is using IRQ 11! ISA Cards using that IRQ may fail! 00:06.0 IDE interface [0101]: nVidia Corporation MCP78S [GeForce 8200] IDE [10de:0759] (rev a1) Subsystem: Unknown [1019:2646] Flags: bus master, 66MHz, latency 0 I/O ports at ffa0 [size=32] 00:07.0 Audio device [0403]: MCP72XE/MCP72P/MCP78U/MCP78S Hig [10de:0774] (rev a1) Subsystem: Unknown [1019:2646] Flags: bus master, 66MHz, latency 0, IRQ 15 Memory at f8e78000 (32-bit, non-prefetchable) [size=32K] Device is using IRQ 15! ISA Cards using that IRQ may fail! 00:08.0 PCI bridge [0604]: MCP78S [GeForce 8200] PCI Bridge [10de:075a] (rev a1) Subsystem: GLoria L [0000:0000] Flags: bus master, 66MHz, latency 0 Memory at 20010100 (32-bit, non-prefetchable) [size=256] Memory at 228000f0 (32-bit, non-prefetchable) [size=8M] Memory at 0000fff0 (32-bit, non-prefetchable) [size=256] Memory at 0000fff0 (32-bit, non-prefetchable) [size=256] 00:09.0 SATA controller [0106]: MCP78S [GeForce 8200] AHCI Contr [10de:0ad4] (rev a2) Subsystem: Unknown [1019:2646] Flags: bus master, 66MHz, latency 0, IRQ 05 I/O ports at b480 [size=128] I/O ports at b400 [size=1K] I/O ports at b080 [size=128] I/O ports at b000 [size=4K] I/O ports at ac00 [size=1K] Memory at f8e76000 (32-bit, non-prefetchable) [size=8K] Device is using IRQ 5! ISA Cards using that IRQ may fail! 00:0b.0 PCI bridge [0604]: MCP78S [GeForce 8200] PCI Expres [10de:0569] (rev a1) Subsystem: GLoria L [0000:0000] Flags: bus master, latency 0 Memory at 00020200 (32-bit, non-prefetchable) [size=512] I/O ports at 2000c1c0 [size=64] Memory at f9f0f8f0 (32-bit, non-prefetchable) [size=2K] I/O ports at cff1c600 [size=512] 00:10.0 PCI bridge [0604]: MCP78S [GeForce 8200] PCI Expres [10de:0778] (rev a1) Subsystem: GLoria L [0000:0000] Flags: bus master, latency 0, IRQ 10 Memory at 00030300 (32-bit, non-prefetchable) [size=256] I/O ports at 2000d1d0 [size=16] Memory at fde0fa00 (32-bit, non-prefetchable) [size=512] I/O ports at dff1d000 [size=4K] 00:12.0 PCI bridge [0604]: MCP78S [GeForce 8200] PCI Expres [10de:075b] (rev a1) Subsystem: GLoria L [0000:0000] Flags: bus master, latency 0, IRQ 11 Memory at 00040400 (32-bit, non-prefetchable) [size=1K] I/O ports at 01f0 [size=16] Memory at 0000fff0 (32-bit, non-prefetchable) [size=256] I/O ports at 1fff0 [size=16] 00:13.0 PCI bridge [0604]: MCP78S [GeForce 8200] PCI Bridge [10de:077a] (rev a1) Subsystem: GLoria L [0000:0000] Flags: bus master, latency 0, IRQ 15 Memory at 00050500 (32-bit, non-prefetchable) [size=256] I/O ports at 01f0 [size=16] Memory at 0000fff0 (32-bit, non-prefetchable) [size=256] I/O ports at 1fff0 [size=16] 00:14.0 PCI bridge [0604]: MCP78S [GeForce 8200] PCI Bridge [10de:077a] (rev a1) Subsystem: GLoria L [0000:0000] Flags: bus master, latency 0, IRQ 07 Memory at 00060600 (32-bit, non-prefetchable) [size=512] I/O ports at 2000e1e0 [size=32] Memory at fdf0fdf0 (32-bit, non-prefetchable) [size=256] I/O ports at f7f1f7f0 [size=16] 00:18.0 Host bridge [0600]: K10 [Opteron, Athlon64, Sempron] [1022:1200] (rev 00) Subsystem: GLoria L [0000:0000] Flags: latency 0 00:18.1 Host bridge [0600]: K10 [Opteron, Athlon64, Sempron] [1022:1201] (rev 00) Subsystem: GLoria L [0000:0000] Flags: latency 0 00:18.2 Host bridge [0600]: K10 [Opteron, Athlon64, Sempron] [1022:1202] (rev 00) Subsystem: GLoria L [0000:0000] Flags: latency 0 00:18.3 Host bridge [0600]: K10 [Opteron, Athlon64, Sempron] [1022:1203] (rev 00) Subsystem: GLoria L [0000:0000] Flags: latency 0 00:18.4 Host bridge [0600]: K10 [Opteron, Athlon64, Sempron] [1022:1204] (rev 00) Subsystem: GLoria L [0000:0000] Flags: latency 0 02:00.0 VGA compatible controller [0300]: nVidia Corporation C77 [GeForce 8200] [10de:0849] (rev a2) Subsystem: Unknown [1019:2646] Flags: latency 0, IRQ 10 Memory at f9000000 (32-bit, non-prefetchable) [size=16M] Memory at c8000000 (64-bit, prefetchable) [size=128M] Memory at c6000000 (64-bit, prefetchable) [size=32M] I/O ports at cc00 [size=1K] Device is using IRQ 10! ISA Cards using that IRQ may fail! 03:00.0 VGA compatible controller [0300]: nVidia Corporation G92 [GeForce 9800 GT] [10de:0605] (rev a2) Subsystem: GLoria L [0000:0000] Flags: bus master, latency 0, IRQ 10 Memory at fc000000 (32-bit, non-prefetchable) [size=64M] Memory at d0000000 (64-bit, prefetchable) [size=256M] Memory at fa000000 (64-bit, non-prefetchable) [size=32M] I/O ports at dc00 [size=1K] Device is using IRQ 10! ISA Cards using that IRQ may fail! 06:00.0 Ethernet controller [0200]: RTL8111/8168B PCI Express Gigabi [10ec:8168] (rev 02) Subsystem: Unknown [1019:8111] Flags: bus master, latency 0, IRQ 07 I/O ports at e800 [size=2K] Memory at fdfff000 (64-bit, non-prefetchable) [size=4K] Memory at f7ff0000 (64-bit, prefetchable) [size=64K] Device is using IRQ 7! ISA Cards using that IRQ may fail! ====== PCI BUS DETECTION COMPLETE ======= PC Compatible Eisa/Isa HAL Detected (ntoskrnl\io\iomgr\iorsrce.c:882) IoReportResourceUsage is halfplemented! (ntoskrnl\io\iomgr\iorsrce.c:882) IoReportResourceUsage is halfplemented! (hal\halx86\generic\legacy\bussupp.c:1149) Slot assignment for 5 on bus 0 (hal\halx86\generic\legacy\bus\pcibus.c:719) WARNING: PCI Slot Resource Assignment is FOOBAR (ntoskrnl\io\iomgr\driver.c:1540) '\Driver\BUSLOGIC' initialization failed, status (0xc00000c0) (ntoskrnl\io\iomgr\iorsrce.c:725) Failed opening given symbolic link! (ntoskrnl\mm\ARM3\sysldr.c:168) Loading: \SystemRoot\System32\DRIVERS\pci.sys at F7A30000 with b pages (ntoskrnl\io\pnpmgr\pnpmgr.c:183) Warning: PnP Start failed (Root\*PNP0A03\0001) (ntoskrnl\io\pnpmgr\pnpmgr.c:183) Warning: PnP Start failed (Root\*PNP0A03\0000) 2011/12/17, ros-dev-request(a)reactos.org <ros-dev-request(a)reactos.org>: > Send Ros-dev mailing list submissions to > ros-dev(a)reactos.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.reactos.org/mailman/listinfo/ros-dev > or, via email, send a message with subject or body 'help' to > ros-dev-request(a)reactos.org > > You can reach the person managing the list at > ros-dev-owner(a)reactos.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Ros-dev digest..." > > > Today's Topics: > > 1. Apps regressions in 0.3.14 vs. 0.3.13 (Aleksey Bragin) > 2. Re: Apps regressions in 0.3.14 vs. 0.3.13 (Igor Paliychuk) > 3. Re: Apps regressions in 0.3.14 vs. 0.3.13 (Aleksey Bragin) > 4. Re: COM Monitor (caemyr(a)myopera.com) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 16 Dec 2011 16:46:07 +0400 > From: Aleksey Bragin <aleksey(a)reactos.org> > Subject: [ros-dev] Apps regressions in 0.3.14 vs. 0.3.13 > To: ReactOS Development List <ros-dev(a)reactos.org> > Message-ID: <4EEB3D8F.7060405(a)reactos.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I did a brief comparison of wiki pages for 0.3.13 and 0.3.14 and found > out at least the following apps which worked in 0.3.13 but does not work > in 0.3.14 RC (aka trunk, we'll set exact revision soon): > > AbiWord > Irfanview > Opera 9.64 > Python - bug #5767 > SMPlayer 0.6.9 > VB5 Runtime > > I will try to go through the list and see what are the problems. > Everyone is welcome to do the same and distribute the workforce on > fixing those issues. > > Certainly, on the positive side, there are "green" fields in the new > test results which were previously "red" in 0.3.13, so user-visible > progress definitely exists, we just need to make sure it's continuously > going better and better, without steps backward. > > > WBR, > Aleksey Bragin. > > > > ------------------------------ > > Message: 2 > Date: Fri, 16 Dec 2011 15:31:41 +0200 > From: Igor Paliychuk <mansonigor(a)gmail.com> > Subject: Re: [ros-dev] Apps regressions in 0.3.14 vs. 0.3.13 > To: ReactOS Development List <ros-dev(a)reactos.org> > Message-ID: > <CAM0_0mZcLikSyHWJvfDfK3+qKi7OXKsTnJ3gCjtv0pjQNaNScA(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Afaik Infanview needs mfc libs to work so it's not regression, just > app requirement(though i didn't try to run it) > > 2011/12/16, Aleksey Bragin <aleksey(a)reactos.org>: >> I did a brief comparison of wiki pages for 0.3.13 and 0.3.14 and found >> out at least the following apps which worked in 0.3.13 but does not work >> in 0.3.14 RC (aka trunk, we'll set exact revision soon): >> >> AbiWord >> Irfanview >> Opera 9.64 >> Python - bug #5767 >> SMPlayer 0.6.9 >> VB5 Runtime >> >> I will try to go through the list and see what are the problems. >> Everyone is welcome to do the same and distribute the workforce on >> fixing those issues. >> >> Certainly, on the positive side, there are "green" fields in the new >> test results which were previously "red" in 0.3.13, so user-visible >> progress definitely exists, we just need to make sure it's continuously >> going better and better, without steps backward. >> >> >> WBR, >> Aleksey Bragin. >> >> _______________________________________________ >> Ros-dev mailing list >> Ros-dev(a)reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >> > > > > ------------------------------ > > Message: 3 > Date: Fri, 16 Dec 2011 19:57:38 +0400 > From: Aleksey Bragin <aleksey(a)reactos.org> > Subject: Re: [ros-dev] Apps regressions in 0.3.14 vs. 0.3.13 > To: ReactOS Development List <ros-dev(a)reactos.org> > Message-ID: <4EEB6A72.50908(a)reactos.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Update: > > out of this list, only VB5 Runtime remains untested. Everything else is > tested and works except for the newer version of AbiWord (2.9) which is > probably not a regression (and I fixed SxS-related problem this version > of AbiWord was suffering from). > > > On 16.12.2011 17:31, Igor Paliychuk wrote: >> Afaik Infanview needs mfc libs to work so it's not regression, just >> app requirement(though i didn't try to run it) >> >> 2011/12/16, Aleksey Bragin<aleksey(a)reactos.org>: >>> I did a brief comparison of wiki pages for 0.3.13 and 0.3.14 and found >>> out at least the following apps which worked in 0.3.13 but does not work >>> in 0.3.14 RC (aka trunk, we'll set exact revision soon): >>> >>> AbiWord >>> Irfanview >>> Opera 9.64 >>> Python - bug #5767 >>> SMPlayer 0.6.9 >>> VB5 Runtime >>> >>> I will try to go through the list and see what are the problems. >>> Everyone is welcome to do the same and distribute the workforce on >>> fixing those issues. >>> >>> Certainly, on the positive side, there are "green" fields in the new >>> test results which were previously "red" in 0.3.13, so user-visible >>> progress definitely exists, we just need to make sure it's continuously >>> going better and better, without steps backward. >>> >>> >>> WBR, >>> Aleksey Bragin. >>> >>> _______________________________________________ >>> Ros-dev mailing list >>> Ros-dev(a)reactos.org >>> http://www.reactos.org/mailman/listinfo/ros-dev >>> >> _______________________________________________ >> Ros-dev mailing list >> Ros-dev(a)reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev > > > > > ------------------------------ > > Message: 4 > Date: Fri, 16 Dec 2011 23:44:29 +0100 > From: caemyr(a)myopera.com > Subject: Re: [ros-dev] COM Monitor > To: "ReactOS Development List" <ros-dev(a)reactos.org> > Message-ID: > <1324075469.24028.140661012646145(a)webmail.messagingengine.com> > Content-Type: text/plain; charset="us-ascii" > > Hiya > > I think it depends what do you want to do with it. If you want it in ROS > codebase (not necessarily in trunk, but still on svn) you should post a > patch to bugzilla, with some info on how it works. > > Best regards > > On Fri, Dec 16, 2011, at 01:34 PM, Love Nystrom wrote: >> Hi, >> >> I wrote a test/debug util (COM monitor) for logging ReactOS dbg/bt >> messages, >> and wonder if it will be better to submit it as a bugzilla patch, or >> start a sourceforge >> or codeproject page for it ? >> >> Most of you probably have other utils, but ComMon is quite handy with >> it's >> auto enumerated COM ports, extended selection mode list, copy selected >> to clip, >> save/clear list etc.. >> >> I have it in my reactos/tools tree and it currently builds with the >> RosBE toolchain >> (standalone w C::B, currently not by rbuild). >> >> Would you be interested at all ? >> >> Best Regards >> // Love >> >> _______________________________________________ >> Ros-dev mailing list >> Ros-dev(a)reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >> > > > -- > With best regards > Caemyr > > > > ------------------------------ > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > > End of Ros-dev Digest, Vol 88, Issue 13 > *************************************** >

2 1

COM Monitor
by Love Nystrom 17 Dec '11

17 Dec '11

Hi, I wrote a test/debug util (COM monitor) for logging ReactOS dbg/bt messages, and wonder if it will be better to submit it as a bugzilla patch, or start a sourceforge or codeproject page for it ? Most of you probably have other utils, but ComMon is quite handy with it's auto enumerated COM ports, extended selection mode list, copy selected to clip, save/clear list etc.. I have it in my reactos/tools tree and it currently builds with the RosBE toolchain (standalone w C::B, currently not by rbuild). Would you be interested at all ? Best Regards // Love

3 3

Notepad and Text
by James Tabor 11 Dec '11

11 Dec '11

Has anyone noticed notepad? While user32_winetest win > data, then notepad data! The balance program go into high speed swapping!! Bunches of theses: (ntoskrnl/mm/section.c:2110) Pagint out 692d. (ntoskrnl/cc/view.c:403) Evicted 256 cache pages (ntoskrnl/mm/balance.c:167) Trimming consumer 0: Freed 256 pages with a target of 256 pages looping over and over~ When all this is going on I managed to get taskman up, notepad using 74,5?? K, wow! Just wondering, James

2 1

FileZilla FTP Client
by Love Nystrom 10 Dec '11

10 Dec '11

Piece of good news too.. FileZilla FTP Client 3.5.2 (latest) installs and runs with flying colors by the looks of it. Would suggest it's added to the Rapps list :D (http://filezilla-project.org/download.php) Best Regards // Love

1 0

Re: [ros-dev] Missing RtlSetUnhandledExceptionFilter
by Love Nystrom 10 Dec '11

10 Dec '11

Filed as #6753. MinGW / Msys-1.0: Sh.exe deadlock seems to be result of unhandled exception. (I.e. got nothing to do with batch processing). Best Regards // Love

1 0

Re: [ros-dev] Invisible dialogs
by Love Nystrom 09 Dec '11

09 Dec '11

Filed as #6751. It's a Z-order problem .. Might be easy to fix (for you). Best Regards // Love

3 3

Missing RtlSetUnhandledExceptionFilter
by Love Nystrom 09 Dec '11

09 Dec '11

It may be old news, but the fact that RtlSetUnhandledExceptionFilter is unimplemented makes it impossible for many apps to handle their heap allocation errors, aggravating the work for the memory manager, and resulting in crashes, leaks, and heap corruption. Whoever knows our SEH well enough could do a major improvement by fixing this. I came across this while testing MinGW 20100909 on r 54606, where sh.exe deadlocks after causing leaks in base/shell/cmd/batch.c [213,116,332]. (I was aiming for a fully bootstrapped system by letting ROS build ROS.) I'll try to establish a trace on the batch processing bug, and file it. Best Regards // Love

1 0

Invisible dialogs
by Love Nystrom 09 Dec '11

09 Dec '11

I've come across a whopper size bug, likely somewhere in USER or GDI (in r54606). If you switch app while you have a modal dialog open, and the new window covers that dialog, then when you come back that dialog is invisible, but it's window proc still active, meaning you have no way to back out of it, and you have to kill the app with taskman (if you can). I would nominate this a real blocker, it's just too embarrassing to release. I'll try to figure a repeatability and file a bug, and I'd recommend that USER and GDI devs heed Alekseys request for feature freeze and roll up their sleeves on this one. Best Regards // Love

1 0

Call for testing in preparation to 0.3.14
by Aleksey Bragin 07 Dec '11

07 Dec '11

Hello testers, your help is greatly needed. Trunk needs to be tested using this template as a guideline http://www.reactos.org/wiki/Tests_for_0.3.14 Imagine that trunk is a 0.3.14 RC (I don't want to branch because I already called for a feature freeze, so essentially trunk is in "release mode" right now, and branching would just require merging all revisions from trunk to the branch). Fill in the revision number in the "comments" section of that page when you test. Also, please be prepared that this might be a double work because after testing more changes (fixes) would come in and eventually require retesting, but it is vital to get clear non-biased understanding on how well trunk performs right now. Thank you, looking forward to see results, Aleksey Bragin.

5 6

Re: [ros-dev] [ros-diffs] [fireball] 54606: [NTDLL/LDR] - Improve LdrpCheckForKnownDll by adding parameters validation, return status value, better failure paths handling.
by Ged Murphy 07 Dec '11

07 Dec '11

Quick typo, your param checks in LdrpCheckForKnownDll come after your initialization -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of fireball(a)svn.reactos.org Sent: 07 December 2011 17:51 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [fireball] 54606: [NTDLL/LDR] - Improve LdrpCheckForKnownDll by adding parameters validation, return status value, better failure paths handling. Author: fireball Date: Wed Dec 7 17:51:18 2011 New Revision: 54606 URL: http://svn.reactos.org/svn/reactos?rev=54606&view=rev Log: [NTDLL/LDR] - Improve LdrpCheckForKnownDll by adding parameters validation, return status value, better failure paths handling. Modified: trunk/reactos/dll/ntdll/include/ntdllp.h trunk/reactos/dll/ntdll/ldr/ldrutils.c

3 2

November meeting minutes are there.
by Jérôme Gardou 04 Dec '11

04 Dec '11

You will find them on the forum : http://reactos.org/forum/viewtopic.php?f=2&t=9918 Best regards. Jérôme

7 8

Re: [ros-dev] HDD Geometry switch
by Love Nystrom 02 Dec '11

02 Dec '11

Olaf, please don't leave, the project needs you just as much as it needs the developers. Eric, Olaf's regression testing can not entail patching/rebuilding the system to accomodate disk structure (as you surely realize). That said, your reasons for change are sound, but perhaps you can make provisions to temporarily revert this if it causes massive problems. The timing _is_ not good if indeed a release is close at hand.. Can it wait until after the release? Alex, calling Olaf "not an OS tester" is a bit harsh, don't you think? Not everyone can be as weather hardened and experienced as you are. Regarding the reasons for change: Max CHS capacity: 10 bit C, 6 bit S, 8 bit H 2^10 * 2^6 * 255 == 16711680 sect(512) == 8.5 GB This is the geometry Eric wants to use, which makes sense because it can utilize the full CHS addressing capacity, and reflects the absolute limit of BIOS int 13h CHS calls. Previous 32S 64H CHS limit: 2^10 * 32 * 64 == 2097152 sect(512) == 1 GB This is an artificial and unnecessary limit, imposed by some strange design decision in Redmond a long long time ago. For non-devs: In CHS mode BIOS has an absolute disk limit of 8.5 GB, due to the available address bits, a 10/6 bit Cylinder/Sector composite, and an 8 bit head number. Any disk bigger than that can only be addressed in LBA mode (logical sector nr), which has a limit of 2^32 sectors == 2 TB. And, if anyone didn't know, the geometry parameters are stored in the boot sector, not in the MBR. There's more to it, but I stop at that. So.. Eric's change _should_ not cause any problem on disks larger than 8.5 GB, since they run in LBA mode by necessity. Concordingly, there could be forseeable problems on virtual disks which will often be smaller than 8 GB and may be running CHS mode. That'll be my penny to the pot for now. PS. A standard sector is 512 bytes. Bigger sectors, e.g 1kB, have been used in the past to increase capacity, but are _very_ unusual since they require proportionately higher bit frequencies on the media and are error-prone. Best Regards // Love

4 3

Re: [ros-dev] [ros-diffs] [cgutman] 54559: [NDIS] - Implement NdisReturnPackets and do proper reference tracking of packets sent to ProtocolReceivePacket - Plug a massive memory leak that resulted in leaking every packet de...
by Cameron Gutman 02 Dec '11

02 Dec '11

This should fix a bunch of weird issues with 3rd party NIC drivers. Most NICs use deserialized drivers and indicate packets using the NdisMIndicatePacket function. I'm fairly sure every modern NIC driver will display a similar problem to http://www.reactos.org/paste/index.php/9607/ and http://www.reactos.org/paste/index.php/9608/ where the driver eventually depletes its packet pool then quits sending and receiving packets. It also causes a leak of non-paged pool since we leak the buffers attached to the packet descriptor. The VirtIO NetKVM driver seems to have a particularly small packet queue (256 RX) and dies very early. I'd be interested to see what kind of uptime you guys can get with a 3rd party NIC driver now. I'm going to do some testing here in VirtualBox with a PRO/1000 to see how much data I can send/receive without problems. Regards, Cameron

1 0

Monthly status meeting
by Aleksey Bragin 01 Dec '11

01 Dec '11

Hello, Let me invite you to the monthly status meeting taking place last thursday of this month, 24th of November, 19:00 UTC. The meeting will be atirc://fezile.reactos.org (Port 6667, no SSL) in the channel #meeting. Note that the IRC service will only be started shortly before the meeting. Everyone is invited to listen, and active community members have their passwords so that they can participate in the discussion. If someone still is not getting passwords sent before a meeting - please email Colin or Pierre before the meeting started to get one. Proposed agenda for the meeting: 1. Release status 2. Website revamp status 3. CMake adoption status More suggestions are welcome as usual. With the best regards, Aleksey Bragin.

7 13

HDD Geometry switch
by caemyr＠myopera.com 28 Nov '11

28 Nov '11

Is the new geometry backward-compatible? If i recreate the partitions, will they be visible when i regress test revisions before 54511? -- With best regards Caemyr

14 29

Rbuild debug & KVM tester offline
by Pierre Schweitzer 28 Nov '11

28 Nov '11

Hi, due to connectivity issues with our servers in Sweden, I've taken our rbuild debug buildslave & our KVM testbot offline. This doesn't affect ISOs storage for the moment. Regards, Pierre

2 3

Sending pointers with non pointer functions!
by James Tabor 27 Nov '11

27 Nov '11

I see this and I LMFAO! co_IntSendMessageNoWait(Window->head.h, WM_WINDOWPOSCHANGING, 0, (LPARAM) WinPos); co_IntSendMessageNoWait(WinPos.hwnd, WM_WINDOWPOSCHANGED, 0, (LPARAM) &WinPos); There is more too! Amazing! Please tell me this is not wrong!!!! James

3 3

Re: [ros-dev] New harddisk geometry
by Love Nystrom 25 Nov '11

25 Nov '11

Hi People, I'm back after my ordeal in Europe and finally got an inet line.. But now I've over 300 mails from the list to wade through.. Ugh. It's gonna take some time to get up to speed. Hi Eric, That's all fine, it's just an educated choice of disk parameters as I see it. But anyway, all disk handling software (drivers etc) should honor whatever disk parameters you write in the boot record when you format the partition, and whatever geometry you write in the MBR when the disk gets partitioned, whether it's this or that. Just in case someone forgot ;) Best Regards Love > From: Eric Kohl <eric.kohl(a)t-online.de> > To: ReactOS Development List <ros-dev(a)reactos.org> > Date: Mon, 21 Nov 2011 23:17:40 +0100 > Subject: [ros-dev] Announcement: New harddisk geometry next weekend > Hi! > > I plan to change the standard harddisk geometry from the old 32 sectors and 64 heads geometry to the > new 63 sectors and 255 heads geometry next weekend. The old disk geometry was used up to > Windows NT4 and the new geometry is used since Windows 2000. So I guess it is time for ReactOS to > make this change too. ;-) > > This should improve the compatiibility with other OSs because every modern OS uses the new disk > geometry. > > Please note that you must delete and re-create all partitions on your virtual harddisk in order to get > a clean partition table when the new disk geomerty is in use. > > Regards, > Eric

1 0

Re: [ros-dev] [ros-diffs] [cgutman] 54484: [SCSIPORT] - Implement ScsiPortGetLogicalUnit
by Timo Kreuzer 25 Nov '11

25 Nov '11

Am 24.11.2011 01:07, schrieb cgutman(a)svn.reactos.org: > Author: cgutman > Date: Thu Nov 24 00:07:15 2011 > New Revision: 54484 > > URL: http://svn.reactos.org/svn/reactos?rev=54484&view=rev > Log: > [SCSIPORT] > - Implement ScsiPortGetLogicalUnit > > Modified: > trunk/reactos/drivers/storage/scsiport/scsiport.c > > ... > + > + /* Return the logical unit miniport extension */ > + return (LunExtension + 1); > } This looks broken to me. The old code was "&LunExtension->MiniportLunExtension", which seems to make more sense.

1 0

Re: [ros-dev] [ros-diffs] [jgardou] 54462: [RTL] - explicitly truncate some values, so it doesn't count as an error for compiler/MSVC runtime checker
by Timo Kreuzer 24 Nov '11

24 Nov '11

That doesn't make much sense. Whats the point of the LOWORD() macro, if not truncating it ? Fix the macro if its broken. Am 20.11.2011 20:45, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Sun Nov 20 19:45:06 2011 > New Revision: 54462 > > URL: http://svn.reactos.org/svn/reactos?rev=54462&view=rev > Log: > [RTL] > - explicitly truncate some values, so it doesn't count as an error for compiler/MSVC runtime checker > > Modified: > trunk/reactos/lib/rtl/image.c > > Modified: trunk/reactos/lib/rtl/image.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/rtl/image.c?rev=54462&… > ============================================================================== > --- trunk/reactos/lib/rtl/image.c [iso-8859-1] (original) > +++ trunk/reactos/lib/rtl/image.c [iso-8859-1] Sun Nov 20 19:45:06 2011 > @@ -369,7 +369,7 @@ > { > SHORT Offset; > USHORT Type; > - USHORT i; > + ULONG i; > PUSHORT ShortPtr; > PULONG LongPtr; > PULONGLONG LongLongPtr; > @@ -379,7 +379,6 @@ > Offset = SWAPW(*TypeOffset)& 0xFFF; > Type = SWAPW(*TypeOffset)>> 12; > ShortPtr = (PUSHORT)(RVA(Address, Offset)); > - > /* > * Don't relocate within the relocation section itself. > * GCC/LD generates sometimes relocation records for the relocation section. > @@ -398,16 +397,16 @@ > break; > > case IMAGE_REL_BASED_HIGH: > - *ShortPtr = HIWORD(MAKELONG(0, *ShortPtr) + (LONG)Delta); > + *ShortPtr = HIWORD(MAKELONG(0, *ShortPtr) + (Delta& 0xFFFFFFFF)); > break; > > case IMAGE_REL_BASED_LOW: > - *ShortPtr = SWAPW(*ShortPtr) + LOWORD(Delta); > + *ShortPtr = SWAPW(*ShortPtr) + LOWORD(Delta& 0xFFFF); > break; > > case IMAGE_REL_BASED_HIGHLOW: > LongPtr = (PULONG)RVA(Address, Offset); > - *LongPtr = SWAPD(*LongPtr) + (ULONG)Delta; > + *LongPtr = SWAPD(*LongPtr) + (Delta& 0xFFFFFFFF); > break; > > case IMAGE_REL_BASED_DIR64: > > >

3 4

Meeting with Stephen Gary Wozniak (Apple 'father')
by Александр 24 Nov '11

24 Nov '11

1 0

Announcement: New harddisk geometry next weekend
by Eric Kohl 23 Nov '11

23 Nov '11

Hi! I plan to change the standard harddisk geometry from the old 32 sectors and 64 heads geometry to the new 63 sectors and 255 heads geometry next weekend. The old disk geometry was used up to Windows NT4 and the new geometry is used since Windows 2000. So I guess it is time for ReactOS to make this change too. ;-) This should improve the compatiibility with other OSs because every modern OS uses the new disk geometry. Please note that you must delete and re-create all partitions on your virtual harddisk in order to get a clean partition table when the new disk geomerty is in use. Regards, Eric

7 11

Re: [ros-dev] [ros-diffs] [cgutman] 54418: [HALX86] - Do not allow software interrupts to preempt code running with interrupts disabled during KfLowerIrql
by Aleksey Bragin 21 Nov '11

21 Nov '11

I would like to ask our kernel gurus if this one is correct. WBR, Aleksey Bragin. On 18.11.2011 22:53, cgutman(a)svn.reactos.org wrote: > Author: cgutman > Date: Fri Nov 18 18:53:41 2011 > New Revision: 54418 > > URL: http://svn.reactos.org/svn/reactos?rev=54418&view=rev > Log: > [HALX86] > - Do not allow software interrupts to preempt code running with interrupts disabled during KfLowerIrql > > Modified: > trunk/reactos/hal/halx86/up/pic.c > > Modified: trunk/reactos/hal/halx86/up/pic.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/up/pic.c?rev=54… > ============================================================================== > --- trunk/reactos/hal/halx86/up/pic.c [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/up/pic.c [iso-8859-1] Fri Nov 18 18:53:41 2011 > @@ -665,26 +665,30 @@ > > /* Set old IRQL */ > Pcr->Irql = OldIrql; > - > - /* Check for pending software interrupts and compare with current IRQL */ > - PendingIrqlMask = Pcr->IRR& FindHigherIrqlMask[OldIrql]; > - if (PendingIrqlMask) > - { > - /* Check if pending IRQL affects hardware state */ > - BitScanReverse(&PendingIrql, PendingIrqlMask); > - if (PendingIrql> DISPATCH_LEVEL) > + > + /* Make sure interrupts were enabled */ > + if (EFlags& EFLAGS_INTERRUPT_MASK) > + { > + /* Check for pending software interrupts and compare with current IRQL */ > + PendingIrqlMask = Pcr->IRR& FindHigherIrqlMask[OldIrql]; > + if (PendingIrqlMask) > { > - /* Set new PIC mask */ > - Mask.Both = Pcr->IDR; > - __outbyte(PIC1_DATA_PORT, Mask.Master); > - __outbyte(PIC2_DATA_PORT, Mask.Slave); > - > - /* Clear IRR bit */ > - Pcr->IRR ^= (1<< PendingIrql); > + /* Check if pending IRQL affects hardware state */ > + BitScanReverse(&PendingIrql, PendingIrqlMask); > + if (PendingIrql> DISPATCH_LEVEL) > + { > + /* Set new PIC mask */ > + Mask.Both = Pcr->IDR; > + __outbyte(PIC1_DATA_PORT, Mask.Master); > + __outbyte(PIC2_DATA_PORT, Mask.Slave); > + > + /* Clear IRR bit */ > + Pcr->IRR ^= (1<< PendingIrql); > + } > + > + /* Now handle pending interrupt */ > + SWInterruptHandlerTable[PendingIrql](); > } > - > - /* Now handle pending interrupt */ > - SWInterruptHandlerTable[PendingIrql](); > } > > /* Restore interrupt state */ > >

3 3

Re: [ros-dev] [ros-diffs] [cgutman] 54415: [I8042PRT] - Implement support for hot plugging PS/2 mice if one was present at boot (same requirement as Windows) - Fixes bug 1395
by Johannnes Anderwald 21 Nov '11

21 Nov '11

Am 18.11.2011 00:41, schrieb cgutman(a)svn.reactos.org: > Author: cgutman > Date: Thu Nov 17 23:41:18 2011 > New Revision: 54415 > > URL: http://svn.reactos.org/svn/reactos?rev=54415&view=rev > Log: > [I8042PRT] > - Implement support for hot plugging PS/2 mice if one was present at boot (same requirement as Windows) > - Fixes bug 1395 > > Exellent! -- Johannes Anderwald

7 6

Looking for new maintainers
by Colin Finck 20 Nov '11

20 Nov '11

Hi all, As some of you know, I have started university about a month ago. Due to the amount of time I have to spend on university tasks these days, I can no longer fulfil all my project obligations. Therefore, I'm looking for new maintainers in the following areas: * RosBE-Unix * My Web tools (especially Testman and the rest of the regression testing system, but also GetBuilds/People Map/Subsystem integration) * Release Engineering (unless Ziliang can fully takeover my position) Provided that I find time, I'll introduce the new maintainers into these tasks as good as possible. I try to stay available for infrastructure and foundation tasks, but my time for these will definitely be limited as well. Best regards, Colin

3 3

Testing sound
by Igor Paliychuk 19 Nov '11

19 Nov '11

Debug log from testing cmake soundchip in KSStudio. http://www.reactos.org/paste/index.php/9568/ Btw i'm getting crash in cmuda.sys on two different PCs (though i didn't notiv=ce if chips are the same) To get your attention, Johannes ;)

1 1

Qemu Recoverable Assertion when Loading Gecko
by James Tabor 18 Nov '11

18 Nov '11

Head up on this one. It's recoverable by just typing "cont" and it goes on. (dll/ntdll/ldr/ldrutils.c:1177) Overlapping DLL: C:\ReactOS\system32\oleaut32.dll WARNING: MmFlushVirtualMemory at ntoskrnl/mm/ARM3/virtual.c:1044 is UNIMPLEMENTED! fixme:(dll/win32/wintrust/register.c:1161) stub (dll/ntdll/ldr/ldrutils.c:1138) LDR: LdrpMapDll Relocating Image Name C:\ReactOS\system32\mshtml.dll (76650000 -> 014C0000) (dll/ntdll/ldr/ldrutils.c:1177) Overlapping DLL: C:\ReactOS\System32\setupapi.dll (ntoskrnl/se/semgr.c:299) SidInToken Calls: 40000 Assertion 'RtlCheckBit(&MiUserPfnBitMap, (ULONG)Page)' failed at ntoskrnl/mm/freelist.c line 127 Entered debugger on embedded INT3 at 0x0008:0x80904efe. kdb:> bt Eip: <NTOSKRNL.EXE:104eff (lib/rtl/i386/debug_asm.S:35 (_DbgBreakPoint@0))> Frames: <NTOSKRNL.EXE:c283d (ntoskrnl/mm/freelist.c:127 (MmRemoveLRUUserPage@4))> <NTOSKRNL.EXE:c18de (ntoskrnl/mm/balance.c:134 (MmReleasePageMemoryConsumer@8))> <NTOSKRNL.EXE:cbf6a (ntoskrnl/mm/section.c:2365 (MmPageOutSectionView@16))> <NTOSKRNL.EXE:c822c (ntoskrnl/mm/rmap.c:143 (MmPageOutPhysicalAddress@4))> <NTOSKRNL.EXE:c17a9 (ntoskrnl/mm/balance.c:177 (MmTrimUserMemory))> <NTOSKRNL.EXE:c141c (ntoskrnl/mm/balance.c:366 (MiBalancerThread@4))> <NTOSKRNL.EXE:f2972 (ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8))> <NTOSKRNL.EXE:5a6a (ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0))> <NTOSKRNL.EXE:f290e (ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28))> <fcdebd80> <NTOSKRNL.EXE:152e5 (ntoskrnl/ke/wait.c:527 (KeWaitForSingleObject@20))> <NTOSKRNL.EXE:c524e (ntoskrnl/mm/mminit.c:292 (MmMpwThreadMain@4))> <NTOSKRNL.EXE:f2972 (ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8))> <NTOSKRNL.EXE:5a6a (ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0))> <NTOSKRNL.EXE:f290e (ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28))> <fce4fab0> <00000001> kdb:> cont Assertion 'RtlCheckBit(&MiUserPfnBitMap, (ULONG)Page)' failed at ntoskrnl/mm/freelist.c line 127 Entered debugger on embedded INT3 at 0x0008:0x80904efe. kdb:> cont (subsystems/win32/win32k/ntuser/keyboard.c:1066) err: No Window for Translate. (dll/ntdll/ldr/ldrutils.c:1138) LDR: LdrpMapDll Relocating Image Name xul.dll (10000000 -> 01DB0000) (dll/ntdll/ldr/ldrutils.c:1177) Overlapping DLL: C:\ReactOS\system32\ \1.0.0\wine_gecko\xpcom.dll

6 11

Re: [ros-dev] [ros-diffs] [tfaber] 54401: [ATL] - Fix buffer overflow in CComDynamicUnkArray::Add. Found by Coverity (CID 2474) [NDK] - Remove meaningless const attribute from pointer rvalues to make Coverity's life easier
by Timo Kreuzer 17 Nov '11

17 Nov '11

Am 16.11.2011 22:17, schrieb tfaber(a)svn.reactos.org: > Author: tfaber > Date: Wed Nov 16 21:17:38 2011 > New Revision: 54401 > > URL: http://svn.reactos.org/svn/reactos?rev=54401&view=rev > Log: > [ATL] - Fix buffer overflow in CComDynamicUnkArray::Add. Found by Coverity (CID 2474) > [NDK] - Remove meaningless const attribute from pointer rvalues to make Coverity's life easier > -#define SharedUserData ((KUSER_SHARED_DATA *CONST)USER_SHARED_DATA) > +#define SharedUserData ((KUSER_SHARED_DATA *)USER_SHARED_DATA) It is like this (with the const) in wdm.h #define SharedUserData ((KUSER_SHARED_DATA * const) KI_USER_SHARED_DATA) maybe its supposed to express that "SharedUserData" is a constant and not a variable... although that doesn't make much sense

3 2

SendMessageW doubt/bug with ANSI LPARAM.
by victor martinez 17 Nov '11

17 Nov '11

>The Total Commander comboboxes for the left and right drive list >are Unicode. However, Total Commander calls >SendMessage(handle,CB_ADDSTRING,0,(LPARAM)ansitext); >to add items as ANSI text. This seems to work, but it's adding some >extra text at the end. If I understand correctly, Total Commander is calling SendMessage, which in this case is translated to SendMessageW (as the comboboxes are Unicode). So TC is calling SendMessageW to append an ANSI string to a Combobox. Let's give a look to SendMessageW implementation thanks to Doxygen: http://doxygen.reactos.org/da/d64/winuser_8h_a18e5b961d742150a18d3039b5dd88… 02161 Result = NtUserMessageCall( Wnd, 02162 KMMsg.message, 02163 KMMsg.wParam, 02164 KMMsg.lParam, 02165 (ULONG_PTR)&Result, 02166 FNID_SENDMESSAGE, 02167 FALSE); Line 2167 FALSE is the BOOL ANSI param of NtUserMessageCall. But in this case the BOOL ANSI should be TRUE as the string is really ANSI. So since this moment we are treating TC call ( SendMessageW(handle,CB_ADDSTRING,0,(LPARAM)ansitext); ) in the same way as we would be treating SendMessageW(handle,CB_ADDSTRING,0,(LPARAM)unicodetext); This seems a bug for me. Feel free to correct me, but seems that SendMessageW is able to set both kind of strings ANSI and UNICODE in Windows, while we are forcing to our SendMessageW implementation to treat them as UNICODE always. Am I wrong? This could be a big potential issue as this could affect to all the SendmessageW calls. This is all just a guess, so please feed me with your knowledge. Thanks a lot!

4 5

1000 EUR for ReactOS - We have made it!
by Colin Finck 15 Nov '11

15 Nov '11

Hi all, Looking at https://verein.ing-diba.de/sonstiges/33378/reactos-deutschland-ev, we have scored the 810th place in the tough competition and just won 1000 EUR for the foundation! :-) Even if we lost our position in the top of the list, comparable German Open-Source foundations like KDE e.V. or Free Software Foundation Europe are both out of the game. I'd like to use this opportunity to thank every voter for the great support towards the project! Over 8000 votes in four weeks really shows that we still have a huge fan base. Best regards, Colin

9 9

Re: [ros-dev] [ion] 54323: [KERNEL32]: Move the "curdir.c" APIs into path.c as well, as they are Path APIs. No code changes (just formatting and moving to DPRINTs).
by Aleksey Bragin 15 Nov '11

15 Nov '11

I'm getting questions, if it's "just formatting and no code changes", why author names are removed for good and not readded in the new file? WBR, Aleksey Bragin. On 07.11.2011 3:01, ion(a)svn.reactos.org wrote: > Author: ion > Date: Sun Nov 6 23:01:04 2011 > New Revision: 54323 > > URL: http://svn.reactos.org/svn/reactos?rev=54323&view=rev > Log: > [KERNEL32]: Move the "curdir.c" APIs into path.c as well, as they are Path APIs. No code changes (just formatting and moving to DPRINTs). > Removed: trunk/reactos/dll/win32/kernel32/client/file/curdir.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/… > ============================================================================== > --- trunk/reactos/dll/win32/kernel32/client/file/curdir.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/kernel32/client/file/curdir.c (removed) > @@ -1,388 +1,0 @@ > -/* $Id$ > - * > - * COPYRIGHT: See COPYING in the top level directory > - * PROJECT: ReactOS system libraries > - * FILE: lib/kernel32/file/curdir.c > - * PURPOSE: Current directory functions > - * PROGRAMMER: Eric Kohl > - * Filip Navara > - * Steven Edwards > - * Thomas Weidenmueller > - * Gunnar Andre' Dalsnes > - * UPDATE HISTORY: > - * Created 30/09/98 > - */ >

2 2

Send Messages
by James Tabor 05 Nov '11

05 Nov '11

Hi! What I have run across in regards of ReactOS send message subsystem, ros is not packing before co_MsqSendMessage and unpacking after co_IntCallWindowProc! Instead packing before co_IntCallWindowProc with send message. Does that not raise any questions? co_IntSendMessageWithCallBack seems to do it almost right, but IntCallWndProc/Ret should be called when calling the client via co_IntCallWindowProc and should pack before the call to MsqWakeQueue and then unpack after the call to co_IntCallWindowProc. Confused? Basing this on IntCallLowLevelEvent and co_IntCallLowLevelHook when the lParam is used to save information that could get lost in a stack switch or release. Setting up the pattern; Pack before co_MsqSendMessage or related friends and Unpack after calling co_IntCallWindowProc to client. Have co_MsqDispatchOneSentMessage call something other than co_IntSendMessage so the Packed data can be handled correctly when calling to the client via co_IntCallWindowProc. I'm sure Michael Martin has brought this up to me on many occasions. Let's see where this goes! Thanks, James

2 2

Linux debug build slave relocated
by Pierre Schweitzer 02 Nov '11

02 Nov '11

Hi, the Linux build slave will be relocated (changing data center & country) starting tomorrow. It will, obviously, be offline during the meantime. So, you will not have any Linux builds nor KVM tests. We will do our best to get it back online as soon as possible. Regards, The ReactOS Sysadmins.

1 1

Minutes from 10.27.2011
by Claudiu Mihail 30 Oct '11

30 Oct '11

Hello all, Here are the minutes from the last ReactOS meeting on the 27th of October 2011: 20:20 Aleksey Bragin called the meeting to order - Aleksey Bragin shared a video interview about ReactOS at http://alenapopova.ru/egov/react-os-kraudsorsing-pri-sozdanii-operacionnoj-… - Aleksey Bragin stated the meeting agenda as being: 1. Website revamp status 2. CMake adoption 3. Release status 1. Website Revamp ----------------- - Amine Khaldi started on the Website revamp status and stated that unfortunately nothing has progressed since the last meeting because of aross, superdog and nisky being extremely busy. - He also stated that Aleksey has yet to commit the bridges needed and that the actual milestone is the theme (ie design/layout that matches the current website), after which devs will need to investigate phpbb issue. - Aleksey Bragin added that almost the only thing left is the theme and with it progress could be made fast to the website engine and have a test run with real data. - He also stated that all details could be provided to anyone motivated enough with HTML/CSS. - Matthias Kupfer said he could support HTML/CSS around Christmas, but not earlier. - Aleksey Bragin asked Maciej Bialas if he could assist in theming. - Maciej Bialas said he could, and added that he tried to create a simple theme first resembling the current one, and that aross said he could have done better by using some Drupal modules Maciej was not aware of. - Aleksey Bragin stated that a simple theme would suffice for now and a better one can always be done later. - Ziliang Guo asked about user and forum transfer status. - Aleksey Bragin replied that the forum is phpbb and therefore easily transferable - Ziliang Guo asked about the reason for sticking with phpbb. - Amine Khaldi and Aleksey Bragin stated that it was for the sake of easier migration (ie migrate one thing at a time not everything at once) - Maciej Bialas stated that one downside to this was tedious integration with phpbb. - Aleksey Bragin pointed out that playground.reactos.org (with its intact database) will be what the new main site looks like when the switch is made. - Ziliang Guo said he can start trying to add content the coming weekend. - Amine Khaldi asked Ziliang Guo to keep everything minimalistic. - Aleksey Bragin moved the meeting on to the CMake adoption topic on the agenda. 2. CMake adoption -------------------- - Aleksey Bragin took this chance to welcome Alex Ionescu back to the ReactOS project. - Amine Khaldi stated that Alex Ionescu stumbled upon a way to separate debug info from binaries, in a pdb similar way, using objcopy. He also mentioned that Alex helped by fixing two bugs in windmc and windres. - He went on to say that Alex suggested that we go back to using dwarf-2, only this time with pdb style debug, and with an improved, out of the kernel, symbols handling. He mentioned that Thomas Faber was kind enough to sketch a batch script that takes a debug log and translates the addresses inside it. - Amine Khaldi further stated that with the script + the CMake changes to take account of windres and objcopy, we'll be able to reduce the iso size, reduce the memory footprint, reduce the disk space needed to compile, use windres alone and get rid of handling symbols in the kernel (something "no other OS does" as Alex describes it). - He then explained that, on the RosBE level, this will only require updating binutils (gcc will stay at 4.4.3) with the patched windres and windmc, and it will also require the translating script to be part of RosBE. A discussion ensued about testing the new RosBE and the following conclusions where reached: - Have a new Build Environment Release Candidate (2.0) which is an update to binutils (ld, windres, windmc, addr2line... etc) until the next meeting. - Keep the 4.4.3 version of gcc until the next meeting. - Alex Ionescu suggested having the new RosBE ready by the time of the next release. He also noted that this does not mean the new BE will be released along with the next version of ReactOS, but that it must be ready by then. - Cameron Gutman then brought up the issue of switching to gcc 4.6, but it was decided to keep gcc 4.4.3 until after the next release. - Thomas Faber then suggested an outlined step by step plan: 1) Update BE 2) Release new version of ReactOS (0.3.14) 3) Get rid of wrc 4) Get rid of rbuild 5) Switch to dwarf 6) Adopt new compiler (gcc 4.6) After some deliberating it was agreed upon that Thomas Faber's proposed course of action is the best way to go, and his proposal was accepted. - Amine Khaldi then moved the meeting to the next topic 3. Release status -------------------- - Cameron Gutman inquired about the progress on the heap regression issue. - Thomas Faber stated that although he himself hasn't made much progress because he is very busy during the week, Jerome has been tracking it down pretty well and that it is apparently caused by resource loading. - Amine Khaldi took this chance too thank everyone for the awesome bugfixing phase, and stated that a lot of bugs has been fixed and a lot of regression has been addressed. He also went on to thank testers, and outlined the importance they have, and stated that he hopes this will be the mentality of the ReactOS project team, as thanks to it ReactOS is improving a lot. - He went on to say that as far as the remaining blockers are concerned, more team work on fixing them is needed, as this has proved very effective in the past. He also added that Jim Tabor did a good one man job on the jre issue, but that the other issues could use some teaming up. - Aleksey Bragin further added to this that ReactOS is on the way to possibly one of the best releases, and that after years have passed everyone is working towards the same goal, which, he added, is fantastic. - Cameron Gutman agreed that ReactOS is indeed very stable now, especially in kernel mode. - Olaf Siejka went on to sum up that entering the release stage would require at the very least fixing mshtml bug and fixing ldr regressions. - Aleksey Bragin agreed with Olaf Siejka on that point. - Kamil Hornicek inquired about the official stance about hackfixing certain bugs. - Aleksey Bragin and Amine Khaldi both explained that while hackfixing should be avoided, there are some bugs which cannot be resolved in a timely fashion. But hackfixing these should clearly be reflected in the commit message and comments in the code. - Amine Khaldi went on to ask for a more visible teaming up, for example on IRC and through bug reports, and to also request marking bugs as assigned when devs take them. He mentioned that since the release blockers remained unassigned for a while, it was difficult at times to keep track of who is working on what. - Cameron Gutman inquired if anybody objects to modifying the default color depth from 16-bit to 32-bit. - Olaf Siejka raised some concerns about this as it will affect QEMU since it does not support 32bpp. - Cameron Cutman further inquired about the possibility of falling back more gracefully as far as color depth is concerned when a video card does not support a certain resolution (right now it falls back directly to 8bpp). He went further to ask Timo Kreuzer if this is standard windows behavior. - Timo Kreuzer said he would need to investigate this issue. - Aleksey Bragin formally ended the meeting, thanking everyone for their time and information. Minutes by Claudiu Mihail.

2 1

Monthly status meeting
by Aleksey Bragin 28 Oct '11

28 Oct '11

Hello, Let me invite you to the monthly status meeting taking place last thursday of this month (hint: today), 27th of October, 19:00 UTC. The meeting will be atirc://fezile.reactos.org (Port 6667, no SSL) in the channel #meeting. Note that the IRC service will only be started shortly before the meeting. Everyone is invited to listen, and active community members have their passwords so that they can participate in the discussion. If someone still is not getting passwords sent before a meeting - please email Colin or Pierre before the meeting started to get one. Proposed agenda for the meeting: 1. Release status 2. CMake adoption status 3. Website revamp status More suggestions are welcome. With the best regards, Aleksey Bragin.

5 5

Regressions / release status
by Aleksey Bragin 27 Oct '11

27 Oct '11

Hello! Time flies fast, and soon we are going to face the deadline (next status meeting) by which we decided to create a RC of the upcoming release. And, there are some problems. I will start from good stuff. Since the last meeting took place, quite a few regressions were fixed, and interesting bugs have also been closed. This is very good and I appreciate your efforts. However some problems remains, and here is where your help is urgently needed! For the current milestone (0.3.14), there are 3 blocker regressions and 2 big buckets of issues - ldr rewrite regressions and shell32 rewrite regressions. From blocker stuff, the most important is the heap-related one. Mephisto provided a good explanation here (http://www.reactos.org/bugzilla/show_bug.cgi?id=5857), and we need someone with a fresh eye to look into this problem. N.B. Please don't go into "let's fix some unrelated stuff in the heap code just to make it better". Look strictly into the specified bug and try to spot the place where the heap lists are getting corrupted. Anyone volunteers to have a look? LDR regressions: there are relatively many of them, but all are more-or-less nicely fixable because of the new, good LDR code. Alex - maybe you could please devote a bit of your time to check the code and see if that fixes some of the regressions? shell32 regressions: I already see some improvements being committed, please continue this way. We can make a good 0.3.14 release only if we act as a team now. It's not someone, it's YOUR help which matters. Testers are already doing as much as they can, retesting issues, providing newer debug logs, and other other things. Now it's time to act and fix regressions before moving further. It's just stupid to move further, if a rewrite introduces new bugs instead of fixing existing. I know how hard it is, but let's finish smaller steps and hence move forward. There is no way forward at all if old bugs are stacked and new regressions are introduced all the time. We can't bring in new good changes (wine syncs, 3rd party code syncs, arwinss, whatever else) until 0.3.14 is ready, and 0.3.14 is not ready until blocking regressions are fixed. As simple as it is. Thanks for reading and I hope you understand. With the best regards, Aleksey Bragin.

4 3

Two petitions
by caemyr＠myopera.com 23 Oct '11

23 Oct '11

Hiya Its still at least two weeks until next meeting, hence i suppose ros-dev could be used in decision making even before that. I have two things i would like to push, things that i discussed a bit with varioius team memebers on IRC and got positive feedback. I would like you guys to comment on those and if you feel that one of both of them are wrong/unnecessary/not needed, please voice it out here. If there is no opposition for them, i`ll consider those two accepted and push for them to be finialised. Here we go: 1. Adding a default theme to ReactOS. We need at least one to test Themes service in trunk ootb and avoid copying it to ros install each time, which is really important in regression testing. Also, a theme is a must for our upcoming release. Since its not a big file usually, it should be present in trunk, not only in release ISO. 2. Moving Starfield screensaver from rosapps to trunk. Rosapps, no matter how much cheered, is a wasteland, a museum, a forgotten place. It will not be even buildable when we move away from rbuild. Old and unneeded code should land there, but not a new creation Carlo has been working on. Apart from that, Starfield is using OpenGL, which is also a handy ootb test tool for 3d acceleration, also important in regression testing. If you think that two screensavers are the top amount you can accept, then lets replace one of the trunk screensavers with Starfield. -- With best regards Caemyr

10 17

Would you donate just 3 minutes to the project?
by The ReactOS Team 21 Oct '11

21 Oct '11

Dear ReactOS Community Member, We contact you today, because you have signed up for a myReactOS account some time ago. And we need your help! A German bank is currently running a sponsoring campaign for all kinds of foundations. The 1000 foundations with the most votes receive 1000 EUR each by the 15th November. You can easily increase our chances by voting on the following website: https://verein.ing-diba.de/sonstiges/33378/reactos-deutschland-ev Here is the complete voting procedure: * Open the link above * Click on the orange button "Stimme abgeben" (= Vote) * Enter your E-Mail address and solve the captcha, then hit the button "Absenden" (= Send) * You will receive a confirmation E-Mail where you have to click the first link. Finally click on "Stimme abgeben" again and you're done. Note that you can vote UP TO 3 TIMES with a single E-Mail address, and you can even cast all votes to the same foundation. You may also share this, so that we can get as many people as possible to vote for us. Let's get ReactOS among the top 1000! Cheers and thanks for your support, Aleksey Bragin and Colin Finck in the name of the ReactOS Team and ReactOS Deutschland e.V.

7 10

Livecd video regression
by Timo Kreuzer 19 Oct '11

19 Oct '11

Hi, Since one of my recent video driver loading changes, livecd video is vga mode. The reson is: When installing bootcd, there will be only 1 video driver installed: based on 1st stage selection, either vbe or vga will be installed the other one is deactivated (start mode = manual). When installing a 3rd party driver, that one used to be installed and loaded prior to VBE and thus became Device/Video0, which win32k happily used as primary adapter. This behaviour changed with ACPI hal and VBE is loaded first, resulting is non functional VBox driver. I fixed this, by having win32k decide which driver to use, by looking if its a vga compatible driver and use that one only as fallback, if no other is present. additionally the VBE was marked as VgaCompatible. Now livecd behaves differently and simply installs both VGA and VBE. and since both are now marked as VgaCompatible, win32k doesn't know which one to use and currently uses VGA. Now how does this work in Windows? Windows has only one Adapter installed for VGA and VBE (vga.sys + vga.dll/vga256.dll/vga64k.dll/framebuf.dll) This service is always loaded and marked as "VgaCompatible". It is also used when a 3rd party driver is installed, when you switch to fullscreen console mode. This adapter is only replaced by a 3rd party adapter if that one is also vga compatible. This way its easy for win32k to decide which one to use: based on whether /BASEVIDEO is passed, either the vga compatible one or the other one can be selected. Possible solutions: 1) Add another workaround to win32k, checking if 2 VGA adapters are installed and then using the first one, instead of the second one as currently (because 1st is VGA, simply the second is used), but thats not a real solution. 2) Fix whatever is neccessary to have VBE be replaced by a 3rd party driver that is installed. (Cameron said it was related to VBE not being PNP ready.) This way we can stop marking it as VgaCompatible. 3) Combine VGA and VBE miniport into one vga compatible driver, like it's in windows. Alex mentioned that eVb has more or less finished that. Question is: whats missing to have the code comitted? Comments and feedback appreciated, Timo

3 5

Re: [ros-dev] [ros-diffs] [jgardou] 54179: [WinMM] - avoid buffer overrun. - do not try to unload uninitialized driver. See issue #6343 for more details.
by Timo Kreuzer 17 Oct '11

17 Oct '11

I think that will not unload the last driver. Looking at MMDRV_Install, MMDrvsHi is the index of the first free array field and its incremented each time MMDRV_Install is called. The assert in line 465 is wrong. It should be "<". The for () loop in line 432 is also wrong Your change starts with MMDrvsHi - 1, the last used index, then decrements i by one before doing anything else. Am 17.10.2011 18:35, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Mon Oct 17 16:35:10 2011 > New Revision: 54179 > > URL: http://svn.reactos.org/svn/reactos?rev=54179&view=rev > Log: > [WinMM] > - avoid buffer overrun. > - do not try to unload uninitialized driver. > See issue #6343 for more details. > > Modified: > trunk/reactos/dll/win32/winmm/lolvldrv.c > > Modified: trunk/reactos/dll/win32/winmm/lolvldrv.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/winmm/lolvldrv.c… > ============================================================================== > --- trunk/reactos/dll/win32/winmm/lolvldrv.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/winmm/lolvldrv.c [iso-8859-1] Mon Oct 17 16:35:10 2011 > @@ -634,7 +634,7 @@ > } > > /* unload driver, in reverse order of loading */ > - i = sizeof(MMDrvs) / sizeof(MMDrvs[0]); > + i = MMDrvsHi - 1; > while (i--> 0) > { > MMDRV_ExitPerType(&MMDrvs[i], MMDRV_AUX); > > >

1 0

CMake migration of Trunk_x86_GCCLin Debug Buildslave
by Colin Finck 16 Oct '11

16 Oct '11

Hello all, The "Trunk_x86_GCCLin Debug" Buildslave has been migrated to RosBE-Unix 2.0-RC1. All builds starting with r53983 are now created using a CMake environment. Unfortunately, the CMake builds don't boot under KVM on the same machine, but apparently for everybody else. To give you an idea what I mean by "don't boot": http://img830.imageshack.us/img830/5145/image1iz.png If nobody has an idea how to debug or fix this, I'm afraid I have to revert everything back to the rbuild scripts until a proper solution is found. - Colin

6 19

Problems linking msxml3.dll
by Alex Ionescu 16 Oct '11

16 Oct '11

This is the original command-line: mingw32-ld --entry=_DllMain@12 --image-base=0x74ae0000 @obj-i386/dll/win32/msxml3/msxml3_objs.rsp --start-group "/usr/local/new/RosBE/i386/lib/gcc/mingw32/4.4.3/libgcc.a" obj-i386/lib/3rdparty/libxml2/libxml2.a output-i386/dll/3rdparty/libxslt/libxslt.dll obj-i386/lib/3rdparty/libwine/wine.a obj-i386/lib/3rdparty/libwine/wineldr.a obj-i386/dll/win32/urlmon/liburlmon.a obj-i386/dll/win32/wininet/libwininet.a obj-i386/dll/win32/ws2_32/libws2_32.a obj-i386/dll/win32/comctl32/libcomctl32.a obj-i386/dll/win32/shell32/libshell32.a obj-i386/dll/win32/shlwapi/libshlwapi.a obj-i386/dll/win32/cabinet/libcabinet.a obj-i386/dll/win32/oleaut32/liboleaut32.a obj-i386/dll/win32/ole32/libole32.a obj-i386/dll/win32/version/libversion.a obj-i386/dll/win32/user32/libuser32.a obj-i386/dll/win32/gdi32/libgdi32.a obj-i386/dll/win32/advapi32/libadvapi32.a obj-i386/lib/sdk/uuid/uuid.a obj-i386/dll/ntdll/libntdll.a obj-i386/lib/3rdparty/mingw/mingw_common.a obj-i386/lib/3rdparty/mingw/oldnames.a obj-i386/dll/ntdll/libntdll.a obj-i386/dll/win32/kernel32/libkernel32.a obj-i386/dll/win32/msvcrt/libmsvcrt.a obj-i386/lib/debugsup/debugsup_ntdll.a --end-group -disable-stdcall-fixup -file-alignment=0x1000 -section-alignment=0x1000 --shared --exclude-all-symbols -o output-i386/dll/win32/msxml3/msxml3.dll This is on RosBE 2.0 with RBUILD. Note that it's trying to link with libxslt.dll, which obviously won-t work on a non-Windows host. Removing that broken linkage makes the link work fine if I do it by hand. Can anyone fix? -- Best regards, Alex Ionescu

1 0

Re: [ros-dev] [ros-diffs] [akhaldi] 54136: [CMD] * Reduce the scope of some variables.
by Alex Ionescu 14 Oct '11

14 Oct '11

Why? It doesn't change anything...and... This is not our coding standard. Best regards, Alex Ionescu On Fri, Oct 14, 2011 at 1:50 PM, <akhaldi(a)svn.reactos.org> wrote: > Author: akhaldi > Date: Fri Oct 14 17:50:16 2011 > New Revision: 54136 > > URL: http://svn.reactos.org/svn/reactos?rev=54136&view=rev > Log: > [CMD] > * Reduce the scope of some variables. > > Modified: > trunk/reactos/base/shell/cmd/assoc.c > trunk/reactos/base/shell/cmd/dir.c > trunk/reactos/base/shell/cmd/filecomp.c > trunk/reactos/base/shell/cmd/start.c > trunk/reactos/base/shell/cmd/ver.c > > Modified: trunk/reactos/base/shell/cmd/assoc.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/base/shell/cmd/assoc.c?rev… > > ============================================================================== > --- trunk/reactos/base/shell/cmd/assoc.c [iso-8859-1] (original) > +++ trunk/reactos/base/shell/cmd/assoc.c [iso-8859-1] Fri Oct 14 17:50:16 > 2011 > @@ -206,8 +206,6 @@ > INT CommandAssoc (LPTSTR param) > { > > - LPTSTR lpEqualSign = NULL; > - > /* print help */ > if (!_tcsncmp (param, _T("/?"), 2)) > { > @@ -221,7 +219,7 @@ > PrintAllAssociations(); > else > { > - lpEqualSign = _tcschr(param, _T('=')); > + LPTSTR lpEqualSign = _tcschr(param, _T('=')); > if(lpEqualSign != NULL) > { > LPTSTR fileType = lpEqualSign + 1; > > Modified: trunk/reactos/base/shell/cmd/dir.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/base/shell/cmd/dir.c?rev=5… > > ============================================================================== > --- trunk/reactos/base/shell/cmd/dir.c [iso-8859-1] (original) > +++ trunk/reactos/base/shell/cmd/dir.c [iso-8859-1] Fri Oct 14 17:50:16 > 2011 > @@ -1260,13 +1260,11 @@ > LPDIRSWITCHFLAGS lpFlags) /* [IN] The flags that > we will use to sort */ > { > LPWIN32_FIND_DATA lpTemp; /* A temporary pointer */ > - int First, Last, Temp; > BOOL Way; > > if (i < j) > { > - First = i; > - Last = j; > + int First = i, Last = j, Temp; > Way = TRUE; > while (i != j) > { > > Modified: trunk/reactos/base/shell/cmd/filecomp.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/base/shell/cmd/filecomp.c?… > > ============================================================================== > --- trunk/reactos/base/shell/cmd/filecomp.c [iso-8859-1] (original) > +++ trunk/reactos/base/shell/cmd/filecomp.c [iso-8859-1] Fri Oct 14 > 17:50:16 2011 > @@ -209,7 +209,6 @@ > TCHAR path[MAX_PATH]; > TCHAR fname[MAX_PATH]; > TCHAR directory[MAX_PATH]; > - UINT longestfname = 0; > SHORT screenwidth; > > /* expand current file name */ > @@ -277,6 +276,7 @@ > hFile = FindFirstFile (path, &file); > if (hFile != INVALID_HANDLE_VALUE) > { > + UINT longestfname = 0; > /* Get the size of longest filename first. */ > do > { > > Modified: trunk/reactos/base/shell/cmd/start.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/base/shell/cmd/start.c?rev… > > ============================================================================== > --- trunk/reactos/base/shell/cmd/start.c [iso-8859-1] (original) > +++ trunk/reactos/base/shell/cmd/start.c [iso-8859-1] Fri Oct 14 17:50:16 > 2011 > @@ -48,7 +48,6 @@ > TCHAR szFullCmdLine [CMDLINE_LENGTH]; > PROCESS_INFORMATION prci; > STARTUPINFO stui; > - INT i = 0; > #ifdef UNICODE > DWORD dwCreationFlags = CREATE_NEW_CONSOLE | > CREATE_UNICODE_ENVIRONMENT; > #else > @@ -213,7 +212,7 @@ > /* Parsing the command that gets called by start, and it's > parameters */ > { > BOOL bInside = FALSE; > - > + INT i; > /* find the end of the command and put the arguments in > param */ > for (i = 0; Rest[i]; i++) > { > > Modified: trunk/reactos/base/shell/cmd/ver.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/base/shell/cmd/ver.c?rev=5… > > ============================================================================== > --- trunk/reactos/base/shell/cmd/ver.c [iso-8859-1] (original) > +++ trunk/reactos/base/shell/cmd/ver.c [iso-8859-1] Fri Oct 14 17:50:16 > 2011 > @@ -28,8 +28,6 @@ > VOID ShortVersion (VOID) > { > OSVERSIONINFO VersionInfo; > - unsigned RosVersionLen; > - LPTSTR RosVersion; > > ConOutResPrintf(STRING_CMD_SHELLINFO, _T(KERNEL_RELEASE_STR), > _T(KERNEL_VERSION_BUILD_STR)); > VersionInfo.dwOSVersionInfoSize = sizeof(OSVERSIONINFO); > @@ -37,6 +35,9 @@ > memset(VersionInfo.szCSDVersion, 0, > sizeof(VersionInfo.szCSDVersion)); > if (GetVersionEx(&VersionInfo)) > { > + LPTSTR RosVersion; > + unsigned RosVersionLen; > + > RosVersion = VersionInfo.szCSDVersion + > _tcslen(VersionInfo.szCSDVersion) + 1; > RosVersionLen = sizeof(VersionInfo.szCSDVersion) / > sizeof(VersionInfo.szCSDVersion[0]) - > (RosVersion - VersionInfo.szCSDVersion); > > >

2 1

RosBE-Unix 2.0-RC1
by Colin Finck 13 Oct '11

13 Oct '11

Hi all, A first release candidate of RosBE-Unix 2.0 is now available on http://svn.reactos.org/RosBE-Temp/. Compared to 1.5, it finally includes CMake 2.8.5 (with Jerome's patches), an updated GNU Make and new GMP and MPFR libraries. For the latter ones, I've added a patch to fix building under Mac OS X 10.7. Please try it out and tell me about your results. If there's anything that needs to be fixed before the release, please tell me in a reply to this mail. For the reference, the current CMake building commands in a ReactOS checkout are as follows: - ./configure.sh - cd output-i386-MinGW/host-tools - makex - cd ../reactos - makex bootcd I'll also set up this Build Environment on the Debug Buildslave as soon as possible. Happy building, Colin

5 6

Bugfixing mode
by Aleksey Bragin 11 Oct '11

11 Oct '11

Hello! As per discussion during the last status meeting, I proposed to set up a deadline for having a 0.3.14 Release Candidate available by the time of the next meeting. Olaf, Amine and others were kind enough to make an up-to-date list of critical bugs and regressions to be fixed. It's available here: http://www.reactos.org/wiki/Buglist (indeed this page should be in your web browser's Favorites!) . I want to ask all of you to concentrate on fixing regressions and critical/blocker bugs first, before going into fancy features or implementing something else. It's really important, we need to make 0.3.14 as the last release before switching to 0.4. We have all necessary prerequisites, and just need to sit down and fix regressions. I personally put off all of my ReactOS-related "fancy" projects because I want a solid trunk first, and I am working only on stuff which is urgently needed - fixing remaining LDR rewrite regressions, special pool to catch pool corruptions, etc. It's meaningless to work on something else now if regressions aren't fixed. Hopefully you will follow my advice and we will have a wonderful bugfixing week(s)! Thank you! WBR, Aleksey Bragin.

3 4

freeldr.ini now is overwritten by newly generated (livecd)
by Minas Abrahamyan 11 Oct '11

11 Oct '11

Hi all, Previously I used edited version of freeldr.ini to build livecd ISOs, it is in \output-i386\livecd\ Now freeldr.ini is becoming overwritten in make process by newly generated "standard" one, and it is overwriting my manually edited version. So 1) what is now the correct way is to have custom freeldr.ini in iso image? 2) For what are these new automagical erase-and-newly-generate scripts? Although I can now manually edit (in iso image) what has been done earlier automatically, replace the file, but, at my PoV something goes wrong. -- Best Regards, M.A.

1 1

[ros-diffs] [rharabien] 54006: [WIN32K] - Rewrite keyboard input processing to match windows behavior -
by James Tabor 11 Oct '11

11 Oct '11

Hi! Well if anyone cares! This commit message is a lie! In IntKeyboardInput I added support for KF_DLGMODE and KF_MENUMODE ! BTW is used! In Dialog.c DF_DIALOGACTIVE! So someone will fix it right? Okay, James

1 0

CMake adoption
by caemyr＠myopera.com 09 Oct '11

09 Oct '11

You might know me as a stout supporter of CMake transition, but a single experience shattered my certainity. Today i tried to resolve a backtrace for a bug report, done with a cmake iso. The results were horrendous. The backtrace was lenghty, but on rbuild such task would take around 15 mintues for me, having all files extracted and prepped log.. At the present moment, cmake bt resolving is a total mess and practically prevents anyone doing such log. I might not be a programmer, but was somewhat skilled in my testers duties, also as some recall, i loved doing manual traces by raddr2line. With cmake - i hate it: 1. the whole process takes minutes more per frame: you need the base address, add the offset and type in the addr2line command 2. base address from kdbg: mod is not reliable, as modules might be relocated. addr2line doesn't know about that... 3. C++ function names are not demangled. For those modules that are written in c++ you will only get source lines, unless you check them up manually. 4. Being somewhat experienced, i see no way how i`m to explain newcomer how to do a backtrace... on the other hand, do you expect anyone to waste half an hour doing so? This HAS to be resolved before rbuild is put to retirement. Amine was talking about getting back to rsym - sure, why not? Anything that works will be better than current situation. -- With best regards Caemyr

5 6

Re: [ros-dev] [ros-diffs] [jimtabor] 54044: [Win32k] - Implement get atom name for user32.
by Timo Kreuzer 07 Oct '11

07 Oct '11

Am 07.10.2011 15:56, schrieb jimtabor(a)svn.reactos.org: > > +DWORD > +APIENTRY > +NtUserGetAtomName( > + ATOM nAtom, > + PUNICODE_STRING pBuffer) > +{ > + DWORD Ret; > + UNICODE_STRING CapturedName = {0}; > + UserEnterShared(); > + _SEH2_TRY > + { > + CapturedName = ProbeForReadUnicodeString(pBuffer); > + Ret = IntGetAtomName((RTL_ATOM)nAtom, CapturedName.Buffer, (ULONG)CapturedName.Length); > + } > + _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > + { > + Ret = 0; > + } > + _SEH2_END > + UserLeave(); > + return Ret; > +} IntGetAtomName must not be called from inside SEH, if it throws you'll be left with a locked atom table. Timo

1 0

Re: [ros-dev] [ros-diffs] [cgutman] 54016: [HAL] - Implement support for scatter/gather DMA - Tested with Intel's NDIS 5.1 PRO/1000 driver (but more testing would be helpful to weed out bugs) [NDIS] - Report NDIS 5.1 now si...
by Colin Finck 06 Oct '11

06 Oct '11

cgutman(a)svn.reactos.org wrote: > - Implement support for scatter/gather DMA This commit deserves a huge LIKE button, thanks! Will try it out as soon as I have access to my ReactOS laptop again. Finally a chance for getting its Ethernet port to work :-) - Colin

5 4

[ros-diffs] [gadamopoulos] 53751: [comctl32]
by James Tabor 06 Oct '11

06 Oct '11

Hi!! This is wrong, 8^( + class.style |= CS_GLOBALCLASS; + class.hInstance = COMCTL32_hModule; The point in THEMING_Initialize was to get the current global classes and make locals for each process. So that process could have it. Not the whole system! Note from a msdn blog, "If you pass the CS_GLOBALCLASS flag when registering the class, then the window manager will ignore the instance handle when looking for your class. All of the USER32 classes are registered as global." I spent a week now looking through it all, ReactOS is handling the class registration correctly. My best guess, if themes is active do as the original code had it before and use IsThemeActive like it is setup. Keep class.hInstance = COMCTL32_hModule; and don't use CS_GLOBALCLAS so you can find it again. Thanks, James

2 2

Proposal for deletion
by Pierre Schweitzer 05 Oct '11

05 Oct '11

Hi, today, after looking at the daily source analysis we have, I found out that all that stuff could be improved by lightening trunk. We have huge amount of unused code (even not linked in CMake) rotting in trunk. I'm mainly talking about icu4ros. AFAIK it was an attempt from KJK for I even don't recall what. Here is my proposal: we do a branch for this. And then, we remove it from trunk. This will make things lighter, without loosing code. Any objections/comments? Regards, Pierre

3 3

Re: [ros-dev] [ros-bugs] [Bug 6535] Sync gdi32+kernel32 winetests to git head
by caemyr＠myopera.com 05 Oct '11

05 Oct '11

With this attempt Thomas proved that it is possible to use patchbot for both trunk and rostests patching. Ask him how he did it:> On Wednesday, October 05, 2011 9:05 AM, ReactOS.Bugzilla(a)reactos.org wrote: > --- Comment #1 from ThFabba <thfabba(a)gmx.de> 2011-10-05 09:05:44 CET --- > Created an attachment (id=6782) > --> (http://www.reactos.org/bugzilla/attachment.cgi?id=6782) > patch 2 > > Maybe this works :p > -- With best regards Caemyr

1 0

Setupapi & VBox additions
by Thomas Faber 04 Oct '11

04 Oct '11

Hi, I've been looking at VirtualBox 4.1.x guest additions, which don't install in ROS [1] and came up with a patch [2] that seems to fix them. While patchbot says this is okay [3] (and the last hunk even fixes a few setupapi tests), I am very unsure about the SP_COPY_NOOVERWRITE part. The correct solution might instead be to handle SetupCopyOEMInf returning ERROR_FILE_EXISTS or I might be "fixing" something in the completely wrong place. It would be great if someone with some insight into setupapi (Eric? Hervé? ;]) could review this and give some pointers. Thanks! -Thomas [1] http://www.reactos.org/bugzilla/show_bug.cgi?id=6522 [2] http://www.reactos.org/bugzilla/attachment.cgi?id=6753 [3] http://www.reactos.org/testman/compare.php?ids=8272,8294,8303,8305 Patch explanation: - The first hunk isn't really required, but I guess it shouldn't break anything, and seems to find what it's looking for this way. - The second hunk is in the code path used by VBox guest additions setup. It is apparently called with an already-existing inf file, but I have no idea why. :| - The third hunk is a trivial bug that our CreateService just didn't complain about before r53872/r53886

2 1

ReactOS August and September Meeting Minutes
by Zachary Gorden 04 Oct '11

04 Oct '11

Though the August minutes were already posted on the forum, they are being resent here for people who may have missed them. August Summary A proposal was made to do winesyncs before a release to force the project to do a better job keeping things in sync and perhaps do a better job making syncs feasible/less time consuming. Rejected by plurality of votes. Questions about how/whether to continue the driver signing program was raised. An advisory vote was held and the majority wished to continue it in one form or another. Feedback based on the advisory vote was incorporated into revised guidelines posted on the Driver Signing wiki page. New projects are now required to find a sponsor ReactOS "core developer" willing to audit their code if they wish to get their driver signed. Decision to integrate arwinss into trunk under a separate directory structure and make it a compile-time option. Passed by majority vote. Decision to switch main Linux build server to use cmake. Passed by majority vote. September Summary Agenda 1. CMake Adoption Status 2. Release Preparation, Determination of Release Date 3. Webportal Upgrade Status 4. ReactOS Target Version Report 1. The build environments for both Windows and Unix have gone through several release candidates and are effectively finalized. For the Windows BE an installer release client using MSI instead of NSIS also needs to be prepared. Minor problems still seem to exist on Mac OS X when using a combination of GCC and LLVM, but these were deemed non-blockers. Building ReactOS using CMake has been reported to take more time than using rbuild, though developers are still working to verify and determine the cause. Current theory is related to changed debug format and more thorough dependency checking by CMake. At present the plan is to put the build environment release candidates on the Linux build servers and determine if there are any problems. The Windows build servers have already been running the new build environments for testing purposes. 2. Due to the significant number of regressions and overall bugginess of ReactOS' current state, release scheduling has been deferred until the next meeting. A list of regressions and bugs has already been compiled and the team intends to work its way through the reported issues in the meantime. At the next meeting, the OS' state will be re-assessed to see whether a release is viable or not. 3. Most of the modules needed to bridge Drupal with things like Bugzilla have already been completed. To speed the transition, a decision was made to retain the current website design. Once the transition is complete, the web team can go back to updating the site's theme. Desired content changes will also not block transition to the new backend. No timetable was given for when the transition would happen. 4. For a while the project adopted the goal of targeting the Windows 2003 kernel and the latest version of Windows for user mode components. Several developers however raised objections to this and presented examples where this methodology does not work. A specific example involved symbolic link support, which required Microsoft rearchitecture not only NTFS but also the kernel's security systems. Its addition in ReactOS, assuming it is done correctly, would require changes to the kernel to adopt features from the Vista kernel, thus violating the kernel target. With these considerations, the project has decided to set both the user and kernel targets to Windows 2003. Dependency on Wine for many user mode libraries actually complicates this, as Wine has been adding Vista and later APIs without proper segregation and the developers will need to figure out how to deal with this in the long run.

5 7

Re: [ros-dev] [ros-diffs] [akhaldi] 53941: [RBUILD] * Plug a leak.
by Timo Kreuzer 02 Oct '11

02 Oct '11

Am 02.10.2011 22:59, schrieb akhaldi(a)svn.reactos.org: > Author: akhaldi > Date: Sun Oct 2 20:59:15 2011 > New Revision: 53941 > > URL: http://svn.reactos.org/svn/reactos?rev=53941&view=rev > Log: > [RBUILD] > * Plug a leak. Bugfix of the month! ;-)

1 0

Tools and ways for our development
by Matthias Kupfer 02 Oct '11

02 Oct '11

Hi, at present I work for mid-sized company for ticketing, parking and mobile solutions in Germany (and Great Britain). I personally work in a project for railway services (using gsm-r network). To understand the tools given below I want to figure out our target and environment in short. We develop for embedded Linux systems with ARM-CPU and Qt-Framework. Therefore C++ was and is used as programming language. Apart from he usual tools like - make-alike build tools (written in perl - a project specific one) - regular make files for some special targets - SVN for source code management we use some interesting tools to keep the source readable and to preserve a minimum of source quality automatically (bear in mind we use C++ instead of C, for our purpose we need to alter some tools for our needs): - Hudson for automatic build and checking the source (see below) - cpplint.py (by Google) for some checking the source - cppcheck for another check of the source - doxygen for checking the missing documentation (in that special case check only by tricky configuration instead of costly generating all documentation files) - format the source code (after agreement of all devs) in a uniform style with astyle before commit (for ReactOS better as commit hook) - finally we gather all check results in one table and mark the results for hudson as stable (if no errors), failed (in case of any errors), unstable (in case of some low-prio warnings) Maybe we can think about some of them, because even if some problems of development remains, it might give us some edge and may also attract some devs. I don't make any suggestions, but I want to tell you how others work. Matthias PS: We are the first project in the company going that way and other project groups would like to adapt the way, because they see the benefit for their/other/future projects. -- Matthias Kupfer phone +49 371 236 46 52 Wilhelm-Firl-Straße 21 mobile +49 160 859 43 54 09122 Chemnitz, Germany

2 1

Re: [ros-dev] [ros-diffs] [dgorbachev] 53907: [NTOSKRNL] Use inline asm in KiIsNpxErrataPresent(). C code can be optimized in a wrong way.
by Alex Ionescu 01 Oct '11

01 Oct '11

Care to explain? If it can be optimized the wrong way -- use a pragma or fix the compiler. I hate these kinds of patches. I think Timo would agree. Best regards, Alex Ionescu On Fri, Sep 30, 2011 at 5:03 PM, <dgorbachev(a)svn.reactos.org> wrote: > Author: dgorbachev > Date: Fri Sep 30 21:03:29 2011 > New Revision: 53907 > > URL: http://svn.reactos.org/svn/reactos?rev=53907&view=rev > Log: > [NTOSKRNL] > Use inline asm in KiIsNpxErrataPresent(). C code can be optimized in a > wrong way. > > Modified: > trunk/reactos/ntoskrnl/ke/i386/cpu.c > > Modified: trunk/reactos/ntoskrnl/ke/i386/cpu.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/cpu.c?rev… > > ============================================================================== > --- trunk/reactos/ntoskrnl/ke/i386/cpu.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ke/i386/cpu.c [iso-8859-1] Fri Sep 30 21:03:29 > 2011 > @@ -1254,9 +1254,9 @@ > INIT_FUNCTION > KiIsNpxErrataPresent(VOID) > { > - BOOLEAN ErrataPresent; > + static double Value1 = 4195835.0, Value2 = 3145727.0; > + INT ErrataPresent; > ULONG Cr0; > - volatile double Value1, Value2; > > /* Disable interrupts */ > _disable(); > @@ -1269,9 +1269,30 @@ > Ke386FnInit(); > > /* Multiply the magic values and divide, we should get the result back > */ > - Value1 = 4195835.0; > - Value2 = 3145727.0; > - ErrataPresent = (Value1 * Value2 / 3145727.0) != 4195835.0; > +#ifdef __GNUC__ > + __asm__ __volatile__ > + ( > + "fldl %1\n\t" > + "fdivl %2\n\t" > + "fmull %2\n\t" > + "fldl %1\n\t" > + "fsubp\n\t" > + "fistpl %0\n\t" > + : "=m" (ErrataPresent) > + : "m" (Value1), > + "m" (Value2) > + ); > +#else > + __asm > + { > + fld Value1 > + fdiv Value2 > + fmul Value2 > + fld Value1 > + fsubp > + fistp ErrataPresent > + }; > +#endif > > /* Restore CR0 */ > __writecr0(Cr0); > @@ -1280,7 +1301,7 @@ > _enable(); > > /* Return if there's an errata */ > - return ErrataPresent; > + return ErrataPresent != 0; > } > > VOID > > >

4 9

trunk is broken Re: [ros-diffs] [tkreuzer] 53896: [FREELDR] - Move some disk related stuff that is unrelated to the registry data into a new file, hwdisk.c - Don't get the disk count from the size value of a structure that was pr...
by Minas Abrahamyan 01 Oct '11

01 Oct '11

Hi there, This patch is to blame (seems to, just this) or another... But trunk is broken: build stops with these messages: [COPY] output-i386\livecd\reactos\system32\ntoskrnl.exe [CC] dll\win32\shell32\shellole.cpp [RSP] obj-i386\dll\win32\shell32\shell32_objs.rsp [LD] output-i386\dll\win32\shell32\shell32.dll [PEFIXUP] output-i386\dll\win32\shell32\shell32.dll [RSYM] output-i386\dll\win32\shell32\shell32.dll [COPY] output-i386\livecd\reactos\system32\shell32.dll [LD] output-i386\boot\freeldr\freeldr\freeldr.sys obj-i386\boot\freeldr\freeldr\arch\i386\hardware_freeldr_arch.o: In function `PcHwDetect': D:/ProgBin/ros/reactos/boot/freeldr/freeldr/arch/i386/hardware.c:1710: undefined reference to `HwInitializeBiosDisks' D:/ProgBin/ros/reactos/boot/freeldr/freeldr/arch/i386/hardware.c:606: undefined reference to `PcBiosDiskCount' D:/ProgBin/ros/reactos/boot/freeldr/freeldr/arch/i386/hardware.c:694: undefined reference to `GetHarddiskIdentifier' D:/ProgBin/ros/reactos/boot/freeldr/freeldr/arch/i386/hardware.c:685: undefined reference to `PcBiosDiskCount' make.exe: *** [output-i386\boot\freeldr\freeldr\freeldr.sys] Error 1 Total Build Time: 00:01:07 D:\ProgBin\ros\reactos> Best regards, M.A. On Fri, Sep 30, 2011 at 2:12 AM, <tkreuzer(a)svn.reactos.org> wrote: > Author: tkreuzer > Date: Thu Sep 29 21:12:40 2011 > New Revision: 53896 > > URL: http://svn.reactos.org/svn/reactos?rev=53896&view=rev > Log: > [FREELDR] > - Move some disk related stuff that is unrelated to the registry data into a new file, hwdisk.c > - Don't get the disk count from the size value of a structure that was previously calculated from the disk count, but instead save it in a global variable. > - Initialize certain data in a better place > > Added: > trunk/reactos/boot/freeldr/freeldr/arch/i386/hwdisk.c (with props) > Modified: > trunk/reactos/boot/freeldr/freeldr/CMakeLists.txt > trunk/reactos/boot/freeldr/freeldr/arch/i386/hardware.c > trunk/reactos/boot/freeldr/freeldr/debug.c > trunk/reactos/boot/freeldr/freeldr/freeldr_arch.rbuild > trunk/reactos/boot/freeldr/freeldr/inifile/ini_init.c > > Modified: trunk/reactos/boot/freeldr/freeldr/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/CMake… > ============================================================================== > --- trunk/reactos/boot/freeldr/freeldr/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/freeldr/CMakeLists.txt [iso-8859-1] Thu Sep 29 21:12:40 2011 > @@ -83,6 +83,7 @@ > arch/i386/hardware.c > arch/i386/hwacpi.c > arch/i386/hwapm.c > + arch/i386/hwdisk.c > arch/i386/hwpci.c > arch/i386/i386bug.c > arch/i386/i386disk.c > > Modified: trunk/reactos/boot/freeldr/freeldr/arch/i386/hardware.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/… > ============================================================================== > --- trunk/reactos/boot/freeldr/freeldr/arch/i386/hardware.c [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/freeldr/arch/i386/hardware.c [iso-8859-1] Thu Sep 29 21:12:40 2011 > @@ -82,12 +82,16 @@ > > DBG_DEFAULT_CHANNEL(HWDETECT); > > -static CHAR Hex[] = "0123456789abcdef"; > static unsigned int delay_count = 1; > > -extern ULONG reactos_disk_count; > -extern ARC_DISK_SIGNATURE reactos_arc_disk_info[]; > -extern char reactos_arc_strings[32][256]; > +extern UCHAR PcBiosDiskCount; > + > +PCHAR > +GetHarddiskIdentifier( > + UCHAR DriveNumber); > + > +VOID > +HwInitializeBiosDisks(VOID); > > /* FUNCTIONS ****************************************************************/ > > @@ -402,218 +406,6 @@ > return PartialResourceList; > } > > -typedef struct tagDISKCONTEXT > -{ > - UCHAR DriveNumber; > - ULONG SectorSize; > - ULONGLONG SectorOffset; > - ULONGLONG SectorCount; > - ULONGLONG SectorNumber; > -} DISKCONTEXT; > - > -static LONG DiskClose(ULONG FileId) > -{ > - DISKCONTEXT* Context = FsGetDeviceSpecific(FileId); > - > - MmHeapFree(Context); > - return ESUCCESS; > -} > - > -static LONG DiskGetFileInformation(ULONG FileId, FILEINFORMATION* Information) > -{ > - DISKCONTEXT* Context = FsGetDeviceSpecific(FileId); > - > - RtlZeroMemory(Information, sizeof(FILEINFORMATION)); > - Information->EndingAddress.QuadPart = (Context->SectorOffset + Context->SectorCount) * Context->SectorSize; > - Information->CurrentAddress.QuadPart = (Context->SectorOffset + Context->SectorNumber) * Context->SectorSize; > - > - return ESUCCESS; > -} > - > -static LONG DiskOpen(CHAR* Path, OPENMODE OpenMode, ULONG* FileId) > -{ > - DISKCONTEXT* Context; > - UCHAR DriveNumber; > - ULONG DrivePartition, SectorSize; > - ULONGLONG SectorOffset = 0; > - ULONGLONG SectorCount = 0; > - PARTITION_TABLE_ENTRY PartitionTableEntry; > - CHAR FileName[1]; > - > - if (!DissectArcPath(Path, FileName, &DriveNumber, &DrivePartition)) > - return EINVAL; > - > - if (DrivePartition == 0xff) > - { > - /* This is a CD-ROM device */ > - SectorSize = 2048; > - } > - else > - { > - /* This is either a floppy disk device (DrivePartition == 0) or > - * a hard disk device (DrivePartition != 0 && DrivePartition != 0xFF) but > - * it doesn't matter which one because they both have 512 bytes per sector */ > - SectorSize = 512; > - } > - > - if (DrivePartition != 0xff && DrivePartition != 0) > - { > - if (!DiskGetPartitionEntry(DriveNumber, DrivePartition, &PartitionTableEntry)) > - return EINVAL; > - SectorOffset = PartitionTableEntry.SectorCountBeforePartition; > - SectorCount = PartitionTableEntry.PartitionSectorCount; > - } > - > - Context = MmHeapAlloc(sizeof(DISKCONTEXT)); > - if (!Context) > - return ENOMEM; > - Context->DriveNumber = DriveNumber; > - Context->SectorSize = SectorSize; > - Context->SectorOffset = SectorOffset; > - Context->SectorCount = SectorCount; > - Context->SectorNumber = 0; > - FsSetDeviceSpecific(*FileId, Context); > - > - return ESUCCESS; > -} > - > -static LONG DiskRead(ULONG FileId, VOID* Buffer, ULONG N, ULONG* Count) > -{ > - DISKCONTEXT* Context = FsGetDeviceSpecific(FileId); > - UCHAR* Ptr = (UCHAR*)Buffer; > - ULONG i, Length; > - BOOLEAN ret; > - > - *Count = 0; > - i = 0; > - while (N > 0) > - { > - Length = N; > - if (Length > Context->SectorSize) > - Length = Context->SectorSize; > - ret = MachDiskReadLogicalSectors( > - Context->DriveNumber, > - Context->SectorNumber + Context->SectorOffset + i, > - 1, > - (PVOID)DISKREADBUFFER); > - if (!ret) > - return EIO; > - RtlCopyMemory(Ptr, (PVOID)DISKREADBUFFER, Length); > - Ptr += Length; > - *Count += Length; > - N -= Length; > - i++; > - } > - > - return ESUCCESS; > -} > - > -static LONG DiskSeek(ULONG FileId, LARGE_INTEGER* Position, SEEKMODE SeekMode) > -{ > - DISKCONTEXT* Context = FsGetDeviceSpecific(FileId); > - > - if (SeekMode != SeekAbsolute) > - return EINVAL; > - if (Position->LowPart & (Context->SectorSize - 1)) > - return EINVAL; > - > - /* FIXME: take HighPart into account */ > - Context->SectorNumber = Position->LowPart / Context->SectorSize; > - return ESUCCESS; > -} > - > -static const DEVVTBL DiskVtbl = { > - DiskClose, > - DiskGetFileInformation, > - DiskOpen, > - DiskRead, > - DiskSeek, > -}; > - > -static VOID > -GetHarddiskIdentifier(PCHAR Identifier, > - UCHAR DriveNumber) > -{ > - PMASTER_BOOT_RECORD Mbr; > - ULONG *Buffer; > - ULONG i; > - ULONG Checksum; > - ULONG Signature; > - CHAR ArcName[256]; > - PARTITION_TABLE_ENTRY PartitionTableEntry; > - > - /* Read the MBR */ > - if (!MachDiskReadLogicalSectors(DriveNumber, 0ULL, 1, (PVOID)DISKREADBUFFER)) > - { > - ERR("Reading MBR failed\n"); > - return; > - } > - > - Buffer = (ULONG*)DISKREADBUFFER; > - Mbr = (PMASTER_BOOT_RECORD)DISKREADBUFFER; > - > - Signature = Mbr->Signature; > - TRACE("Signature: %x\n", Signature); > - > - /* Calculate the MBR checksum */ > - Checksum = 0; > - for (i = 0; i < 128; i++) > - { > - Checksum += Buffer[i]; > - } > - Checksum = ~Checksum + 1; > - TRACE("Checksum: %x\n", Checksum); > - > - /* Fill out the ARC disk block */ > - reactos_arc_disk_info[reactos_disk_count].Signature = Signature; > - reactos_arc_disk_info[reactos_disk_count].CheckSum = Checksum; > - sprintf(ArcName, "multi(0)disk(0)rdisk(%lu)", reactos_disk_count); > - strcpy(reactos_arc_strings[reactos_disk_count], ArcName); > - reactos_arc_disk_info[reactos_disk_count].ArcName = > - reactos_arc_strings[reactos_disk_count]; > - reactos_disk_count++; > - > - sprintf(ArcName, "multi(0)disk(0)rdisk(%u)partition(0)", DriveNumber - 0x80); > - FsRegisterDevice(ArcName, &DiskVtbl); > - > - /* Add partitions */ > - i = 1; > - DiskReportError(FALSE); > - while (DiskGetPartitionEntry(DriveNumber, i, &PartitionTableEntry)) > - { > - if (PartitionTableEntry.SystemIndicator != PARTITION_ENTRY_UNUSED) > - { > - sprintf(ArcName, "multi(0)disk(0)rdisk(%u)partition(%lu)", DriveNumber - 0x80, i); > - FsRegisterDevice(ArcName, &DiskVtbl); > - } > - i++; > - } > - DiskReportError(TRUE); > - > - /* Convert checksum and signature to identifier string */ > - Identifier[0] = Hex[(Checksum >> 28) & 0x0F]; > - Identifier[1] = Hex[(Checksum >> 24) & 0x0F]; > - Identifier[2] = Hex[(Checksum >> 20) & 0x0F]; > - Identifier[3] = Hex[(Checksum >> 16) & 0x0F]; > - Identifier[4] = Hex[(Checksum >> 12) & 0x0F]; > - Identifier[5] = Hex[(Checksum >> 8) & 0x0F]; > - Identifier[6] = Hex[(Checksum >> 4) & 0x0F]; > - Identifier[7] = Hex[Checksum & 0x0F]; > - Identifier[8] = '-'; > - Identifier[9] = Hex[(Signature >> 28) & 0x0F]; > - Identifier[10] = Hex[(Signature >> 24) & 0x0F]; > - Identifier[11] = Hex[(Signature >> 20) & 0x0F]; > - Identifier[12] = Hex[(Signature >> 16) & 0x0F]; > - Identifier[13] = Hex[(Signature >> 12) & 0x0F]; > - Identifier[14] = Hex[(Signature >> 8) & 0x0F]; > - Identifier[15] = Hex[(Signature >> 4) & 0x0F]; > - Identifier[16] = Hex[Signature & 0x0F]; > - Identifier[17] = '-'; > - Identifier[18] = 'A'; > - Identifier[19] = 0; > - TRACE("Identifier: %s\n", Identifier); > -} > - > static UCHAR > GetFloppyCount(VOID) > { > @@ -810,37 +602,8 @@ > UCHAR DiskCount; > USHORT i; > ULONG Size; > - BOOLEAN Changed; > - > - /* Count the number of visible drives */ > - DiskReportError(FALSE); > - DiskCount = 0; > - > - /* There are some really broken BIOSes out there. There are even BIOSes > - * that happily report success when you ask them to read from non-existent > - * harddisks. So, we set the buffer to known contents first, then try to > - * read. If the BIOS reports success but the buffer contents haven't > - * changed then we fail anyway */ > - memset((PVOID) DISKREADBUFFER, 0xcd, 512); > - while (MachDiskReadLogicalSectors(0x80 + DiskCount, 0ULL, 1, (PVOID)DISKREADBUFFER)) > - { > - Changed = FALSE; > - for (i = 0; ! Changed && i < 512; i++) > - { > - Changed = ((PUCHAR)DISKREADBUFFER)[i] != 0xcd; > - } > - if (! Changed) > - { > - TRACE("BIOS reports success for disk %d but data didn't change\n", > - (int)DiskCount); > - break; > - } > - DiskCount++; > - memset((PVOID) DISKREADBUFFER, 0xcd, 512); > - } > - DiskReportError(TRUE); > - TRACE("BIOS reports %d harddisk%s\n", > - (int)DiskCount, (DiskCount == 1) ? "": "s"); > + > + DiskCount = PcBiosDiskCount; > > /* Allocate resource descriptor */ > Size = sizeof(CM_PARTIAL_RESOURCE_LIST) + > @@ -900,49 +663,11 @@ > return SystemKey; > } > > -static UCHAR > -GetDiskCount(PCONFIGURATION_COMPONENT_DATA BusKey) > -{ > - PCONFIGURATION_COMPONENT_DATA System; > - ULONG ConfigurationDataLength; > - UCHAR DiskCount = 0; > - > - // > - // Get root component > - // > - System = BusKey; > - while (System->Parent) > - System = System->Parent; > - > - // > - // Get root configuration data length > - // > - ConfigurationDataLength = System->ComponentEntry.ConfigurationDataLength; > - > - // > - // We assume that nothing wrong happened, and that configuration > - // only consists of one CM_PARTIAL_RESOURCE_LIST entry, followed > - // by n entries of CM_INT13_DRIVE_PARAMETER > - // > - if (ConfigurationDataLength > 0) > - DiskCount = (UCHAR)((ConfigurationDataLength - sizeof(CM_PARTIAL_RESOURCE_LIST)) > - / sizeof(CM_INT13_DRIVE_PARAMETER)); > - > - // > - // Return number of disks > - // > - TRACE("Retrieving %lu INT13 disks\\0\n", DiskCount); > - return DiskCount; > -}; > - > static VOID > DetectBiosDisks(PCONFIGURATION_COMPONENT_DATA BusKey) > { > PCONFIGURATION_COMPONENT_DATA DiskKey, ControllerKey; > - BOOLEAN BootDriveReported = FALSE; > ULONG i; > - UCHAR DiskCount = GetDiskCount(BusKey); > - CHAR BootPath[512]; > > FldrCreateComponentKey(BusKey, > ControllerClass, > @@ -957,19 +682,16 @@ > TRACE("Created key: DiskController\\0\n"); > > /* Create and fill subkey for each harddisk */ > - for (i = 0; i < DiskCount; i++) > + for (i = 0; i < PcBiosDiskCount; i++) > { > PCM_PARTIAL_RESOURCE_LIST PartialResourceList; > ULONG Size; > - CHAR Identifier[20]; > + PCHAR Identifier; > UCHAR DriveNumber = 0x80 + (UCHAR)i; > - > - if (FrldrBootDrive == DriveNumber) > - BootDriveReported = TRUE; > > /* Get disk values */ > PartialResourceList = GetHarddiskConfigurationData(DriveNumber, &Size); > - GetHarddiskIdentifier(Identifier, DriveNumber); > + Identifier = GetHarddiskIdentifier(DriveNumber); > > /* Create disk key */ > FldrCreateComponentKey(ControllerKey, > @@ -984,40 +706,6 @@ > &DiskKey); > } > > - /* Get the drive we're booting from */ > - MachDiskGetBootPath(BootPath, sizeof(BootPath)); > - > - /* Add it, if it's a floppy or cdrom */ > - if ((FrldrBootDrive >= 0x80 && !BootDriveReported) || > - DiskIsDriveRemovable(FrldrBootDrive)) > - { > - /* TODO: Check if it's really a cdrom drive */ > - ULONG* Buffer; > - ULONG Checksum = 0; > - > - /* Read the MBR */ > - if (!MachDiskReadLogicalSectors(FrldrBootDrive, 16ULL, 1, (PVOID)DISKREADBUFFER)) > - { > - ERR("Reading MBR failed\n"); > - return; > - } > - > - Buffer = (ULONG*)DISKREADBUFFER; > - > - /* Calculate the MBR checksum */ > - for (i = 0; i < 2048 / sizeof(ULONG); i++) Checksum += Buffer[i]; > - Checksum = ~Checksum + 1; > - TRACE("Checksum: %x\n", Checksum); > - > - /* Fill out the ARC disk block */ > - reactos_arc_disk_info[reactos_disk_count].CheckSum = Checksum; > - strcpy(reactos_arc_strings[reactos_disk_count], BootPath); > - reactos_arc_disk_info[reactos_disk_count].ArcName = > - reactos_arc_strings[reactos_disk_count]; > - reactos_disk_count++; > - > - FsRegisterDevice(BootPath, &DiskVtbl); > - } > } > > static VOID > @@ -2019,6 +1707,8 @@ > > TRACE("DetectHardware()\n"); > > + HwInitializeBiosDisks(); > + > /* Create the 'System' key */ > SystemKey = DetectSystem(); > > > Added: trunk/reactos/boot/freeldr/freeldr/arch/i386/hwdisk.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/… > ============================================================================== > --- trunk/reactos/boot/freeldr/freeldr/arch/i386/hwdisk.c (added) > +++ trunk/reactos/boot/freeldr/freeldr/arch/i386/hwdisk.c [iso-8859-1] Thu Sep 29 21:12:40 2011 > @@ -1,0 +1,342 @@ > +/* > + * FreeLoader > + * > + * Copyright (C) 2003, 2004 Eric Kohl > + * Copyright (C) 2009 Hervé Poussineau > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License along > + * with this program; if not, write to the Free Software Foundation, Inc., > + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. > + */ > + > +#include <freeldr.h> > + > +#define NDEBUG > +#include <debug.h> > + > +DBG_DEFAULT_CHANNEL(HWDETECT); > + > +typedef struct tagDISKCONTEXT > +{ > + UCHAR DriveNumber; > + ULONG SectorSize; > + ULONGLONG SectorOffset; > + ULONGLONG SectorCount; > + ULONGLONG SectorNumber; > +} DISKCONTEXT; > + > +extern ULONG reactos_disk_count; > +extern ARC_DISK_SIGNATURE reactos_arc_disk_info[]; > +extern char reactos_arc_strings[32][256]; > + > +static CHAR Hex[] = "0123456789abcdef"; > +UCHAR PcBiosDiskCount = 0; > +CHAR PcDiskIdentifier[32][20]; > + > + > +static LONG DiskClose(ULONG FileId) > +{ > + DISKCONTEXT* Context = FsGetDeviceSpecific(FileId); > + > + MmHeapFree(Context); > + return ESUCCESS; > +} > + > +static LONG DiskGetFileInformation(ULONG FileId, FILEINFORMATION* Information) > +{ > + DISKCONTEXT* Context = FsGetDeviceSpecific(FileId); > + > + RtlZeroMemory(Information, sizeof(FILEINFORMATION)); > + Information->EndingAddress.QuadPart = (Context->SectorOffset + Context->SectorCount) * Context->SectorSize; > + Information->CurrentAddress.QuadPart = (Context->SectorOffset + Context->SectorNumber) * Context->SectorSize; > + > + return ESUCCESS; > +} > + > +static LONG DiskOpen(CHAR* Path, OPENMODE OpenMode, ULONG* FileId) > +{ > + DISKCONTEXT* Context; > + UCHAR DriveNumber; > + ULONG DrivePartition, SectorSize; > + ULONGLONG SectorOffset = 0; > + ULONGLONG SectorCount = 0; > + PARTITION_TABLE_ENTRY PartitionTableEntry; > + CHAR FileName[1]; > + > + if (!DissectArcPath(Path, FileName, &DriveNumber, &DrivePartition)) > + return EINVAL; > + > + if (DrivePartition == 0xff) > + { > + /* This is a CD-ROM device */ > + SectorSize = 2048; > + } > + else > + { > + /* This is either a floppy disk device (DrivePartition == 0) or > + * a hard disk device (DrivePartition != 0 && DrivePartition != 0xFF) but > + * it doesn't matter which one because they both have 512 bytes per sector */ > + SectorSize = 512; > + } > + > + if (DrivePartition != 0xff && DrivePartition != 0) > + { > + if (!DiskGetPartitionEntry(DriveNumber, DrivePartition, &PartitionTableEntry)) > + return EINVAL; > + SectorOffset = PartitionTableEntry.SectorCountBeforePartition; > + SectorCount = PartitionTableEntry.PartitionSectorCount; > + } > + > + Context = MmHeapAlloc(sizeof(DISKCONTEXT)); > + if (!Context) > + return ENOMEM; > + Context->DriveNumber = DriveNumber; > + Context->SectorSize = SectorSize; > + Context->SectorOffset = SectorOffset; > + Context->SectorCount = SectorCount; > + Context->SectorNumber = 0; > + FsSetDeviceSpecific(*FileId, Context); > + > + return ESUCCESS; > +} > + > +static LONG DiskRead(ULONG FileId, VOID* Buffer, ULONG N, ULONG* Count) > +{ > + DISKCONTEXT* Context = FsGetDeviceSpecific(FileId); > + UCHAR* Ptr = (UCHAR*)Buffer; > + ULONG i, Length; > + BOOLEAN ret; > + > + *Count = 0; > + i = 0; > + while (N > 0) > + { > + Length = N; > + if (Length > Context->SectorSize) > + Length = Context->SectorSize; > + ret = MachDiskReadLogicalSectors( > + Context->DriveNumber, > + Context->SectorNumber + Context->SectorOffset + i, > + 1, > + (PVOID)DISKREADBUFFER); > + if (!ret) > + return EIO; > + RtlCopyMemory(Ptr, (PVOID)DISKREADBUFFER, Length); > + Ptr += Length; > + *Count += Length; > + N -= Length; > + i++; > + } > + > + return ESUCCESS; > +} > + > +static LONG DiskSeek(ULONG FileId, LARGE_INTEGER* Position, SEEKMODE SeekMode) > +{ > + DISKCONTEXT* Context = FsGetDeviceSpecific(FileId); > + > + if (SeekMode != SeekAbsolute) > + return EINVAL; > + if (Position->LowPart & (Context->SectorSize - 1)) > + return EINVAL; > + > + /* FIXME: take HighPart into account */ > + Context->SectorNumber = Position->LowPart / Context->SectorSize; > + return ESUCCESS; > +} > + > +static const DEVVTBL DiskVtbl = { > + DiskClose, > + DiskGetFileInformation, > + DiskOpen, > + DiskRead, > + DiskSeek, > +}; > + > +PCHAR > +GetHarddiskIdentifier( > + UCHAR DriveNumber) > +{ > + return PcDiskIdentifier[DriveNumber - 0x80]; > +} > + > +VOID > +GetHarddiskInformation( > + UCHAR DriveNumber) > +{ > + PMASTER_BOOT_RECORD Mbr; > + ULONG *Buffer; > + ULONG i; > + ULONG Checksum; > + ULONG Signature; > + CHAR ArcName[256]; > + PARTITION_TABLE_ENTRY PartitionTableEntry; > + PCHAR Identifier = PcDiskIdentifier[DriveNumber - 0x80]; > + > + /* Read the MBR */ > + if (!MachDiskReadLogicalSectors(DriveNumber, 0ULL, 1, (PVOID)DISKREADBUFFER)) > + { > + ERR("Reading MBR failed\n"); > + return; > + } > + > + Buffer = (ULONG*)DISKREADBUFFER; > + Mbr = (PMASTER_BOOT_RECORD)DISKREADBUFFER; > + > + Signature = Mbr->Signature; > + TRACE("Signature: %x\n", Signature); > + > + /* Calculate the MBR checksum */ > + Checksum = 0; > + for (i = 0; i < 128; i++) > + { > + Checksum += Buffer[i]; > + } > + Checksum = ~Checksum + 1; > + TRACE("Checksum: %x\n", Checksum); > + > + /* Fill out the ARC disk block */ > + reactos_arc_disk_info[reactos_disk_count].Signature = Signature; > + reactos_arc_disk_info[reactos_disk_count].CheckSum = Checksum; > + sprintf(ArcName, "multi(0)disk(0)rdisk(%lu)", reactos_disk_count); > + strcpy(reactos_arc_strings[reactos_disk_count], ArcName); > + reactos_arc_disk_info[reactos_disk_count].ArcName = > + reactos_arc_strings[reactos_disk_count]; > + reactos_disk_count++; > + > + sprintf(ArcName, "multi(0)disk(0)rdisk(%u)partition(0)", DriveNumber - 0x80); > + FsRegisterDevice(ArcName, &DiskVtbl); > + > + /* Add partitions */ > + i = 1; > + DiskReportError(FALSE); > + while (DiskGetPartitionEntry(DriveNumber, i, &PartitionTableEntry)) > + { > + if (PartitionTableEntry.SystemIndicator != PARTITION_ENTRY_UNUSED) > + { > + sprintf(ArcName, "multi(0)disk(0)rdisk(%u)partition(%lu)", DriveNumber - 0x80, i); > + FsRegisterDevice(ArcName, &DiskVtbl); > + } > + i++; > + } > + DiskReportError(TRUE); > + > + /* Convert checksum and signature to identifier string */ > + Identifier[0] = Hex[(Checksum >> 28) & 0x0F]; > + Identifier[1] = Hex[(Checksum >> 24) & 0x0F]; > + Identifier[2] = Hex[(Checksum >> 20) & 0x0F]; > + Identifier[3] = Hex[(Checksum >> 16) & 0x0F]; > + Identifier[4] = Hex[(Checksum >> 12) & 0x0F]; > + Identifier[5] = Hex[(Checksum >> 8) & 0x0F]; > + Identifier[6] = Hex[(Checksum >> 4) & 0x0F]; > + Identifier[7] = Hex[Checksum & 0x0F]; > + Identifier[8] = '-'; > + Identifier[9] = Hex[(Signature >> 28) & 0x0F]; > + Identifier[10] = Hex[(Signature >> 24) & 0x0F]; > + Identifier[11] = Hex[(Signature >> 20) & 0x0F]; > + Identifier[12] = Hex[(Signature >> 16) & 0x0F]; > + Identifier[13] = Hex[(Signature >> 12) & 0x0F]; > + Identifier[14] = Hex[(Signature >> 8) & 0x0F]; > + Identifier[15] = Hex[(Signature >> 4) & 0x0F]; > + Identifier[16] = Hex[Signature & 0x0F]; > + Identifier[17] = '-'; > + Identifier[18] = 'A'; > + Identifier[19] = 0; > + TRACE("Identifier: %s\n", Identifier); > +} > + > + > +VOID > +HwInitializeBiosDisks(VOID) > +{ > + UCHAR DiskCount, DriveNumber; > + ULONG i; > + BOOLEAN Changed; > + CHAR BootPath[512]; > + BOOLEAN BootDriveReported = FALSE; > + > + /* Count the number of visible drives */ > + DiskReportError(FALSE); > + DiskCount = 0; > + DriveNumber = 0x80; > + > + /* There are some really broken BIOSes out there. There are even BIOSes > + * that happily report success when you ask them to read from non-existent > + * harddisks. So, we set the buffer to known contents first, then try to > + * read. If the BIOS reports success but the buffer contents haven't > + * changed then we fail anyway */ > + memset((PVOID) DISKREADBUFFER, 0xcd, 512); > + while (MachDiskReadLogicalSectors(DriveNumber, 0ULL, 1, (PVOID)DISKREADBUFFER)) > + { > + Changed = FALSE; > + for (i = 0; ! Changed && i < 512; i++) > + { > + Changed = ((PUCHAR)DISKREADBUFFER)[i] != 0xcd; > + } > + if (! Changed) > + { > + TRACE("BIOS reports success for disk %d but data didn't change\n", > + (int)DiskCount); > + break; > + } > + > + GetHarddiskInformation(DriveNumber); > + > + if (FrldrBootDrive == DriveNumber) > + BootDriveReported = TRUE; > + > + DiskCount++; > + DriveNumber++; > + memset((PVOID) DISKREADBUFFER, 0xcd, 512); > + } > + DiskReportError(TRUE); > + TRACE("BIOS reports %d harddisk%s\n", > + (int)DiskCount, (DiskCount == 1) ? "": "s"); > + > + /* Get the drive we're booting from */ > + MachDiskGetBootPath(BootPath, sizeof(BootPath)); > + > + /* Add it, if it's a floppy or cdrom */ > + if ((FrldrBootDrive >= 0x80 && !BootDriveReported) || > + DiskIsDriveRemovable(FrldrBootDrive)) > + { > + /* TODO: Check if it's really a cdrom drive */ > + ULONG* Buffer; > + ULONG Checksum = 0; > + > + /* Read the MBR */ > + if (!MachDiskReadLogicalSectors(FrldrBootDrive, 16ULL, 1, (PVOID)DISKREADBUFFER)) > + { > + ERR("Reading MBR failed\n"); > + return; > + } > + > + Buffer = (ULONG*)DISKREADBUFFER; > + > + /* Calculate the MBR checksum */ > + for (i = 0; i < 2048 / sizeof(ULONG); i++) Checksum += Buffer[i]; > + Checksum = ~Checksum + 1; > + TRACE("Checksum: %x\n", Checksum); > + > + /* Fill out the ARC disk block */ > + reactos_arc_disk_info[reactos_disk_count].CheckSum = Checksum; > + strcpy(reactos_arc_strings[reactos_disk_count], BootPath); > + reactos_arc_disk_info[reactos_disk_count].ArcName = > + reactos_arc_strings[reactos_disk_count]; > + reactos_disk_count++; > + > + FsRegisterDevice(BootPath, &DiskVtbl); > + } > + > + PcBiosDiskCount = DiskCount; > +} > > Propchange: trunk/reactos/boot/freeldr/freeldr/arch/i386/hwdisk.c > ------------------------------------------------------------------------------ > svn:eol-style = native > > Modified: trunk/reactos/boot/freeldr/freeldr/debug.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/debug… > ============================================================================== > --- trunk/reactos/boot/freeldr/freeldr/debug.c [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/freeldr/debug.c [iso-8859-1] Thu Sep 29 21:12:40 2011 > @@ -289,7 +289,6 @@ > } > > //DECLSPEC_NORETURN > -NTKERNELAPI > VOID > NTAPI > KeBugCheckEx( > > Modified: trunk/reactos/boot/freeldr/freeldr/freeldr_arch.rbuild > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/freel… > ============================================================================== > --- trunk/reactos/boot/freeldr/freeldr/freeldr_arch.rbuild [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/freeldr/freeldr_arch.rbuild [iso-8859-1] Thu Sep 29 21:12:40 2011 > @@ -19,6 +19,7 @@ > <file>hardware.c</file> > <file>hwacpi.c</file> > <file>hwapm.c</file> > + <file>hwdisk.c</file> > <file>hwpci.c</file> > <file>i386bug.c</file> > <file>i386disk.c</file> > > Modified: trunk/reactos/boot/freeldr/freeldr/inifile/ini_init.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/inifi… > ============================================================================== > --- trunk/reactos/boot/freeldr/freeldr/inifile/ini_init.c [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/freeldr/inifile/ini_init.c [iso-8859-1] Thu Sep 29 21:12:40 2011 > @@ -18,6 +18,8 @@ > */ > > #include <freeldr.h> > +#include <debug.h> > +DBG_DEFAULT_CHANNEL(INIFILE); > > static LONG IniOpenIniFile(ULONG* FileId) > { > @@ -44,6 +46,7 @@ > ULONG FreeLoaderIniFileSize, Count; > LONG ret; > BOOLEAN Success; > + TRACE("IniFileInitialize()\n"); > > // > // Open freeldr.ini > > >

7 9

NDK
by dmex 30 Sep '11

30 Sep '11

The NDK has allot of 64bit alignment issues mostly from omitted SIZE_T fields, There's at least 20 or so other structures with issues but here's two corrected structures below: typedef struct _SYSTEM_VERIFIER_INFORMATION { ULONG NextEntryOffset; ULONG Level; UNICODE_STRING DriverName; ULONG RaiseIrqls; ULONG AcquireSpinLocks; ULONG SynchronizeExecutions; ULONG AllocationsAttempted; ULONG AllocationsSucceeded; ULONG AllocationsSucceededSpecialPool; ULONG AllocationsWithNoTag; ULONG TrimRequests; ULONG Trims; ULONG AllocationsFailed; ULONG AllocationsFailedDeliberately; ULONG Loads; ULONG Unloads; ULONG UnTrackedPool; ULONG CurrentPagedPoolAllocations; ULONG CurrentNonPagedPoolAllocations; ULONG PeakPagedPoolAllocations; ULONG PeakNonPagedPoolAllocations; SIZE_T PagedPoolUsageInBytes; SIZE_T NonPagedPoolUsageInBytes; SIZE_T PeakPagedPoolUsageInBytes; SIZE_T PeakNonPagedPoolUsageInBytes; } SYSTEM_VERIFIER_INFORMATION, *PSYSTEM_VERIFIER_INFORMATION; // Class 22 typedef struct _SYSTEM_POOLTAG { union { UCHAR Tag[4]; ULONG TagUlong; }; ULONG PagedAllocs; ULONG PagedFrees; SIZE_T PagedUsed; ULONG NonPagedAllocs; ULONG NonPagedFrees; SIZE_T NonPagedUsed; } SYSTEM_POOLTAG, *PSYSTEM_POOLTAG;

4 4

Services interruptions
by Pierre Schweitzer 29 Sep '11

29 Sep '11

Hi, due to a HDD failure in one of our major servers, you've been encountering services interruptions (mail, svn, web, mainly) this afternoon and tonight. The issue has been successfully addressed right now, and the server is back online with its new hard-drive. Regards, The ReactOS sysadmins.

1 0

September Status Meeting
by Aleksey Bragin 29 Sep '11

29 Sep '11

Hi, this is a reminder about the Status meeting, which is to happen tomorrow, 29th of September at 19:00 UTC. Please don't miss it. The meeting is declared private. I will lead the meeting, as usual. Proposed agenda for the meeting: 1. CMake adoption progress. 2. Release preparation status report, deciding on the release date. 3. Webportal upgrade plans. 4. ReactOS target version: strict sticking to it or hybrid. List of participants: - Giannis Adamopoulos (smiley1_) - Johannes Anderwald (janderwald) - Javier Agustìn Fernàndez Arroyo (elhoir) - Maciej Bialas (niski) - Jan Blomqvist-Kinander (JaixBly) - Aleksey Bragin (abragin) - Thomas Faber (ThFabba) - Colin Finck (Colin_Finck) - Jérôme Gardou (zefklop) - Danny Götte (dangerground) - Cameron Gutman (aicom) - Ziliang Guo (ZWabbit) - Rafal Harabien (rafalh) - Andrew Hill (ash77) - Kamil Hornicek (Pigglesworth) - Gabriel Ilardi (gabriel_it) - Alex Ionescu (Alex_Ionescu) - Amine Khaldi (AmineKhaldi) - Igor Koshpaev (tower) - Timo Kreuzer (tkreuzer) - Matthias Kupfer (Collibri) - Michael Martin (mjmartin) - Victor Martinez (vicmarcal) - Roel Messiant (Mephisto) - Claudiu Mihail (KlausM) - Andrew Munger (WaxDragon) - Ged Murphy (GedMurphy) - Igor Paliychuk (igorko) - Sylvain Petreolle (Usurp) - Hervé Poussineau (hpoussin) - Daniel Reimer (dreimer) - Pierre Schweitzer (HeisSpiter) - Samuel Serapion (encoded) - Olaf Siejka (Caemyr) - James Tabor (jimtabor) - Christoph von Wittich (Christoph_vW) - Art Yerkes (arty) WBR, Aleksey Bragin.

4 4

Interesting article
by Aleksey Bragin 29 Sep '11

29 Sep '11

FYI: This is Linus' interview. http://h30565.www3.hp.com/t5/Feature- Articles/Linus-Torvalds-s-Lessons-on-Software-Development-Management/ ba-p/440 He very correctly outlines many things. One of the most important: "The other thing—and it's kind of related—that people seem to get wrong is to think that the code they write is what matters. No, even if you wrote 100% of the code, and even if you are the best programmer in the world and will never need any help with the project at all, the thing that really matters is the users of the code. The code itself is unimportant; the project is only as useful as people actually find it.” And this: "Way too many projects seem to think that the code is more important than the user, and they break things left and right, and they don't apologize for it, because they feel that they are ‘fixing’ the code and doing the right thing.” WBR, Aleksey Bragin.

5 9

ACPI enabled on Linux Testslave
by Colin Finck 27 Sep '11

27 Sep '11

Hi all, Just for your information, I have enabled ACPI for the KVM machine used by the Linux Testslave today. For reference, the full VM configuration is like this: * QEMU/KVM-based i686 ACPI machine * 256MB of RAM * 512MB HDD on IDE Primary Master * ReactOS ISO on IDE Secondary Master * AMD PCNet-compatible Network Adapter * COM1 port redirected to a virtual Linux terminal device * PS/2 mouse * Tablet pointing device on USB Usually useful if any KVM machine is controlled over VNC, but probably not relevant for ReactOS yet. As you see, there is no virtual sound card (disabled as of 2011-06-07 due to r52098 according to my notes). Is this still correct? - Colin

3 2

Usual build breakage rant again...
by caemyr＠myopera.com 25 Sep '11

25 Sep '11

Wont be that usual. Happened twice today, still broken atm. I`m not a dev, hence i have no idea how the devs commit stuff works and all the problems you guys have to overcome... I suppose it is too difficult for you simply to visit http://build.reactos.org/waterfall and just check if its all green (yes, no need to check stdio, just noticing the color). Your time is probably too precious to wait up to 5 bloody minutes, to see if previous build was ok... I`m not even talking about runtime regressions. Its understandable, that 45 minutes is often too much to wait, but 5?? I`m not even talking about patchbot, why should I? Already did, already tried, to no effect. If you really care about ROS, then by commiting on a broken trunk, you are practically shooting yourself in your foot. Trunk will be most likely not fixed until several other commits, sometimes a day or so. ISO will not be build. Commits will not be tested, neither by automation, nor by community, bugs will not be reported and regressions will only be found in more distant future. Then, you will ask for regtesting. You should better start doing it yourself, because you guys too often are not doing even the simplest things to keep trunk clean and working, making development harder for everyone around! -- With best regards Caemyr

3 3

Compiler warnings
by Dmitry Gorbachev 24 Sep '11

24 Sep '11

Hi, Are there any bugs: /reactos/dll/directx/ksproxy/allocator.cpp: In member function 'void CKsAllocator::FreeMediaSamples()': /reactos/dll/directx/ksproxy/allocator.cpp:586:16: warning: deleting object of abstract class type 'IMediaSample' which has non-virtual destructor will cause undefined behaviour [-Wdelete-non-virtual-dtor] /reactos/dll/directx/ksproxy/proxy.cpp: In function 'HRESULT CKsProxy_Constructor(IUnknown*, const IID&, void**)': /reactos/dll/directx/ksproxy/proxy.cpp:3188:16: warning: deleting object of polymorphic class type 'CKsProxy' which has non-virtual destructor might cause undefined behaviour [-Wdelete-non-virtual-dtor] In file included from /reactos/dll/win32/browseui/precomp.h:8:0, from /reactos/dll/win32/browseui/browseui.cpp:21: /reactos/lib/atl/atlcom.h: In instantiation of 'static HRESULT ATL::CComCreator<T1>::CreateInstance(void*, const IID&, void**) [with T1 = ATL::CComObjectCached<ATL::CComClassFactory>, HRESULT = int, IID = _GUID, LPVOID = void*]': /reactos/dll/win32/browseui/browseui.cpp:32:1: required from here /reactos/lib/atl/atlcom.h:253:5: warning: deleting object of polymorphic class type 'ATL::CComObjectCached<ATL::CComClassFactory>' which has non-virtual destructor might cause undefined behaviour [-Wdelete-non-virtual-dtor] /reactos/lib/atl/atlcom.h: In instantiation of 'ULONG ATL::CComObjectCached<Base>::Release() [with Base = ATL::CComClassFactory, ULONG = unsigned int]': /reactos/dll/win32/browseui/browseui.cpp:121:1: required from here /reactos/lib/atl/atlcom.h:304:4: warning: deleting object of polymorphic class type 'ATL::CComObjectCached<ATL::CComClassFactory>' which has non-virtual destructor might cause undefined behaviour [-Wdelete-non-virtual-dtor] In file included from /reactos/dll/win32/shell32/precomp.h:50:0, from /reactos/dll/win32/shell32/shell32_main.cpp:22: /reactos/lib/atl/atlcom.h: In instantiation of 'static HRESULT ATL::CComCreator<T1>::CreateInstance(void*, const IID&, void**) [with T1 = ATL::CComObjectCached<ATL::CComClassFactory>, HRESULT = long int, IID = _GUID, LPVOID = void*]': /reactos/dll/win32/shell32/shell32_main.cpp:1273:1: required from here /reactos/lib/atl/atlcom.h:253:5: warning: deleting object of polymorphic class type 'ATL::CComObjectCached<ATL::CComClassFactory>' which has non-virtual destructor might cause undefined behaviour [-Wdelete-non-virtual-dtor] /reactos/lib/atl/atlcom.h: In instantiation of 'ULONG ATL::CComObjectCached<Base>::Release() [with Base = ATL::CComClassFactory, ULONG = long unsigned int]': /reactos/dll/win32/shell32/shell32_main.cpp:1478:1: required from here /reactos/lib/atl/atlcom.h:304:4: warning: deleting object of polymorphic class type 'ATL::CComObjectCached<ATL::CComClassFactory>' which has non-virtual destructor might cause undefined behaviour [-Wdelete-non-virtual-dtor] /reactos/drivers/wdm/audio/backpln/portcls/miniport_dmus.cpp: In member function 'virtual ULONG CMiniportDMusUART::Release()': /reactos/drivers/wdm/audio/backpln/portcls/miniport_dmus.cpp:114:20: warning: deleting object of polymorphic class type 'CMiniportDMusUART' which has non-virtual destructor might cause undefined behaviour [-Wdelete-non-virtual-dtor] /reactos/drivers/wdm/audio/backpln/portcls/miniport_dmus.cpp: In member function 'virtual ULONG CMiniportDMusUARTStream::Release()': /reactos/drivers/wdm/audio/backpln/portcls/miniport_dmus.cpp:239:20: warning: deleting object of polymorphic class type 'CMiniportDMusUARTStream' which has non-virtual destructor might cause undefined behaviour [-Wdelete-non-virtual-dtor] /reactos/drivers/wdm/audio/backpln/portcls/miniport_dmus.cpp: In function 'NTSTATUS NewMiniportDMusUART(IMiniport**, const CLSID&)': /reactos/drivers/wdm/audio/backpln/portcls/miniport_dmus.cpp:1274:16: warning: deleting object of polymorphic class type 'CMiniportDMusUART' which has non-virtual destructor might cause undefined behaviour [-Wdelete-non-virtual-dtor]

1 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 53823: [KERNEL32] Simplify overcomplicated function CreateHardlinkW(), and SEHify it.
by Alex Ionescu 24 Sep '11

24 Sep '11

Why are you putting SEH everywhere??? Just to avoid goto? This is infinitely retarded. Exceptions should not be used as a mechanism for flow control. Best regards, Alex Ionescu On Sat, Sep 24, 2011 at 3:51 AM, <pschweitzer(a)svn.reactos.org> wrote: > Author: pschweitzer > Date: Sat Sep 24 07:51:21 2011 > New Revision: 53823 > > URL: http://svn.reactos.org/svn/reactos?rev=53823&view=rev > Log: > [KERNEL32] > Simplify overcomplicated function CreateHardlinkW(), and SEHify it. > > Modified: > trunk/reactos/dll/win32/kernel32/client/file/hardlink.c > > Modified: trunk/reactos/dll/win32/kernel32/client/file/hardlink.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/… > > ============================================================================== > --- trunk/reactos/dll/win32/kernel32/client/file/hardlink.c [iso-8859-1] > (original) > +++ trunk/reactos/dll/win32/kernel32/client/file/hardlink.c [iso-8859-1] > Sat Sep 24 07:51:21 2011 > @@ -2,11 +2,10 @@ > * > * COPYRIGHT: See COPYING in the top level directory > * PROJECT: ReactOS system libraries > - * FILE: lib/kernel32/file/hardlink.c > + * FILE: dll/win32/kernel32/client/file/hardlink.c > * PURPOSE: Hardlink functions > * PROGRAMMER: Thomas Weidenmueller (w3seek(a)users.sourceforge.net) > - * UPDATE HISTORY: > - * Created 13/03/2004 > + * Pierre Schweitzer (pierre.schweitzer(a)reactos.org) > */ > > /* INCLUDES > *****************************************************************/ > @@ -27,169 +26,110 @@ > LPCWSTR lpExistingFileName, > LPSECURITY_ATTRIBUTES lpSecurityAttributes) > { > - UNICODE_STRING LinkTarget, LinkName; > - LPVOID lpSecurityDescriptor; > - PFILE_LINK_INFORMATION LinkInformation; > - IO_STATUS_BLOCK IoStatus; > - NTSTATUS Status; > - BOOL Ret = FALSE; > + NTSTATUS Status; > + BOOL Ret = FALSE; > + ULONG NeededSize; > + IO_STATUS_BLOCK IoStatusBlock; > + OBJECT_ATTRIBUTES ObjectAttributes; > + HANDLE hTarget = INVALID_HANDLE_VALUE; > + PFILE_LINK_INFORMATION LinkInformation = NULL; > + UNICODE_STRING LinkTarget = {0, 0, NULL}, LinkName = {0, 0, NULL}; > > - if(!lpFileName || !lpExistingFileName) > - { > - SetLastError(ERROR_INVALID_PARAMETER); > - return FALSE; > - } > + TRACE("CreateHardLinkW: %S, %S, %p\n", lpFileName, lpExistingFileName, > lpSecurityAttributes); > > - lpSecurityDescriptor = (lpSecurityAttributes ? > lpSecurityAttributes->lpSecurityDescriptor : NULL); > + /* Validate parameters */ > + if(!lpFileName || !lpExistingFileName) > + { > + SetLastError(ERROR_INVALID_PARAMETER); > + return FALSE; > + } > > - if(RtlDetermineDosPathNameType_U((LPWSTR)lpFileName) == 1 || > - RtlDetermineDosPathNameType_U((LPWSTR)lpExistingFileName) == 1) > - { > - WARN("CreateHardLinkW() cannot handle UNC Paths!\n"); > - SetLastError(ERROR_INVALID_NAME); > - return FALSE; > - } > + _SEH2_TRY > + { > + /* Get target UNC path */ > + if (!RtlDosPathNameToNtPathName_U(lpExistingFileName, &LinkTarget, > NULL, NULL)) > + { > + SetLastError(ERROR_PATH_NOT_FOUND); > + _SEH2_LEAVE; > + } > > - if(RtlDosPathNameToNtPathName_U(lpExistingFileName, &LinkTarget, NULL, > NULL)) > - { > - ULONG NeededSize = RtlGetFullPathName_U((LPWSTR)lpExistingFileName, 0, > NULL, NULL); > - if(NeededSize > 0) > + /* Open target */ > + InitializeObjectAttributes(&ObjectAttributes, > + &LinkTarget, > + OBJ_CASE_INSENSITIVE, > + NULL, > + (lpSecurityAttributes ? > lpSecurityAttributes->lpSecurityDescriptor : NULL)); > + > + Status = NtOpenFile(&hTarget, > + SYNCHRONIZE | FILE_WRITE_ATTRIBUTES, > + &ObjectAttributes, > + &IoStatusBlock, > + FILE_SHARE_READ | FILE_SHARE_WRITE | > FILE_SHARE_DELETE, > + FILE_SYNCHRONOUS_IO_NONALERT | > FILE_OPEN_REPARSE_POINT); > + if (!NT_SUCCESS(Status)) > + { > + BaseSetLastNTError(Status); > + _SEH2_LEAVE; > + } > + > + /* Get UNC path name for link */ > + if (!RtlDosPathNameToNtPathName_U(lpFileName, &LinkName, NULL, > NULL)) > + { > + SetLastError(ERROR_PATH_NOT_FOUND); > + _SEH2_LEAVE; > + } > + > + /* Prepare data for link */ > + NeededSize = sizeof(FILE_LINK_INFORMATION) + LinkName.Length; > + LinkInformation = RtlAllocateHeap(RtlGetProcessHeap(), 0, > NeededSize); > + if (!LinkInformation) > + { > + SetLastError(ERROR_NOT_ENOUGH_MEMORY); > + _SEH2_LEAVE; > + } > + > + RtlMoveMemory(LinkInformation->FileName, LinkName.Buffer, > LinkName.Length); > + LinkInformation->ReplaceIfExists = FALSE; > + LinkInformation->RootDirectory = 0; > + LinkInformation->FileNameLength = LinkName.Length; > + > + /* Create hard link */ > + Status = NtSetInformationFile(hTarget, > + &IoStatusBlock, > + LinkInformation, > + NeededSize, > + FileLinkInformation); > + if (NT_SUCCESS(Status)) > + { > + Ret = TRUE; > + } > + } > + _SEH2_FINALLY > { > - LPWSTR lpNtLinkTarget = RtlAllocateHeap(RtlGetProcessHeap(), > HEAP_ZERO_MEMORY, NeededSize * sizeof(WCHAR)); > - if(lpNtLinkTarget != NULL) > - { > - LPWSTR lpFilePart; > + if (LinkTarget.Buffer) > + { > + RtlFreeHeap(RtlGetProcessHeap(), 0, LinkTarget.Buffer); > + } > > - if(RtlGetFullPathName_U((LPWSTR)lpExistingFileName, NeededSize, > lpNtLinkTarget, &lpFilePart) && > - (*lpNtLinkTarget) != L'\0') > + if (hTarget != INVALID_HANDLE_VALUE) > { > - UNICODE_STRING CheckDrive, LinkDrive; > - WCHAR wCheckDrive[10]; > + NtClose(hTarget); > + } > > - swprintf(wCheckDrive, L"\\??\\%c:", (WCHAR)(*lpNtLinkTarget)); > - RtlInitUnicodeString(&CheckDrive, wCheckDrive); > + if (LinkName.Buffer) > + { > + RtlFreeHeap(RtlGetProcessHeap(), 0, LinkName.Buffer); > + } > > - RtlZeroMemory(&LinkDrive, sizeof(UNICODE_STRING)); > + if (LinkInformation) > + { > + RtlFreeHeap(RtlGetProcessHeap(), 0, LinkInformation); > + } > + } > + _SEH2_END; > > - LinkDrive.Buffer = RtlAllocateHeap(RtlGetProcessHeap(), > HEAP_ZERO_MEMORY, (MAX_PATH + 1) * sizeof(WCHAR)); > - if(LinkDrive.Buffer != NULL) > - { > - HANDLE hFile, hTarget; > - OBJECT_ATTRIBUTES ObjectAttributes; > - > - InitializeObjectAttributes(&ObjectAttributes, > - &CheckDrive, > - OBJ_CASE_INSENSITIVE, > - NULL, > - NULL); > - > - Status = NtOpenSymbolicLinkObject(&hFile, 1, > &ObjectAttributes); > - if(NT_SUCCESS(Status)) > - { > - UNICODE_STRING LanManager; > - > - RtlInitUnicodeString(&LanManager, > L"\\Device\\LanmanRedirector\\"); > - > - NtQuerySymbolicLinkObject(hFile, &LinkDrive, NULL); > - > - if(!RtlPrefixUnicodeString(&LanManager, &LinkDrive, TRUE)) > - { > - InitializeObjectAttributes(&ObjectAttributes, > - &LinkTarget, > - OBJ_CASE_INSENSITIVE, > - NULL, > - lpSecurityDescriptor); > - Status = NtOpenFile(&hTarget, > - SYNCHRONIZE | DELETE, > - &ObjectAttributes, > - &IoStatus, > - FILE_SHARE_READ | FILE_SHARE_WRITE | > FILE_SHARE_DELETE, > - FILE_SYNCHRONOUS_IO_NONALERT | > FILE_OPEN_FOR_BACKUP_INTENT | FILE_OPEN_REPARSE_POINT); > - if(NT_SUCCESS(Status)) > - { > - if(RtlDosPathNameToNtPathName_U(lpFileName, &LinkName, > NULL, NULL)) > - { > - NeededSize = sizeof(FILE_LINK_INFORMATION) + > LinkName.Length + sizeof(WCHAR); > - LinkInformation = RtlAllocateHeap(RtlGetProcessHeap(), > HEAP_ZERO_MEMORY, NeededSize); > - if(LinkInformation != NULL) > - { > - LinkInformation->ReplaceIfExists = FALSE; > - LinkInformation->RootDirectory = 0; > - LinkInformation->FileNameLength = LinkName.Length; > - RtlCopyMemory(LinkInformation->FileName, > LinkName.Buffer, LinkName.Length); > - > - Status = NtSetInformationFile(hTarget, &IoStatus, > LinkInformation, NeededSize, FileLinkInformation); > - if(NT_SUCCESS(Status)) > - { > - Ret = TRUE; > - } > - else > - { > - BaseSetLastNTError(Status); > - } > - > - RtlFreeHeap(RtlGetProcessHeap(), 0, > LinkInformation); > - } > - else > - { > - SetLastError(ERROR_NOT_ENOUGH_MEMORY); > - } > - } > - else > - { > - SetLastError(ERROR_PATH_NOT_FOUND); > - } > - NtClose(hTarget); > - } > - else > - { > - WARN("Unable to open link destination \"%wZ\"!\n", > &LinkTarget); > - BaseSetLastNTError(Status); > - } > - } > - else > - { > - WARN("Path \"%wZ\" must not be a mapped drive!\n", > &LinkDrive); > - SetLastError(ERROR_INVALID_NAME); > - } > - > - NtClose(hFile); > - } > - else > - { > - BaseSetLastNTError(Status); > - } > - } > - else > - { > - SetLastError(ERROR_NOT_ENOUGH_MEMORY); > - } > - } > - else > - { > - SetLastError(ERROR_INVALID_NAME); > - } > - RtlFreeHeap(RtlGetProcessHeap(), 0, lpNtLinkTarget); > - } > - else > - { > - SetLastError(ERROR_NOT_ENOUGH_MEMORY); > - } > - } > - else > - { > - SetLastError(ERROR_INVALID_NAME); > - } > - RtlFreeHeap(RtlGetProcessHeap(), 0, LinkTarget.Buffer); > - } > - else > - { > - SetLastError(ERROR_PATH_NOT_FOUND); > - } > - > - return Ret; > + return Ret; > } > - > > /* > * @implemented > @@ -199,26 +139,32 @@ > LPCSTR lpExistingFileName, > LPSECURITY_ATTRIBUTES lpSecurityAttributes) > { > - PWCHAR FileNameW, ExistingFileNameW; > - BOOL Ret; > + BOOL Ret; > + PUNICODE_STRING lpFileNameW; > + UNICODE_STRING ExistingFileNameW; > > - if(!lpFileName || !lpExistingFileName) > - { > - SetLastError(ERROR_INVALID_PARAMETER); > - return FALSE; > - } > + lpFileNameW = Basep8BitStringToStaticUnicodeString(lpFileName); > + if (!lpFileNameW) > + { > + return FALSE; > + } > > - if (!(FileNameW = FilenameA2W(lpFileName, FALSE))) > - return FALSE; > + if (!lpExistingFileName) > + { > + SetLastError(ERROR_INVALID_PARAMETER); > + return FALSE; > + } > > - if (!(ExistingFileNameW = FilenameA2W(lpExistingFileName, TRUE))) > - return FALSE; > + if (!Basep8BitStringToDynamicUnicodeString(&ExistingFileNameW, > lpExistingFileName)) > + { > + return FALSE; > + } > > - Ret = CreateHardLinkW(FileNameW , ExistingFileNameW , > lpSecurityAttributes); > + Ret = CreateHardLinkW(lpFileNameW->Buffer, ExistingFileNameW.Buffer, > lpSecurityAttributes); > > - RtlFreeHeap(RtlGetProcessHeap(), 0, ExistingFileNameW); > + RtlFreeHeap(RtlGetProcessHeap(), 0, ExistingFileNameW.Buffer); > > - return Ret; > + return Ret; > } > > /* EOF */ > > >

1 0

Problem with new BE release candidate
by caemyr＠myopera.com 22 Sep '11

22 Sep '11

Windows cmake builder is running new BE since yesterday. First thing that i noticed, is the increase of buildtime. Previous version was consistent around 5 minutes, the new candidate - more than 7. I doublechecked it by swapping BE's back and forth. This might look not serious, but if this problem scales up, we are talking about 35 minutes of buildtime for someone who needed 25 minutes previously. -- With best regards Caemyr

1 0

[ros-diffs] [gadamopoulos] 52716: [win32k] - Fix TrackMouseEvent. Now hot tracking really works
by James Tabor 20 Sep '11

20 Sep '11

If it passes all the wine tests w/o the intermittent hits and misses! SYNC it to HEAD!

1 1

Re: [ros-dev] [ros-diffs] [dgorbachev] 53730: [CMAKE] Allow to specify prefix/suffix for GCC and Binutils.
by Jérôme Gardou 20 Sep '11

20 Sep '11

Hello. May I ask why you removed the -nodefaultlibs flag? Regards. Jérôme. Le 18/09/2011 02:57, dgorbachev(a)svn.reactos.org a écrit : > Author: dgorbachev > Date: Sun Sep 18 00:57:17 2011 > New Revision: 53730 > > URL: http://svn.reactos.org/svn/reactos?rev=53730&view=rev > Log: > [CMAKE] > Allow to specify prefix/suffix for GCC and Binutils. > > Modified: > trunk/reactos/cmake/gcc.cmake > trunk/reactos/lib/3rdparty/mingw/CMakeLists.txt > trunk/reactos/lib/sdk/crt/oldnames.cmake > trunk/reactos/toolchain-gcc.cmake > > Modified: trunk/reactos/cmake/gcc.cmake > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/cmake/gcc.cmake?rev=53730&… > ============================================================================== > --- trunk/reactos/cmake/gcc.cmake [iso-8859-1] (original) > +++ trunk/reactos/cmake/gcc.cmake [iso-8859-1] Sun Sep 18 00:57:17 2011 > @@ -86,7 +86,7 @@ > > set(CMAKE_CXX_LINK_EXECUTABLE "<CMAKE_CXX_COMPILER> <CMAKE_CXX_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o<TARGET> <LINK_LIBRARIES>") > > -set(CMAKE_EXE_LINKER_FLAGS "-nodefaultlibs -nostdlib -Wl,--enable-auto-image-base -Wl,--disable-auto-import -Wl,--disable-stdcall-fixup") > +set(CMAKE_EXE_LINKER_FLAGS "-nostdlib -Wl,--enable-auto-image-base,--disable-auto-import,--disable-stdcall-fixup") > > set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS_INIT} -Wl,--disable-stdcall-fixup") > > @@ -134,7 +134,7 @@ > endif() > > if(${TYPE} STREQUAL kernelmodedriver) > - add_target_link_flags(${MODULE} "-Wl,--exclude-all-symbols -Wl,-file-alignment=0x1000 -Wl,-section-alignment=0x1000") > + add_target_link_flags(${MODULE} "-Wl,--exclude-all-symbols,-file-alignment=0x1000,-section-alignment=0x1000") > endif() > endfunction() > > @@ -190,25 +190,25 @@ > add_custom_command( > OUTPUT ${CMAKE_BINARY_DIR}/importlibs/lib${_name}.a > COMMAND native-spec2def -n=${_name}${_suffix} -a=${ARCH2} -d=${CMAKE_CURRENT_BINARY_DIR}/${_name}_implib.def ${CMAKE_CURRENT_SOURCE_DIR}/${_exports_file} > - COMMAND ${MINGW_PREFIX}dlltool --def ${CMAKE_CURRENT_BINARY_DIR}/${_name}_implib.def --kill-at --output-lib=${CMAKE_BINARY_DIR}/importlibs/lib${_name}.a > + COMMAND ${CMAKE_DLLTOOL} --def ${CMAKE_CURRENT_BINARY_DIR}/${_name}_implib.def --kill-at --output-lib=${CMAKE_BINARY_DIR}/importlibs/lib${_name}.a > DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${_exports_file} native-spec2def) > > # Delayed importlib creation > add_custom_command( > OUTPUT ${CMAKE_BINARY_DIR}/importlibs/lib${_name}_delayed.a > COMMAND native-spec2def -n=${_name}${_suffix} -a=${ARCH2} -d=${CMAKE_CURRENT_BINARY_DIR}/${_name}_delayed_implib.def ${CMAKE_CURRENT_SOURCE_DIR}/${_exports_file} > - COMMAND ${MINGW_PREFIX}dlltool --def ${CMAKE_CURRENT_BINARY_DIR}/${_name}_delayed_implib.def --kill-at --output-delaylib ${CMAKE_BINARY_DIR}/importlibs/lib${_name}_delayed.a > + COMMAND ${CMAKE_DLLTOOL} --def ${CMAKE_CURRENT_BINARY_DIR}/${_name}_delayed_implib.def --kill-at --output-delaylib ${CMAKE_BINARY_DIR}/importlibs/lib${_name}_delayed.a > DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${_exports_file} native-spec2def) > > elseif(${_extension} STREQUAL ".def") > message("Use of def files for import libs is deprecated: ${_exports_file}") > add_custom_command( > OUTPUT ${CMAKE_BINARY_DIR}/importlibs/lib${_name}.a > - COMMAND ${MINGW_PREFIX}dlltool --def ${CMAKE_CURRENT_SOURCE_DIR}/${_exports_file} --kill-at --output-lib=${CMAKE_BINARY_DIR}/importlibs/lib${_name}.a > + COMMAND ${CMAKE_DLLTOOL} --def ${CMAKE_CURRENT_SOURCE_DIR}/${_exports_file} --kill-at --output-lib=${CMAKE_BINARY_DIR}/importlibs/lib${_name}.a > DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${_exports_file}) > add_custom_command( > OUTPUT ${CMAKE_BINARY_DIR}/importlibs/lib${_name}_delayed.a > - COMMAND ${MINGW_PREFIX}dlltool --def ${CMAKE_CURRENT_SOURCE_DIR}/${_exports_file} --kill-at --output-delaylib ${CMAKE_BINARY_DIR}/importlibs/lib${_name}_delayed.a > + COMMAND ${CMAKE_DLLTOOL} --def ${CMAKE_CURRENT_SOURCE_DIR}/${_exports_file} --kill-at --output-delaylib ${CMAKE_BINARY_DIR}/importlibs/lib${_name}_delayed.a > DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${_exports_file}) > else() > message(FATAL_ERROR "Unsupported exports file extension: ${_extension}") > @@ -243,7 +243,7 @@ > endfunction() > > macro(macro_mc FILE) > - set(COMMAND_MC ${MINGW_PREFIX}windmc -A -b ${CMAKE_CURRENT_SOURCE_DIR}/${FILE}.mc -r ${REACTOS_BINARY_DIR}/include/reactos -h ${REACTOS_BINARY_DIR}/include/reactos) > + set(COMMAND_MC ${CMAKE_MC_COMPILER} -A -b ${CMAKE_CURRENT_SOURCE_DIR}/${FILE}.mc -r ${REACTOS_BINARY_DIR}/include/reactos -h ${REACTOS_BINARY_DIR}/include/reactos) > endmacro() > > #pseh lib, needed with mingw > > Modified: trunk/reactos/lib/3rdparty/mingw/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/3rdparty/mingw/CMakeLi… > ============================================================================== > --- trunk/reactos/lib/3rdparty/mingw/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/lib/3rdparty/mingw/CMakeLists.txt [iso-8859-1] Sun Sep 18 00:57:17 2011 > @@ -65,8 +65,7 @@ > if(NOT MSVC) > add_custom_command( > OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/liboldnames.a > - COMMAND ${MINGW_PREFIX}dlltool --def ${CMAKE_CURRENT_SOURCE_DIR}/moldname-msvcrt.def --kill-at --output-lib ${CMAKE_CURRENT_BINARY_DIR}/liboldnames.a > - COMMAND ${MINGW_PREFIX}ar -rc ${CMAKE_CURRENT_BINARY_DIR}/liboldnames.a) > + COMMAND ${CMAKE_DLLTOOL} --def ${CMAKE_CURRENT_SOURCE_DIR}/moldname-msvcrt.def --kill-at --output-lib ${CMAKE_CURRENT_BINARY_DIR}/liboldnames.a) > > set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/liboldnames.a PROPERTIES GENERATED TRUE) > > > Modified: trunk/reactos/lib/sdk/crt/oldnames.cmake > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/sdk/crt/oldnames.cmake… > ============================================================================== > --- trunk/reactos/lib/sdk/crt/oldnames.cmake [iso-8859-1] (original) > +++ trunk/reactos/lib/sdk/crt/oldnames.cmake [iso-8859-1] Sun Sep 18 00:57:17 2011 > @@ -1,8 +1,7 @@ > if(NOT MSVC) > add_custom_command( > OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/liboldnames.a > - COMMAND ${MINGW_PREFIX}dlltool --def ${CMAKE_CURRENT_SOURCE_DIR}/moldname-msvcrt.def --kill-at --output-lib ${CMAKE_CURRENT_BINARY_DIR}/liboldnames.a > - COMMAND ${MINGW_PREFIX}ar -rc ${CMAKE_CURRENT_BINARY_DIR}/liboldnames.a) > + COMMAND ${CMAKE_DLLTOOL} --def ${CMAKE_CURRENT_SOURCE_DIR}/moldname-msvcrt.def --kill-at --output-lib ${CMAKE_CURRENT_BINARY_DIR}/liboldnames.a) > > set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/liboldnames.a PROPERTIES GENERATED TRUE) > > > Modified: trunk/reactos/toolchain-gcc.cmake > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/toolchain-gcc.cmake?rev=53… > ============================================================================== > --- trunk/reactos/toolchain-gcc.cmake [iso-8859-1] (original) > +++ trunk/reactos/toolchain-gcc.cmake [iso-8859-1] Sun Sep 18 00:57:17 2011 > @@ -3,19 +3,25 @@ > set(ARCH i386) > endif() > > -# Choose the right MinGW prefix > -if(ARCH MATCHES i386) > +# Choose the right MinGW toolchain prefix > +if (NOT DEFINED MINGW_TOOLCHAIN_PREFIX) > + if(ARCH MATCHES i386) > > - if(CMAKE_HOST_SYSTEM_NAME MATCHES Windows) > - set(MINGW_PREFIX "" CACHE STRING "MinGW Prefix") > - else() > - set(MINGW_PREFIX "mingw32-" CACHE STRING "MinGW Prefix") > - endif(CMAKE_HOST_SYSTEM_NAME MATCHES Windows) > + if(CMAKE_HOST_SYSTEM_NAME MATCHES Windows) > + set(MINGW_TOOLCHAIN_PREFIX "" CACHE STRING "MinGW Toolchain Prefix") > + else() > + set(MINGW_TOOLCHAIN_PREFIX "mingw32-" CACHE STRING "MinGW Toolchain Prefix") > + endif(CMAKE_HOST_SYSTEM_NAME MATCHES Windows) > > -elseif(ARCH MATCHES amd64) > - set(MINGW_PREFIX "x86_64-w64-mingw32-" CACHE STRING "MinGW Prefix") > -elseif(ARCH MATCHES arm) > - set(MINGW_PREFIX "arm-mingw32ce-" CACHE STRING "MinGW Prefix") > + elseif(ARCH MATCHES amd64) > + set(MINGW_TOOLCHAIN_PREFIX "x86_64-w64-mingw32-" CACHE STRING "MinGW Toolchain Prefix") > + elseif(ARCH MATCHES arm) > + set(MINGW_TOOLCHAIN_PREFIX "arm-mingw32ce-" CACHE STRING "MinGW Toolchain Prefix") > + endif() > +endif() > + > +if (NOT DEFINED MINGW_TOOLCHAIN_SUFFIX) > + set(MINGW_TOOLCHAIN_SUFFIX "" CACHE STRING "MinGW Toolchain Suffix") > endif() > > if(ENABLE_CCACHE) > @@ -28,11 +34,13 @@ > set(CMAKE_SYSTEM_NAME Windows) > set(CMAKE_SYSTEM_PROCESSOR i686) > > -# Which compilers to use for C and C++ > -set(CMAKE_C_COMPILER ${CCACHE} ${MINGW_PREFIX}gcc) > -set(CMAKE_CXX_COMPILER ${CCACHE} ${MINGW_PREFIX}g++) > -set(CMAKE_RC_COMPILER ${MINGW_PREFIX}windres) > -set(CMAKE_ASM_COMPILER ${MINGW_PREFIX}gcc) > +# Which tools to use > +set(CMAKE_C_COMPILER ${CCACHE} ${MINGW_TOOLCHAIN_PREFIX}gcc${MINGW_TOOLCHAIN_SUFFIX}) > +set(CMAKE_CXX_COMPILER ${CCACHE} ${MINGW_TOOLCHAIN_PREFIX}g++${MINGW_TOOLCHAIN_SUFFIX}) > +set(CMAKE_ASM_COMPILER ${MINGW_TOOLCHAIN_PREFIX}gcc${MINGW_TOOLCHAIN_SUFFIX}) > +set(CMAKE_MC_COMPILER ${MINGW_TOOLCHAIN_PREFIX}windmc) > +set(CMAKE_RC_COMPILER ${MINGW_TOOLCHAIN_PREFIX}windres) > +set(CMAKE_DLLTOOL ${MINGW_TOOLCHAIN_PREFIX}dlltool) > > if(NOT CMAKE_HOST_SYSTEM_NAME MATCHES Windows) > set(CMAKE_C_CREATE_STATIC_LIBRARY "<CMAKE_AR> crs<TARGET> <LINK_FLAGS> <OBJECTS>") > @@ -46,4 +54,4 @@ > #MARK_AS_ADVANCED(CLEAR CMAKE_CXX_STANDARD_LIBRARIES) > set(CMAKE_CXX_STANDARD_LIBRARIES "" CACHE STRING "Standard C++ Libraries") > > -set(CMAKE_SHARED_LINKER_FLAGS_INIT "-nodefaultlibs -nostdlib -Wl,--enable-auto-image-base -Wl,--disable-auto-import") > +set(CMAKE_SHARED_LINKER_FLAGS_INIT "-nostdlib -Wl,--enable-auto-image-base,--disable-auto-import") > >

2 1

Re: [ros-dev] [ros-diffs] [rmessiant] 53729: [NTOSKRNL] Disable normal APC delivery while acquiring/releasing a heap lock. Also, BOOLEAN != NTSTATUS.
by Timo Kreuzer 19 Sep '11

19 Sep '11

Am 17.09.2011 22:26, schrieb rmessiant(a)svn.reactos.org: > Author: rmessiant > Date: Sat Sep 17 20:26:31 2011 > New Revision: 53729 > > URL: http://svn.reactos.org/svn/reactos?rev=53729&view=rev > Log: > [NTOSKRNL] > Disable normal APC delivery while acquiring/releasing a heap lock. Also, BOOLEAN != NTSTATUS. > > > Modified: > trunk/reactos/ntoskrnl/rtl/libsupp.c > > Modified: trunk/reactos/ntoskrnl/rtl/libsupp.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/rtl/libsupp.c?rev… > ============================================================================== > --- trunk/reactos/ntoskrnl/rtl/libsupp.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/rtl/libsupp.c [iso-8859-1] Sat Sep 17 20:26:31 2011 > @@ -168,7 +168,10 @@ > RtlEnterHeapLock( > PHEAP_LOCK Lock) > { > - return ExAcquireResourceExclusive(&Lock->Resource, TRUE); > + KeEnterCriticalRegion(); > + ExAcquireResourceExclusive(&Lock->Resource, TRUE); > + KeLeaveCriticalRegion(); > + return STATUS_SUCCESS; > } > > NTSTATUS > @@ -185,7 +188,9 @@ > RtlLeaveHeapLock( > PHEAP_LOCK Lock) > { > + KeEnterCriticalRegion(); > ExReleaseResource(&Lock->Resource); > + KeLeaveCriticalRegion(); > return STATUS_SUCCESS; > } > Why enable APC delivery after the resource is acquired? It should stay disabled to prevent deadlocks.

3 2

IServ secured access
by Pierre Schweitzer 18 Sep '11

18 Sep '11

Hi, small note to inform people who were having issues connecting to secured IServ services due to wrong SSL certificate (issued for the wrong address) that the certificate has been renewed today and the issues are gone. Regards, Pierre

2 2

Re: [ros-dev] [ros-diffs] [tkreuzer] 53695: [HAL] Implement lazy irql for APIC. This is useful for VMs, since APIC usually has high overhead due to the need of invoking the hypervisor on every irql raise and lower. With laz...
by Alex Ionescu 12 Sep '11

12 Sep '11

http://blogs.technet.com/b/askperf/archive/2010/07/23/windows-xp-guests-exh… Windows does have APIC Lazy IRQL, Microsoft are not idiots. Best regards, Alex Ionescu On Mon, Sep 12, 2011 at 2:46 AM, <tkreuzer(a)svn.reactos.org> wrote: > Author: tkreuzer > Date: Mon Sep 12 09:46:20 2011 > New Revision: 53695 > > URL: http://svn.reactos.org/svn/reactos?rev=53695&view=rev > Log: > [HAL] > Implement lazy irql for APIC. This is useful for VMs, since APIC usually > has high overhead due to the need of invoking the hypervisor on every irql > raise and lower. With lazy irql we avoid that until absolutely neccessary. > Note that we misuse the PCR's IRR field to save the current hardware irql. > Its a huge performance boost (some parts take half the time), making APIC > performance close to PIC performance on VBox. This is something that Windows > doesn't have :) > > Modified: > trunk/reactos/hal/halx86/apic/apic.c > trunk/reactos/hal/halx86/apic/rtctimer.c > > Modified: trunk/reactos/hal/halx86/apic/apic.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/apic/apic.c?rev… > > ============================================================================== > --- trunk/reactos/hal/halx86/apic/apic.c [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/apic/apic.c [iso-8859-1] Mon Sep 12 09:46:20 > 2011 > @@ -17,6 +17,8 @@ > > #include "apic.h" > void HackEoi(void); > + > +#define APIC_LAZY_IRQL > > /* GLOBALS > ********************************************************************/ > > @@ -105,6 +107,46 @@ > > VOID > FORCEINLINE > +ApicWriteIORedirectionEntry( > + UCHAR Index, > + IOAPIC_REDIRECTION_REGISTER ReDirReg) > +{ > + IOApicWrite(IOAPIC_REDTBL + 2 * Index, ReDirReg.Long0); > + IOApicWrite(IOAPIC_REDTBL + 2 * Index + 1, ReDirReg.Long1); > +} > + > +IOAPIC_REDIRECTION_REGISTER > +FORCEINLINE > +ApicReadIORedirectionEntry( > + UCHAR Index) > +{ > + IOAPIC_REDIRECTION_REGISTER ReDirReg; > + > + ReDirReg.Long0 = IOApicRead(IOAPIC_REDTBL + 2 * Index); > + ReDirReg.Long1 = IOApicRead(IOAPIC_REDTBL + 2 * Index + 1); > + > + return ReDirReg; > +} > + > +VOID > +FORCEINLINE > +ApicRequestInterrupt(IN UCHAR Vector) > +{ > + APIC_COMMAND_REGISTER CommandRegister; > + > + /* Setup the command register */ > + CommandRegister.Long0 = 0; > + CommandRegister.Vector = Vector; > + CommandRegister.MessageType = APIC_MT_Fixed; > + CommandRegister.TriggerMode = APIC_TGM_Edge; > + CommandRegister.DestinationShortHand = APIC_DSH_Self; > + > + /* Write the low dword to send the interrupt */ > + ApicWrite(APIC_ICR0, CommandRegister.Long0); > +} > + > +VOID > +FORCEINLINE > ApicSendEOI(void) > { > //ApicWrite(APIC_EOI, 0); > @@ -125,6 +167,12 @@ > { > #ifdef _M_AMD64 > return (KIRQL)__readcr8(); > +#elif defined(APIC_LAZY_IRQL) > + // HACK: some magic to Sync VBox's APIC registers > + ApicRead(APIC_VER); > + > + /* Return the field in the PCR */ > + return (KIRQL)__readfsbyte(FIELD_OFFSET(KPCR, Irql)); > #else > // HACK: some magic to Sync VBox's APIC registers > ApicRead(APIC_VER); > @@ -136,16 +184,42 @@ > > VOID > FORCEINLINE > -ApicSetCurrentIrql(KIRQL Irql) > +ApicRaiseIrql(KIRQL Irql) > { > #ifdef _M_AMD64 > __writecr8(Irql); > +#elif defined(APIC_LAZY_IRQL) > + __writefsbyte(FIELD_OFFSET(KPCR, Irql), Irql); > #else > /* Convert IRQL and write the TPR */ > ApicWrite(APIC_TPR, IrqlToTpr(Irql)); > #endif > } > > +VOID > +FORCEINLINE > +ApicLowerIrql(KIRQL Irql) > +{ > +#ifdef _M_AMD64 > + __writecr8(Irql); > +#elif defined(APIC_LAZY_IRQL) > + __writefsbyte(FIELD_OFFSET(KPCR, Irql), Irql); > + > + /* Is the new Irql lower than set in the TPR? */ > + if (Irql < KeGetPcr()->IRR) > + { > + /* Save the new hard IRQL in the IRR field */ > + KeGetPcr()->IRR = Irql; > + > + /* Need to lower it back */ > + ApicWrite(APIC_TPR, IrqlToTpr(Irql)); > + } > +#else > + /* Convert IRQL and write the TPR */ > + ApicWrite(APIC_TPR, IrqlToTpr(Irql)); > +#endif > +} > + > UCHAR > FASTCALL > HalpIrqToVector(UCHAR Irq) > @@ -171,6 +245,13 @@ > HalpVectorToIrq(UCHAR Vector) > { > return HalpVectorToIndex[Vector]; > +} > + > +VOID > +NTAPI > +HalpSendEOI(VOID) > +{ > + ApicSendEOI(); > } > > VOID > @@ -311,31 +392,10 @@ > ApicWrite(APIC_ERRLVTR, LvtEntry.Long); > > /* Set the IRQL from the PCR */ > - ApicSetCurrentIrql(KeGetPcr()->Irql); > -} > - > - > -VOID > -FORCEINLINE > -ApicWriteIORedirectionEntry( > - UCHAR Index, > - IOAPIC_REDIRECTION_REGISTER ReDirReg) > -{ > - IOApicWrite(IOAPIC_REDTBL + 2 * Index, ReDirReg.Long0); > - IOApicWrite(IOAPIC_REDTBL + 2 * Index + 1, ReDirReg.Long1); > -} > - > -IOAPIC_REDIRECTION_REGISTER > -FORCEINLINE > -ApicReadIORedirectionEntry( > - UCHAR Index) > -{ > - IOAPIC_REDIRECTION_REGISTER ReDirReg; > - > - ReDirReg.Long0 = IOApicRead(IOAPIC_REDTBL + 2 * Index); > - ReDirReg.Long1 = IOApicRead(IOAPIC_REDTBL + 2 * Index + 1); > - > - return ReDirReg; > + ApicWrite(APIC_TPR, IrqlToTpr(KeGetPcr()->Irql)); > + > + /* Save the new hard IRQL in the IRR field */ > + KeGetPcr()->IRR = KeGetPcr()->Irql; > } > > UCHAR > @@ -486,6 +546,9 @@ > __writeeflags(EFlags); > } > > + > +/* SOFTWARE INTERRUPT TRAPS > ***************************************************/ > + > VOID > DECLSPEC_NORETURN > FASTCALL > @@ -493,17 +556,25 @@ > { > KPROCESSOR_MODE ProcessorMode; > KIRQL OldIrql; > - ASSERT(ApicGetCurrentIrql() < APC_LEVEL); > ASSERT(ApicGetProcessorIrql() == APC_LEVEL); > > /* Enter trap */ > KiEnterInterruptTrap(TrapFrame); > > +#ifdef APIC_LAZY_IRQL > + if (!HalBeginSystemInterrupt(APC_LEVEL, APC_VECTOR, &OldIrql)) > + { > + /* "Spurious" interrupt, exit the interrupt */ > + KiEoiHelper(TrapFrame); > + } > +#else > /* Save the old IRQL */ > OldIrql = ApicGetCurrentIrql(); > + ASSERT(OldIrql < APC_LEVEL); > +#endif > > /* Raise to APC_LEVEL */ > - ApicSetCurrentIrql(APC_LEVEL); > + ApicRaiseIrql(APC_LEVEL); > > /* End the interrupt */ > ApicSendEOI(); > @@ -521,7 +592,7 @@ > _disable(); > > /* Restore the old IRQL */ > - ApicSetCurrentIrql(OldIrql); > + ApicLowerIrql(OldIrql); > > /* Exit the interrupt */ > KiEoiHelper(TrapFrame); > @@ -534,17 +605,25 @@ > HalpDispatchInterruptHandler(IN PKTRAP_FRAME TrapFrame) > { > KIRQL OldIrql; > - ASSERT(ApicGetCurrentIrql() < DISPATCH_LEVEL); > ASSERT(ApicGetProcessorIrql() == DISPATCH_LEVEL); > > /* Enter trap */ > KiEnterInterruptTrap(TrapFrame); > > - /* Save the old IRQL */ > +#ifdef APIC_LAZY_IRQL > + if (!HalBeginSystemInterrupt(DISPATCH_LEVEL, DISPATCH_VECTOR, > &OldIrql)) > + { > + /* "Spurious" interrupt, exit the interrupt */ > + KiEoiHelper(TrapFrame); > + } > +#else > + /* Get the current IRQL */ > OldIrql = ApicGetCurrentIrql(); > + ASSERT(OldIrql < DISPATCH_LEVEL); > +#endif > > /* Raise to DISPATCH_LEVEL */ > - ApicSetCurrentIrql(DISPATCH_LEVEL); > + ApicRaiseIrql(DISPATCH_LEVEL); > > /* End the interrupt */ > ApicSendEOI(); > @@ -555,37 +634,23 @@ > _disable(); > > /* Restore the old IRQL */ > - ApicSetCurrentIrql(OldIrql); > + ApicLowerIrql(OldIrql); > > /* Exit the interrupt */ > KiEoiHelper(TrapFrame); > } > #endif > > -VOID > -NTAPI > -HalpSendEOI(VOID) > -{ > - ApicSendEOI(); > -} > - > -/* PUBLIC FUNCTIONS > ***********************************************************/ > + > +/* SOFTWARE INTERRUPTS > ********************************************************/ > + > > VOID > FASTCALL > HalRequestSoftwareInterrupt(IN KIRQL Irql) > { > - APIC_COMMAND_REGISTER CommandRegister; > - > - /* Setup the command register */ > - CommandRegister.Long0 = 0; > - CommandRegister.Vector = IrqlToTpr(Irql); > - CommandRegister.MessageType = APIC_MT_Fixed; > - CommandRegister.TriggerMode = APIC_TGM_Edge; > - CommandRegister.DestinationShortHand = APIC_DSH_Self; > - > - /* Write the low dword to send the interrupt */ > - ApicWrite(APIC_ICR0, CommandRegister.Long0); > + /* Convert irql to vector and request an interrupt */ > + ApicRequestInterrupt(IrqlToTpr(Irql)); > } > > VOID > @@ -595,6 +660,9 @@ > { > /* Nothing to do */ > } > + > + > +/* SYSTEM INTERRUPTS > **********************************************************/ > > BOOLEAN > NTAPI > @@ -678,11 +746,37 @@ > IN UCHAR Vector, > OUT PKIRQL OldIrql) > { > + KIRQL CurrentIrql; > + > /* Get the current IRQL */ > - *OldIrql = ApicGetCurrentIrql(); > + CurrentIrql = ApicGetCurrentIrql(); > + > +#ifdef APIC_LAZY_IRQL > + /* Check if this interrupt is allowed */ > + if (CurrentIrql >= Irql) > + { > + /* It is not, set the real Irql in the TPR! */ > + ApicWrite(APIC_TPR, IrqlToTpr(CurrentIrql)); > + > + /* Save the new hard IRQL in the IRR field */ > + KeGetPcr()->IRR = CurrentIrql; > + > + /* End this interrupt */ > + ApicSendEOI(); > + > + // FIXME: level interrupts > + /* Re-request the interrupt to be handled later */ > + ApicRequestInterrupt(Vector); > + > + /* Pretend it was a spurious interrupt */ > + return FALSE; > + } > +#endif > + /* Save the current IRQL */ > + *OldIrql = CurrentIrql; > > /* Set the new IRQL */ > - ApicSetCurrentIrql(Irql); > + ApicRaiseIrql(Irql); > > /* Turn on interrupts */ > _enable(); > @@ -701,9 +795,11 @@ > ApicSendEOI(); > > /* Restore the old IRQL */ > - ApicSetCurrentIrql(OldIrql); > -} > - > + ApicLowerIrql(OldIrql); > +} > + > + > +/* IRQL MANAGEMENT > ************************************************************/ > > KIRQL > NTAPI > @@ -726,8 +822,8 @@ > KeBugCheck(IRQL_NOT_LESS_OR_EQUAL); > } > #endif > - /* Convert the new IRQL to a TPR value and write the register */ > - ApicSetCurrentIrql(OldIrql); > + /* Set the new IRQL */ > + ApicLowerIrql(OldIrql); > } > > KIRQL > @@ -748,7 +844,7 @@ > } > #endif > /* Convert the new IRQL to a TPR value and write the register */ > - ApicSetCurrentIrql(NewIrql); > + ApicRaiseIrql(NewIrql); > > /* Return old IRQL */ > return OldIrql; > > Modified: trunk/reactos/hal/halx86/apic/rtctimer.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/apic/rtctimer.c… > > ============================================================================== > --- trunk/reactos/hal/halx86/apic/rtctimer.c [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/apic/rtctimer.c [iso-8859-1] Mon Sep 12 > 09:46:20 2011 > @@ -111,7 +111,7 @@ > KiEnterInterruptTrap(TrapFrame); > > /* Start the interrupt */ > - if (HalBeginSystemInterrupt(CLOCK_LEVEL, PRIMARY_VECTOR_BASE, &Irql)) > + if (HalBeginSystemInterrupt(CLOCK_LEVEL, HalpClockVector, &Irql)) > { > /* Read register C, so that the next interrupt can happen */ > HalpReadCmos(RTC_REGISTER_C);; > > >

2 1

Re: [ros-dev] [ros-diffs] [fireball] 53635: - Downgrade some DPRINT1s to DPRINTs.
by Alex Ionescu 11 Sep '11

11 Sep '11

For the stuff that was obviously designed to warn at least once, have you filled out bug reports for all these missing features, or do you think that someone will now remember all this missing code? Best regards, Alex Ionescu On Thu, Sep 8, 2011 at 9:28 AM, <fireball(a)svn.reactos.org> wrote: > Author: fireball > Date: Thu Sep 8 08:28:41 2011 > New Revision: 53635 > > URL: http://svn.reactos.org/svn/reactos?rev=53635&view=rev > Log: > - Downgrade some DPRINT1s to DPRINTs. > > Modified: > trunk/reactos/dll/ntdll/ldr/ldrapi.c > trunk/reactos/dll/ntdll/ldr/ldrinit.c > trunk/reactos/ntoskrnl/mm/ARM3/procsup.c > trunk/reactos/subsystems/win32/csrss/csrsrv/api/process.c > trunk/reactos/subsystems/win32/csrss/csrsrv/api/wapi.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] Thu Sep 8 08:28:41 > 2011 > @@ -1542,8 +1542,8 @@ > NTAPI > LdrUnloadAlternateResourceModule(IN PVOID BaseAddress) > { > - static BOOLEAN WarnedOnce = FALSE; > - if (WarnedOnce == FALSE) { UNIMPLEMENTED; WarnedOnce = TRUE; } > + //static BOOLEAN WarnedOnce = FALSE; > + //if (WarnedOnce == FALSE) { UNIMPLEMENTED; WarnedOnce = TRUE; } > return FALSE; > } > > > Modified: trunk/reactos/dll/ntdll/ldr/ldrinit.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/ntdll/ldr/ldrinit.c?re… > > ============================================================================== > --- trunk/reactos/dll/ntdll/ldr/ldrinit.c [iso-8859-1] (original) > +++ trunk/reactos/dll/ntdll/ldr/ldrinit.c [iso-8859-1] Thu Sep 8 08:28:41 > 2011 > @@ -728,7 +728,7 @@ > > /* Clear it */ > //Kernel32ProcessInitPostImportfunction = NULL; > - UNIMPLEMENTED; > + //UNIMPLEMENTED; > } > > /* No root entry? return */ > @@ -1988,7 +1988,7 @@ > if (NtHeader->OptionalHeader.Subsystem == IMAGE_SUBSYSTEM_WINDOWS_GUI) > { > /* Load kernel32 and call BasePostImportInit... */ > - DPRINT1("Unimplemented codepath!\n"); > + DPRINT("Unimplemented codepath!\n"); > } > > /* Walk the IAT and load all the DLLs */ > @@ -2095,7 +2095,7 @@ > { > /* Check for Application Compatibility Goo */ > //LdrQueryApplicationCompatibilityGoo(hKey); > - DPRINT1("Querying app compat hacks is missing!\n"); > + DPRINT("Querying app compat hacks is missing!\n"); > } > > /* > > 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] Thu Sep 8 > 08:28:41 2011 > @@ -590,7 +590,7 @@ > ViewShare, > MEM_TOP_DOWN, > PAGE_READONLY); > - DPRINT1("NLS Tables at: %p\n", TableBase); > + DPRINT("NLS Tables at: %p\n", TableBase); > if (!NT_SUCCESS(Status)) > { > /* Cleanup and exit */ > @@ -602,7 +602,7 @@ > // Allocate the PEB > // > Status = MiCreatePebOrTeb(Process, sizeof(PEB), (PULONG_PTR)&Peb); > - DPRINT1("PEB at: %p\n", Peb); > + DPRINT("PEB at: %p\n", Peb); > if (!NT_SUCCESS(Status)) > { > /* Cleanup and exit */ > > Modified: trunk/reactos/subsystems/win32/csrss/csrsrv/api/process.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/csrss/csr… > > ============================================================================== > --- trunk/reactos/subsystems/win32/csrss/csrsrv/api/process.c [iso-8859-1] > (original) > +++ trunk/reactos/subsystems/win32/csrss/csrsrv/api/process.c [iso-8859-1] > Thu Sep 8 08:28:41 2011 > @@ -105,7 +105,7 @@ > PROCESS_ALL_ACCESS, > &ObjectAttributes, > &ClientId); > - DPRINT1("CSR Process: %p Handle: %p\n", pProcessData, > pProcessData->Process); > + DPRINT("CSR Process: %p Handle: %p\n", pProcessData, > pProcessData->Process); > if (!NT_SUCCESS(Status)) > { > ProcessData[hash] = pProcessData->next; > > Modified: trunk/reactos/subsystems/win32/csrss/csrsrv/api/wapi.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/csrss/csr… > > ============================================================================== > --- trunk/reactos/subsystems/win32/csrss/csrsrv/api/wapi.c [iso-8859-1] > (original) > +++ trunk/reactos/subsystems/win32/csrss/csrsrv/api/wapi.c [iso-8859-1] Thu > Sep 8 08:28:41 2011 > @@ -278,8 +278,8 @@ > /* Check if we have a process */ > if (CsrProcess) > { > - /* Map the sectio into this process */ > - DPRINT1("CSR Process Handle: %p. CSR Process: %p\n", > CsrProcess->Process, CsrProcess); > + /* Map the section into this process */ > + DPRINT("CSR Process Handle: %p. CSR Process: %p\n", > CsrProcess->Process, CsrProcess); > Status = NtMapViewOfSection(CsrSrvSharedSection, > CsrProcess->Process, > &CsrSrvSharedSectionBase, > @@ -520,7 +520,7 @@ > Status = CsrSrvAttachSharedSection(ProcessData, ConnectInfo); > if (NT_SUCCESS(Status)) > { > - DPRINT1("Connection ok\n"); > + DPRINT("Connection ok\n"); > AllowConnection = TRUE; > } > else > > >

2 7

Re: [ros-dev] [ros-diffs] [tfaber] 53688: [NTOSKRNL][RTL][DOC] - Fix incorrect loop boundaries in the ARM version of MmCreateProcessAddressSpace. Spotted by Vincenzo Cotugno and cppcheck - Correct outdated wineimport.cmd UR...
by Alex Ionescu 11 Sep '11

11 Sep '11

Sorry but these kinds of fixes are not "readability fixes", in fact they make things more obtuse. (*MdlPages << PAGE_SHIFT)) could be interpreted as *(MdlPages << PAGE_SHIFT). while ((*MdlPages) << PAGE_SHIFT) Makes it clear what is happening. In general, all operations affecting the contents of a *dereference should be in parens. Best regards, Alex Ionescu On Sun, Sep 11, 2011 at 7:47 AM, <tfaber(a)svn.reactos.org> wrote: > - ((*MdlPages) << PAGE_SHIFT)); > + (*MdlPages << PAGE_SHIFT)); >

1 0

PVS-Studio analysis of ReactOS code: error explanations in English
by Minas Abrahamyan 11 Sep '11

11 Sep '11

Hi all, Andrey Karpov of "SiProVer" Ltd (www.viva64.com/ ), the authors of PVS-Studio, a statical source code analyzer/checker wrote (in Russian, this translation is conducted by me): "Have checked source code of ReactOS with PVS-Studio, I fulfilled three wishes of mine at once: Firstly, for a long time I wanted to write an article about ordinary project. It is not so interesting to check source code of such projects as Chromium, It is of too high quality and resources are spending for keeping this level of quality, resources which are unavailable to ordinary projects. Secondly, ReactOS appears to be a good example of project, for which high need of statical analysis of source code can be shown, especially as project being developed with distributed team of developers with diversely different experience. Thirdly, I got confirmation of PVS-Studio getting better and better and more useful all along the way..." Full text of original Russian article is here: http://habrahabr.ru/blogs/os/127493/ titled on Russian as "PVS-Studio: analysing ReactOS operating system source code". Evgeniy Ryzhkov of "SiProVer" adds: "Soon we will translate and publish article on English. But if you have questions now - we are ready for discussion. If some of English-speaking comrades of ReactOS would like to work with errors list, generated with PVS-Studio we have prepared for them translation of errors explanations, here it is: http://www.viva64.com/external-pictures/txt/PVS-Studio-vs-ReactOS-en-unicod… ". Original article refers to long list of generated errors with manually added explanations for errors found by their static checker, so this is translated version of that list. --- Looking backward to few applied patches, it turns out that not all of them were absolutely useful, some patches were reversed, etc. But nevertheless, I think it makes sense to use this tool. They promised to donate some version of PVS-Studio to project, and it is to ROS developers to decide is it worth of taking. What I would suggest: anybody working with some module or part of code can take corresponding part of messages (or in future, possibly check with tool only these parts of interest) and work with them. Also Karpov gave good advise to check newly written code, since it is still of interest to developer: write and time for time test with it. P.S. Disclaimer: I am not in any connection with "SiProVer" Regards, M.A.

1 0

Re: [ros-dev] [ros-diffs] [akhaldi] 53653: [SHELL32] * Reintegrate the c++ shell32 branch. Exemplary team-work.. kudos ! * Better code quality, more tests run with less failures... and more. * Dedicated to everyone who help...
by Ged Murphy 09 Sep '11

09 Sep '11

Nice work guys. It was great to watch you pull this together as a team. Hopefully there's more to come :) -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of akhaldi(a)svn.reactos.org Sent: 09 September 2011 11:55 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [akhaldi] 53653: [SHELL32] * Reintegrate the c++ shell32 branch. Exemplary team-work.. kudos ! * Better code quality, more tests run with less failures... and more. * Dedicated to everyone who help... Author: akhaldi Date: Fri Sep 9 10:55:09 2011 New Revision: 53653 URL: http://svn.reactos.org/svn/reactos?rev=53653&view=rev Log: [SHELL32] * Reintegrate the c++ shell32 branch. Exemplary team-work.. kudos ! * Better code quality, more tests run with less failures... and more. * Dedicated to everyone who helped ;)

1 0

Re: [ros-dev] [ros-diffs] [fireball] 53596: [NTOS/CONFIG] - Remove unnecessary assignments. Spotted by PVS and Dmitry Chapyshev. This may change the behaviour of that codepath, so test results are going to be observed.
by Alex Ionescu 05 Sep '11

05 Sep '11

Uhhhh... Am I really the *only* one who sees a problem here? ChildList = &Kcb->ValueCache; - ChildList = (PCACHED_CHILD_LIST)&KeyNode->ValueList; Best regards, Alex Ionescu On Mon, Sep 5, 2011 at 10:54 AM, <fireball(a)svn.reactos.org> wrote: > Author: fireball > Date: Mon Sep 5 09:54:20 2011 > New Revision: 53596 > > URL: http://svn.reactos.org/svn/reactos?rev=53596&view=rev > Log: > [NTOS/CONFIG] > - Remove unnecessary assignments. Spotted by PVS and Dmitry Chapyshev. This > may change the behaviour of that codepath, so test results are going to be > observed. > > Modified: > trunk/reactos/ntoskrnl/config/cmvalche.c > > Modified: trunk/reactos/ntoskrnl/config/cmvalche.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/config/cmvalche.c… > > ============================================================================== > --- trunk/reactos/ntoskrnl/config/cmvalche.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/config/cmvalche.c [iso-8859-1] Mon Sep 5 > 09:54:20 2011 > @@ -49,7 +49,6 @@ > PHHIVE Hive; > PCACHED_CHILD_LIST ChildList; > HCELL_INDEX CellToRelease; > - PCM_KEY_NODE KeyNode; > > /* Set defaults */ > *ValueListToRelease = HCELL_NIL; > @@ -58,8 +57,6 @@ > /* Get the hive and value cache */ > Hive = Kcb->KeyHive; > ChildList = &Kcb->ValueCache; > - KeyNode = (PCM_KEY_NODE)HvGetCell(Hive, Kcb->KeyCell); > - ChildList = (PCACHED_CHILD_LIST)&KeyNode->ValueList; > > /* Check if the value is cached */ > if (CmpIsValueCached(ChildList->ValueList)) > @@ -212,7 +209,6 @@ > BOOLEAN IndexIsCached; > ULONG i = 0; > HCELL_INDEX Cell = HCELL_NIL; > - PCM_KEY_NODE KeyNode; > > /* Set defaults */ > *CellToRelease = HCELL_NIL; > @@ -221,8 +217,6 @@ > /* Get the hive and child list */ > Hive = Kcb->KeyHive; > ChildList = &Kcb->ValueCache; > - KeyNode = (PCM_KEY_NODE)HvGetCell(Hive, Kcb->KeyCell); > - ChildList = (PCACHED_CHILD_LIST)&KeyNode->ValueList; > > /* Check if the child list has any entries */ > if (ChildList->Count != 0) > > >

3 8

Re: [ros-dev] [ros-diffs] [fireball] 53599: [NTOS] - Fix IoCheckEaBufferValidity (IntEaLength must be signed, otherwise loop exiting condition may not trigger). - SEH-protect ObQueryNameString (by Dmitry Chapyshev's request).
by Alex Ionescu 05 Sep '11

05 Sep '11

Good to know we are now changing good, working code, on people's "request". Best regards, Alex Ionescu On Mon, Sep 5, 2011 at 4:05 PM, <fireball(a)svn.reactos.org> wrote: > Author: fireball > Date: Mon Sep 5 15:05:56 2011 > New Revision: 53599 > > URL: http://svn.reactos.org/svn/reactos?rev=53599&view=rev > Log: > [NTOS] > - Fix IoCheckEaBufferValidity (IntEaLength must be signed, otherwise loop > exiting condition may not trigger). > - SEH-protect ObQueryNameString (by Dmitry Chapyshev's request). > > Modified: > trunk/reactos/ntoskrnl/io/iomgr/util.c > trunk/reactos/ntoskrnl/ob/obname.c > > Modified: trunk/reactos/ntoskrnl/io/iomgr/util.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/iomgr/util.c?r… > > ============================================================================== > --- trunk/reactos/ntoskrnl/io/iomgr/util.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/io/iomgr/util.c [iso-8859-1] Mon Sep 5 15:05:56 > 2011 > @@ -166,7 +166,8 @@ > OUT PULONG ErrorOffset) > { > PFILE_FULL_EA_INFORMATION EaBufferEnd; > - ULONG NextEaBufferOffset, IntEaLength; > + ULONG NextEaBufferOffset; > + LONG IntEaLength; > > PAGED_CODE(); > > > Modified: trunk/reactos/ntoskrnl/ob/obname.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ob/obname.c?rev=5… > > ============================================================================== > --- trunk/reactos/ntoskrnl/ob/obname.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ob/obname.c [iso-8859-1] Mon Sep 5 15:05:56 > 2011 > @@ -986,6 +986,7 @@ > ULONG NameSize; > PWCH ObjectName; > BOOLEAN ObjectIsNamed; > + NTSTATUS Status = STATUS_SUCCESS; > > /* Get the Kernel Meta-Structures */ > ObjectHeader = OBJECT_TO_OBJECT_HEADER(Object); > @@ -994,28 +995,57 @@ > /* Check if a Query Name Procedure is available */ > if (ObjectHeader->Type->TypeInfo.QueryNameProcedure) > { > - /* Call the procedure */ > + /* Call the procedure inside SEH */ > ObjectIsNamed = ((LocalInfo) && (LocalInfo->Name.Length > 0)); > - return ObjectHeader->Type->TypeInfo.QueryNameProcedure(Object, > + > + _SEH2_TRY > + { > + Status = > ObjectHeader->Type->TypeInfo.QueryNameProcedure(Object, > > ObjectIsNamed, > > ObjectNameInfo, > Length, > > ReturnLength, > KernelMode); > + } > + _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > + { > + /* Return the exception code */ > + Status = _SEH2_GetExceptionCode(); > + } > + _SEH2_END; > + > + return Status; > } > > /* Check if the object doesn't even have a name */ > if (!(LocalInfo) || !(LocalInfo->Name.Buffer)) > { > - /* We're returning the name structure */ > - *ReturnLength = sizeof(OBJECT_NAME_INFORMATION); > - > - /* Check if we were given enough space */ > - if (*ReturnLength > Length) return STATUS_INFO_LENGTH_MISMATCH; > - > - /* Return an empty buffer */ > - RtlInitEmptyUnicodeString(&ObjectNameInfo->Name, NULL, 0); > - return STATUS_SUCCESS; > + Status = STATUS_SUCCESS; > + > + _SEH2_TRY > + { > + /* We're returning the name structure */ > + *ReturnLength = sizeof(OBJECT_NAME_INFORMATION); > + > + /* Check if we were given enough space */ > + if (*ReturnLength > Length) > + { > + Status = STATUS_INFO_LENGTH_MISMATCH; > + } > + else > + { > + /* Return an empty buffer */ > + RtlInitEmptyUnicodeString(&ObjectNameInfo->Name, NULL, 0); > + } > + } > + _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > + { > + /* Return the exception code */ > + Status = _SEH2_GetExceptionCode(); > + } > + _SEH2_END; > + > + return Status; > } > > /* > @@ -1025,126 +1055,136 @@ > * enough right at the beginning, not work our way through > * and find out at the end > */ > - if (Object == ObpRootDirectoryObject) > - { > - /* Size of the '\' string */ > - NameSize = sizeof(OBJ_NAME_PATH_SEPARATOR); > - } > - else > - { > - /* Get the Object Directory and add name of Object */ > - ParentDirectory = LocalInfo->Directory; > - NameSize = sizeof(OBJ_NAME_PATH_SEPARATOR) + > LocalInfo->Name.Length; > - > - /* Loop inside the directory to get the top-most one (meaning > root) */ > - while ((ParentDirectory != ObpRootDirectoryObject) && > (ParentDirectory)) > - { > - /* Get the Name Information */ > - LocalInfo = OBJECT_HEADER_TO_NAME_INFO( > - OBJECT_TO_OBJECT_HEADER(ParentDirectory)); > - > - /* Add the size of the Directory Name */ > - if (LocalInfo && LocalInfo->Directory) > - { > - /* Size of the '\' string + Directory Name */ > - NameSize += sizeof(OBJ_NAME_PATH_SEPARATOR) + > - LocalInfo->Name.Length; > - > - /* Move to next parent Directory */ > - ParentDirectory = LocalInfo->Directory; > - } > - else > - { > - /* Directory with no name. We append "...\" */ > - NameSize += sizeof(L"...") + > sizeof(OBJ_NAME_PATH_SEPARATOR); > - break; > - } > - } > - } > - > - /* Finally, add the name of the structure and the null char */ > - *ReturnLength = NameSize + > - sizeof(OBJECT_NAME_INFORMATION) + > - sizeof(UNICODE_NULL); > - > - /* Check if we were given enough space */ > - if (*ReturnLength > Length) return STATUS_INFO_LENGTH_MISMATCH; > - > - /* > - * Now we will actually create the name. We work backwards because > - * it's easier to start off from the Name we have and walk up the > - * parent directories. We use the same logic as Name Length > calculation. > - */ > - LocalInfo = OBJECT_HEADER_TO_NAME_INFO(ObjectHeader); > - ObjectName = (PWCH)((ULONG_PTR)ObjectNameInfo + *ReturnLength); > - *--ObjectName = UNICODE_NULL; > - > - /* Check if the object is actually the Root directory */ > - if (Object == ObpRootDirectoryObject) > - { > - /* This is already the Root Directory, return "\\" */ > - *--ObjectName = OBJ_NAME_PATH_SEPARATOR; > - ObjectNameInfo->Name.Length = (USHORT)NameSize; > - ObjectNameInfo->Name.MaximumLength = (USHORT)(NameSize + > - > sizeof(UNICODE_NULL)); > - ObjectNameInfo->Name.Buffer = ObjectName; > - return STATUS_SUCCESS; > - } > - else > - { > - /* Start by adding the Object's Name */ > - ObjectName = (PWCH)((ULONG_PTR)ObjectName - > - LocalInfo->Name.Length); > - RtlCopyMemory(ObjectName, > - LocalInfo->Name.Buffer, > - LocalInfo->Name.Length); > - > - /* Now parse the Parent directories until we reach the top */ > - ParentDirectory = LocalInfo->Directory; > - while ((ParentDirectory != ObpRootDirectoryObject) && > (ParentDirectory)) > - { > - /* Get the name information */ > - LocalInfo = OBJECT_HEADER_TO_NAME_INFO( > - OBJECT_TO_OBJECT_HEADER(ParentDirectory)); > - > - /* Add the "\" */ > + _SEH2_TRY > + { > + if (Object == ObpRootDirectoryObject) > + { > + /* Size of the '\' string */ > + NameSize = sizeof(OBJ_NAME_PATH_SEPARATOR); > + } > + else > + { > + /* Get the Object Directory and add name of Object */ > + ParentDirectory = LocalInfo->Directory; > + NameSize = sizeof(OBJ_NAME_PATH_SEPARATOR) + > LocalInfo->Name.Length; > + > + /* Loop inside the directory to get the top-most one (meaning > root) */ > + while ((ParentDirectory != ObpRootDirectoryObject) && > (ParentDirectory)) > + { > + /* Get the Name Information */ > + LocalInfo = OBJECT_HEADER_TO_NAME_INFO( > + OBJECT_TO_OBJECT_HEADER(ParentDirectory)); > + > + /* Add the size of the Directory Name */ > + if (LocalInfo && LocalInfo->Directory) > + { > + /* Size of the '\' string + Directory Name */ > + NameSize += sizeof(OBJ_NAME_PATH_SEPARATOR) + > + LocalInfo->Name.Length; > + > + /* Move to next parent Directory */ > + ParentDirectory = LocalInfo->Directory; > + } > + else > + { > + /* Directory with no name. We append "...\" */ > + NameSize += sizeof(L"...") + > sizeof(OBJ_NAME_PATH_SEPARATOR); > + break; > + } > + } > + } > + > + /* Finally, add the name of the structure and the null char */ > + *ReturnLength = NameSize + > + sizeof(OBJECT_NAME_INFORMATION) + > + sizeof(UNICODE_NULL); > + > + /* Check if we were given enough space */ > + if (*ReturnLength > Length) _SEH2_YIELD(return > STATUS_INFO_LENGTH_MISMATCH); > + > + /* > + * Now we will actually create the name. We work backwards because > + * it's easier to start off from the Name we have and walk up the > + * parent directories. We use the same logic as Name Length > calculation. > + */ > + LocalInfo = OBJECT_HEADER_TO_NAME_INFO(ObjectHeader); > + ObjectName = (PWCH)((ULONG_PTR)ObjectNameInfo + *ReturnLength); > + *--ObjectName = UNICODE_NULL; > + > + /* Check if the object is actually the Root directory */ > + if (Object == ObpRootDirectoryObject) > + { > + /* This is already the Root Directory, return "\\" */ > + *--ObjectName = OBJ_NAME_PATH_SEPARATOR; > + ObjectNameInfo->Name.Length = (USHORT)NameSize; > + ObjectNameInfo->Name.MaximumLength = (USHORT)(NameSize + > + > sizeof(UNICODE_NULL)); > + ObjectNameInfo->Name.Buffer = ObjectName; > + _SEH2_YIELD(return STATUS_SUCCESS); > + } > + else > + { > + /* Start by adding the Object's Name */ > + ObjectName = (PWCH)((ULONG_PTR)ObjectName - > + LocalInfo->Name.Length); > + RtlCopyMemory(ObjectName, > + LocalInfo->Name.Buffer, > + LocalInfo->Name.Length); > + > + /* Now parse the Parent directories until we reach the top */ > + ParentDirectory = LocalInfo->Directory; > + while ((ParentDirectory != ObpRootDirectoryObject) && > (ParentDirectory)) > + { > + /* Get the name information */ > + LocalInfo = OBJECT_HEADER_TO_NAME_INFO( > + OBJECT_TO_OBJECT_HEADER(ParentDirectory)); > + > + /* Add the "\" */ > + *(--ObjectName) = OBJ_NAME_PATH_SEPARATOR; > + > + /* Add the Parent Directory's Name */ > + if (LocalInfo && LocalInfo->Name.Buffer) > + { > + /* Add the name */ > + ObjectName = (PWCH)((ULONG_PTR)ObjectName - > + > LocalInfo->Name.Length); > + RtlCopyMemory(ObjectName, > + LocalInfo->Name.Buffer, > + LocalInfo->Name.Length); > + > + /* Move to next parent */ > + ParentDirectory = LocalInfo->Directory; > + } > + else > + { > + /* Directory without a name, we add "..." */ > + ObjectName = (PWCH)((ULONG_PTR)ObjectName - > + sizeof(L"...") + > + sizeof(UNICODE_NULL)); > + RtlCopyMemory(ObjectName, > + L"...", > + sizeof(L"...") + sizeof(UNICODE_NULL)); > + break; > + } > + } > + > + /* Add Root Directory Name */ > *(--ObjectName) = OBJ_NAME_PATH_SEPARATOR; > - > - /* Add the Parent Directory's Name */ > - if (LocalInfo && LocalInfo->Name.Buffer) > - { > - /* Add the name */ > - ObjectName = (PWCH)((ULONG_PTR)ObjectName - > - LocalInfo->Name.Length); > - RtlCopyMemory(ObjectName, > - LocalInfo->Name.Buffer, > - LocalInfo->Name.Length); > - > - /* Move to next parent */ > - ParentDirectory = LocalInfo->Directory; > - } > - else > - { > - /* Directory without a name, we add "..." */ > - ObjectName = (PWCH)((ULONG_PTR)ObjectName - > - sizeof(L"...") + > sizeof(UNICODE_NULL)); > - RtlCopyMemory(ObjectName, > - L"...", > - sizeof(L"...") + sizeof(UNICODE_NULL)); > - break; > - } > - } > - > - /* Add Root Directory Name */ > - *(--ObjectName) = OBJ_NAME_PATH_SEPARATOR; > - ObjectNameInfo->Name.Length = (USHORT)NameSize; > - ObjectNameInfo->Name.MaximumLength = (USHORT)(NameSize + > - > sizeof(UNICODE_NULL)); > - ObjectNameInfo->Name.Buffer = ObjectName; > - } > + ObjectNameInfo->Name.Length = (USHORT)NameSize; > + ObjectNameInfo->Name.MaximumLength = > + (USHORT)(NameSize + sizeof(UNICODE_NULL)); > + ObjectNameInfo->Name.Buffer = ObjectName; > + } > + } > + _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > + { > + /* Return the exception code */ > + Status = _SEH2_GetExceptionCode(); > + } > + _SEH2_END; > > /* Return success */ > - return STATUS_SUCCESS; > + return Status; > } > > VOID > > >

2 1

Re: [ros-dev] [ros-diffs] [tkreuzer] 53600: [HAL] - Use functions instead of macros for irq<->vector<->irql translation, this will be neccessary, once apic support is there - Disable mp hal in rbuild for now, its broken anyway
by Alex Ionescu 05 Sep '11

05 Sep '11

There are already hal private dispatch table functions to deal with this. Please see older HAL commits and the changes in ke/i386/interrupt.c & friends. Best regards, Alex Ionescu On Mon, Sep 5, 2011 at 4:20 PM, <tkreuzer(a)svn.reactos.org> wrote: > Author: tkreuzer > Date: Mon Sep 5 15:20:07 2011 > New Revision: 53600 > > URL: http://svn.reactos.org/svn/reactos?rev=53600&view=rev > Log: > [HAL] > - Use functions instead of macros for irq<->vector<->irql translation, this > will be neccessary, once apic support is there > - Disable mp hal in rbuild for now, its broken anyway > > Modified: > trunk/reactos/hal/halx86/directory.rbuild > trunk/reactos/hal/halx86/include/hal.h > trunk/reactos/hal/halx86/include/halirq.h > trunk/reactos/hal/halx86/up/pic.c > > Modified: trunk/reactos/hal/halx86/directory.rbuild > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/directory.rbuil… > > ============================================================================== > --- trunk/reactos/hal/halx86/directory.rbuild [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/directory.rbuild [iso-8859-1] Mon Sep 5 > 15:20:07 2011 > @@ -13,9 +13,9 @@ > <xi:include href="hal.rbuild" /> > <xi:include href="halacpi.rbuild" /> > <xi:include href="halxbox.rbuild" /> > - <if property="BUILD_MP" value="1"> > +  > </if> > > <if property="ARCH" value="amd64"> > > Modified: trunk/reactos/hal/halx86/include/hal.h > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/include/hal.h?r… > > ============================================================================== > --- trunk/reactos/hal/halx86/include/hal.h [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/include/hal.h [iso-8859-1] Mon Sep 5 15:20:07 > 2011 > @@ -55,13 +55,11 @@ > #define TAG_BUS_HANDLER 'BusH' > > /* Internal HAL Headers */ > -#include "apic.h" > #include "bus.h" > #include "halirq.h" > #include "haldma.h" > #include "halp.h" > #include "mps.h" > -#include "ioapic.h" > #include "halacpi.h" > > /* EOF */ > > Modified: trunk/reactos/hal/halx86/include/halirq.h > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/include/halirq.… > > ============================================================================== > --- trunk/reactos/hal/halx86/include/halirq.h [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/include/halirq.h [iso-8859-1] Mon Sep 5 > 15:20:07 2011 > @@ -4,29 +4,19 @@ > > #pragma once > > -#ifdef CONFIG_SMP > +UCHAR > +FASTCALL > +HalpIrqToVector(UCHAR Irq); > > -#define FIRST_DEVICE_VECTOR (0x30) > -#define FIRST_SYSTEM_VECTOR (0xef) > +KIRQL > +FASTCALL > +HalpVectorToIrql(UCHAR Vector); > > -#define IRQ_BASE FIRST_DEVICE_VECTOR > -#define NR_IRQS (FIRST_SYSTEM_VECTOR - > FIRST_DEVICE_VECTOR) > +UCHAR > +FASTCALL > +HalpVectorToIrq(UCHAR Vector); > > -/* > - * FIXME: > - * This does not work if we have more than 24 IRQs (ie. more than one > I/O APIC) > - */ > -#define VECTOR2IRQ(vector) (23 - (vector - IRQ_BASE) / 8) > -#define VECTOR2IRQL(vector) (PROFILE_LEVEL - VECTOR2IRQ(vector)) > -#define IRQ2VECTOR(irq) (((23 - (irq)) * 8) + > FIRST_DEVICE_VECTOR) > +#define VECTOR2IRQ(vector) HalpVectorToIrq(vector) > +#define VECTOR2IRQL(vector) HalpVectorToIrql(vector) > +#define IRQ2VECTOR(irq) HalpIrqToVector(irq) > > -#else > - > -#define IRQ_BASE (0x30) > -#define NR_IRQS (16) > - > -#define VECTOR2IRQ(vector) ((vector) - IRQ_BASE) > -#define VECTOR2IRQL(vector) (PROFILE_LEVEL - VECTOR2IRQ(vector)) > -#define IRQ2VECTOR(irq) ((irq) + IRQ_BASE) > - > -#endif > > Modified: trunk/reactos/hal/halx86/up/pic.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/up/pic.c?rev=53… > > ============================================================================== > --- trunk/reactos/hal/halx86/up/pic.c [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/up/pic.c [iso-8859-1] Mon Sep 5 15:20:07 2011 > @@ -512,6 +512,27 @@ > __writeeflags(EFlags); > } > > +UCHAR > +FASTCALL > +HalpIrqToVector(UCHAR Irq) > +{ > + return (PRIMARY_VECTOR_BASE + Irq); > +} > + > +UCHAR > +FASTCALL > +HalpVectorToIrq(UCHAR Vector) > +{ > + return (Vector - PRIMARY_VECTOR_BASE); > +} > + > +KIRQL > +FASTCALL > +HalpVectorToIrql(UCHAR Vector) > +{ > + return (PROFILE_LEVEL - (Vector - PRIMARY_VECTOR_BASE)); > +} > + > /* IRQL MANAGEMENT > ************************************************************/ > > /* > > >

1 0

Re: [ros-dev] [ros-diffs] [dchapyshev] 53519: - Fix multiple typos and bugs, found by PVS-Studio
by Alex Ionescu 05 Sep '11

05 Sep '11

A lot of these are in 3rdparty/wine DLLs. Were these bugs reported to the appropriate projects? Best regards, Alex Ionescu On Thu, Sep 1, 2011 at 4:30 PM, <dchapyshev(a)svn.reactos.org> wrote: > Author: dchapyshev > Date: Thu Sep 1 15:30:19 2011 > New Revision: 53519 > > URL: http://svn.reactos.org/svn/reactos?rev=53519&view=rev > Log: > - Fix multiple typos and bugs, found by PVS-Studio > > Modified: > trunk/reactos/base/applications/sndrec32/sndrec32.cpp > trunk/reactos/base/system/smss/client.c > trunk/reactos/dll/cpl/desk/screensaver.c > trunk/reactos/dll/win32/browseui/bandsite.cpp > trunk/reactos/dll/win32/glu32/libnurbs/internals/mapdesc.cc > trunk/reactos/dll/win32/oleaut32/typelib2.c > trunk/reactos/dll/win32/rsaenh/sha2.c > trunk/reactos/dll/win32/shell32/pidl.c > trunk/reactos/drivers/storage/ide/uniata/id_dma.cpp > trunk/reactos/ntoskrnl/config/cmcontrl.c > trunk/reactos/subsystems/win32/win32k/eng/gradient.c > trunk/reactos/subsystems/win32/win32k/objects/bitblt.c > > Modified: trunk/reactos/base/applications/sndrec32/sndrec32.cpp > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/sndrec32… > > ============================================================================== > --- trunk/reactos/base/applications/sndrec32/sndrec32.cpp [iso-8859-1] > (original) > +++ trunk/reactos/base/applications/sndrec32/sndrec32.cpp [iso-8859-1] Thu > Sep 1 15:30:19 2011 > @@ -766,7 +766,7 @@ > isnew = TRUE; > display_dur = TRUE; > > - ZeroMemory( file_path, MAX_PATH ); > + ZeroMemory( file_path, MAX_PATH * sizeof(TCHAR) ); > > EnableWindow( slider, FALSE ); > > > Modified: trunk/reactos/base/system/smss/client.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/base/system/smss/client.c?… > > ============================================================================== > --- trunk/reactos/base/system/smss/client.c [iso-8859-1] (original) > +++ trunk/reactos/base/system/smss/client.c [iso-8859-1] Thu Sep 1 > 15:30:19 2011 > @@ -441,7 +441,7 @@ > */ > RtlCopyMemory > (SmpClientDirectory.CandidateClient->ProgramName, > ProgramName, > - SM_SB_NAME_MAX_LENGTH); > + SM_SB_NAME_MAX_LENGTH * > sizeof(WCHAR)); > } > } else { > DPRINT1("SM: %s: CandidateClient %p pending!\n", > __FUNCTION__, > > Modified: trunk/reactos/dll/cpl/desk/screensaver.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/cpl/desk/screensaver.c… > > ============================================================================== > --- trunk/reactos/dll/cpl/desk/screensaver.c [iso-8859-1] (original) > +++ trunk/reactos/dll/cpl/desk/screensaver.c [iso-8859-1] Thu Sep 1 > 15:30:19 2011 > @@ -450,7 +450,7 @@ > lpBackSlash = _tcsrchr(szSearchPath, _T('\\')); > if (lpBackSlash != NULL) > { > - lpBackSlash = '\0'; > + *lpBackSlash = '\0'; > SearchScreenSavers(hwndScreenSavers, szSearchPath, pData); > } > } > > Modified: trunk/reactos/dll/win32/browseui/bandsite.cpp > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/browseui/bandsit… > > ============================================================================== > --- trunk/reactos/dll/win32/browseui/bandsite.cpp [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/browseui/bandsite.cpp [iso-8859-1] Thu Sep 1 > 15:30:19 2011 > @@ -719,7 +719,7 @@ > if (fRebarWindow == NULL) > return E_FAIL; > > - if (IsEqualIID(pguidCmdGroup, IID_IDeskBand)) > + if (IsEqualIID(*pguidCmdGroup, IID_IDeskBand)) > { > switch (nCmdID) > { > > Modified: trunk/reactos/dll/win32/glu32/libnurbs/internals/mapdesc.cc > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/glu32/libnurbs/i… > > ============================================================================== > --- trunk/reactos/dll/win32/glu32/libnurbs/internals/mapdesc.cc > [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/glu32/libnurbs/internals/mapdesc.cc > [iso-8859-1] Thu Sep 1 15:30:19 2011 > @@ -90,7 +90,7 @@ > } > > void > -Mapdesc::identify( REAL dest[MAXCOORDS][MAXCOORDS] ) > +Mapdesc::identify( REAL (&dest)[MAXCOORDS][MAXCOORDS] ) > { > memset( dest, 0, sizeof( dest ) ); > for( int i=0; i != hcoords; i++ ) > > Modified: trunk/reactos/dll/win32/oleaut32/typelib2.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/oleaut32/typelib… > > ============================================================================== > --- trunk/reactos/dll/win32/oleaut32/typelib2.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/oleaut32/typelib2.c [iso-8859-1] Thu Sep 1 > 15:30:19 2011 > @@ -317,7 +317,7 @@ > while (offset != -1) { > guidentry = (MSFT_GuidEntry > *)&This->typelib_segment_data[MSFT_SEG_GUID][offset]; > > - if (IsEqualGUID(guidentry, guid)) return offset; > + if (IsEqualGUID(*guidentry, guid)) return offset; > > offset = guidentry->next_hash; > } > > Modified: trunk/reactos/dll/win32/rsaenh/sha2.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/rsaenh/sha2.c?re… > > ============================================================================== > --- trunk/reactos/dll/win32/rsaenh/sha2.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/rsaenh/sha2.c [iso-8859-1] Thu Sep 1 15:30:19 > 2011 > @@ -563,7 +563,7 @@ > } > > /* Clean up state data: */ > - MEMSET_BZERO(context, sizeof(context)); > + MEMSET_BZERO(context, sizeof(*context)); > usedspace = 0; > } > > @@ -584,7 +584,7 @@ > } > *buffer = 0; > } else { > - MEMSET_BZERO(context, sizeof(context)); > + MEMSET_BZERO(context, sizeof(*context)); > } > MEMSET_BZERO(digest, SHA256_DIGEST_LENGTH); > return buffer; > @@ -893,7 +893,7 @@ > } > > /* Zero out state data */ > - MEMSET_BZERO(context, sizeof(context)); > + MEMSET_BZERO(context, sizeof(*context)); > } > > char *SHA512_End(SHA512_CTX* context, char buffer[]) { > @@ -913,7 +913,7 @@ > } > *buffer = 0; > } else { > - MEMSET_BZERO(context, sizeof(context)); > + MEMSET_BZERO(context, sizeof(*context)); > } > MEMSET_BZERO(digest, SHA512_DIGEST_LENGTH); > return buffer; > @@ -968,7 +968,7 @@ > } > > /* Zero out state data */ > - MEMSET_BZERO(context, sizeof(context)); > + MEMSET_BZERO(context, sizeof(*context)); > } > > char *SHA384_End(SHA384_CTX* context, char buffer[]) { > @@ -988,7 +988,7 @@ > } > *buffer = 0; > } else { > - MEMSET_BZERO(context, sizeof(context)); > + MEMSET_BZERO(context, sizeof(*context)); > } > MEMSET_BZERO(digest, SHA384_DIGEST_LENGTH); > return buffer; > > Modified: trunk/reactos/dll/win32/shell32/pidl.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/shell32/pidl.c?r… > > ============================================================================== > --- trunk/reactos/dll/win32/shell32/pidl.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/shell32/pidl.c [iso-8859-1] Thu Sep 1 15:30:19 > 2011 > @@ -1157,7 +1157,7 @@ > if (len < sizeof(WIN32_FIND_DATAW)) > return E_INVALIDARG; > > - ZeroMemory(pfd, sizeof (WIN32_FIND_DATAA)); > + ZeroMemory(pfd, sizeof (WIN32_FIND_DATAW)); > _ILGetFileDateTime( pidl, &(pfd->ftLastWriteTime)); > pfd->dwFileAttributes = _ILGetFileAttributes(pidl, NULL, 0); > pfd->nFileSizeLow = _ILGetFileSize ( pidl, NULL, 0); > > Modified: trunk/reactos/drivers/storage/ide/uniata/id_dma.cpp > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/storage/ide/uniata… > > ============================================================================== > --- trunk/reactos/drivers/storage/ide/uniata/id_dma.cpp [iso-8859-1] > (original) > +++ trunk/reactos/drivers/storage/ide/uniata/id_dma.cpp [iso-8859-1] Thu > Sep 1 15:30:19 2011 > @@ -1607,7 +1607,7 @@ > { 0xc2, 0x82, 0x042, 0x8a, 0x4a, 0x0a } }; > static const UCHAR cmd_wdma_modes[] = { 0x87, 0x32, 0x3f }; > static const UCHAR cmd_pio_modes[] = { 0xa9, 0x57, 0x44, 0x32, > 0x3f }; > - ULONG treg = 0x54 + (dev < 3) ? (dev << 1) : 7; > + ULONG treg = 0x54 + ((dev < 3) ? (dev << 1) : 7); > > udmamode = min(udmamode, 5); > /* enable UDMA mode */ > > Modified: trunk/reactos/ntoskrnl/config/cmcontrl.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/config/cmcontrl.c… > > ============================================================================== > --- trunk/reactos/ntoskrnl/config/cmcontrl.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/config/cmcontrl.c [iso-8859-1] Thu Sep 1 > 15:30:19 2011 > @@ -118,7 +118,7 @@ > if (!SystemHiveData) return; > > /* Initialize the Hive View List and the security cache */ > - RtlZeroMemory(SystemHive, sizeof(SystemHive)); > + RtlZeroMemory(SystemHive, sizeof(*SystemHive)); > CmpInitHiveViewList((PCMHIVE)SystemHive); > CmpInitSecurityCache((PCMHIVE)SystemHive); > > > Modified: trunk/reactos/subsystems/win32/win32k/eng/gradient.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/en… > > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/eng/gradient.c [iso-8859-1] > (original) > +++ trunk/reactos/subsystems/win32/win32k/eng/gradient.c [iso-8859-1] Thu > Sep 1 15:30:19 2011 > @@ -298,7 +298,7 @@ > #define SMALLER(a,b) (a->y < b->y) || (a->y == b->y && a->x < b->x) > #define SWAP(a,b,c) c = a;\ > a = b;\ > - a = c > + b = c > #define NLINES 3 > BOOL FASTCALL > IntEngGradientFillTriangle( > > Modified: trunk/reactos/subsystems/win32/win32k/objects/bitblt.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/ob… > > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/objects/bitblt.c [iso-8859-1] > (original) > +++ trunk/reactos/subsystems/win32/win32k/objects/bitblt.c [iso-8859-1] Thu > Sep 1 15:30:19 2011 > @@ -667,7 +667,7 @@ > MaskPoint.y = YOriginMask; > IntLPtoDP(DCMask, &MaskPoint, 1); > MaskPoint.x += DCMask->ptlDCOrig.x; > - MaskPoint.y += DCMask->ptlDCOrig.x; > + MaskPoint.y += DCMask->ptlDCOrig.y; > } > > /* Perform the bitblt operation */ > > >

4 5

Re: [ros-dev] [ros-diffs] [tkreuzer] 53399: [VMWINST] Fix amd64 build [NTDLL] add missing amd64 specific exports [MSVCRT*] Fix mangled c++ exports for amd64 [OLEAUT32] Add amd64 adm stub for call_method, fix MSVC/amd64 buil...
by Jérôme Gardou 04 Sep '11

04 Sep '11

Le 23/08/2011 10:58, tkreuzer(a)svn.reactos.org a écrit : > Author: tkreuzer > Date: Tue Aug 23 08:58:15 2011 > New Revision: 53399 > > URL: http://svn.reactos.org/svn/reactos?rev=53399&view=rev > Log: > [VMWINST] Fix amd64 build > What about : [VMWINST] Get rid of this useless relic. I mean it's something we have to maintain, it was written for antediluvian vmware versions, and I see no reason to have such a thing. I may as well write an application to install specific ATI card drivers, or intel chipset drivers...

7 12

Re: [ros-dev] [ros-diffs] [jgardou] 53547: [VGA_NEW] - fix some warnings
by Alex Ionescu 04 Sep '11

04 Sep '11

These changes are wrong :( Please use the correct compiler flag instead (-mrtd) Best regards, Alex Ionescu On Sat, Sep 3, 2011 at 5:09 PM, <jgardou(a)svn.reactos.org> wrote: > Author: jgardou > Date: Sat Sep 3 16:09:34 2011 > New Revision: 53547 > > URL: http://svn.reactos.org/svn/reactos?rev=53547&view=rev > Log: > [VGA_NEW] > - fix some warnings > > Modified: > trunk/reactos/drivers/video/miniport/vga_new/vga.c > > Modified: trunk/reactos/drivers/video/miniport/vga_new/vga.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/video/miniport/vga… > > ============================================================================== > --- trunk/reactos/drivers/video/miniport/vga_new/vga.c [iso-8859-1] > (original) > +++ trunk/reactos/drivers/video/miniport/vga_new/vga.c [iso-8859-1] Sat Sep > 3 16:09:34 2011 > @@ -19,6 +19,7 @@ > // > > VP_STATUS > +NTAPI > VgaFindAdapter( > PVOID HwDeviceExtension, > PVOID HwContext, > @@ -28,11 +29,13 @@ > ); > > BOOLEAN > +NTAPI > VgaInitialize( > PVOID HwDeviceExtension > ); > > BOOLEAN > +NTAPI > VgaStartIO( > PVOID HwDeviceExtension, > PVIDEO_REQUEST_PACKET RequestPacket > @@ -102,6 +105,7 @@ > ); > > VP_STATUS > +NTAPI > GetDeviceDataCallback( > PVOID HwDeviceExtension, > PVOID Context, > @@ -130,7 +134,6 @@ > #pragma alloc_text(PAGE,VgaSetColorLookup) > #endif > > - > > //--------------------------------------------------------------------------- > ULONG > // eVb: 1.3 [GCC] - Add NTAPI for GCC support > @@ -303,9 +306,10 @@ > return initializationStatus; > > } // end DriverEntry() > - > + > > //--------------------------------------------------------------------------- > VP_STATUS > +NTAPI > VgaFindAdapter( > PVOID HwDeviceExtension, > PVOID HwContext, > @@ -383,7 +387,7 @@ > if ((ConfigInfo->AdapterInterfaceType == Internal) && > (VideoPortGetDeviceData(HwDeviceExtension, > VpControllerData, > - &GetDeviceDataCallback, > + GetDeviceDataCallback, > VgaAccessRange) != NO_ERROR)) > { > return ERROR_INVALID_PARAMETER; > @@ -485,9 +489,10 @@ > > > } // VgaFindAdapter() > - > + > > //--------------------------------------------------------------------------- > BOOLEAN > +NTAPI > VgaInitialize( > PVOID HwDeviceExtension > ) > @@ -527,9 +532,10 @@ > return TRUE; > > } // VgaInitialize() > - > + > > //--------------------------------------------------------------------------- > BOOLEAN > +NTAPI > VgaStartIO( > PVOID HwDeviceExtension, > PVIDEO_REQUEST_PACKET RequestPacket > @@ -1440,8 +1446,9 @@ > return ERROR_INVALID_PARAMETER; > > } // end VgaSetColorLookup() > - > + > VP_STATUS > +NTAPI > GetDeviceDataCallback( > PVOID HwDeviceExtension, > PVOID Context, > > >

4 11

Re: [ros-dev] [ros-diffs] [jgardou] 53551: - revert r53547, although setting explicitly something which is default isn't a "wrong change" per se.
by Alex Ionescu 03 Sep '11

03 Sep '11

It is when it breaks the easyness to sync this code with it's original source and do diffs, sorry for not being clear. I believe the whole driver was carefully commented in the locations where it differs from the original source, and this would've added extra burden. Best regards, Alex Ionescu On Sat, Sep 3, 2011 at 5:44 PM, <jgardou(a)svn.reactos.org> wrote: > Author: jgardou > Date: Sat Sep 3 16:44:49 2011 > New Revision: 53551 > > URL: http://svn.reactos.org/svn/reactos?rev=53551&view=rev > Log: > - revert r53547, although setting explicitly something which is default > isn't a "wrong change" per se. > > Modified: > trunk/reactos/drivers/video/miniport/vga_new/vga.c > > Modified: trunk/reactos/drivers/video/miniport/vga_new/vga.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/video/miniport/vga… > > ============================================================================== > --- trunk/reactos/drivers/video/miniport/vga_new/vga.c [iso-8859-1] > (original) > +++ trunk/reactos/drivers/video/miniport/vga_new/vga.c [iso-8859-1] Sat Sep > 3 16:44:49 2011 > @@ -19,7 +19,6 @@ > // > > VP_STATUS > -NTAPI > VgaFindAdapter( > PVOID HwDeviceExtension, > PVOID HwContext, > @@ -29,13 +28,11 @@ > ); > > BOOLEAN > -NTAPI > VgaInitialize( > PVOID HwDeviceExtension > ); > > BOOLEAN > -NTAPI > VgaStartIO( > PVOID HwDeviceExtension, > PVIDEO_REQUEST_PACKET RequestPacket > @@ -105,7 +102,6 @@ > ); > > VP_STATUS > -NTAPI > GetDeviceDataCallback( > PVOID HwDeviceExtension, > PVOID Context, > @@ -134,6 +130,7 @@ > #pragma alloc_text(PAGE,VgaSetColorLookup) > #endif > > + > > //--------------------------------------------------------------------------- > ULONG > // eVb: 1.3 [GCC] - Add NTAPI for GCC support > @@ -306,10 +303,9 @@ > return initializationStatus; > > } // end DriverEntry() > - > + > > //--------------------------------------------------------------------------- > VP_STATUS > -NTAPI > VgaFindAdapter( > PVOID HwDeviceExtension, > PVOID HwContext, > @@ -387,7 +383,7 @@ > if ((ConfigInfo->AdapterInterfaceType == Internal) && > (VideoPortGetDeviceData(HwDeviceExtension, > VpControllerData, > - GetDeviceDataCallback, > + &GetDeviceDataCallback, > VgaAccessRange) != NO_ERROR)) > { > return ERROR_INVALID_PARAMETER; > @@ -489,10 +485,9 @@ > > > } // VgaFindAdapter() > - > + > > //--------------------------------------------------------------------------- > BOOLEAN > -NTAPI > VgaInitialize( > PVOID HwDeviceExtension > ) > @@ -532,10 +527,9 @@ > return TRUE; > > } // VgaInitialize() > - > + > > //--------------------------------------------------------------------------- > BOOLEAN > -NTAPI > VgaStartIO( > PVOID HwDeviceExtension, > PVIDEO_REQUEST_PACKET RequestPacket > @@ -1446,9 +1440,8 @@ > return ERROR_INVALID_PARAMETER; > > } // end VgaSetColorLookup() > - > + > VP_STATUS > -NTAPI > GetDeviceDataCallback( > PVOID HwDeviceExtension, > PVOID Context, > > >

1 0

Re: [ros-dev] [ros-diffs] [cmihail] 53543: [shell32.dll] - Fix bug related to correct error code returning in delete_files. The value of 1026 was revealed to be returned by windows 2003 server. Score several passed winetest...
by Jérôme Gardou 03 Sep '11

03 Sep '11

Hello Claudiu! I notice some weird tab/spaces modifications here. Regards. Jérôme. Le 03/09/2011 16:20, cmihail(a)svn.reactos.org a écrit : > Author: cmihail > Date: Sat Sep 3 14:20:03 2011 > New Revision: 53543 > > URL: http://svn.reactos.org/svn/reactos?rev=53543&view=rev > Log: > [shell32.dll] > - Fix bug related to correct error code returning in delete_files. The value of 1026 was revealed to be returned by windows 2003 server. Score several passed winetests. > - Fix a bug in ShellLink::SetShowCmd and score one more passed winetest > > Modified: > branches/shell32_new-bringup/dll/win32/shell32/shelllink.cpp > branches/shell32_new-bringup/dll/win32/shell32/shlfileop.cpp > >

2 1

Re: [ros-dev] [ros-diffs] [rharabien] 53542: [FREELDR] - Introduce WINE-like debug macros ERR, FIXME, WARN and TRACE - Always show ERR and FIXME information - WARN and TRACE are enabled by DebugPrintMask in debug.c as befor...
by Alex Ionescu 03 Sep '11

03 Sep '11

And the bug was...? Best regards, Alex Ionescu On Sat, Sep 3, 2011 at 11:56 AM, <rharabien(a)svn.reactos.org> wrote: > Author: rharabien > Date: Sat Sep 3 10:56:36 2011 > New Revision: 53542 > > URL: http://svn.reactos.org/svn/reactos?rev=53542&view=rev > Log: > [FREELDR] > - Introduce WINE-like debug macros ERR, FIXME, WARN and TRACE > - Always show ERR and FIXME information > - WARN and TRACE are enabled by DebugPrintMask in debug.c as before > - Thanks to new macros find bug in CMake livecd creation and fix it > > Modified: > trunk/reactos/boot/freeldr/freeldr/CMakeLists.txt > trunk/reactos/boot/freeldr/freeldr/arch/amd64/winldr.c > trunk/reactos/boot/freeldr/freeldr/arch/i386/drivemap.c > trunk/reactos/boot/freeldr/freeldr/arch/i386/hardware.c > trunk/reactos/boot/freeldr/freeldr/arch/i386/hwacpi.c > trunk/reactos/boot/freeldr/freeldr/arch/i386/hwapm.c > trunk/reactos/boot/freeldr/freeldr/arch/i386/hwpci.c > trunk/reactos/boot/freeldr/freeldr/arch/i386/i386disk.c > trunk/reactos/boot/freeldr/freeldr/arch/i386/i386vid.c > trunk/reactos/boot/freeldr/freeldr/arch/i386/pcdisk.c > trunk/reactos/boot/freeldr/freeldr/arch/i386/pcmem.c > trunk/reactos/boot/freeldr/freeldr/arch/i386/pcvideo.c > trunk/reactos/boot/freeldr/freeldr/arch/i386/winldr.c > trunk/reactos/boot/freeldr/freeldr/arch/i386/xboxdisk.c > trunk/reactos/boot/freeldr/freeldr/arch/i386/xboxhw.c > trunk/reactos/boot/freeldr/freeldr/cache/blocklist.c > trunk/reactos/boot/freeldr/freeldr/cache/cache.c > trunk/reactos/boot/freeldr/freeldr/debug.c > trunk/reactos/boot/freeldr/freeldr/disk/disk.c > trunk/reactos/boot/freeldr/freeldr/disk/partition.c > trunk/reactos/boot/freeldr/freeldr/disk/scsiport.c > trunk/reactos/boot/freeldr/freeldr/freeldr.c > trunk/reactos/boot/freeldr/freeldr/fs/ext2.c > trunk/reactos/boot/freeldr/freeldr/fs/fat.c > trunk/reactos/boot/freeldr/freeldr/fs/fs.c > trunk/reactos/boot/freeldr/freeldr/fs/iso.c > trunk/reactos/boot/freeldr/freeldr/fs/ntfs.c > trunk/reactos/boot/freeldr/freeldr/fs/pxe.c > trunk/reactos/boot/freeldr/freeldr/include/debug.h > trunk/reactos/boot/freeldr/freeldr/inifile/inifile.c > trunk/reactos/boot/freeldr/freeldr/inifile/parse.c > trunk/reactos/boot/freeldr/freeldr/linuxboot.c > trunk/reactos/boot/freeldr/freeldr/mm/meminit.c > trunk/reactos/boot/freeldr/freeldr/mm/mm.c > trunk/reactos/boot/freeldr/freeldr/reactos/binhive.c > trunk/reactos/boot/freeldr/freeldr/reactos/registry.c > trunk/reactos/boot/freeldr/freeldr/ui/ui.c > trunk/reactos/boot/freeldr/freeldr/windows/conversion.c > trunk/reactos/boot/freeldr/freeldr/windows/peloader.c > trunk/reactos/boot/freeldr/freeldr/windows/setupldr.c > trunk/reactos/boot/freeldr/freeldr/windows/winldr.c > trunk/reactos/boot/freeldr/freeldr/windows/wlmemory.c > trunk/reactos/boot/freeldr/freeldr/windows/wlregistry.c > > [This mail would be too long, it was shortened to contain the URLs only.] > > Modified: trunk/reactos/boot/freeldr/freeldr/CMakeLists.txt > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/CMake… > > Modified: trunk/reactos/boot/freeldr/freeldr/arch/amd64/winldr.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/… > > Modified: trunk/reactos/boot/freeldr/freeldr/arch/i386/drivemap.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/… > > Modified: trunk/reactos/boot/freeldr/freeldr/arch/i386/hardware.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/… > > Modified: trunk/reactos/boot/freeldr/freeldr/arch/i386/hwacpi.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/… > > Modified: trunk/reactos/boot/freeldr/freeldr/arch/i386/hwapm.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/… > > Modified: trunk/reactos/boot/freeldr/freeldr/arch/i386/hwpci.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/… > > Modified: trunk/reactos/boot/freeldr/freeldr/arch/i386/i386disk.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/… > > Modified: trunk/reactos/boot/freeldr/freeldr/arch/i386/i386vid.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/… > > Modified: trunk/reactos/boot/freeldr/freeldr/arch/i386/pcdisk.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/… > > Modified: trunk/reactos/boot/freeldr/freeldr/arch/i386/pcmem.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/… > > Modified: trunk/reactos/boot/freeldr/freeldr/arch/i386/pcvideo.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/… > > Modified: trunk/reactos/boot/freeldr/freeldr/arch/i386/winldr.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/… > > Modified: trunk/reactos/boot/freeldr/freeldr/arch/i386/xboxdisk.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/… > > Modified: trunk/reactos/boot/freeldr/freeldr/arch/i386/xboxhw.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/… > > Modified: trunk/reactos/boot/freeldr/freeldr/cache/blocklist.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/cache… > > Modified: trunk/reactos/boot/freeldr/freeldr/cache/cache.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/cache… > > Modified: trunk/reactos/boot/freeldr/freeldr/debug.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/debug… > > Modified: trunk/reactos/boot/freeldr/freeldr/disk/disk.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/disk/… > > Modified: trunk/reactos/boot/freeldr/freeldr/disk/partition.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/disk/… > > Modified: trunk/reactos/boot/freeldr/freeldr/disk/scsiport.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/disk/… > > Modified: trunk/reactos/boot/freeldr/freeldr/freeldr.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/freel… > > Modified: trunk/reactos/boot/freeldr/freeldr/fs/ext2.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/fs/ex… > > Modified: trunk/reactos/boot/freeldr/freeldr/fs/fat.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/fs/fa… > > Modified: trunk/reactos/boot/freeldr/freeldr/fs/fs.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/fs/fs… > > Modified: trunk/reactos/boot/freeldr/freeldr/fs/iso.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/fs/is… > > Modified: trunk/reactos/boot/freeldr/freeldr/fs/ntfs.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/fs/nt… > > Modified: trunk/reactos/boot/freeldr/freeldr/fs/pxe.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/fs/px… > > Modified: trunk/reactos/boot/freeldr/freeldr/include/debug.h > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/inclu… > > Modified: trunk/reactos/boot/freeldr/freeldr/inifile/inifile.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/inifi… > > Modified: trunk/reactos/boot/freeldr/freeldr/inifile/parse.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/inifi… > > Modified: trunk/reactos/boot/freeldr/freeldr/linuxboot.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/linux… > > Modified: trunk/reactos/boot/freeldr/freeldr/mm/meminit.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/mm/me… > > Modified: trunk/reactos/boot/freeldr/freeldr/mm/mm.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/mm/mm… > > Modified: trunk/reactos/boot/freeldr/freeldr/reactos/binhive.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/react… > > Modified: trunk/reactos/boot/freeldr/freeldr/reactos/registry.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/react… > > Modified: trunk/reactos/boot/freeldr/freeldr/ui/ui.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/ui/ui… > > Modified: trunk/reactos/boot/freeldr/freeldr/windows/conversion.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/windo… > > Modified: trunk/reactos/boot/freeldr/freeldr/windows/peloader.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/windo… > > Modified: trunk/reactos/boot/freeldr/freeldr/windows/setupldr.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/windo… > > Modified: trunk/reactos/boot/freeldr/freeldr/windows/winldr.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/windo… > > Modified: trunk/reactos/boot/freeldr/freeldr/windows/wlmemory.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/windo… > > Modified: trunk/reactos/boot/freeldr/freeldr/windows/wlregistry.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/windo… > > >

2 1

Re: [ros-dev] [ros-diffs] [cmihail] 53541: [shell32.dll] - Don't do some parameter checks, even if MSDN says they're incompatible. Winetests with windows 2003 server as reference tells us msdn lies. (Spotted by Victor Marti...
by Alex Ionescu 03 Sep '11

03 Sep '11

Just because the checks aren't in THIS api doesn't mean MSDN lies. Best regards, Alex Ionescu On Sat, Sep 3, 2011 at 11:55 AM, <cmihail(a)svn.reactos.org> wrote: > Author: cmihail > Date: Sat Sep 3 10:55:51 2011 > New Revision: 53541 > > URL: http://svn.reactos.org/svn/reactos?rev=53541&view=rev > Log: > [shell32.dll] > - Don't do some parameter checks, even if MSDN says they're incompatible. > Winetests with windows 2003 server as reference tells us msdn lies. (Spotted > by Victor Martinez) > > Modified: > branches/shell32_new-bringup/dll/win32/shell32/shell32_main.cpp > > Modified: branches/shell32_new-bringup/dll/win32/shell32/shell32_main.cpp > URL: > http://svn.reactos.org/svn/reactos/branches/shell32_new-bringup/dll/win32/s… > > ============================================================================== > --- branches/shell32_new-bringup/dll/win32/shell32/shell32_main.cpp > [iso-8859-1] (original) > +++ branches/shell32_new-bringup/dll/win32/shell32/shell32_main.cpp > [iso-8859-1] Sat Sep 3 10:55:51 2011 > @@ -330,9 +330,6 @@ > (flags & SHGFI_PIDL)? "pidl" : debugstr_w(path), > dwFileAttributes, > psfi, psfi->dwAttributes, sizeofpsfi, flags); > > - if ( (flags & SHGFI_USEFILEATTRIBUTES) && > - (flags & (SHGFI_ATTRIBUTES|SHGFI_EXETYPE|SHGFI_PIDL))) > - return FALSE; > if (!path) > return FALSE; > > > >

2 1

Re: [ros-dev] [ros-diffs] [cmihail] 53537: [shell32.dll] [FORMATTING] - Format the code to a more acceptable level. This is just for my sanity while sifting through it.
by Timo Kreuzer 03 Sep '11

03 Sep '11

Am 03.09.2011 02:08, schrieb cmihail(a)svn.reactos.org: > Author: cmihail > Date: Sat Sep 3 00:08:11 2011 > New Revision: 53537 > > URL:http://svn.reactos.org/svn/reactos?rev=53537&view=rev > Log: > [shell32.dll] > [FORMATTING] > - Format the code to a more acceptable level. This is just for my sanity while sifting through it. > /* skip the remaining spaces */ > - while (*cs==0x0009 || *cs==0x0020) { > + while (*cs==0x0009 || *cs==0x0020) > + { > cs++; > } > if (*cs==0) > Please don't mix tabs and spaces or we'll end up looking like GNU style ;-) Since the file already uses spaces (as we use almost everywhere), please stick to that here. Regards, Timo

3 2

Re: [ros-dev] [ros-diffs] [akhaldi] 53527: [WIN32K] * Remove some useless asserts considering cLockObj is DWORD.
by Alex Ionescu 02 Sep '11

02 Sep '11

These asserts are not useless. A DWORD can also underflow (due to a bug), hence the point of these ASSERTs -- the only bug is that the ASSERT should cast to LONG. Best regards, Alex Ionescu On Fri, Sep 2, 2011 at 9:23 AM, <akhaldi(a)svn.reactos.org> wrote: > Author: akhaldi > Date: Fri Sep 2 09:23:20 2011 > New Revision: 53527 > > URL: http://svn.reactos.org/svn/reactos?rev=53527&view=rev > Log: > [WIN32K] > * Remove some useless asserts considering cLockObj is DWORD. > > Modified: > trunk/reactos/subsystems/win32/win32k/ntuser/menu.c > trunk/reactos/subsystems/win32/win32k/ntuser/monitor.c > trunk/reactos/subsystems/win32/win32k/ntuser/window.c > > Modified: trunk/reactos/subsystems/win32/win32k/ntuser/menu.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt… > > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/ntuser/menu.c [iso-8859-1] > (original) > +++ trunk/reactos/subsystems/win32/win32k/ntuser/menu.c [iso-8859-1] Fri > Sep 2 09:23:20 2011 > @@ -74,7 +74,6 @@ > return NULL; > } > > - ASSERT(Menu->head.cLockObj >= 0); > return Menu; > } > > @@ -137,11 +136,8 @@ > { > PMENU_OBJECT Menu = UserGetMenuObject(hMenu); > if (Menu) > - { > - ASSERT(Menu->head.cLockObj >= 0); > - > Menu->head.cLockObj++; > - } > + > return Menu; > } > > > Modified: trunk/reactos/subsystems/win32/win32k/ntuser/monitor.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt… > > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/ntuser/monitor.c [iso-8859-1] > (original) > +++ trunk/reactos/subsystems/win32/win32k/ntuser/monitor.c [iso-8859-1] Fri > Sep 2 09:23:20 2011 > @@ -93,8 +93,6 @@ > return NULL; > } > > - ASSERT(Monitor->head.cLockObj >= 0); > - > return Monitor; > } > > > Modified: trunk/reactos/subsystems/win32/win32k/ntuser/window.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt… > > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/ntuser/window.c [iso-8859-1] > (original) > +++ trunk/reactos/subsystems/win32/win32k/ntuser/window.c [iso-8859-1] Fri > Sep 2 09:23:20 2011 > @@ -61,11 +61,8 @@ > > Window = UserGetWindowObject(hWnd); > if (Window) > - { > - ASSERT(Window->head.cLockObj >= 0); > - > Window->head.cLockObj++; > - } > + > return Window; > } > > @@ -86,8 +83,6 @@ > EngSetLastError(ERROR_INVALID_WINDOW_HANDLE); > return NULL; > } > - > - ASSERT(Window->head.cLockObj >= 0); > > return Window; > } > > >

3 2

Re: [ros-dev] [ros-diffs] [dchapyshev] 53516: - Fix typos, found by PVS-Studio
by Thomas Faber 01 Sep '11

01 Sep '11

Hey again, On 2011-09-01 15:18, dchapyshev(a)svn.reactos.org wrote: > --- trunk/reactos/dll/win32/netshell/lanstatusui.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/netshell/lanstatusui.c [iso-8859-1] Thu Sep 1 13:18:22 2011 > @@ -179,7 +179,7 @@ > pContext->Status = 3; > } > } > - else if (IfEntry.dwOperStatus == MIB_IF_OPER_STATUS_UNREACHABLE || MIB_IF_OPER_STATUS_DISCONNECTED) > + else if (IfEntry.dwOperStatus == MIB_IF_OPER_STATUS_UNREACHABLE | MIB_IF_OPER_STATUS_DISCONNECTED) > { > if (pContext->Status != 4) > { > this should more likely be else if (IfEntry.dwOperStatus == MIB_IF_OPER_STATUS_UNREACHABLE || IfEntry.dwOperStatus == MIB_IF_OPER_STATUS_DISCONNECTED) Some nice fixes right there by the way. :) *hopes this might fix some evil bugs that have been lurking* ;) Thanks, Tom

1 0

Re: [ros-dev] [ros-diffs] [dchapyshev] 53513: - Fix wrong macros usage, found by PVS-Studio
by Thomas Faber 01 Sep '11

01 Sep '11

Hi, On 2011-09-01 14:34, dchapyshev(a)svn.reactos.org wrote: > --- trunk/reactos/lib/rtl/bitmap.c [iso-8859-1] (original) > +++ trunk/reactos/lib/rtl/bitmap.c [iso-8859-1] Thu Sep 1 12:34:51 2011 > @@ -339,7 +339,7 @@ > } > > /* Set all full ULONGs */ > - RtlFillMemoryUlong(Buffer, NumberToSet >> 3, MAXULONG); > + RtlFillMemoryUlong(Buffer, MAXULONG, NumberToSet >> 3); > Buffer += NumberToSet >> 5; > > /* Set what's left */ > > This is wrong. We don't want to fill 4GB of memory :) Regards, Tom

1 0

Re: [ros-dev] [ros-diffs] [jgardou] 53503: [WINETESTS/RPCRT4] Until now, rpcrt4 winetests where badly broken : client calls remotely forwarded to serverside functions which called... client side functions. One has to wonder...
by Aleksey Bragin 31 Aug '11

31 Aug '11

This breaks RBUILD-based build. More precisely these lines: +  + <define name="s_IServer_v0_0_s_ifspec">IServer_v0_0_s_ifspec</redefine> it seems to be already defined by something. WBR, Aleksey Bragin. -----Original Message----- From: jgardou(a)svn.reactos.org Sent: Wednesday, August 31, 2011 12:49 AM To: ros-diffs(a)reactos.org Subject: [ros-diffs] [jgardou] 53503: [WINETESTS/RPCRT4] Until now, rpcrt4 winetests where badly broken : client calls remotely forwarded to serverside functions which called... client side functions. One has to wonder... Author: jgardou Date: Tue Aug 30 20:49:31 2011 New Revision: 53503 URL: http://svn.reactos.org/svn/reactos?rev=53503&view=rev Log: [WINETESTS/RPCRT4] Until now, rpcrt4 winetests where badly broken : client calls remotely forwarded to serverside functions which called... client side functions. One has to wonder how testbot survived the operation - Cmake : fix that - rbuild : add a hack keeping the old behaviour, because I don't know how to make this right Modified: trunk/rostests/winetests/rpcrt4/CMakeLists.txt trunk/rostests/winetests/rpcrt4/rpcrt4.rbuild trunk/rostests/winetests/rpcrt4/server.c Modified: trunk/rostests/winetests/rpcrt4/CMakeLists.txt URL: http://svn.reactos.org/svn/reactos/trunk/rostests/winetests/rpcrt4/CMakeLis… ============================================================================== --- trunk/rostests/winetests/rpcrt4/CMakeLists.txt [iso-8859-1] (original) +++ trunk/rostests/winetests/rpcrt4/CMakeLists.txt [iso-8859-1] Tue Aug 30 20:49:31 2011 @@ -5,9 +5,16 @@ add_definitions( -D__ROS_LONG64__ -D_DLL -D__USE_CRTIMP) + +if(MSVC) + set(IDL_FLAGS ${IDL_FLAGS} /prefix server s_) +else() + set(IDL_FLAGS ${IDL_FLAGS} --prefix-server=s_) +endif() add_rpc_files(client server.idl) add_rpc_files(server server.idl) +unset(IDL_FLAGS) list(APPEND SOURCE cstub.c Modified: trunk/rostests/winetests/rpcrt4/rpcrt4.rbuild URL: http://svn.reactos.org/svn/reactos/trunk/rostests/winetests/rpcrt4/rpcrt4.r… ============================================================================== --- trunk/rostests/winetests/rpcrt4/rpcrt4.rbuild [iso-8859-1] (original) +++ trunk/rostests/winetests/rpcrt4/rpcrt4.rbuild [iso-8859-1] Tue Aug 30 20:49:31 2011 @@ -12,6 +12,8 @@ <include root="intermediate" base="rpcrt4_winetest">.</include> <define name="__ROS_LONG64__" /> <redefine name="_WIN32_WINNT">0x0500</redefine> +  + <define name="s_IServer_v0_0_s_ifspec">IServer_v0_0_s_ifspec</redefine> <library>wine</library> <library>pseh</library> <library>ole32</library> Modified: trunk/rostests/winetests/rpcrt4/server.c URL: http://svn.reactos.org/svn/reactos/trunk/rostests/winetests/rpcrt4/server.c… ============================================================================== --- trunk/rostests/winetests/rpcrt4/server.c [iso-8859-1] (original) +++ trunk/rostests/winetests/rpcrt4/server.c [iso-8859-1] Tue Aug 30 20:49:31 2011 @@ -1542,12 +1542,12 @@ if (pRpcServerRegisterIfEx) { trace("Using RpcServerRegisterIfEx\n"); - status = pRpcServerRegisterIfEx(IServer_v0_0_s_ifspec, NULL, NULL, + status = pRpcServerRegisterIfEx(s_IServer_v0_0_s_ifspec, NULL, NULL, RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH, RPC_C_LISTEN_MAX_CALLS_DEFAULT, NULL); } else - status = RpcServerRegisterIf(IServer_v0_0_s_ifspec, NULL, NULL); + status = RpcServerRegisterIf(s_IServer_v0_0_s_ifspec, NULL, NULL); ok(status == RPC_S_OK, "RpcServerRegisterIf failed with status %d\n", status); status = RpcServerListen(1, 20, TRUE); ok(status == RPC_S_OK, "RpcServerListen failed with status %d\n", status);

1 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 53496: [HAL] We cannot make any assumptions about the latency whith which the timer interrupt fires after a rollover, since VBox (other VMs probably as well) doesn't always meet this. Ad...
by Alex Ionescu 31 Aug '11

31 Aug '11

Funny how Windows works without these hacks. Let's hide more bugs :D Best regards, Alex Ionescu On Tue, Aug 30, 2011 at 12:01 PM, <tkreuzer(a)svn.reactos.org> wrote: > Author: tkreuzer > Date: Tue Aug 30 12:01:01 2011 > New Revision: 53496 > > URL: http://svn.reactos.org/svn/reactos?rev=53496&view=rev > Log: > [HAL] > We cannot make any assumptions about the latency whith which the timer > interrupt fires after a rollover, since VBox (other VMs probably as well) > doesn't always meet this. Add another check to KeQueryPerformanceCounter > that gracefully handles missing interrupts. Also raise to DISPATCH_LEVEL, > since the function is not reentrant. > > Modified: > trunk/reactos/hal/halx86/generic/timer.c > > Modified: trunk/reactos/hal/halx86/generic/timer.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/generic/timer.c… > > ============================================================================== > --- trunk/reactos/hal/halx86/generic/timer.c [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/generic/timer.c [iso-8859-1] Tue Aug 30 > 12:01:01 2011 > @@ -253,6 +253,7 @@ > { > LARGE_INTEGER CurrentPerfCounter; > ULONG CounterValue, ClockDelta; > + KIRQL OldIrql; > > /* If caller wants performance frequency, return hardcoded value */ > if (PerformanceFrequency) PerformanceFrequency->QuadPart = > PIT_FREQUENCY; > @@ -262,6 +263,10 @@ > > /* Check if interrupts are disabled */ > if(!(__readeflags() & EFLAGS_INTERRUPT_MASK)) return HalpPerfCounter; > + > + /* Raise irql to DISPATCH_LEVEL */ > + OldIrql = KeGetCurrentIrql(); > + if (OldIrql < DISPATCH_LEVEL) KfRaiseIrql(DISPATCH_LEVEL); > > do > { > @@ -287,13 +292,21 @@ > /* Add the clock delta */ > CurrentPerfCounter.QuadPart += ClockDelta; > > - /* This must be true unless HalpPerfCounter has changed sign, > - which takes approximately 245,118 years */ > - ASSERT(CurrentPerfCounter.QuadPart >= HalpLastPerfCounter.QuadPart); > + /* Check if the value is smaller then before, this means, we somehow > + missed an interrupt. This is a sign that the timer interrupt > + is very inaccurate. Probably a virtual machine. */ > + if (CurrentPerfCounter.QuadPart < HalpLastPerfCounter.QuadPart) > + { > + /* We missed an interrupt. Assume we will receive it later */ > + CurrentPerfCounter.QuadPart += HalpCurrentRollOver; > + } > > /* Update the last counter value */ > HalpLastPerfCounter = CurrentPerfCounter; > > + /* Restore previous irql */ > + if (OldIrql < DISPATCH_LEVEL) KfLowerIrql(OldIrql); > + > /* Return the result */ > return CurrentPerfCounter; > } > > >

2 1

ReactOS unattended.inf
by Mario Gzuk 30 Aug '11

30 Aug '11

Hi, I am the maintainer of uranos (http://uranos.sf.net) and want to implement the unattended setup of ReactOS into uranos. I read that you have implemented a answer file into ReactOS. Because of uranos does all the parts which is done by the txtinstaller from ReactOS (partition disk, write mbr, copy files and so on) from a linux boot environment - I want to know if it is possible to place the unattended.inf into the filesystem so the ReactOS is read the file in the first GUI boot. Thank you! Cheers mario

3 5

Re: [ros-dev] [ros-diffs] [tkreuzer] 53494: [INTRIN] - add __nop()
by Alex Ionescu 30 Aug '11

30 Aug '11

Can you also add __noop please? Best regards, Alex Ionescu On Mon, Aug 29, 2011 at 11:10 PM, <tkreuzer(a)svn.reactos.org> wrote: > Author: tkreuzer > Date: Mon Aug 29 23:10:04 2011 > New Revision: 53494 > > URL: http://svn.reactos.org/svn/reactos?rev=53494&view=rev > Log: > [INTRIN] > - add __nop() > > Modified: > trunk/reactos/include/crt/mingw32/intrin_x86.h > > Modified: trunk/reactos/include/crt/mingw32/intrin_x86.h > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/include/crt/mingw32/intrin… > > ============================================================================== > --- trunk/reactos/include/crt/mingw32/intrin_x86.h [iso-8859-1] (original) > +++ trunk/reactos/include/crt/mingw32/intrin_x86.h [iso-8859-1] Mon Aug 29 > 23:10:04 2011 > @@ -1505,11 +1505,18 @@ > __asm__ __volatile__("sidt %0" : : "m"(*(short*)Destination) : > "memory"); > } > > +/*** Misc operations ***/ > + > __INTRIN_INLINE void _mm_pause(void) > { > __asm__ __volatile__("pause" : : : "memory"); > } > > +__INTRIN_INLINE void __nop(void) > +{ > + __asm__ __volatile__("nop"); > +} > + > #ifdef __cplusplus > } > #endif > > >

2 1

Re: [ros-dev] [ros-diffs] [jgardou] 53481: [WIDL] - reenable -Oif flag, it's too good to be disabled With this commit, advapi32:service winetest suffers only 2 failures.
by Jérôme Gardou 28 Aug '11

28 Aug '11

Feel free to disable it again if probems occur. "Probable bugs" are hard to test alone, so I'm waiting for test bot to confirm this fixes things without breaking others. Regards. Jérôme. Le 28/08/2011 17:37, jgardou(a)svn.reactos.org a écrit : > Author: jgardou > Date: Sun Aug 28 15:37:01 2011 > New Revision: 53481 > > URL: http://svn.reactos.org/svn/reactos?rev=53481&view=rev > Log: > [WIDL] > - reenable -Oif flag, it's too good to be disabled > With this commit, advapi32:service winetest suffers only 2 failures. > > Modified: > trunk/reactos/cmake/idl-support.cmake > trunk/reactos/tools/rbuild/backend/mingw/rules.mak > > Modified: trunk/reactos/cmake/idl-support.cmake > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/cmake/idl-support.cmake?re… > ============================================================================== > --- trunk/reactos/cmake/idl-support.cmake [iso-8859-1] (original) > +++ trunk/reactos/cmake/idl-support.cmake [iso-8859-1] Sun Aug 28 15:37:01 2011 > @@ -22,8 +22,8 @@ > set(IDL_HEADER_ARG -h -o) #.h > set(IDL_HEADER_ARG2 -h -H) #.h > set(IDL_TYPELIB_ARG -t -o) #.tlb > - set(IDL_SERVER_ARG -s -o) #.c for server library > - set(IDL_CLIENT_ARG -c -o) #.c for stub client library > + set(IDL_SERVER_ARG -Oif -s -o) #.c for server library > + set(IDL_CLIENT_ARG -Oif -c -o) #.c for stub client library > set(IDL_PROXY_ARG -p -o) > set(IDL_INTERFACE_ARG -u -o) > if(ARCH MATCHES i386) > @@ -169,6 +169,6 @@ > list(APPEND IID_SOURCES ${NAME}_i.c) > endforeach() > add_library(${TARGET} ${IID_SOURCES}) > - add_dependencies(${TARGET} psdk) > + add_dependencies(${TARGET} psdk) > set_target_properties(${TARGET} PROPERTIES EXCLUDE_FROM_ALL TRUE) > endfunction() > > Modified: trunk/reactos/tools/rbuild/backend/mingw/rules.mak > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/rbuild/backend/mingw… > ============================================================================== > --- trunk/reactos/tools/rbuild/backend/mingw/rules.mak [iso-8859-1] (original) > +++ trunk/reactos/tools/rbuild/backend/mingw/rules.mak [iso-8859-1] Sun Aug 28 15:37:01 2011 > @@ -264,7 +264,7 @@ > > ${call RBUILD_intermediate_path_noext,$(2)}_c: $(2) $(3) $$(widl_TARGET) | ${call RBUILD_intermediate_dir,$(2)} > $$(ECHO_WIDL) > - $$(Q)$$(widl_TARGET) ${call RBUILD_midlflags,$(1),$(4),-I${call RBUILD_dir,$(2)}} -h -H ${call RBUILD_intermediate_path_noext,$(2)}_c.h -c -C ${call RBUILD_intermediate_path_noext,$(2)}_c.c $(2) > + $$(Q)$$(widl_TARGET) ${call RBUILD_midlflags,$(1),$(4),-I${call RBUILD_dir,$(2)}} -Oif -h -H ${call RBUILD_intermediate_path_noext,$(2)}_c.h -c -C ${call RBUILD_intermediate_path_noext,$(2)}_c.c $(2) > $${checkpoint} $$@>$(NUL) > > ${call RBUILD_CC,$(1),${call RBUILD_intermediate_path_noext,$(2)}_c.c,,,${call RBUILD_intermediate_path_noext,$(2)}_c.o} > @@ -280,7 +280,7 @@ > > ${call RBUILD_intermediate_path_noext,$(2)}_s: $(2) $(3) $$(widl_TARGET) | ${call RBUILD_intermediate_dir,$(2)} > $$(ECHO_WIDL) > - $$(Q)$$(widl_TARGET) ${call RBUILD_midlflags,$(1),$(4),-I${call RBUILD_dir,$(2)}} -h -H ${call RBUILD_intermediate_path_noext,$(2)}_s.h -s -S ${call RBUILD_intermediate_path_noext,$(2)}_s.c $(2) > + $$(Q)$$(widl_TARGET) ${call RBUILD_midlflags,$(1),$(4),-I${call RBUILD_dir,$(2)}} -Oif -h -H ${call RBUILD_intermediate_path_noext,$(2)}_s.h -s -S ${call RBUILD_intermediate_path_noext,$(2)}_s.c $(2) > $${checkpoint} $$@>$(NUL) > > ${call RBUILD_CC,$(1),${call RBUILD_intermediate_path_noext,$(2)}_s.c,,,${call RBUILD_intermediate_path_noext,$(2)}_s.o} > >

3 2

(no subject)
by Dimas FranK 28 Aug '11

28 Aug '11

I want to do some testing on physical machines until now was doing the vbox will charge the machine a good desepenho memory and I'll need to spend sitema ospedeiro vbox and the problem and that the machines do not have a serial port was taking a look at these wiki but did not see exact references on how to get the debug log on the cable network vbox but works well for the network that will be with you http://www.reactos.org/wiki/Debugging http://www.reactos.org/wiki/ReactOS_Remote_Debugger#TCP.2FIP_.28QEMU_only.29

3 2

Re: [ros-dev] [ros-diffs] [ekohl] 53469: [WIDL] Revert parts of r53171: Remove the -Oif flag for WIDL because the NT4 stub code generated by the current WIDL is heavily broken with respect to the range attribute and others....
by Jérôme Gardou 28 Aug '11

28 Aug '11

HI Eric! I'm not sure about what you mean for range attribute, but I notice that typedef [context_handle] PVOID my_handle; makes widl thinks that any value of the my_handle type is passed by pointer, whereas midl considers it is passed by value. Could you be more precise about "range attributes and others?" please. Regards. Jérôme. Le 27/08/2011 18:24, ekohl(a)svn.reactos.org a écrit : > Author: ekohl > Date: Sat Aug 27 16:24:40 2011 > New Revision: 53469 > > URL: http://svn.reactos.org/svn/reactos?rev=53469&view=rev > Log: > [WIDL] > Revert parts of r53171: > Remove the -Oif flag for WIDL because the NT4 stub code generated by the current WIDL is heavily broken with respect to the range attribute and others. Please enable the -Oif feature only after these bugs are fixed in WIDL! > > Modified: > trunk/reactos/cmake/idl-support.cmake > trunk/reactos/tools/rbuild/backend/mingw/rules.mak > > Modified: trunk/reactos/cmake/idl-support.cmake > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/cmake/idl-support.cmake?re… > ============================================================================== > --- trunk/reactos/cmake/idl-support.cmake [iso-8859-1] (original) > +++ trunk/reactos/cmake/idl-support.cmake [iso-8859-1] Sat Aug 27 16:24:40 2011 > @@ -22,8 +22,8 @@ > set(IDL_HEADER_ARG -h -o) #.h > set(IDL_HEADER_ARG2 -h -H) #.h > set(IDL_TYPELIB_ARG -t -o) #.tlb > - set(IDL_SERVER_ARG -Oif -s -o) #.c for server library > - set(IDL_CLIENT_ARG -Oif -c -o) #.c for stub client library > + set(IDL_SERVER_ARG -s -o) #.c for server library > + set(IDL_CLIENT_ARG -c -o) #.c for stub client library > set(IDL_PROXY_ARG -p -o) > set(IDL_INTERFACE_ARG -u -o) > if(ARCH MATCHES i386) > @@ -169,6 +169,6 @@ > list(APPEND IID_SOURCES ${NAME}_i.c) > endforeach() > add_library(${TARGET} ${IID_SOURCES}) > - add_dependencies(${TARGET} psdk) > + add_dependencies(${TARGET} psdk) > set_target_properties(${TARGET} PROPERTIES EXCLUDE_FROM_ALL TRUE) > endfunction() > > Modified: trunk/reactos/tools/rbuild/backend/mingw/rules.mak > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/rbuild/backend/mingw… > ============================================================================== > --- trunk/reactos/tools/rbuild/backend/mingw/rules.mak [iso-8859-1] (original) > +++ trunk/reactos/tools/rbuild/backend/mingw/rules.mak [iso-8859-1] Sat Aug 27 16:24:40 2011 > @@ -264,7 +264,7 @@ > > ${call RBUILD_intermediate_path_noext,$(2)}_c: $(2) $(3) $$(widl_TARGET) | ${call RBUILD_intermediate_dir,$(2)} > $$(ECHO_WIDL) > - $$(Q)$$(widl_TARGET) ${call RBUILD_midlflags,$(1),$(4),-I${call RBUILD_dir,$(2)}} -Oif -h -H ${call RBUILD_intermediate_path_noext,$(2)}_c.h -c -C ${call RBUILD_intermediate_path_noext,$(2)}_c.c $(2) > + $$(Q)$$(widl_TARGET) ${call RBUILD_midlflags,$(1),$(4),-I${call RBUILD_dir,$(2)}} -h -H ${call RBUILD_intermediate_path_noext,$(2)}_c.h -c -C ${call RBUILD_intermediate_path_noext,$(2)}_c.c $(2) > $${checkpoint} $$@>$(NUL) > > ${call RBUILD_CC,$(1),${call RBUILD_intermediate_path_noext,$(2)}_c.c,,,${call RBUILD_intermediate_path_noext,$(2)}_c.o} > @@ -280,7 +280,7 @@ > > ${call RBUILD_intermediate_path_noext,$(2)}_s: $(2) $(3) $$(widl_TARGET) | ${call RBUILD_intermediate_dir,$(2)} > $$(ECHO_WIDL) > - $$(Q)$$(widl_TARGET) ${call RBUILD_midlflags,$(1),$(4),-I${call RBUILD_dir,$(2)}} -Oif -h -H ${call RBUILD_intermediate_path_noext,$(2)}_s.h -s -S ${call RBUILD_intermediate_path_noext,$(2)}_s.c $(2) > + $$(Q)$$(widl_TARGET) ${call RBUILD_midlflags,$(1),$(4),-I${call RBUILD_dir,$(2)}} -h -H ${call RBUILD_intermediate_path_noext,$(2)}_s.h -s -S ${call RBUILD_intermediate_path_noext,$(2)}_s.c $(2) > $${checkpoint} $$@>$(NUL) > > ${call RBUILD_CC,$(1),${call RBUILD_intermediate_path_noext,$(2)}_s.c,,,${call RBUILD_intermediate_path_noext,$(2)}_s.o} > >

3 5

Sugetao
by Dimas FranK 27 Aug '11

27 Aug '11

I obeservado that companies have made the opening of perfius on social sites like orkte, face buk to have a closer contacts with its customers Suggestions Taves Foce the time to develop a page-pink similar to orkut only for pelomenos emvolvidos list of ros-dev communicate mellhor we take for example the option orkut This allows you to replaying a message to the entire group or just for some or open a profile but it would be the maintainer of the profile to select some options has some social networks that desacoselho to be very open but partially open orkut and where he has partial control of where and where does the information would be very nice to have something in ros.org or maybe opening a profile on some these social networks a method would be to discuss and APREDE programs in a more dynamic

2 1

Uma Questao
by Dimas FranK 27 Aug '11

27 Aug '11

A Matter discursoes saw some about the future of Roses A sugentao as a powerful gaming machine MaxiVista server and at the same time continue the development of financial markets and earn some cash to the developers and everyone involved in the project we will take as examples the maximum this game is notable that the projects do not get for the day for the night

2 1

Re: [ros-dev] Ros-dev Digest, Vol 84, Issue 22
by Dimas FranK 27 Aug '11

27 Aug '11

When complete the installation of the driver placa GF8200A shipeset 8200 Through the message that the dll not found Wow32.dll MainFrameBase::OpenShellFolders():parent_pidl=C:\Documents and Settgs\Administrator\Desktop MainFrameBase::OpenShellFolders(): pidl_abs=(null) (drivers\filesystems\cdfs\create.c:148) Status c0000013 (drivers\filesystems\cdfs\create.c:148) Status c0000013 (drivers\flesystems\cdfs\common.c:196) STATUS_VERIFY_REQUIRED (drivers\filesystems\cdfs\fsctl.c:590) CDFS: IRP_MN_VERIFY_VOLUME (drivers\filesystems\cdfs\fsctl.c:467) CdfsVerifyVolume() called (drivers\filesystems\cdfs\fsctl.c:494) Deviceobject B1285A48 Device to verify B1285A48 (drivers\filesystems\cdfs\devctrl.c:34) FIXME: CdfsDevieControl called without FileObjec! (drivers\filesystems\cdfs\fsct.c:511) Different volume! (drives\filesystems\cdfs\fsctl.c:518) OenFile \ RefCount 1 (drivers\fiesystems\cdfs\fsctl.c:518) OpenFie \loader RefCount 0 (drivers\flesystems\cdfs\fsctl.c:518) OpenFile \reactos RefCount 0 (drivers\filesystems\cdfs\fsctl.c:518) OenFile \reactos\system32 RefCoun 0 (drivers\filesystems\cdfs\common.c203) IoVerifyVolume() returned (Status c0000012) (drivers\filesysems\cdfs\create.c:148) Status 8000016 MainFrameBase::OpenShellFolders():parent_pidl=(null) MainFrameBase:OpenShellFolders(): pidl_abs=D:\ MDIMainFrame PM_OPEN_WINDOW: pat=D:\ MainFrameBase::OpenShellFolders():rent_pidl=D:\ (lib\rtl\path.c:256) don't keep the directory handl open on removable media (dll\ntdll\ldr\utils.c:2301) Faile to create or open dll section of'WOW32.DLL' (Status c0000135) (d\ntdll\ldr\utils.c:1512) failed tload WOW32.DLL (subsystems\win32csrss\csrsrv\api\wapi.c:115) CSR:received hard error c0000135 WARNING: MmLockPageableDataSectio at ntoskrnl\mm\ARM3\drvmgmt.c:62s UNIMPLEMENTED! WARNING: MmUnlockPageableImageSecon at ntoskrnl\mm\ARM3\drvmgmt.c: is UNIMPLEMENTED! (ntoskrnl\se\semgr.c:299) SidInTok Calls: 30000 2011/8/26, ros-dev-request(a)reactos.org <ros-dev-request(a)reactos.org>: > Send Ros-dev mailing list submissions to > ros-dev(a)reactos.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.reactos.org/mailman/listinfo/ros-dev > or, via email, send a message with subject or body 'help' to > ros-dev-request(a)reactos.org > > You can reach the person managing the list at > ros-dev-owner(a)reactos.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Ros-dev digest..." > > > Today's Topics: > > 1. Re: Debug Buildslave Maintenance (caemyr(a)myopera.com) > 2. Re: Debug Buildslave Maintenance (Eric Kohl) > 3. Re: [ros-diffs] [fireball] 53446: [NTDLL/LDR] - Fix wrong > loop condition which would often lead to heap underread. - Fix > wrong subkey string length calculation, which would result in an > incorrect string being used... (Ged Murphy) > 4. Re: [ros-diffs] [fireball] 53446: [NTDLL/LDR] - Fix wrong > loop condition which would often lead to heap underread. - Fix > wrong subkey string length calculation, which would result in an > incorrect string being used... (Aleksey Bragin) > 5. Re: Debug Buildslave Maintenance (Aleksey Bragin) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 25 Aug 2011 23:29:55 +0200 > From: caemyr(a)myopera.com > Subject: Re: [ros-dev] Debug Buildslave Maintenance > To: "ReactOS Development List" <ros-dev(a)reactos.org> > Message-ID: > <1314307795.18690.140258133790149(a)webmail.messagingengine.com> > Content-Type: text/plain; charset="us-ascii" > > @Eric > > http://reactos.org/testman/compare.php?ids=7429,7579 > http://reactos.org/testman/detail.php?id=2639952 > > Please find that the crash is not CMake related, and CMake build is not > inherently broken. > > On Thu, 25 Aug 2011 23:03 +0200, "Pierre Schweitzer" > <pierre.schweitzer(a)reactos.org> wrote: >> Hi, >> >> finally. >> Colin and I are pleased to announce you that ReactOS Linux KVM tests are >> back online and working. You can find the first tests results (on r53383) >> sent tonight by the testbot on testman: http://www.reactos.org/testman/. >> >> Regards, >> Pierre. >> >> ReactOS Development List <ros-dev(a)reactos.org> wrote on Sat, August 20th, >> 2011, 4:24 PM: >> > Timo Kreuzer <timo.kreuzer(a)web.de> wrote: >> > > What about fixing release buildbot first? >> > >> > It's still a private machine owned and administered solely by Christoph. >> > >> > As long as I can't even reach him by phone, we can only wait. >> > >> > >> > > And is there a chance, maybe in the future, to switch buildbots more >> > > easily, to have a backup solution running? >> > >> > First of all, we hope that we can get the same reliability as our other >> > servers after reinstalling the server OS, giving more ReactOS admins >> > access to the machine and adding monitoring. >> > The current OS was meant to be reinstalled for quite a long time, but up >> > >> > to now, nobody with physical access to the machine had any time to do >> > it. >> > >> > If such problems continue to exist afterwards, we can try to set up a >> > fallback system, but this would require an equally configured and >> > powerful Linux machine first. >> > >> > >> > > One week without debug builds is a serious thing. >> > >> > I hope you're aware that builds are still properly uploaded, it's only >> > the testing step which fails. >> > >> > >> > - Colin >> > >> > _______________________________________________ >> > Ros-dev mailing list >> > Ros-dev(a)reactos.org >> > http://www.reactos.org/mailman/listinfo/ros-dev >> >> _______________________________________________ >> Ros-dev mailing list >> Ros-dev(a)reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >> > With best regards > Caemyr > > > > ------------------------------ > > Message: 2 > Date: Fri, 26 Aug 2011 01:01:40 +0200 > From: Eric Kohl <eric.kohl(a)t-online.de> > Subject: Re: [ros-dev] Debug Buildslave Maintenance > To: ReactOS Development List <ros-dev(a)reactos.org> > Message-ID: <4E56D454.6060606(a)t-online.de> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Olaf, > > I am already investigating the services test issues. One of my first > findings is that the current widl seems to mess up value ranges in some > cases. This is the cause of the following errors: > err:(dll/win32/rpcrt4/ndr_marshall.c:6496) value exceeded bounds: 918, > low: 0, high: 514 > > <rant> > It is pretty annoying that jgardou updated rpcrt4, widl and other > components without proper testing. At least he should have posted a bug > list BEFORE he comitted the new stuff. > </rant> > > Regards > Eric > >> @Eric >> >> http://reactos.org/testman/compare.php?ids=7429,7579 >> http://reactos.org/testman/detail.php?id=2639952 >> >> Please find that the crash is not CMake related, and CMake build is not >> inherently broken. >> > > > > ------------------------------ > > Message: 3 > Date: Fri, 26 Aug 2011 09:05:21 +0100 > From: "Ged Murphy" <gedmurphy.maillists(a)gmail.com> > Subject: Re: [ros-dev] [ros-diffs] [fireball] 53446: [NTDLL/LDR] - Fix > wrong loop condition which would often lead to heap underread. - Fix > wrong subkey string length calculation, which would result in an > incorrect string being used... > To: <ros-dev(a)reactos.org> > Message-ID: <004201cc63c6$e7a44a40$b6ecdec0$(a)gmail.com> > Content-Type: text/plain; charset="utf-8" > > fireball(a)svn.reactos.org wrote: > >> - Use Zw* functions instead of Nt* where necessary in >> LdrQueryImageFileKeyOption(). > > 'where necessary'm I don't understand this change. > People prefer (and Microsoft recommend) that Nt* is used in usermode. > Nt and Zw APIs point to the same address in usermode, so why is it > necessary? > > Ged. > > > > > > ------------------------------ > > Message: 4 > Date: Fri, 26 Aug 2011 12:13:26 +0400 > From: Aleksey Bragin <aleksey(a)reactos.org> > Subject: Re: [ros-dev] [ros-diffs] [fireball] 53446: [NTDLL/LDR] - Fix > wrong loop condition which would often lead to heap underread. - Fix > wrong subkey string length calculation, which would result in an > incorrect string being used... > To: ReactOS Development List <ros-dev(a)reactos.org> > Message-ID: <7766A32C-3CB0-446A-96F4-4EDC73BC3A29(a)reactos.org> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > > On Aug 26, 2011, at 12:05 PM, Ged Murphy wrote: > >> fireball(a)svn.reactos.org wrote: >> >>> - Use Zw* functions instead of Nt* where necessary in >>> LdrQueryImageFileKeyOption(). >> >> 'where necessary'm I don't understand this change. >> People prefer (and Microsoft recommend) that Nt* is used in usermode. >> Nt and Zw APIs point to the same address in usermode, so why is it >> necessary? > > This was a test for attention, and so far I got a few notices in IRC > and one in ros-dev. Good! > > Seriously, the change slipped through because I was editing source > code of both RTL (which works both at umode and kmode) and NTDLL/LDR > (which is only umode) a while ago. Of course, Nt is "preferable" in > usermode because there is just no reason to use Zw there. > > > WBR, > Aleksey Bragin. > > > > > ------------------------------ > > Message: 5 > Date: Fri, 26 Aug 2011 12:15:24 +0400 > From: Aleksey Bragin <aleksey(a)reactos.org> > Subject: Re: [ros-dev] Debug Buildslave Maintenance > To: ReactOS Development List <ros-dev(a)reactos.org> > Message-ID: <1F3FEE77-59BC-4D24-83A9-5D280FB45966(a)reactos.org> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > > On Aug 26, 2011, at 3:01 AM, Eric Kohl wrote: > >> <rant> >> It is pretty annoying that jgardou updated rpcrt4, widl and other >> components without proper testing. At least he should have posted a >> bug list BEFORE he comitted the new stuff. >> </rant> > I also ranted about that. In fact that's why I stopped syncing rpcrt4 > some time ago - because new version always gave problems. So I wanted > to solve problems first and only then commit. > > But, OK, as Olaf said - if something needs to be done, let's simply > do that and fix everything which broke ;). > > WBR, > Aleksey. > > > > > ------------------------------ > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > > End of Ros-dev Digest, Vol 84, Issue 22 > *************************************** >

1 1

Re: [ros-dev] Ros-dev Digest, Vol 84, Issue 22
by Dimas FranK 26 Aug '11

26 Aug '11

When complete the installation of the driver placa GF8200A shipeset 8200 Through the message that the dll not found Wow32.dll 2011/8/26, ros-dev-request(a)reactos.org <ros-dev-request(a)reactos.org>: > Send Ros-dev mailing list submissions to > ros-dev(a)reactos.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.reactos.org/mailman/listinfo/ros-dev > or, via email, send a message with subject or body 'help' to > ros-dev-request(a)reactos.org > > You can reach the person managing the list at > ros-dev-owner(a)reactos.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Ros-dev digest..." > > > Today's Topics: > > 1. Re: Debug Buildslave Maintenance (caemyr(a)myopera.com) > 2. Re: Debug Buildslave Maintenance (Eric Kohl) > 3. Re: [ros-diffs] [fireball] 53446: [NTDLL/LDR] - Fix wrong > loop condition which would often lead to heap underread. - Fix > wrong subkey string length calculation, which would result in an > incorrect string being used... (Ged Murphy) > 4. Re: [ros-diffs] [fireball] 53446: [NTDLL/LDR] - Fix wrong > loop condition which would often lead to heap underread. - Fix > wrong subkey string length calculation, which would result in an > incorrect string being used... (Aleksey Bragin) > 5. Re: Debug Buildslave Maintenance (Aleksey Bragin) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 25 Aug 2011 23:29:55 +0200 > From: caemyr(a)myopera.com > Subject: Re: [ros-dev] Debug Buildslave Maintenance > To: "ReactOS Development List" <ros-dev(a)reactos.org> > Message-ID: > <1314307795.18690.140258133790149(a)webmail.messagingengine.com> > Content-Type: text/plain; charset="us-ascii" > > @Eric > > http://reactos.org/testman/compare.php?ids=7429,7579 > http://reactos.org/testman/detail.php?id=2639952 > > Please find that the crash is not CMake related, and CMake build is not > inherently broken. > > On Thu, 25 Aug 2011 23:03 +0200, "Pierre Schweitzer" > <pierre.schweitzer(a)reactos.org> wrote: >> Hi, >> >> finally. >> Colin and I are pleased to announce you that ReactOS Linux KVM tests are >> back online and working. You can find the first tests results (on r53383) >> sent tonight by the testbot on testman: http://www.reactos.org/testman/. >> >> Regards, >> Pierre. >> >> ReactOS Development List <ros-dev(a)reactos.org> wrote on Sat, August 20th, >> 2011, 4:24 PM: >> > Timo Kreuzer <timo.kreuzer(a)web.de> wrote: >> > > What about fixing release buildbot first? >> > >> > It's still a private machine owned and administered solely by Christoph. >> > >> > As long as I can't even reach him by phone, we can only wait. >> > >> > >> > > And is there a chance, maybe in the future, to switch buildbots more >> > > easily, to have a backup solution running? >> > >> > First of all, we hope that we can get the same reliability as our other >> > servers after reinstalling the server OS, giving more ReactOS admins >> > access to the machine and adding monitoring. >> > The current OS was meant to be reinstalled for quite a long time, but up >> > >> > to now, nobody with physical access to the machine had any time to do >> > it. >> > >> > If such problems continue to exist afterwards, we can try to set up a >> > fallback system, but this would require an equally configured and >> > powerful Linux machine first. >> > >> > >> > > One week without debug builds is a serious thing. >> > >> > I hope you're aware that builds are still properly uploaded, it's only >> > the testing step which fails. >> > >> > >> > - Colin >> > >> > _______________________________________________ >> > Ros-dev mailing list >> > Ros-dev(a)reactos.org >> > http://www.reactos.org/mailman/listinfo/ros-dev >> >> _______________________________________________ >> Ros-dev mailing list >> Ros-dev(a)reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >> > With best regards > Caemyr > > > > ------------------------------ > > Message: 2 > Date: Fri, 26 Aug 2011 01:01:40 +0200 > From: Eric Kohl <eric.kohl(a)t-online.de> > Subject: Re: [ros-dev] Debug Buildslave Maintenance > To: ReactOS Development List <ros-dev(a)reactos.org> > Message-ID: <4E56D454.6060606(a)t-online.de> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Olaf, > > I am already investigating the services test issues. One of my first > findings is that the current widl seems to mess up value ranges in some > cases. This is the cause of the following errors: > err:(dll/win32/rpcrt4/ndr_marshall.c:6496) value exceeded bounds: 918, > low: 0, high: 514 > > <rant> > It is pretty annoying that jgardou updated rpcrt4, widl and other > components without proper testing. At least he should have posted a bug > list BEFORE he comitted the new stuff. > </rant> > > Regards > Eric > >> @Eric >> >> http://reactos.org/testman/compare.php?ids=7429,7579 >> http://reactos.org/testman/detail.php?id=2639952 >> >> Please find that the crash is not CMake related, and CMake build is not >> inherently broken. >> > > > > ------------------------------ > > Message: 3 > Date: Fri, 26 Aug 2011 09:05:21 +0100 > From: "Ged Murphy" <gedmurphy.maillists(a)gmail.com> > Subject: Re: [ros-dev] [ros-diffs] [fireball] 53446: [NTDLL/LDR] - Fix > wrong loop condition which would often lead to heap underread. - Fix > wrong subkey string length calculation, which would result in an > incorrect string being used... > To: <ros-dev(a)reactos.org> > Message-ID: <004201cc63c6$e7a44a40$b6ecdec0$(a)gmail.com> > Content-Type: text/plain; charset="utf-8" > > fireball(a)svn.reactos.org wrote: > >> - Use Zw* functions instead of Nt* where necessary in >> LdrQueryImageFileKeyOption(). > > 'where necessary'm I don't understand this change. > People prefer (and Microsoft recommend) that Nt* is used in usermode. > Nt and Zw APIs point to the same address in usermode, so why is it > necessary? > > Ged. > > > > > > ------------------------------ > > Message: 4 > Date: Fri, 26 Aug 2011 12:13:26 +0400 > From: Aleksey Bragin <aleksey(a)reactos.org> > Subject: Re: [ros-dev] [ros-diffs] [fireball] 53446: [NTDLL/LDR] - Fix > wrong loop condition which would often lead to heap underread. - Fix > wrong subkey string length calculation, which would result in an > incorrect string being used... > To: ReactOS Development List <ros-dev(a)reactos.org> > Message-ID: <7766A32C-3CB0-446A-96F4-4EDC73BC3A29(a)reactos.org> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > > On Aug 26, 2011, at 12:05 PM, Ged Murphy wrote: > >> fireball(a)svn.reactos.org wrote: >> >>> - Use Zw* functions instead of Nt* where necessary in >>> LdrQueryImageFileKeyOption(). >> >> 'where necessary'm I don't understand this change. >> People prefer (and Microsoft recommend) that Nt* is used in usermode. >> Nt and Zw APIs point to the same address in usermode, so why is it >> necessary? > > This was a test for attention, and so far I got a few notices in IRC > and one in ros-dev. Good! > > Seriously, the change slipped through because I was editing source > code of both RTL (which works both at umode and kmode) and NTDLL/LDR > (which is only umode) a while ago. Of course, Nt is "preferable" in > usermode because there is just no reason to use Zw there. > > > WBR, > Aleksey Bragin. > > > > > ------------------------------ > > Message: 5 > Date: Fri, 26 Aug 2011 12:15:24 +0400 > From: Aleksey Bragin <aleksey(a)reactos.org> > Subject: Re: [ros-dev] Debug Buildslave Maintenance > To: ReactOS Development List <ros-dev(a)reactos.org> > Message-ID: <1F3FEE77-59BC-4D24-83A9-5D280FB45966(a)reactos.org> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > > On Aug 26, 2011, at 3:01 AM, Eric Kohl wrote: > >> <rant> >> It is pretty annoying that jgardou updated rpcrt4, widl and other >> components without proper testing. At least he should have posted a >> bug list BEFORE he comitted the new stuff. >> </rant> > I also ranted about that. In fact that's why I stopped syncing rpcrt4 > some time ago - because new version always gave problems. So I wanted > to solve problems first and only then commit. > > But, OK, as Olaf said - if something needs to be done, let's simply > do that and fix everything which broke ;). > > WBR, > Aleksey. > > > > > ------------------------------ > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > > End of Ros-dev Digest, Vol 84, Issue 22 > *************************************** >

1 0

Debug Buildslave Maintenance
by Colin Finck 26 Aug '11

26 Aug '11

Hello all, The Debug Buildslave will be down for maintenance throughout the next week. We hope to have it fully working again by next weekend. In the process of this maintenance, the OS will be reinstalled to match the one we already use on our other servers. Besides, more of our administrators will get access to the machine, so that further problems can be debugged more easily. - Colin

6 9

Re: [ros-dev] [ros-diffs] [fireball] 53446: [NTDLL/LDR] - Fix wrong loop condition which would often lead to heap underread. - Fix wrong subkey string length calculation, which would result in an incorrect string being used...
by Ged Murphy 26 Aug '11

26 Aug '11

fireball(a)svn.reactos.org wrote: > - Use Zw* functions instead of Nt* where necessary in LdrQueryImageFileKeyOption(). 'where necessary'm I don't understand this change. People prefer (and Microsoft recommend) that Nt* is used in usermode. Nt and Zw APIs point to the same address in usermode, so why is it necessary? Ged.

2 1

August meeting
by Aleksey Bragin 25 Aug '11

25 Aug '11

Hi, this is a reminder about the Status meeting, which is to happen tomorrow, 25th of August at 19:00 UTC. Please don't miss it. Proposed agenda for the meeting: 1. Arwinss adoption voting. 2. CMake adoption voting. 3. Release preparation status report, deciding on the next release date. 4. Driver signing. Discussing possible threats and deciding on an official position wrt driver signing in future. 4. Party related to GSoC results. I propose to move individual devs status reports to ros-dev mailing list, because there is no reason to just sit in the irc channel and listen to them for hours. List of participants: - Giannis Adamopoulos (smiley1_) - Johannes Anderwald (janderwald) - Javier Agustìn Fernàndez Arroyo (elhoir) - Maciej Bialas (niski) - Jan Blomqvist-Kinander (JaixBly) - Aleksey Bragin (abragin) - Thomas Faber (ThFabba) - Colin Finck (Colin_Finck) - Jérôme Gardou (zefklop) - Danny Götte (dangerground) - Cameron Gutman (aicom) - Ziliang Guo (ZWabbit) - Rafal Harabien (rafalh) - Andrew Hill (ash77) - Kamil Hornicek (Pigglesworth) - Gabriel Ilardi (gabriel_it) - Alex Ionescu (Alex_Ionescu) - Amine Khaldi (AmineKhaldi) - Igor Koshpaev (tower) - Timo Kreuzer (tkreuzer) - Matthias Kupfer (Collibri) - Michael Martin (mjmartin) - Victor Martinez (vicmarcal) - Roel Messiant (Mephisto) - Claudiu Mihail (KlausM) - Andrew Munger (WaxDragon) - Ged Murphy (GedMurphy) - Igor Paliychuk (igorko) - Sylvain Petreolle (Usurp) - Hervé Poussineau (hpoussin) - Daniel Reimer (dreimer) - Pierre Schweitzer (HeisSpiter) - Samuel Serapion (encoded) - Olaf Siejka (Caemyr) - James Tabor (jimtabor) - Christoph von Wittich (Christoph_vW) - Art Yerkes (arty) WBR, Aleksey Bragin.

7 9

[53425] ekohl: [HAL] Add PCI_HAL device for non-ACPI machines. Code taken from the ACPI-HAL. This is just a quick hack and needs some more improvements.
by caemyr＠myopera.com 24 Aug '11

24 Aug '11

r53425 broke CMake build. To make the things worse, this is our only working test\iso provider at the moment. I would reckon fixing it a priority. CMakeFiles/hal.dir/generic/halinit.c.obj: In function `HalInitSystem@8': P:/Trunk_slave/x86_CMake/build/hal/halx86/generic/halinit.c:116: undefined reference to `HaliInitPnpDriver@0' collect2: ld returned 1 exit status -- With best regards Caemyr

1 0

Another regression
by caemyr＠myopera.com 24 Aug '11

24 Aug '11

Revision 53257 breaks Vbox test runtime at 2nd stage booting. http://svn.reactos.org/svn/reactos?view=rev&revision=53257 -- With best regards Caemyr

8 12

Re: [ros-dev] [ros-diffs] [akhaldi] 53405: [EVENTLOG] * Fix a bad sizeof().‏
by Pierre Schweitzer 24 Aug '11

24 Aug '11

Hi, same thing that for r53402, but with structure: RPC_SID. Cf: http://doxygen.reactos.org/d5/df6/structRPC__SID.html Regards, Pierre

1 0

Re: [ros-dev] [ros-diffs] [akhaldi] 53402: [HAL] * Fix a couple bad sizeof().‏
by Pierre Schweitzer 24 Aug '11

24 Aug '11

Hi, this is wrong and does actually change nothing regarding previous code. You need to copy data (structure) length, not pointer length. Structure is: CM_PARTIAL_RESOURCE_DESCRIPTOR. Cf: http://doxygen.reactos.org/db/d22/structCM__PARTIAL__RESOURCE__DESCRIPTOR.h… Regards, Pierre

1 0

Re: [ros-dev] [ros-diffs] [akhaldi] 53404: [VIDEOPRT] * Fix a bad sizeof() that's been with us since r12860 (more than 6 years ago).
by Dmitry Gorbachev 24 Aug '11

24 Aug '11

Hi Amine! > - RtlCopyMemory(AgpServices, &Interface.AgpReservePhysical, sizeof(AgpServices)); > + RtlCopyMemory(AgpServices, &Interface.AgpReservePhysical, sizeof(PVIDEO_PORT_AGP_SERVICES)); You mean sizeof(VIDEO_PORT_AGP_SERVICES), right?

1 0

Suspicious Bill
by arkoprovomukherjee＠gmail.com 18 Aug '11

18 Aug '11

2 1

lwIP testing request
by Cameron Gutman 18 Aug '11

18 Aug '11

LwIP is in the final stage of testing, pending one bug fix before all known bugs are fixed. I would greatly appreciate everyone to try it and reply to this email with the results of your tests. I've already tried many apps including telnetd, chargen, and abyss web server, samba tng, and Opera 9.6. During my testing, the lwIP implementation performed flawlessly. It handled several chargen sessions while serving web pages and servicing open telnet sessions plus being probed by nmap. The only thing that finally killed the server was a pool leak that caused a win32k assert failure. I also ran a BitTorrent download and it peaked at 2.3 MB/s down. Web browsing is an absolute pleasure on lwIP. It really feels like I'm browsing on the host system directly. There are no more stutters like oskit had. I'd encourage everyone to try it. It's surprising how well it works especially since I thought oskit was fairly good. My testing on lwIP has been perfect and I hope everyone else has a similar experience. Please only report bugs that don't also happen with oskit. Happy testing! LwIP ISO Link: http://www.mediafire.com/?d6j4qwz8vgabj9i Thanks in advance, Cameron

7 9

Faça parte da minha rede no LinkedIn
by dimas francisco 15 Aug '11

15 Aug '11

LinkedIn ------------ Eu gostaria de adicioná-lo à minha rede profissional no LinkedIn. -dimas dimas francisco Profissional de Serviços da informação São Paulo e redondezas, Brasil Confirme que você conhece dimas francisco https://www.linkedin.com/e/-w5xu2x-gre1loc3-34/isd/3867275872/u_LdDFjC/ -- (c) 2011, LinkedIn Corporation

1 0

Re: [ros-dev] [ros-diffs] [cgutman] 53249: [NTOSKRNL] - Rewrite IopIsAcpiComputer (and rename to IopIsFirmwareMapperDisabled) to eliminate the need for the ENABLE_ACPI define - IopIsFirmwareMapperDisabled now reads the regi...
by Alex Ionescu 15 Aug '11

15 Aug '11

At some point after initializing RAWFS you need to call HalInitPnpDriver -- which through the HAL private dispatch table should call into the HAL's PNP driver (either ACPI or PCAT). Richard and I got that far with Gopher. Best regards, Alex Ionescu On Sun, Aug 14, 2011 at 10:15 PM, <cgutman(a)svn.reactos.org> wrote: > Author: cgutman > Date: Mon Aug 15 02:15:18 2011 > New Revision: 53249 > > URL: http://svn.reactos.org/svn/reactos?rev=53249&view=rev > Log: > [NTOSKRNL] > - Rewrite IopIsAcpiComputer (and rename to IopIsFirmwareMapperDisabled) to > eliminate the need for the ENABLE_ACPI define > - IopIsFirmwareMapperDisabled now reads the registry entry that HAL sets to > indicate that the firmware mapper should be disabled > - Partially rewrite IopUpdateRootKey so it does not interfere with HAL's > PnP driver > - ACPI is automatically enabled when the ACPI HAL is loaded and disabled > when the standard HAL is loaded > > Modified: > trunk/reactos/ntoskrnl/io/pnpmgr/pnpmgr.c > > Modified: trunk/reactos/ntoskrnl/io/pnpmgr/pnpmgr.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/pnpmgr/pnpmgr.… > > ============================================================================== > --- trunk/reactos/ntoskrnl/io/pnpmgr/pnpmgr.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/io/pnpmgr/pnpmgr.c [iso-8859-1] Mon Aug 15 > 02:15:18 2011 > @@ -12,8 +12,6 @@ > #include <ntoskrnl.h> > #define NDEBUG > #include <debug.h> > - > -//#define ENABLE_ACPI > > /* GLOBALS > *******************************************************************/ > > @@ -2693,143 +2691,73 @@ > } > > static BOOLEAN INIT_FUNCTION > -IopIsAcpiComputer(VOID) > -{ > -#ifndef ENABLE_ACPI > - return FALSE; > -#else > - UNICODE_STRING MultiKeyPathU = > RTL_CONSTANT_STRING(L"\\Registry\\Machine\\HARDWARE\\DESCRIPTION\\System\\MultifunctionAdapter"); > - UNICODE_STRING IdentifierU = RTL_CONSTANT_STRING(L"Identifier"); > - UNICODE_STRING AcpiBiosIdentifier = RTL_CONSTANT_STRING(L"ACPI BIOS"); > +IopIsFirmwareMapperDisabled(VOID) > +{ > + UNICODE_STRING KeyPathU = > RTL_CONSTANT_STRING(L"\\Registry\\Machine\\SYSTEM\\CURRENTCONTROLSET\\Control\\Pnp"); > + UNICODE_STRING KeyNameU = > RTL_CONSTANT_STRING(L"DisableFirmwareMapper"); > OBJECT_ATTRIBUTES ObjectAttributes; > - PKEY_BASIC_INFORMATION pDeviceInformation = NULL; > - ULONG DeviceInfoLength = sizeof(KEY_BASIC_INFORMATION) + 50 * > sizeof(WCHAR); > - PKEY_VALUE_PARTIAL_INFORMATION pValueInformation = NULL; > - ULONG ValueInfoLength = sizeof(KEY_VALUE_PARTIAL_INFORMATION) + 50 * > sizeof(WCHAR); > - ULONG RequiredSize; > - ULONG IndexDevice = 0; > - UNICODE_STRING DeviceName, ValueName; > - HANDLE hDevicesKey = NULL; > - HANDLE hDeviceKey = NULL; > + HANDLE hPnpKey; > + PKEY_VALUE_PARTIAL_INFORMATION KeyInformation; > + ULONG DesiredLength, Length, KeyValue; > NTSTATUS Status; > - BOOLEAN ret = FALSE; > - > - InitializeObjectAttributes(&ObjectAttributes, &MultiKeyPathU, > OBJ_KERNEL_HANDLE | OBJ_CASE_INSENSITIVE, NULL, NULL); > - Status = ZwOpenKey(&hDevicesKey, KEY_ENUMERATE_SUB_KEYS, > &ObjectAttributes); > - if (!NT_SUCCESS(Status)) > - { > - DPRINT("ZwOpenKey() failed with status 0x%08lx\n", Status); > - goto cleanup; > - } > - > - pDeviceInformation = ExAllocatePool(PagedPool, DeviceInfoLength); > - if (!pDeviceInformation) > - { > - DPRINT("ExAllocatePool() failed\n"); > - Status = STATUS_NO_MEMORY; > - goto cleanup; > - } > - > - pValueInformation = ExAllocatePool(PagedPool, ValueInfoLength); > - if (!pDeviceInformation) > - { > - DPRINT("ExAllocatePool() failed\n"); > - Status = STATUS_NO_MEMORY; > - goto cleanup; > - } > - > - while (TRUE) > - { > - Status = ZwEnumerateKey(hDevicesKey, IndexDevice, > KeyBasicInformation, pDeviceInformation, DeviceInfoLength, &RequiredSize); > - if (Status == STATUS_NO_MORE_ENTRIES) > - break; > - else if (Status == STATUS_BUFFER_OVERFLOW || Status == > STATUS_BUFFER_TOO_SMALL) > - { > - ExFreePool(pDeviceInformation); > - DeviceInfoLength = RequiredSize; > - pDeviceInformation = ExAllocatePool(PagedPool, DeviceInfoLength); > - if (!pDeviceInformation) > - { > - DPRINT("ExAllocatePool() failed\n"); > - Status = STATUS_NO_MEMORY; > - goto cleanup; > - } > - Status = ZwEnumerateKey(hDevicesKey, IndexDevice, > KeyBasicInformation, pDeviceInformation, DeviceInfoLength, &RequiredSize); > - } > - if (!NT_SUCCESS(Status)) > - { > - DPRINT("ZwEnumerateKey() failed with status 0x%08lx\n", Status); > - goto cleanup; > - } > - IndexDevice++; > - > - /* Open device key */ > - DeviceName.Length = DeviceName.MaximumLength = > pDeviceInformation->NameLength; > - DeviceName.Buffer = pDeviceInformation->Name; > - InitializeObjectAttributes(&ObjectAttributes, &DeviceName, > OBJ_KERNEL_HANDLE, hDevicesKey, NULL); > - Status = ZwOpenKey( > - &hDeviceKey, > - KEY_QUERY_VALUE, > - &ObjectAttributes); > - if (!NT_SUCCESS(Status)) > - { > - DPRINT("ZwOpenKey() failed with status 0x%08lx\n", Status); > - goto cleanup; > - } > - > - /* Read identifier */ > - Status = ZwQueryValueKey(hDeviceKey, &IdentifierU, > KeyValuePartialInformation, pValueInformation, ValueInfoLength, > &RequiredSize); > - if (Status == STATUS_BUFFER_OVERFLOW || Status == > STATUS_BUFFER_TOO_SMALL) > - { > - ExFreePool(pValueInformation); > - ValueInfoLength = RequiredSize; > - pValueInformation = ExAllocatePool(PagedPool, ValueInfoLength); > - if (!pValueInformation) > - { > - DPRINT("ExAllocatePool() failed\n"); > - Status = STATUS_NO_MEMORY; > - goto cleanup; > - } > - Status = ZwQueryValueKey(hDeviceKey, &IdentifierU, > KeyValuePartialInformation, pValueInformation, ValueInfoLength, > &RequiredSize); > - } > - if (!NT_SUCCESS(Status)) > - { > - DPRINT("ZwQueryValueKey() failed with status 0x%08lx\n", Status); > - goto nextdevice; > - } > - else if (pValueInformation->Type != REG_SZ) > - { > - DPRINT("Wrong registry type: got 0x%lx, expected 0x%lx\n", > pValueInformation->Type, REG_SZ); > - goto nextdevice; > - } > - > - ValueName.Length = ValueName.MaximumLength = > pValueInformation->DataLength; > - ValueName.Buffer = (PWCHAR)pValueInformation->Data; > - if (ValueName.Length >= sizeof(WCHAR) && > ValueName.Buffer[ValueName.Length / sizeof(WCHAR) - 1] == UNICODE_NULL) > - ValueName.Length -= sizeof(WCHAR); > - if (RtlCompareUnicodeString(&ValueName, &AcpiBiosIdentifier, FALSE) > == 0) > - { > - DPRINT("Found ACPI BIOS\n"); > - ret = TRUE; > - goto cleanup; > - } > - > -nextdevice: > - ZwClose(hDeviceKey); > - hDeviceKey = NULL; > - } > - > -cleanup: > - if (pDeviceInformation) > - ExFreePool(pDeviceInformation); > - if (pValueInformation) > - ExFreePool(pValueInformation); > - if (hDevicesKey) > - ZwClose(hDevicesKey); > - if (hDeviceKey) > - ZwClose(hDeviceKey); > - return ret; > -#endif > + > + InitializeObjectAttributes(&ObjectAttributes, &KeyPathU, > OBJ_KERNEL_HANDLE | OBJ_CASE_INSENSITIVE, NULL, NULL); > + Status = ZwOpenKey(&hPnpKey, KEY_QUERY_VALUE, &ObjectAttributes); > + if (NT_SUCCESS(Status)) > + { > + Status = ZwQueryValueKey(hPnpKey, > + &KeyNameU, > + KeyValuePartialInformation, > + NULL, > + 0, > + &DesiredLength); > + if ((Status == STATUS_BUFFER_TOO_SMALL) || > + (Status == STATUS_BUFFER_OVERFLOW)) > + { > + Length = DesiredLength; > + KeyInformation = ExAllocatePool(PagedPool, Length); > + if (KeyInformation) > + { > + Status = ZwQueryValueKey(hPnpKey, > + &KeyNameU, > + KeyValuePartialInformation, > + KeyInformation, > + Length, > + &DesiredLength); > + if (NT_SUCCESS(Status) && KeyInformation->DataLength == > sizeof(ULONG)) > + { > + KeyValue = (ULONG)(*KeyInformation->Data); > + } > + else > + { > + DPRINT1("ZwQueryValueKey(%wZ%wZ) failed\n", &KeyPathU, > &KeyNameU); > + KeyValue = 0; > + } > + > + ExFreePool(KeyInformation); > + } > + else > + { > + DPRINT1("Failed to allocate memory for registry query\n"); > + KeyValue = 0; > + } > + } > + else > + { > + DPRINT1("ZwQueryValueKey(%wZ%wZ) failed with status 0x%08lx\n", > &KeyPathU, &KeyNameU, Status); > + KeyValue = 0; > + } > + > + ZwClose(hPnpKey); > + } > + else > + { > + DPRINT1("ZwOpenKey(%wZ) failed with status 0x%08lx\n", &KeyPathU, > Status); > + } > + > + DPRINT1("Firmware mapper is %s\n", KeyValue != 0 ? "disabled" : > "enabled"); > + > + return (KeyValue != 0) ? TRUE : FALSE; > } > > NTSTATUS > @@ -2840,17 +2768,9 @@ > UNICODE_STRING EnumU = > RTL_CONSTANT_STRING(L"\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Enum"); > UNICODE_STRING RootPathU = RTL_CONSTANT_STRING(L"Root"); > UNICODE_STRING MultiKeyPathU = > RTL_CONSTANT_STRING(L"\\Registry\\Machine\\HARDWARE\\DESCRIPTION\\System\\MultifunctionAdapter"); > - UNICODE_STRING DeviceDescU = RTL_CONSTANT_STRING(L"DeviceDesc"); > - UNICODE_STRING HardwareIDU = RTL_CONSTANT_STRING(L"HardwareID"); > - UNICODE_STRING LogConfU = RTL_CONSTANT_STRING(L"LogConf"); > - UNICODE_STRING HalAcpiDevice = RTL_CONSTANT_STRING(L"ACPI_HAL"); > - UNICODE_STRING HalAcpiId = RTL_CONSTANT_STRING(L"0000"); > - UNICODE_STRING HalAcpiDeviceDesc = RTL_CONSTANT_STRING(L"HAL ACPI"); > - UNICODE_STRING HalAcpiHardwareID = RTL_CONSTANT_STRING(L"*PNP0C08\0"); > OBJECT_ATTRIBUTES ObjectAttributes; > - HANDLE hEnum, hRoot, hHalAcpiDevice, hHalAcpiId, hLogConf; > + HANDLE hEnum, hRoot; > NTSTATUS Status; > - ULONG Disposition; > > InitializeObjectAttributes(&ObjectAttributes, &EnumU, OBJ_KERNEL_HANDLE > | OBJ_CASE_INSENSITIVE, NULL, NULL); > Status = ZwCreateKey(&hEnum, KEY_CREATE_SUB_KEY, &ObjectAttributes, 0, > NULL, 0, NULL); > @@ -2869,35 +2789,7 @@ > return Status; > } > > - if (IopIsAcpiComputer()) > - { > - InitializeObjectAttributes(&ObjectAttributes, &HalAcpiDevice, > OBJ_KERNEL_HANDLE | OBJ_CASE_INSENSITIVE, hRoot, NULL); > - Status = ZwCreateKey(&hHalAcpiDevice, KEY_CREATE_SUB_KEY, > &ObjectAttributes, 0, NULL, 0, NULL); > - ZwClose(hRoot); > - if (!NT_SUCCESS(Status)) > - return Status; > - InitializeObjectAttributes(&ObjectAttributes, &HalAcpiId, > OBJ_KERNEL_HANDLE | OBJ_CASE_INSENSITIVE, hHalAcpiDevice, NULL); > - Status = ZwCreateKey(&hHalAcpiId, KEY_CREATE_SUB_KEY | > KEY_SET_VALUE, &ObjectAttributes, 0, NULL, 0, &Disposition); > - ZwClose(hHalAcpiDevice); > - if (!NT_SUCCESS(Status)) > - return Status; > - if (Disposition == REG_CREATED_NEW_KEY) > - { > - Status = ZwSetValueKey(hHalAcpiId, &DeviceDescU, 0, REG_SZ, > HalAcpiDeviceDesc.Buffer, HalAcpiDeviceDesc.MaximumLength); > - if (NT_SUCCESS(Status)) > - Status = ZwSetValueKey(hHalAcpiId, &HardwareIDU, 0, > REG_MULTI_SZ, HalAcpiHardwareID.Buffer, HalAcpiHardwareID.MaximumLength); > - } > - if (NT_SUCCESS(Status)) > - { > - InitializeObjectAttributes(&ObjectAttributes, &LogConfU, > OBJ_KERNEL_HANDLE | OBJ_CASE_INSENSITIVE, hHalAcpiId, NULL); > - Status = ZwCreateKey(&hLogConf, 0, &ObjectAttributes, 0, NULL, > REG_OPTION_VOLATILE, NULL); > - if (NT_SUCCESS(Status)) > - ZwClose(hLogConf); > - } > - ZwClose(hHalAcpiId); > - return Status; > - } > - else > + if (!IopIsFirmwareMapperDisabled()) > { > Status = IopOpenRegistryKeyEx(&hEnum, NULL, &MultiKeyPathU, > KEY_ENUMERATE_SUB_KEYS); > if (!NT_SUCCESS(Status)) > @@ -2915,9 +2807,16 @@ > NULL, > 0); > ZwClose(hEnum); > - ZwClose(hRoot); > - return Status; > - } > + } > + else > + { > + /* Enumeration is disabled */ > + Status = STATUS_SUCCESS; > + } > + > + ZwClose(hRoot); > + > + return Status; > } > > NTSTATUS > > >

1 0

Re: [ros-dev] [ros-diffs] [cgutman] 53232: [NTOSKRNL] - Fix NULL termination of strings in IoGetDeviceProperty - Fixes garbage displayed in the Enumerator field of the device manager property page
by caemyr＠myopera.com 15 Aug '11

15 Aug '11

This revision breaks up MSVC iso booting: http://www.reactos.org/paste/index.php/9231/ -- With best regards Caemyr

1 0

Re: [ros-dev] [ros-diffs] [cgutman] 53232: [NTOSKRNL] - Fix NULL termination of strings in IoGetDeviceProperty - Fixes garbage displayed in the Enumerator field of the device manager property page
by Alex Ionescu 14 Aug '11

14 Aug '11

And, you have, of course, confirmed that this piece of kernel code is wrong, and that DevMgr/Cfgapi/SetupApi are doing the right thing, right? So if I was to reverse engineer ntoskrnl I wouldn't discover that it was actually doing the same thing as the un-"fixed" code, right? Best regards, Alex Ionescu On Sun, Aug 14, 2011 at 10:44 AM, <cgutman(a)svn.reactos.org> wrote: > Author: cgutman > Date: Sun Aug 14 14:44:34 2011 > New Revision: 53232 > > URL: http://svn.reactos.org/svn/reactos?rev=53232&view=rev > Log: > [NTOSKRNL] > - Fix NULL termination of strings in IoGetDeviceProperty > - Fixes garbage displayed in the Enumerator field of the device manager > property page > > Modified: > trunk/reactos/ntoskrnl/io/pnpmgr/pnpmgr.c > > Modified: trunk/reactos/ntoskrnl/io/pnpmgr/pnpmgr.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/pnpmgr/pnpmgr.… > > ============================================================================== > --- trunk/reactos/ntoskrnl/io/pnpmgr/pnpmgr.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/io/pnpmgr/pnpmgr.c [iso-8859-1] Sun Aug 14 > 14:44:34 2011 > @@ -3467,6 +3467,8 @@ > NTSTATUS Status = STATUS_BUFFER_TOO_SMALL; > GUID BusTypeGuid; > POBJECT_NAME_INFORMATION ObjectNameInfo = NULL; > + BOOLEAN NullTerminate = FALSE; > + > DPRINT("IoGetDeviceProperty(0x%p %d)\n", DeviceObject, DeviceProperty); > > /* Assume failure */ > @@ -3517,7 +3519,10 @@ > /* Get the name from the path */ > EnumeratorNameEnd = wcschr(DeviceInstanceName, > OBJ_NAME_PATH_SEPARATOR); > ASSERT(EnumeratorNameEnd); > - > + > + /* This string needs to be NULL-terminated */ > + NullTerminate = TRUE; > + > /* This is the format of the returned data */ > PIP_RETURN_DATA((EnumeratorNameEnd - DeviceInstanceName) * > sizeof(WCHAR), > DeviceInstanceName); > @@ -3567,7 +3572,10 @@ > /* It's up to the caller to try again */ > Status = STATUS_BUFFER_TOO_SMALL; > } > - > + > + /* This string needs to be NULL-terminated */ > + NullTerminate = TRUE; > + > /* Return if successful */ > if (NT_SUCCESS(Status)) > PIP_RETURN_DATA(ObjectNameInfo->Name.Length, > > ObjectNameInfo->Name.Buffer); > @@ -3633,15 +3641,14 @@ > else if (NT_SUCCESS(Status)) > { > /* We know up-front how much data to expect, check the caller's > buffer */ > - *ResultLength = ReturnLength; > - if (ReturnLength <= BufferLength) > + *ResultLength = ReturnLength + (NullTerminate ? > sizeof(UNICODE_NULL) : 0); > + if (*ResultLength <= BufferLength) > { > /* Buffer is all good, copy the data */ > RtlCopyMemory(PropertyBuffer, Data, ReturnLength); > > - /* Check for properties that require a null-terminated string > */ > - if ((DeviceProperty == DevicePropertyEnumeratorName) || > - (DeviceProperty == > DevicePropertyPhysicalDeviceObjectName)) > + /* Check if we need to NULL-terminate the string */ > + if (NullTerminate) > { > /* Terminate the string */ > ((PWCHAR)PropertyBuffer)[ReturnLength / sizeof(WCHAR)] = > UNICODE_NULL; > > >

3 2

Re: [ros-dev] [ros-diffs] [akhaldi] 53230: [AUTOCHK][CMD][TASKMGR] * Exclude some indirectly included headers.
by Alex Ionescu 14 Aug '11

14 Aug '11

Never depend on this! Depending on funcs.h including types.h of the same module is fine, but you should not depend on rtlfuncs dependong on pstypes. Best regards, Alex Ionescu On Sun, Aug 14, 2011 at 8:57 AM, <akhaldi(a)svn.reactos.org> wrote: > #define NTOS_MODE_USER > -#include <ndk/pstypes.h> > #include <ndk/rtlfuncs.h> >

2 1

Re: [ros-dev] [ros-diffs] [ekohl] 53201: [ADVAPI32] Fix EnumServicesStatusEx[A/W]: - If lpServices is NULL or cbBufSize is less than sizeof(ENUM_SERVICE_STATUS_PROCESS) pass a pointer to an internal status buffer to REnumSe...
by Jérôme Gardou 14 Aug '11

14 Aug '11

Passing [in] and [unique] to RQueryServiceonfigW is not a solution either. It was a quick and dirty hack to get things working. I'm working on a proper solution right now, unless you already have something in your hat :-) Le 13/08/2011 12:53, ekohl(a)svn.reactos.org a écrit : > Author: ekohl > Date: Sat Aug 13 10:53:15 2011 > New Revision: 53201 > > URL: http://svn.reactos.org/svn/reactos?rev=53201&view=rev > Log: > [ADVAPI32] > Fix EnumServicesStatusEx[A/W]: > - If lpServices is NULL or cbBufSize is less than sizeof(ENUM_SERVICE_STATUS_PROCESS) pass a pointer to an internal status buffer to REnumServicesStatusExA/W. Adding 'in' and 'unique' attributes in the idl file is NOT an option because this is not compatible with Windows. > - Check the InfoLevel. > > Modified: > trunk/reactos/dll/win32/advapi32/service/scm.c > > Modified: trunk/reactos/dll/win32/advapi32/service/scm.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/advapi32/service… > ============================================================================== > --- trunk/reactos/dll/win32/advapi32/service/scm.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/advapi32/service/scm.c [iso-8859-1] Sat Aug 13 10:53:15 2011 > @@ -1150,7 +1150,9 @@ > LPDWORD lpResumeHandle, > LPCSTR pszGroupName) > { > + ENUM_SERVICE_STATUS_PROCESSA ServiceStatus; > LPENUM_SERVICE_STATUS_PROCESSA lpStatusPtr; > + DWORD dwBufferSize; > DWORD dwError; > DWORD dwCount; > > @@ -1166,6 +1168,18 @@ > { > SetLastError(ERROR_INVALID_HANDLE); > return FALSE; > + } > + > + if (lpServices == NULL || > + cbBufSize< sizeof(ENUM_SERVICE_STATUS_PROCESSA)) > + { > + lpStatusPtr =&ServiceStatus; > + dwBufferSize = sizeof(ENUM_SERVICE_STATUS_PROCESSA); > + } > + else > + { > + lpStatusPtr = (LPENUM_SERVICE_STATUS_PROCESSA)lpServices; > + dwBufferSize = cbBufSize; > } > > RpcTryExcept > @@ -1174,8 +1188,8 @@ > InfoLevel, > dwServiceType, > dwServiceState, > - (LPBYTE)lpServices, > - cbBufSize, > + (LPBYTE)lpStatusPtr, > + dwBufferSize, > pcbBytesNeeded, > lpServicesReturned, > lpResumeHandle, > @@ -1189,18 +1203,20 @@ > > if (dwError == ERROR_SUCCESS || dwError == ERROR_MORE_DATA) > { > - lpStatusPtr = (LPENUM_SERVICE_STATUS_PROCESSA)lpServices; > - for (dwCount = 0; dwCount< *lpServicesReturned; dwCount++) > + if (InfoLevel == SC_ENUM_PROCESS_INFO) > { > - if (lpStatusPtr->lpServiceName) > - lpStatusPtr->lpServiceName = > - (LPSTR)((ULONG_PTR)lpServices + (ULONG_PTR)lpStatusPtr->lpServiceName); > - > - if (lpStatusPtr->lpDisplayName) > - lpStatusPtr->lpDisplayName = > - (LPSTR)((ULONG_PTR)lpServices + (ULONG_PTR)lpStatusPtr->lpDisplayName); > - > - lpStatusPtr++; > + for (dwCount = 0; dwCount< *lpServicesReturned; dwCount++) > + { > + if (lpStatusPtr->lpServiceName) > + lpStatusPtr->lpServiceName = > + (LPSTR)((ULONG_PTR)lpServices + (ULONG_PTR)lpStatusPtr->lpServiceName); > + > + if (lpStatusPtr->lpDisplayName) > + lpStatusPtr->lpDisplayName = > + (LPSTR)((ULONG_PTR)lpServices + (ULONG_PTR)lpStatusPtr->lpDisplayName); > + > + lpStatusPtr++; > + } > } > } > > @@ -1234,11 +1250,31 @@ > LPDWORD lpResumeHandle, > LPCWSTR pszGroupName) > { > + ENUM_SERVICE_STATUS_PROCESSW ServiceStatus; > LPENUM_SERVICE_STATUS_PROCESSW lpStatusPtr; > + DWORD dwBufferSize; > DWORD dwError; > DWORD dwCount; > > TRACE("EnumServicesStatusExW() called\n"); > + > + if (InfoLevel != SC_ENUM_PROCESS_INFO) > + { > + SetLastError(ERROR_INVALID_LEVEL); > + return FALSE; > + } > + > + if (lpServices == NULL || > + cbBufSize< sizeof(ENUM_SERVICE_STATUS_PROCESSW)) > + { > + lpStatusPtr =&ServiceStatus; > + dwBufferSize = sizeof(ENUM_SERVICE_STATUS_PROCESSW); > + } > + else > + { > + lpStatusPtr = (LPENUM_SERVICE_STATUS_PROCESSW)lpServices; > + dwBufferSize = cbBufSize; > + } > > RpcTryExcept > { > @@ -1246,8 +1282,8 @@ > InfoLevel, > dwServiceType, > dwServiceState, > - (LPBYTE)lpServices, > - cbBufSize, > + (LPBYTE)lpStatusPtr, > + dwBufferSize, > pcbBytesNeeded, > lpServicesReturned, > lpResumeHandle, > @@ -1261,18 +1297,20 @@ > > if (dwError == ERROR_SUCCESS || dwError == ERROR_MORE_DATA) > { > - lpStatusPtr = (LPENUM_SERVICE_STATUS_PROCESSW)lpServices; > - for (dwCount = 0; dwCount< *lpServicesReturned; dwCount++) > + if (InfoLevel == SC_ENUM_PROCESS_INFO) > { > - if (lpStatusPtr->lpServiceName) > - lpStatusPtr->lpServiceName = > - (LPWSTR)((ULONG_PTR)lpServices + (ULONG_PTR)lpStatusPtr->lpServiceName); > - > - if (lpStatusPtr->lpDisplayName) > - lpStatusPtr->lpDisplayName = > - (LPWSTR)((ULONG_PTR)lpServices + (ULONG_PTR)lpStatusPtr->lpDisplayName); > - > - lpStatusPtr++; > + for (dwCount = 0; dwCount< *lpServicesReturned; dwCount++) > + { > + if (lpStatusPtr->lpServiceName) > + lpStatusPtr->lpServiceName = > + (LPWSTR)((ULONG_PTR)lpServices + (ULONG_PTR)lpStatusPtr->lpServiceName); > + > + if (lpStatusPtr->lpDisplayName) > + lpStatusPtr->lpDisplayName = > + (LPWSTR)((ULONG_PTR)lpServices + (ULONG_PTR)lpStatusPtr->lpDisplayName); > + > + lpStatusPtr++; > + } > } > } > > >

3 3

Re: [ros-dev] [ros-diffs] [jgardou] 53158: [TOOLS] - sync wpp, widl and wrc with wine 1.3.26
by Jérôme Gardou 09 Aug '11

09 Aug '11

CMake users : please don't forget to rebuild your host tools :-) Non cmake user : don't worry, this user unfriendly-ness is being worked on. Le 10/08/2011 00:51, jgardou(a)svn.reactos.org a écrit : > Author: jgardou > Date: Tue Aug 9 22:51:55 2011 > New Revision: 53158 > > URL: http://svn.reactos.org/svn/reactos?rev=53158&view=rev > Log: > [TOOLS] > - sync wpp, widl and wrc with wine 1.3.26 > > Added: > trunk/reactos/tools/wrc/po.c (with props) > Modified: > trunk/reactos/include/host/nls.h > trunk/reactos/include/host/wine/wpp.h > trunk/reactos/tools/widl/client.c > trunk/reactos/tools/widl/expr.c > trunk/reactos/tools/widl/hash.c > trunk/reactos/tools/widl/header.c > trunk/reactos/tools/widl/header.h > trunk/reactos/tools/widl/parser.l > trunk/reactos/tools/widl/parser.tab.c > trunk/reactos/tools/widl/parser.tab.h > trunk/reactos/tools/widl/parser.y > trunk/reactos/tools/widl/parser.yy.c > trunk/reactos/tools/widl/proxy.c > trunk/reactos/tools/widl/register.c > trunk/reactos/tools/widl/server.c > trunk/reactos/tools/widl/typegen.c > trunk/reactos/tools/widl/typegen.h > trunk/reactos/tools/widl/typelib.c > trunk/reactos/tools/widl/typelib_struct.h > trunk/reactos/tools/widl/utils.c > trunk/reactos/tools/widl/utils.h > trunk/reactos/tools/widl/widl.c > trunk/reactos/tools/widl/widl.h > trunk/reactos/tools/widl/widl.rbuild > trunk/reactos/tools/widl/widltypes.h > trunk/reactos/tools/widl/write_msft.c > trunk/reactos/tools/wpp/lex.yy.c > trunk/reactos/tools/wpp/ppl.l > trunk/reactos/tools/wpp/ppy.tab.c > trunk/reactos/tools/wpp/ppy.tab.h > trunk/reactos/tools/wpp/ppy.y > trunk/reactos/tools/wpp/preproc.c > trunk/reactos/tools/wpp/wpp.c > trunk/reactos/tools/wpp/wpp_private.h > trunk/reactos/tools/wrc/CMakeLists.txt > trunk/reactos/tools/wrc/dumpres.c > trunk/reactos/tools/wrc/genres.c > trunk/reactos/tools/wrc/lex.yy.c > trunk/reactos/tools/wrc/newstruc.c > trunk/reactos/tools/wrc/newstruc.h > trunk/reactos/tools/wrc/parser.h > trunk/reactos/tools/wrc/parser.l > trunk/reactos/tools/wrc/parser.tab.c > trunk/reactos/tools/wrc/parser.tab.h > trunk/reactos/tools/wrc/parser.y > trunk/reactos/tools/wrc/translation.c > trunk/reactos/tools/wrc/utils.c > trunk/reactos/tools/wrc/utils.h > trunk/reactos/tools/wrc/wrc.c > trunk/reactos/tools/wrc/wrc.h > trunk/reactos/tools/wrc/wrc.rbuild > trunk/reactos/tools/wrc/wrcrostypes.h > trunk/reactos/tools/wrc/wrctypes.h > > [This mail would be too long, it was shortened to contain the URLs only.] > > Modified: trunk/reactos/include/host/nls.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/host/nls.h?rev=531… > > Modified: trunk/reactos/include/host/wine/wpp.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/host/wine/wpp.h?re… > > Modified: trunk/reactos/tools/widl/client.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/client.c?rev=53… > > Modified: trunk/reactos/tools/widl/expr.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/expr.c?rev=5315… > > Modified: trunk/reactos/tools/widl/hash.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/hash.c?rev=5315… > > Modified: trunk/reactos/tools/widl/header.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/header.c?rev=53… > > Modified: trunk/reactos/tools/widl/header.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/header.h?rev=53… > > Modified: trunk/reactos/tools/widl/parser.l > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/parser.l?rev=53… > > Modified: trunk/reactos/tools/widl/parser.tab.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/parser.tab.c?re… > > Modified: trunk/reactos/tools/widl/parser.tab.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/parser.tab.h?re… > > Modified: trunk/reactos/tools/widl/parser.y > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/parser.y?rev=53… > > Modified: trunk/reactos/tools/widl/parser.yy.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/parser.yy.c?rev… > > Modified: trunk/reactos/tools/widl/proxy.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/proxy.c?rev=531… > > Modified: trunk/reactos/tools/widl/register.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/register.c?rev=… > > Modified: trunk/reactos/tools/widl/server.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/server.c?rev=53… > > Modified: trunk/reactos/tools/widl/typegen.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/typegen.c?rev=5… > > Modified: trunk/reactos/tools/widl/typegen.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/typegen.h?rev=5… > > Modified: trunk/reactos/tools/widl/typelib.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/typelib.c?rev=5… > > Modified: trunk/reactos/tools/widl/typelib_struct.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/typelib_struct.… > > Modified: trunk/reactos/tools/widl/utils.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/utils.c?rev=531… > > Modified: trunk/reactos/tools/widl/utils.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/utils.h?rev=531… > > Modified: trunk/reactos/tools/widl/widl.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/widl.c?rev=5315… > > Modified: trunk/reactos/tools/widl/widl.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/widl.h?rev=5315… > > Modified: trunk/reactos/tools/widl/widl.rbuild > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/widl.rbuild?rev… > > Modified: trunk/reactos/tools/widl/widltypes.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/widltypes.h?rev… > > Modified: trunk/reactos/tools/widl/write_msft.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/write_msft.c?re… > > Modified: trunk/reactos/tools/wpp/lex.yy.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wpp/lex.yy.c?rev=531… > > Modified: trunk/reactos/tools/wpp/ppl.l > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wpp/ppl.l?rev=53158&… > > Modified: trunk/reactos/tools/wpp/ppy.tab.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wpp/ppy.tab.c?rev=53… > > Modified: trunk/reactos/tools/wpp/ppy.tab.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wpp/ppy.tab.h?rev=53… > > Modified: trunk/reactos/tools/wpp/ppy.y > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wpp/ppy.y?rev=53158&… > > Modified: trunk/reactos/tools/wpp/preproc.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wpp/preproc.c?rev=53… > > Modified: trunk/reactos/tools/wpp/wpp.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wpp/wpp.c?rev=53158&… > > Modified: trunk/reactos/tools/wpp/wpp_private.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wpp/wpp_private.h?re… > > Modified: trunk/reactos/tools/wrc/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/CMakeLists.txt?r… > > Modified: trunk/reactos/tools/wrc/dumpres.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/dumpres.c?rev=53… > > Modified: trunk/reactos/tools/wrc/genres.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/genres.c?rev=531… > > Modified: trunk/reactos/tools/wrc/lex.yy.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/lex.yy.c?rev=531… > > Modified: trunk/reactos/tools/wrc/newstruc.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/newstruc.c?rev=5… > > Modified: trunk/reactos/tools/wrc/newstruc.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/newstruc.h?rev=5… > > Modified: trunk/reactos/tools/wrc/parser.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/parser.h?rev=531… > > Modified: trunk/reactos/tools/wrc/parser.l > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/parser.l?rev=531… > > Modified: trunk/reactos/tools/wrc/parser.tab.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/parser.tab.c?rev… > > Modified: trunk/reactos/tools/wrc/parser.tab.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/parser.tab.h?rev… > > Modified: trunk/reactos/tools/wrc/parser.y > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/parser.y?rev=531… > > Added: trunk/reactos/tools/wrc/po.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/po.c?rev=53158&v… > > Modified: trunk/reactos/tools/wrc/translation.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/translation.c?re… > > Modified: trunk/reactos/tools/wrc/utils.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/utils.c?rev=5315… > > Modified: trunk/reactos/tools/wrc/utils.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/utils.h?rev=5315… > > Modified: trunk/reactos/tools/wrc/wrc.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/wrc.c?rev=53158&… > > Modified: trunk/reactos/tools/wrc/wrc.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/wrc.h?rev=53158&… > > Modified: trunk/reactos/tools/wrc/wrc.rbuild > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/wrc.rbuild?rev=5… > > Modified: trunk/reactos/tools/wrc/wrcrostypes.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/wrcrostypes.h?re… > > Modified: trunk/reactos/tools/wrc/wrctypes.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/wrctypes.h?rev=5… > >

1 0

Re: [ros-dev] [ros-diffs] [jgardou] 53152: [RPCRT4] - restore lost ros specific change. Thanks Vic.
by Ged Murphy 09 Aug '11

09 Aug '11

Maybe you could add all the other changes with checkin comments such as "this should be sent upstream to wine" to that plan too :) That practice has become quite common these days. Ged. Sent from my Windows Phone From: Jérôme Gardou Sent: 09 August 2011 22:32 To: ros-dev(a)reactos.org Subject: Re: [ros-dev] [ros-diffs] [jgardou] 53152: [RPCRT4] - restore lost ros specific change. Thanks Vic. Don't worry, it's part of the plan! Le 09/08/2011 23:29, Ged Murphy a écrit : > Call me nuts, but why don't you add a ros_diff patch so it doesn't get > lost again??? > From: jgardou(a)svn.reactos.org > Sent: 09 August 2011 18:43 > To: ros-diffs(a)reactos.org > Subject: [ros-diffs] [jgardou] 53152: [RPCRT4] - restore lost ros > specific change. Thanks Vic. > Author: jgardou > Date: Tue Aug 9 17:43:37 2011 > New Revision: 53152 > > URL: http://svn.reactos.org/svn/reactos?rev=53152&view=rev > Log: > [RPCRT4] > - restore lost ros specific change. > Thanks Vic. > > Modified: > trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c > > Modified: trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/rpcrt4/ndr_marsh… > ============================================================================== > --- trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c [iso-8859-1] Tue Aug > 9 17:43:37 2011 > @@ -6159,6 +6159,7 @@ > case RPC_FC_WCHAR: > case RPC_FC_SHORT: > case RPC_FC_USHORT: > + case RPC_FC_ENUM16: > { > USHORT d; > align_pointer(&pStubMsg->Buffer, sizeof(USHORT)); > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev

1 0

Re: [ros-dev] [ros-diffs] [jgardou] 53152: [RPCRT4] - restore lost ros specific change. Thanks Vic.
by Ged Murphy 09 Aug '11

09 Aug '11

Call me nuts, but why don't you add a ros_diff patch so it doesn't get lost again??? From: jgardou(a)svn.reactos.org Sent: 09 August 2011 18:43 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [jgardou] 53152: [RPCRT4] - restore lost ros specific change. Thanks Vic. Author: jgardou Date: Tue Aug 9 17:43:37 2011 New Revision: 53152 URL: http://svn.reactos.org/svn/reactos?rev=53152&view=rev Log: [RPCRT4] - restore lost ros specific change. Thanks Vic. Modified: trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c Modified: trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/rpcrt4/ndr_marsh… ============================================================================== --- trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c [iso-8859-1] (original) +++ trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c [iso-8859-1] Tue Aug 9 17:43:37 2011 @@ -6159,6 +6159,7 @@ case RPC_FC_WCHAR: case RPC_FC_SHORT: case RPC_FC_USHORT: + case RPC_FC_ENUM16: { USHORT d; align_pointer(&pStubMsg->Buffer, sizeof(USHORT));

2 1

BuildBot ISOs
by Colin Finck 07 Aug '11

07 Aug '11

Hello everybody, Due to a mistake from my side, the uploaded BuildBot 7zipped ISO files in the revision range from 53120 to 53127 as created by the Debug Buildslave contained the very same ISO of revision 53119. This has been fixed in the meantime, the faulty files have been removed from the server and at least the 7-Zip archive of revision 53127 has been recreated. On the other hand, Olaf and I have finally enabled his server to upload ISOs to http://iso.reactos.org. These ISOs are built by his Buildslave running under Windows, already using the new CMake buildsystem and incorporating our regression tests and the Gecko CAB file. I might have time to add another filter to http://reactos.org/getbuilds soon, so that everybody can download the new ISOs easily. - Colin

1 1

[FREELDR]: Some ARM architectures do not necessarily have CS0_BASE at 0x00000000...
by Igor Paliychuk 06 Aug '11

06 Aug '11

Commit http://svn.reactos.org/svn/reactos?view=rev&revision=52098 by Sir Richard caused the regression http://www.reactos.org/bugzilla/show_bug.cgi?id=6292 that is marked as blocker. I have reverted this commit (and applied hachfix for driver setup fixing) and now ReactOS boots and sound is ok. Could you, Sir Richard, look at the report and fix the bug?

1 1

Re: [ros-dev] [ros-diffs] [jgardou] 53087: [PSDK] - do not redefine UNICODE_STRING and NTSTATUS if wintrnl.h has already been included - define PNTSTATUS in wintrnl.h - add RPC_PROTSEC_VECTOR and RPC_MGMT_AUTHORIZATION_FN d...
by Timo Kreuzer 05 Aug '11

05 Aug '11

Am 05.08.2011 21:35, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Fri Aug 5 19:35:54 2011 > New Revision: 53087 > > URL: http://svn.reactos.org/svn/reactos?rev=53087&view=rev > Log: > [PSDK] > - do not redefine UNICODE_STRING and NTSTATUS if wintrnl.h has already been included ... > -#if !defined(_NTDEF_) > +#if !defined(_NTDEF_)&& !defined(__WINE_WINTERNL_H) > typedef LONG NTSTATUS, *PNTSTATUS; > #endif Thats disgusting! Why do we need this? I hate hacking headers because of crap elsewhere. Regards, Timo

2 1

Status updates of ReactOS people
by Colin Finck 05 Aug '11

05 Aug '11

Hi everybody, As promised, here are the status updates of several ReactOS people based on the texts I received after our failed meeting a week ago. Thomas Faber has reported that the Kernel-Mode Test Framework is pretty much standing, together with extensive tests for Spin Locks, Executive Resources and IRQ-Level functions. Additional "comfort" functions might be added as the need arises. Basic tests also exist for Singly and Doubly Linked Lists, Hard Error Messages, Deferred Procedure Calls and Asynchronous Procedure Call Disabling. Furthermore, applicable tests have been ported from the old "kmtests" module. Thomas is currently working on tests for Events, Fast and Guarded Mutexes as well as basic I/O functionality (Driver/Device Objects, app-driver communication). Latter ones are partly based on the "not-applicable" old tests. More tests concerning Object Referencing, Singly and Doubly Linked Lists and Sequenced lists are going to follow. Even more may follow afterwards based on his personal function list or current requirements. Finally, the integration with our automated testing tools has to be tested. Colin Finck did not have much time for ReactOS in the last month, so he could just assist Pierre Schweitzer with setting up the Icinga monitoring solution. Claudiu Mihail has integrated lwIP into the tcpip.sys driver. The library has also been updated to the most recent version (1.40), which required no changes to the interface code. On top of this, the speed issue has been resolved, so the performance of our lwIP-based stack is on par with our existing OSKitTCP-based stack now. The new network stack has been tested by replacing the tcpip.sys of a regular Trunk build with the lwIP-based one. This posed no problems, so merging the new stack back to Trunk should work nicely. According to Claudiu, initial testing using applications such as Opera, Firefox and BitTorrent shows very promising results in terms of stability and performance. In the short term future, he plans to conduct more testing to fix any outstanding bugs in the implementation. Besides, he plans to optimize some aspects of the implementation, especially regarding memory usage, together with Art Yerkes and Cameron Gutman. For the long-term future, which also includes the time after GSoC, he thinks about moving more TCP/IP functionality to lwIP such as UDP. Pierre Schweitzer has been setting up an Icinga solution for monitoring all our physical servers and VMs, including the services running on them. This will allow the project to have a higher quality of service, and let ReactOS sysadmins be aware quicker about issues raising on the servers. He also announced that he is leaving ReactOS development and only focuses on sysadmin work for the project. - Colin

1 0

Re: [ros-dev] [ros-diffs] [jgardou] 53085: [FREELDR] - Add back apparently lost line of r52098. Patch by Alex Ionescu, tested by Igor Paliychuk. See issue #6292 for more details.
by Jérôme Gardou 05 Aug '11

05 Aug '11

Credits go to Cameron Gutman for the idea. Le 05/08/2011 19:54, jgardou(a)svn.reactos.org a écrit : > Author: jgardou > Date: Fri Aug 5 17:54:06 2011 > New Revision: 53085 > > URL: http://svn.reactos.org/svn/reactos?rev=53085&view=rev > Log: > [FREELDR] > - Add back apparently lost line of r52098. > Patch by Alex Ionescu, tested by Igor Paliychuk. > See issue #6292 for more details. > > Modified: > trunk/reactos/boot/freeldr/freeldr/arcemul/mm.c > > Modified: trunk/reactos/boot/freeldr/freeldr/arcemul/mm.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arcem… > ============================================================================== > --- trunk/reactos/boot/freeldr/freeldr/arcemul/mm.c [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/freeldr/arcemul/mm.c [iso-8859-1] Fri Aug 5 17:54:06 2011 > @@ -30,6 +30,7 @@ > { { MemoryFirmwareTemporary, 0x80, 0x10 }, 4, }, // File system read buffer. FILESYSBUFFER > { { MemoryFirmwareTemporary, 0x90, 0x10 }, 5, }, // Disk read buffer for int 13h. DISKREADBUFFER > { { MemoryFirmwarePermanent, 0xA0, 0x60 }, 6, }, // ROM / Video > + { { MemorySpecialMemory, 0xFFF, 1 }, 7, }, // unusable memory > #elif __arm__ // This needs to be done per-platform specific way > > #endif > >

2 1

Broken Windows_AMD64_1 VBox-Test
by James Tabor 03 Aug '11

03 Aug '11

Hi! I think this broke it.... [ros-diffs] [jgardou] 53025: [CMAKE/GCC] - fix entry point for native dlls Thanks, James

2 1

July Meeting Minutes
by Colin Finck 01 Aug '11

01 Aug '11

Hello all, Today's planned meeting has been postponed to the 25th August (the time of the next regular meeting) based on a voting of the participants present at 19:39 UTC. These were: * Giannis Adamopoulos * Javier Agustìn Fernàndez Arroyo * Maciej Bialas * Thomas Faber * Colin Finck * Ziliang Guo * Cameron Gutman * Rafal Harabien * Timo Kreuzer * Matthias Kupfer * Igor Paliychuk * Sylvain Petreolle * Daniel Reimer * Pierre Schweitzer * Samuel Serapion * Olaf Siejka ○ Result: [19:44] <VoteBot> Question: Please vote for a date for postponing this meeting. [19:44] <VoteBot> Answers: [19:44] <VoteBot> Abstention - 7 votes [19:44] <VoteBot> 11th August (in 2 weeks) - 3 votes [19:44] <VoteBot> 25th August (in 4 weeks, regular next meeting) - 6 votes [19:44] <VoteBot> Total number of votes: 16 ○ Main reasons were that the following people were still not present at the time of voting: * Aleksey Bragin (supposed meeting leader and key person in the Arwinss and Release preparation agenda points) * Amine Khaldi (supposed backup meeting leader and key person in the CMake agenda point) * Ged Murphy (key person in the GSoC and Driver Signing agenda points) ○ Unfortunately, nobody has been prepared for this kind of situation, so a lot of time has been wasted and confusing decisions might have been made. ○ Postponing the points also gives Aleksey time to prepare a new Arwinss build and the Build Environment guys (Daniel, me, anybody wants to join?) time to prepare a final CMake version of RosBE, which might be a factor when deciding about doing the migration to CMake. ○ The IRC Server has been closed at 20:03 UTC. To allow the participants to get an unbiased idea about today's meeting, I will post the original IRC log by the server to ros-priv. Would actually like to make it public on ros-dev as well, but will abstain from doing so until Ged's confusion about the openness of our meetings is cleared. If people have already prepared texts for this meeting (status updates, whatever else you wanted to say), please send them to my E-Mail address within the next 3 days and I'll compose a summary out of them, which I will send to ros-dev. If you think that these texts don't just deserve a simple summary, keep them for the next meeting or do whatever you want about them. And finally a personal note: Please keep in mind that it was not an easy decision for me to just close the IRC Server after I believed that main discussions were over. If I had left it running, it would have invalidated the voting (again) and participants would have treated the meeting even more as a joke. By closing it, I obviously received complaints from people who had prepared stuff for this meeting and wanted to revive it. In good hopes, Colin

5 4

Monthly status meeting reminder
by Aleksey Bragin 01 Aug '11

01 Aug '11

Hello, Let me invite you to the monthly status meeting taking place last thursday of this month, 28th of July, 19:00 UTC. The meeting will be at irc://fezile.reactos.org (Port 6667, no SSL) in the channel #meeting. Note that the IRC service will only be started shortly before the meeting. Everyone is invited to listen, and active community members have their passwords so that they can participate in the discussion. If someone doesn't have a password - please don't hesitate to email Colin to get one. Colin - would you publish the most up-to-date list of participants? Proposed agenda for the meeting: 1. Arwinss adoption voting. 2. CMake status report?. (Do we need to decide anything? If not, then let's move discussion to the mailing list) 3. Release preparation status report. (Decide when to do winesyncs and branch off the release) More suggestions are welcome. With the best regards, Aleksey Bragin.

10 22

Re: [ros-dev] [ros-diffs] [dgorbachev] 52916: [CDFS] Workaround for GCC 4.6 optimizer bug (ICE when compiling with -O3).
by Timo Kreuzer 27 Jul '11

27 Jul '11

Can you explain this one in detail? Am 27.07.2011 04:37, schrieb dgorbachev(a)svn.reactos.org: > Author: dgorbachev > Date: Wed Jul 27 02:37:40 2011 > New Revision: 52916 > > URL: http://svn.reactos.org/svn/reactos?rev=52916&view=rev > Log: > [CDFS] > Workaround for GCC 4.6 optimizer bug (ICE when compiling with -O3). > > Modified: > trunk/reactos/drivers/filesystems/cdfs/fsctl.c > > Modified: trunk/reactos/drivers/filesystems/cdfs/fsctl.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/cdfs/f… > ============================================================================== > --- trunk/reactos/drivers/filesystems/cdfs/fsctl.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/cdfs/fsctl.c [iso-8859-1] Wed Jul 27 02:37:40 2011 > @@ -63,10 +63,10 @@ > for (i = 0; i< 2048; i += 4) > { > /* DON'T optimize this to ULONG!!! (breaks overflow) */ > + Serial.Part[3] += Buffer[i+0]; > + Serial.Part[2] += Buffer[i+1]; > + Serial.Part[1] += Buffer[i+2]; > Serial.Part[0] += Buffer[i+3]; > - Serial.Part[1] += Buffer[i+2]; > - Serial.Part[2] += Buffer[i+1]; > - Serial.Part[3] += Buffer[i+0]; > } > CdInfo->SerialNumber = Serial.Value; > > > >

4 5

Re: [ros-dev] [ros-diffs] [rharabien] 52892: [DESK] - Fix #6262: each new applied color scheme increase the window title height by one - Don't read REG_QWORD directly to DWORD variable
by Jérôme Gardou 26 Jul '11

26 Jul '11

Le 26/07/2011 12:51, rharabien(a)svn.reactos.org a écrit : > - theme->Size[i] = GetSystemMetrics(g_SizeMetric[i]); > + theme->Size[i] = GetSystemMetrics(g_SizeMetric[i]); if(i == SIZE_CAPTION_Y) OutputDebugStringA("GetSystemMetrics!\n"); > This looks strange ;-)

1 0

cmake rant
by Timo Kreuzer 25 Jul '11

25 Jul '11

Hi, Several times now cmake build has been broken. Time for some action! Last meeting I asked everyone to test/use cmake. It was also mentioned that if questions arise, we (Amine and me) would be happy to help out. I can't remember anyone has asked how it works, so I assume noone had any problems. There's also a pretty good wiki entry describing the whole procedure for n00bs. Now people tell me it's complicated, people are complaining that its ridiculous to have 2 build systems, etc. And probably noone has ever tried it. We really need to move on. I don't like having 2 build systems as well. Current blocker is the debugging which has some issues, Arty is working on that. Another problem is a boot problem on real hardware, but no I don't know on which configuration it doesn't work, so we need more people testing it on their real hardware setup and report any issues. Here's a list with current issues: http://www.reactos.org/wiki/CMake_Todo So please: If you are missing something, let us know. If you like to make it better, make suggestions. But stop ignoring cmake! If noone cares and everyone just thinks he can give a s^Z damn until we officially switch, then we can as well delete all cmake stuff and keep rbuild. It has a lot of awesome advantages, like you only have to type one command to build everything and you don't need to install cmake and you can export whatever you want from kernel32 even if the functions don't exist. Also you can enjoy the rbuild-loop again and again. Or we can do it the hard way and delete rbuild, so people are forced to use cmake. I'm sure this approach would be *really* appreaciated. Thanks, Timo

15 25

Re: [ros-dev] [ros-diffs] [jgardou] 52840: [CRT] - get back atexit handling as it was before. (reverts 52838, 52829, 52828) Thanks to Kai and Timo for the explanation
by Jérôme Gardou 24 Jul '11

24 Jul '11

Reverts 52836, 52829 and 52828, sorry. Le 24/07/2011 18:45, jgardou(a)svn.reactos.org a écrit : > Author: jgardou > Date: Sun Jul 24 16:45:41 2011 > New Revision: 52840 > > URL: http://svn.reactos.org/svn/reactos?rev=52840&view=rev > Log: > [CRT] > - get back atexit handling as it was before. > (reverts 52838, 52829, 52828) > Thanks to Kai and Timo for the explanation > > Modified: > trunk/reactos/dll/win32/msvcrt/msvcrt.spec > trunk/reactos/dll/win32/msvcrt20/msvcrt20.spec > trunk/reactos/dll/win32/msvcrt40/msvcrt40.spec > trunk/reactos/lib/3rdparty/mingw/crtexe.c > trunk/reactos/lib/3rdparty/mingw/mingw.rbuild > trunk/reactos/lib/sdk/crt/msvcrtex.cmake > trunk/reactos/lib/sdk/crt/startup/crtdll.c > trunk/reactos/lib/sdk/crt/startup/crtexe.c > > Modified: trunk/reactos/dll/win32/msvcrt/msvcrt.spec > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msvcrt/msvcrt.sp… > ============================================================================== > --- trunk/reactos/dll/win32/msvcrt/msvcrt.spec [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/msvcrt/msvcrt.spec [iso-8859-1] Sun Jul 24 16:45:41 2011 > @@ -1156,7 +1156,7 @@ > @ cdecl asin(double) > @ cdecl atan(double) > @ cdecl atan2(double double) > -@ cdecl atexit(ptr) > +@ extern atexit #<-- keep this as an extern, thank you > @ cdecl atof(str) > @ cdecl atoi(str) > @ cdecl atol(str) > > Modified: trunk/reactos/dll/win32/msvcrt20/msvcrt20.spec > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msvcrt20/msvcrt2… > ============================================================================== > --- trunk/reactos/dll/win32/msvcrt20/msvcrt20.spec [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/msvcrt20/msvcrt20.spec [iso-8859-1] Sun Jul 24 16:45:41 2011 > @@ -937,7 +937,7 @@ > @ cdecl asin(double) > @ cdecl atan(double) > @ cdecl atan2(double double) > -@ cdecl atexit(ptr) > +@ extern atexit #<-- do not touch this! > @ cdecl atof(str) > @ cdecl atoi(str) > @ cdecl atol(str) > > Modified: trunk/reactos/dll/win32/msvcrt40/msvcrt40.spec > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msvcrt40/msvcrt4… > ============================================================================== > --- trunk/reactos/dll/win32/msvcrt40/msvcrt40.spec [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/msvcrt40/msvcrt40.spec [iso-8859-1] Sun Jul 24 16:45:41 2011 > @@ -975,7 +975,7 @@ > @ cdecl asin(double) > @ cdecl atan(double) > @ cdecl atan2(double double) > -@ cdecl atexit(ptr) > +@ extern atexit #<-- changing this will kill your cat, understand? > @ cdecl atof(str) > @ cdecl atoi(str) > @ cdecl atol(str) > > Modified: trunk/reactos/lib/3rdparty/mingw/crtexe.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/3rdparty/mingw/crtexe.… > ============================================================================== > --- trunk/reactos/lib/3rdparty/mingw/crtexe.c [iso-8859-1] (original) > +++ trunk/reactos/lib/3rdparty/mingw/crtexe.c [iso-8859-1] Sun Jul 24 16:45:41 2011 > @@ -71,8 +71,8 @@ > /* TLS initialization hook. */ > extern const PIMAGE_TLS_CALLBACK __dyn_tls_init_callback; > > -//extern _PVFV *__onexitbegin; > -//extern _PVFV *__onexitend; > +extern _PVFV *__onexitbegin; > +extern _PVFV *__onexitend; > > extern int mingw_app_type; > > @@ -119,7 +119,7 @@ > __set_app_type(_GUI_APP); > else > __set_app_type (_CONSOLE_APP); > -// __onexitbegin = __onexitend = (_PVFV *) _encode_pointer ((_PVFV *)(-1)); > + __onexitbegin = __onexitend = (_PVFV *) _encode_pointer ((_PVFV *)(-1)); > > * __MINGW_IMP_SYMBOL(_fmode) = _fmode; > * __MINGW_IMP_SYMBOL(_commode) = _commode; > > Modified: trunk/reactos/lib/3rdparty/mingw/mingw.rbuild > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/3rdparty/mingw/mingw.r… > ============================================================================== > --- trunk/reactos/lib/3rdparty/mingw/mingw.rbuild [iso-8859-1] (original) > +++ trunk/reactos/lib/3rdparty/mingw/mingw.rbuild [iso-8859-1] Sun Jul 24 16:45:41 2011 > @@ -12,7 +12,7 @@ > <include base="ReactOS">include/reactos/mingw-w64</include> > <library>kernel32</library> > <file>_newmode.c</file> > -  > + <file>atonexit.c</file> > <file>binmode.c</file> > <file>charmax.c</file> > <file>cinitexe.c</file> > > Modified: trunk/reactos/lib/sdk/crt/msvcrtex.cmake > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/sdk/crt/msvcrtex.cmake… > ============================================================================== > --- trunk/reactos/lib/sdk/crt/msvcrtex.cmake [iso-8859-1] (original) > +++ trunk/reactos/lib/sdk/crt/msvcrtex.cmake [iso-8859-1] Sun Jul 24 16:45:41 2011 > @@ -17,7 +17,7 @@ > startup/natstart.c > startup/charmax.c > startup/merr.c > -# startup/atonexit.c > + startup/atonexit.c > startup/txtmode.c > startup/pesect.c > startup/tlsmcrt.c > > Modified: trunk/reactos/lib/sdk/crt/startup/crtdll.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/sdk/crt/startup/crtdll… > ============================================================================== > --- trunk/reactos/lib/sdk/crt/startup/crtdll.c [iso-8859-1] (original) > +++ trunk/reactos/lib/sdk/crt/startup/crtdll.c [iso-8859-1] Sun Jul 24 16:45:41 2011 > @@ -49,8 +49,8 @@ > > static int __proc_attached = 0; > > -//extern _PVFV *__onexitbegin; > -//extern _PVFV *__onexitend; > +extern _PVFV *__onexitbegin; > +extern _PVFV *__onexitend; > > extern int mingw_app_type; > > @@ -65,7 +65,7 @@ > static int > pre_c_init (void) > { > -/* _PVFV *onexitbegin; > + _PVFV *onexitbegin; > > onexitbegin = (_PVFV *) malloc (32 * sizeof (_PVFV)); > __onexitend = __onexitbegin = (_PVFV *) _encode_pointer (onexitbegin); > @@ -73,8 +73,7 @@ > if (onexitbegin == NULL) > return 1; > *onexitbegin = (_PVFV) NULL; > - return 0;*/ > - return 1; > + return 0; > } > > WINBOOL WINAPI _CRT_INIT (HANDLE hDllHandle, DWORD dwReason, LPVOID lpreserved) > @@ -136,7 +135,7 @@ > _amsg_exit (31); > } > else > - {/* > + { > _PVFV * onexitbegin = (_PVFV *) _decode_pointer (__onexitbegin); > if (onexitbegin) > { > @@ -146,7 +145,7 @@ > (**onexitend) (); > free (onexitbegin); > __onexitbegin = __onexitend = (_PVFV *) NULL; > - }*/ > + } > __native_startup_state = __uninitialized; > (void) InterlockedExchangePointer ((volatile PVOID *)&__native_startup_lock, 0); > } > > Modified: trunk/reactos/lib/sdk/crt/startup/crtexe.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/sdk/crt/startup/crtexe… > ============================================================================== > --- trunk/reactos/lib/sdk/crt/startup/crtexe.c [iso-8859-1] (original) > +++ trunk/reactos/lib/sdk/crt/startup/crtexe.c [iso-8859-1] Sun Jul 24 16:45:41 2011 > @@ -75,8 +75,8 @@ > /* TLS initialization hook. */ > extern const PIMAGE_TLS_CALLBACK __dyn_tls_init_callback; > > -//extern _PVFV *__onexitbegin; > -//extern _PVFV *__onexitend; > +extern _PVFV *__onexitbegin; > +extern _PVFV *__onexitend; > > extern int mingw_app_type; > > @@ -128,7 +128,7 @@ > __set_app_type(_GUI_APP); > else > __set_app_type (_CONSOLE_APP); > -// __onexitbegin = __onexitend = (_PVFV *) _encode_pointer ((_PVFV *)(-1)); > + __onexitbegin = __onexitend = (_PVFV *) _encode_pointer ((_PVFV *)(-1)); > > * __MINGW_IMP_SYMBOL(_fmode) = _fmode; > * __MINGW_IMP_SYMBOL(_commode) = _commode; > >

1 0

Re: [ros-dev] [ros-diffs] [jgardou] 52831: [LIBWINE] - new tentative to fix build : get rid of libwine's stricmp, we have it in our crt
by Gabriel ilardi 24 Jul '11

24 Jul '11

Wouldn't it be advisable besides the commit message also to add a comment to the code as why stuff is commented out ? > Date: Sun, 24 Jul 2011 10:29:53 +0000 > To: ros-diffs(a)reactos.org > From: jgardou(a)svn.reactos.org > Subject: [ros-diffs] [jgardou] 52831: [LIBWINE] - new tentative to fix build : get rid of libwine's stricmp, we have it in our crt > > Author: jgardou > Date: Sun Jul 24 10:29:52 2011 > New Revision: 52831 > > URL: http://svn.reactos.org/svn/reactos?rev=52831&view=rev > Log: > [LIBWINE] > - new tentative to fix build : get rid of libwine's stricmp, we have it in our crt > > Modified: > trunk/reactos/lib/3rdparty/libwine/CMakeLists.txt > trunk/reactos/lib/3rdparty/libwine/libwine.rbuild > > Modified: trunk/reactos/lib/3rdparty/libwine/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/3rdparty/libwine/CMake… > ============================================================================== > --- trunk/reactos/lib/3rdparty/libwine/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/lib/3rdparty/libwine/CMakeLists.txt [iso-8859-1] Sun Jul 24 10:29:52 2011 > @@ -6,7 +6,7 @@ > config.c > debug_ros.c > loader.c > - string.c) > +# string.c) > > add_library(wine ${SOURCE}) > > > Modified: trunk/reactos/lib/3rdparty/libwine/libwine.rbuild > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/3rdparty/libwine/libwi… > ============================================================================== > --- trunk/reactos/lib/3rdparty/libwine/libwine.rbuild [iso-8859-1] (original) > +++ trunk/reactos/lib/3rdparty/libwine/libwine.rbuild [iso-8859-1] Sun Jul 24 10:29:52 2011 > @@ -7,7 +7,7 @@ > <file>config.c</file> > <file>debug_ros.c</file> > <file>loader.c</file> > - <file>string.c</file> > +  > </module> > <module name="wineldr" type="staticlibrary"> > <include base="ReactOS">include/reactos/wine</include> > >

1 0

Re: [ros-dev] [ros-diffs] [ion] 52807: [KERNEL32]: Optimize SwitchToFiber to simply use "ret" to jump between fibers, instead of saving EIP and doing a JMP. Bug #50: SwitchToFiber needs to check if FXSR is *NOT* present in ...
by Timo Kreuzer 23 Jul '11

23 Jul '11

This won't work, since new Fibers, created with CreateFiber(Ex) don't push a "return address" on the stack, but set the Eip member to BaseFiberStartup. Am 23.07.2011 14:08, schrieb ion(a)svn.reactos.org: > Author: ion > Date: Sat Jul 23 12:08:36 2011 > New Revision: 52807 > > URL: http://svn.reactos.org/svn/reactos?rev=52807&view=rev > Log: > [KERNEL32]: Optimize SwitchToFiber to simply use "ret" to jump between fibers, instead of saving EIP and doing a JMP. > Bug #50: SwitchToFiber needs to check if FXSR is *NOT* present in order to skip using ldmxcsr/stmxcsr. Previously, it would check if it's unsupported, and jump past the instruction if it was (resulting in invalid opcode instructions on older systems) > 50 bugs. Penance has been paid. > > Modified: > trunk/reactos/dll/win32/kernel32/client/i386/fiber.S > > Modified: trunk/reactos/dll/win32/kernel32/client/i386/fiber.S > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/… > ============================================================================== > --- trunk/reactos/dll/win32/kernel32/client/i386/fiber.S [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/kernel32/client/i386/fiber.S [iso-8859-1] Sat Jul 23 12:08:36 2011 > @@ -26,20 +26,16 @@ > mov [eax+FIBER_CONTEXT_EDI], edi > mov [eax+FIBER_CONTEXT_EBP], ebp > > - /* Save the return address */ > - mov ebx, [esp] > - mov [eax+FIBER_CONTEXT_EIP], ebx > - > /* Check if we're to save FPU State */ > cmp dword ptr [eax+FIBER_CONTEXT_FLAGS], CONTEXT_FULL OR CONTEXT_FLOATING_POINT > jnz NoFpuStateSave > > /* Save the FPU State (Status and Control)*/ > fstsw [eax+FIBER_CONTEXT_FLOAT_SAVE_STATUS_WORD] > - fstcw [eax+FIBER_CONTEXT_FLOAT_SAVE_CONTROL_WORD] > + fnstcw [eax+FIBER_CONTEXT_FLOAT_SAVE_CONTROL_WORD] > > /* Check if the CPU supports SIMD MXCSR State Save */ > - cmp byte ptr ds:[PROCESSOR_FEATURE_FXSR], 0 > + cmp byte ptr ds:[PROCESSOR_FEATURE_FXSR], 1 > jnz NoFpuStateSave > stmxcsr [eax+FIBER_CONTEXT_DR6] > > @@ -103,7 +99,7 @@ > ControlWordEqual: > > /* Load the new one */ > - cmp byte ptr ds:[PROCESSOR_FEATURE_FXSR], 0 > + cmp byte ptr ds:[PROCESSOR_FEATURE_FXSR], 1 > jnz NoFpuStateRestore > ldmxcsr [ecx+FIBER_CONTEXT_DR6] > > @@ -121,7 +117,8 @@ > mov [edx+TEB_FLS_DATA], eax > > /* Jump to new fiber */ > - jmp dword ptr [ecx+FIBER_CONTEXT_EIP] > + mov esp, [ecx+FIBER_CONTEXT_ESP] > + ret 4 > +END > > -END > /* EOF */ > > >

1 0

Re: [ros-dev] [ros-diffs] [ion] 52806: [KERNEL32]: Implement BaseFiberStartup in ASM, just like the thread/process thunks, so we get a "naked" thunk without any compiler-generated crap.
by Timo Kreuzer 23 Jul '11

23 Jul '11

Am 23.07.2011 14:05, schrieb ion(a)svn.reactos.org: > Author: ion > Date: Sat Jul 23 12:05:38 2011 > New Revision: 52806 > > URL: http://svn.reactos.org/svn/reactos?rev=52806&view=rev > Log: > [KERNEL32]: Implement BaseFiberStartup in ASM, just like the thread/process thunks, so we get a "naked" thunk without any compiler-generated crap. I don't see the point in this change. That "crap" is setting up a stack frame, which is pretty useful for debugging. It consists of 3 instructions: push ebp mov ebp, esp sub esp, 8 Your change also broke compilation with MSVC (the END directive is only at the end of the file!) and deleted the function for amd64. The function is not performance critical and the asm code doesn't really add any performace gain anyway. So why are we going back? I'm asking, because I've been working on converting more asm code to C code and IMO thats the way to go. Regards, Timo

1 0

Re: [ros-dev] [ros-diffs] [dgorbachev] 52557: [FREELDR] - Move read-only data into data section (allows to boot with GRUB again). - Discard .drectve sections. - Silence "set but not used" warnings.
by Timo Kreuzer 15 Jul '11

15 Jul '11

Am 07.07.2011 21:19, schrieb dgorbachev(a)svn.reactos.org: > Author: dgorbachev > Date: Thu Jul 7 19:19:44 2011 > New Revision: 52557 > > URL: http://svn.reactos.org/svn/reactos?rev=52557&view=rev > Log: > [FREELDR] > - Move read-only data into data section (allows to boot with GRUB again). > - Discard .drectve sections. > - Silence "set but not used" warnings. I assume this is for rbuild. Did you check cmake builds, too?

3 4

ReactOS MSVC Debugging Snapshot
by Neeraj Yadav 12 Jul '11

12 Jul '11

Hi, Amine Khaldi suggested me to take this snapshot of ReactOS being debugged in Visual Studio.Here it is

2 1

Re: [ros-dev] [ros-diffs] [ion] 52596: [NTDLL]: More attempts at fixing up the loader, this time in the PE side of things.
by Aleksey Bragin 12 Jul '11

12 Jul '11

-----Original Message----- From: ion(a)svn.reactos.org Sent: Sunday, July 10, 2011 6:14 AM To: ros-diffs(a)reactos.org Subject: [ros-diffs] [ion] 52596: [NTDLL]: More attempts at fixing up the loader, this time in the PE side of things. Author: ion Date: Sun Jul 10 02:14:29 2011 New Revision: 52596 /* Check if we got at least one */ - if (BoundEntry || ImportEntry) + if ((BoundEntry) || (ImportEntry)) Could you enlighten me why do you add these redunandant braces? WBR, Aleksey.

5 4

Snapshot of ReactOS being Debugged in Visual Studio
by Neeraj Yadav 10 Jul '11

10 Jul '11

http://img855.imageshack.us/img855/7541/reactosmsvcdebugging.jpg

1 0

TestCD regression
by caemyr＠myopera.com 09 Jul '11

09 Jul '11

As some of you might already noticed, we have another runtime regression, this time limited to TestCD. What is even more interesting, same as in AC97 driver issue, it was the CMake build which started to show this bug, then followed by rbuild trunk: CMake r52578: http://build.reactos.org/builders/Windows_AMD64_1%20VBox-Test/builds/1962 RBuild r52580: http://build.reactos.org/builders/Windows_AMD64_1%20VBox-Test/builds/1961 RBuild r52581: http://build.reactos.org/builders/Windows_AMD64_1%20VBox-Test/builds/1963 I haven't seen anything hawkward on bootcd's. Those can be still booted to 3rd stage. With best regards Caemyr

1 0

June ReactOS Meeting Minutes
by victor martinez 07 Jul '11

07 Jul '11

June Meeting Minutes 2011-06-28 19:05 UTC Fezile IRC Server, #meeting Participants ============= - Jan_Blomqvist_Kinander - Igor_Paliychuk - MfldElton - Usurp - Aleksey_Bragin - Thomas_Faber - Giannis_Adamopoulos - Thomas_Faber - Johannes_Anderwald - Timo_Kreuzer - Olaf_Siejka - Jerome_Gardou - Gabriel_Ilardi - Andrew_Green - Javier_Fernandez - Victor_Martinez - Amine_Khaldi - Claudiu_Mihail - Colin_Finck - Rafal_Harabien - Sylvain_Petreolle - Matthias_Kupfer - Danny_Goette - Maciej_Bialas - Ged_Murphy - Ziliang_Guo - Art_Yerkes - Cameron_Gutman - Neeraj_Yadav - Herve_Poussineau - Daniel_Reimer - James_Tabor - Olaf_Siejka - Samuel_Serapion - Pierre_Schweitzer - Alex_Ionescu - Gabriel_Ilardi Proceedings ============ ○ Meeting called to order at 19:05 UTC by Aleksey Bragin. ○ ReactOS Project coordinator Aleksey Bragin listed the points of the proposed agenda for June meeting: 1. Cmake switching 2. Next ReactOS release 3. Website revamp status 4. GSoC status 5. Developers status reports The Minute Taker rol was given to Victor_Martinez for this meeting. ○ Point 1: CMake switching -------------------------------------------- ■ The ReactOS developer Timo gave a quick sum up about CMake status: He reported that the CMake build is more or less ready, currently missing rosapps. He stated that rosapps are not a major problem as they're rarely used, and cmake files for them can be done if needed. He also mentioned a problem, confirmed by Igor_Paliychuk, related to booting in real hardware, in addition to the winmm:mci regression. The problem detected in real hardware is very specific to the hardware combination thus hard to test. ■ Amine mentioned that several comparative tests have been done through buildbot/testman between the rbuild build and the CMake build, showing no measurable differences. He also stated that the CMake port shouldn't be considered done yet, as it still lacks many planned features. He highlighted some of the CMake patches,made by Jerome, to be sent upstream, like the PCH support and its related dependency tracking, and also the benefits of using CMake to compile ros, like the improved performance, the small disk space needed for builds (half of what the rbuild builds require) and the cool new kdbg features.Gabriel_Ilardi expressed his concers about merging more code in the current trunk situation. Timo replied that no code merge is needed,in case of switching to Cmake. ■ Timo, Colin and Aleksey asked about measuring the CMake build performance over the rbuild build in numbers. Jerome performed a quick benchmark: First test: makex ntoskrnl (all clean, toold already built). Cmake: 04:06 , Rbuild: 04:55 (17% faster) Second test: rebuild (only dependencies check). Cmake: 0:28 , Rbuild: 1:04 (56% faster) The benchmark shows Cmake is faster not only for a full compilation but also recompiling (ntoskrnl) modules. ■ The ReactOS Cmake Team suggested to begin using Cmake with current RosBE to compile ReactOS ISOs in order to assure they are as good as Rbuild’s. A "How to compile with Cmake" tutorial can be found in the following wikipage: http://reactos.org/wiki/Cmake Summing up, the Cmake switch will bring better dependency checking, fast rebuild of single modules and much better symbols support in kdbg according to the ReactOS Cmake Team The technical description was left to be discussed in #reactos-dev, if anyone was interested. ○ Point 2 : Next ReactOS release -------------------------------------------------------- ¦ReactOS release was the 2nd point of the June meeting agenda. ■ Gabriel_Ilardi and Victor_Martinez were asked to report current trunk state from Compatibility/Stability point of view. Accordingly to forum threads, Bugzilla new entries, and Own testing,Gabriel and Victor said important regressions have been introduced due the latest changes, and mainly the LDR rewrite. Wrong icons, impossibility to shutdown, AC97 hang, several installers/apps failing are some of those important regressions. ■ Art_Yerkes has been giving a look at the AC97 bug, he was able to gather a lot of information about the regression and asks for collaboration to fix it. ■ Aleksey_Bragin, as the author of the LDR rewrite, stated that he knew the new LDR could introduce regressions but that it is a big step forward. The top priority is fixing those LDR regressions, instead of reverting, as the old LDR was indeed worse. Aleksey remarks that he needs every dev to take a look at the LDR bugs and try to fix them. The LDR regressions should be really easy to fix thanks to the rewrite, he said. ■ Amine_Khaldi suggested to decide when it is time to release performing bugfixing and full regression testing. ■ The idea of performing full regression tests now was inmediatly rejected by Colin_Finck and Olaf_Siejka since bug reports are currently showing that our trunk is in a really bad shape. Due to this, the Release discussion will be on hold until the next meeting. During this month ReactOS devs are suggested to focus in bugfixing mainly the LDR code. As these bugs are critical and able to hide other minors regressions, a special call is being made: ****************Special Call**************** "Please pick a bug from the linked ones in http://reactos.org/bugzilla/show_bug.cgi?id=6346 " ****************Special Call**************** ○ Point 3 : Website Revamp Status ------------------------------------------------------- ¦ Thanks to Colin's help, a new playground with correct permissions and tied to an SVN branch has been created. ■ Niski and aross, main webrevamp developers, have been focused on Bugzilla and Mediawiki integration, compatdb drupal port, and forum. Forum will have new features as "the best answer" and "karma" modules which will improve forum users experience. ■ Niski has completed the work on Bugzilla and Mediawiki while aross is working on compatdb and the new forum. ■ Right now, Amine said, a design/layout work is needed in parallel. ■ Colin_Finck stated that finding a designer among ReactOS developers is more difficult than findind a developer so he offered himself to help with the design/layout. ○ Point 4: Gsoc status ------------------------------------------------------------------- ■ AndrewGreen is currently cleaning a mixture of explorer_new, atl com and browseui code. The resultant code will be commited afterwards. Although he recognizes his project is behind schedule, after apologizing he says he’s confident to meet the goals by midsemester evaluation. Ged_Murphy cpp shell32 code will allow him to use atl com for everything shell related. Colin_Finck and Olaf_Siejka discussed the best way to test the new implementation to check for any possible regressions, due to the fact that Ged was not around the discussion was postponed. Jerome_Gardou asked Andrew about the WINE Shell32 Gsoc project but accordingly to Olaf, Wine has refused to cooperate regarding those. Status: Behind Schedule. ■ Giannis_Adamopoulos was too busy with exams so his project was parked a little. His commits will raise up when the last exam is done. Status: On time ■ Claudiu_Mihail thanked the great help of Cameron_Gutman and Art_Yerkes. The project is set to meet the deadlines for midterm. There are still two problems remaining: browsers don't work(it will be solved by midterms), slowness of the lwIP implementation. He has followed the test approach using several simple test apps and fixing revealed bugs. After finishing his thesis project, which is highly related to his Gsoc project,he will start commiting again. ■ Neeraj_Yadav has divided his sound project in 5 parts. 1.[Finished] Writing a skeleton server which can hold the audio converter modules and the mixer modules ...This server should be capable of insertion in the reactos audio chain [4 weeks] 2.[Now] Writing mixer modules [2 weeks] 3.Writing audio converter [ 4 weeks] 4.Inserting this audio server in the reactos audio chain [1 week] 5.testing/styling/documentation [1 week] He expects to finish the 2nd step in midterm evaluation. Alex_Ionescu and Giannis_Adamopoulos asked for a way to test Neeraj code. If anyone is interested, this is the best way: 1)make audsrv && make audclient 2)run audsrv -n in one console 3)run audclient in other 4)open as many audclients as you want 5)the server should play a mixed sound Status: On time ■ Thomas_Faber is finishing the main framework needed to run the tests. Most of the old tests have been ported and now he is currently working on getting special-purpose drivers and usermode test parts up and running. Lately he has been quite busy with a university project but he expects to commit the framework in these days. Status: On time ■ Timo_Kreuzer has finished the font driver loading and now he is working on the font mapper, which is complex and needs a good design. Status: Ahead of time ○ Point 5: Developers status reports ------------------------------------------------------------------- ■ Alex_Ionescu will help Aleksey commit his scater/gather DMA patch. ■ Alex_Bragin is working on remaining LDR code and afterwards he'll take part in processing bugzilla patches. ■ Amine_Khaldi is focused in cmake and the website revamp. ■ Art_Yerkes made some improvements to symbol handling in the cmake branch and now he’s working with Claudiu. ■ Colin_Finck has been trying the KDUSBCOM idea (KD DLL for debugging over an USB-to-Serial adapter), and he’s moving now to help with the website layout. ■ Daniel_Reimer is playing with Gcc builds and updating RosBE.He added Cmake support a while ago and he is still battling with GCC 4.6 and Wine RC files. ■ Gabriel_Ilardi is focused in mantaining Bugzilla and the forum and he’s performing some testing in his few spare time. ■ Ged_Murphy is helping with shell32 c++ fixup ■ Herve_Poussineau is currently inactive on ReactOS ■ James_Tabor is still working on bug report issues. ■ Jan_Blomqvist_Kinander will move the Fezile server to the concrete bunker creating a LAN behind Fezile to get automated tests on real hardware. ■ Johannes Anderwald will work in HID (Human Interface Devices for USB) support during the summer, a hard task as it is completly undocumented. ■ Maciej_Bialas is working on mediawiki integration for the new revamped site. ■ Matthias_Kupfer has been bugfixing and commiting some patches. ■ Pierre_Schweitzer has no time nor willingness right now. Once time will be back,he'll invest it in his summer student.Once willingness will be back, he'll keep on his current ReactOS work and help with the ReactOS infrastructure ■ Olaf_Siejka is waiting for Aleksey to finish the LDR code so he can team up with him to solve the remaining issues of sysreg4. After finishing the utf-8 resource conversion, he will get more involved in testing. He will also help with the hardware testbot from the buildbot side. ■ Sylvain_Petreolle is working on French translations. ■ Timo_Kreuzer is working on MSVC builds fixing several bugs that prevent ReactOS to reach the desktop. ■ Victor_Martinez has finished his exams recently and now he’s preparing a forum team to test the revision before the LDR rewrite and the one after it, this way it'll be easier to find regressions. Also he will help with the revamp webpage. ○ Point 6: Suggestions --------------------------- ■ Jan_Blomqvist_Kinander suggested to create a ReactOS annual bootcamp with devs, testers and fanatics plus having a look at SAMBA 4 - ROS port ○ Meeting closed at 22:08 UTC by Colin Finck on behalf of Aleksey Bragin. ○ Minutes written by Víctor Martínez. ○ Reviewed by Amine_Khaldi, and Gabriel_Ilardi

2 1

Myreactos.com hosting account will be suspended in the next 24 hours.
by victor martinez 06 Jul '11

06 Jul '11

Hi! Sadly the hosting that I was providing for free will be suspended in the next 24 hours. I was totally fed up with these iPage guys so decided to move everything out. The website and all the content in the folders will be removed. I will keep the myreactos.com domain for a year or maybe I will remove it too.If anyone is interested please contact me. If anyone is still using the hosting, please back your files up. WBR, Víctor Martínez

1 0

Re: [ros-dev] [ros-diffs] [cgutman] 52522: [LDR] - "Just to be sure" is no reason to overwrite a potential DLL load failure status
by Aleksey Bragin 04 Jul '11

04 Jul '11

That was there on purpose really, because the error had to be ignored. I will get back to this tomorrow to review, so just "marking" this revision that way. WBR, Aleksey. -----Original Message----- From: cgutman(a)svn.reactos.org Sent: Monday, July 04, 2011 12:16 AM To: ros-diffs(a)reactos.org Subject: [ros-diffs] [cgutman] 52522: [LDR] - "Just to be sure" is no reason to overwrite a potential DLL load failure status Author: cgutman Date: Sun Jul 3 20:16:12 2011 New Revision: 52522 URL: http://svn.reactos.org/svn/reactos?rev=52522&view=rev Log: [LDR] - "Just to be sure" is no reason to overwrite a potential DLL load failure status 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] Sun Jul 3 20:16:12 2011 @@ -345,9 +345,6 @@ DllName, BaseAddress, TRUE); - - /* Set it to success just to be sure */ - Status = STATUS_SUCCESS; /* Restore the old TLD DLL */ LdrpTopLevelDllBeingLoaded = OldTldDll;

1 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 52513: [NTOSKRNL] - Fix KdComponentTableSize - Make assembly instruction in KiCallUserMode MASM compatible - silence some KD internal debug prints The MSVC bootcd boots to desktop, but c...
by Alex Ionescu 03 Jul '11

03 Jul '11

There's a nice RTL_NUMBER_OF or similar macro for the KdComponentTableSize. Best regards, Alex Ionescu On Sun, Jul 3, 2011 at 11:57 AM, <tkreuzer(a)svn.reactos.org> wrote: > Author: tkreuzer > Date: Sun Jul 3 09:56:59 2011 > New Revision: 52513 > > URL: http://svn.reactos.org/svn/reactos?rev=52513&view=rev > Log: > [NTOSKRNL] > - Fix KdComponentTableSize > - Make assembly instruction in KiCallUserMode MASM compatible > - silence some KD internal debug prints > The MSVC bootcd boots to desktop, but crashes with BAD_POOL_HEADER before 2nd stage setup starts. > > Modified: > trunk/reactos/ntoskrnl/kd64/kddata.c > trunk/reactos/ntoskrnl/ke/i386/usercall_asm.S > trunk/reactos/ntoskrnl/mm/ARM3/mmdbg.c > > Modified: trunk/reactos/ntoskrnl/kd64/kddata.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/kd64/kddata.c?rev… > ============================================================================== > --- trunk/reactos/ntoskrnl/kd64/kddata.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/kd64/kddata.c [iso-8859-1] Sun Jul 3 09:56:59 2011 > @@ -356,7 +356,7 @@ > &Kd_ENDOFTABLE_Mask, > }; > > -ULONG KdComponentTableSize = sizeof(KdComponentTable); > +ULONG KdComponentTableSize = sizeof(KdComponentTable) / sizeof(KdComponentTable[0]); > > // > // Debugger Data > > Modified: trunk/reactos/ntoskrnl/ke/i386/usercall_asm.S > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/usercall_… > ============================================================================== > --- trunk/reactos/ntoskrnl/ke/i386/usercall_asm.S [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ke/i386/usercall_asm.S [iso-8859-1] Sun Jul 3 09:56:59 2011 > @@ -13,7 +13,7 @@ > #include <internal/i386/asmmacro.S> > > EXTERN _MmGrowKernelStack@4:PROC > -EXTERN _KeUserCallbackDispatcher:PROC > +EXTERN _KeUserCallbackDispatcher:DWORD > EXTERN @KiServiceExit@8:PROC > EXTERN _KeGetCurrentIrql@0:PROC > EXTERN _KeBugCheckEx@20:PROC > @@ -190,7 +190,7 @@ > > /* Get user-mode dispatcher address and set it as EIP */ > SetEip: > - mov eax, _KeUserCallbackDispatcher > + mov eax, dword ptr [_KeUserCallbackDispatcher] > mov [esp+KTRAP_FRAME_EIP], eax > > /* Set the exception list */ > > Modified: trunk/reactos/ntoskrnl/mm/ARM3/mmdbg.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/mmdbg.c?r… > ============================================================================== > --- trunk/reactos/ntoskrnl/mm/ARM3/mmdbg.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/mm/ARM3/mmdbg.c [iso-8859-1] Sun Jul 3 09:56:59 2011 > @@ -17,6 +17,8 @@ > > #ifndef _WINKD_ > #define KdpDprintf DPRINT > +#elif defined(NDEBUG) > +#define KdpDprintf(...) > #endif > > /* GLOBALS ********************************************************************/ > > >

1 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 52507: [NTOSKNRL] - Change an ASSERT to a KeBugCheck, since the assertion can fail for any invalid memory access and this is not an internal Mm failure. - Remove 2 cases, that "Should NE...
by Alex Ionescu 03 Jul '11

03 Jul '11

Why do you have to be this way? I gave you a link to 3 PDFs and our own Wiki that explain these functions. Did you even read them? Don't be an asshole just for fun. Best regards, Alex Ionescu On Sun, Jul 3, 2011 at 1:11 AM, <tkreuzer(a)svn.reactos.org> wrote: > Author: tkreuzer > Date: Sat Jul 2 23:11:06 2011 > New Revision: 52507 > > URL: http://svn.reactos.org/svn/reactos?rev=52507&view=rev > Log: > [NTOSKNRL] > - Change an ASSERT to a KeBugCheck, since the assertion can fail for any invalid memory access and this is not an internal Mm failure. > - Remove 2 cases, that "Should NEVER happen on ARM3!!!", but can very well happen. > - Do NOT make the code cleaner, by releasing the PFN lock in the same function that acquires it, but keep it 2 functions down. This is because it *SHOULD* be that way, since some internal undocumented functions, that we do not implement but that are (theoretically) called from here, also do release the PFN lock. Thanks Alex for explaining this. > > 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] Sat Jul 2 23:11:06 2011 > @@ -583,10 +583,19 @@ > } > > // > - // The PTE must be invalid, but not totally blank > + // The PTE must be invalid > // > ASSERT(TempPte.u.Hard.Valid == 0); > - ASSERT(TempPte.u.Long != 0); > + > + /* Check if the PTE is completely empty */ > + if (TempPte.u.Long == 0) > + { > + KeBugCheckEx(PAGE_FAULT_IN_NONPAGED_AREA, > + (ULONG_PTR)Address, > + StoreInstruction, > + (ULONG_PTR)TrapInformation, > + 2); > + } > > // > // No prototype, transition or page file software PTEs in ARM3 yet > @@ -727,11 +736,6 @@ > // Writing to a read-only page (the stuff ARM3 works with is write, > // so again, moot point). > // > - if (StoreInstruction) > - { > - DPRINT1("Should NEVER happen on ARM3!!!\n"); > - return STATUS_ACCESS_VIOLATION; > - } > > // > // Otherwise, the PDE was probably invalid, and all is good now > @@ -776,11 +780,6 @@ > // Writing to a read-only page (the stuff ARM3 works with is write, > // so again, moot point. > // > - if (StoreInstruction) > - { > - DPRINT1("Should NEVER happen on ARM3!!!\n"); > - return STATUS_ACCESS_VIOLATION; > - } > > /* Release the working set */ > MiUnlockWorkingSet(CurrentThread, WorkingSet); > > >

1 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 52496: [FAT32] Add some code that does ... nothing, but fixes 2nd stage boot with msvc. To figure out why this is needed, is left as an excercise to the reader :)
by Alex Ionescu 01 Jul '11

01 Jul '11

I know why this is "needed", but this is a temporary hack, right? Best regards, Alex Ionescu On Thu, Jun 30, 2011 at 9:06 PM, <tkreuzer(a)svn.reactos.org> wrote: > Author: tkreuzer > Date: Fri Jul 1 01:06:19 2011 > New Revision: 52496 > > URL: http://svn.reactos.org/svn/reactos?rev=52496&view=rev > Log: > [FAT32] > Add some code that does ... nothing, but fixes 2nd stage boot with msvc. To figure out why this is needed, is left as an excercise to the reader :) > > Modified: > trunk/reactos/boot/freeldr/bootsect/fat32.S > > Modified: trunk/reactos/boot/freeldr/bootsect/fat32.S > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/bootsect/fat3… > ============================================================================== > --- trunk/reactos/boot/freeldr/bootsect/fat32.S [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/bootsect/fat32.S [iso-8859-1] Fri Jul 1 01:06:19 2011 > @@ -194,6 +194,13 @@ > mov dl, byte ptr BP_REL(BootDrive) // Drive number > mov ah, HEX(42) // Int 13h, AH = 42h - Extended Read > int HEX(13) // Call BIOS > + > + /* This code "fixes" loading the MSVC built kernel */ > + pushad > + mov si, offset msgNull > + call PutChars > + popad > + > jc PrintDiskError // If the read failed then abort > > add sp, 16 // Remove disk address packet from stack > @@ -302,6 +309,8 @@ > .ascii "File system error", CR, LF, NUL > msgAnyKey: > .ascii "Press any key to restart", CR, LF, NUL > +msgNull: > + .ascii NUL > > .org 509 // Pad to 509 bytes > > @@ -527,7 +536,7 @@ > filename: > .ascii "FREELDR SYS" > msgLoading: > - .ascii "Loading FreeLoader...\r\n", CR, LF, NUL > + .ascii "Loading FreeLoader...", CR, LF, NUL > > .org 1022 // Pad to 1022 bytes > > > >

2 1

Monthly meeting reminder
by Aleksey Bragin 30 Jun '11

30 Jun '11

Hello, Last thursday of this month is quite close, 30th of June, 20:00 UTC I'm awaiting you all for the monthly status meeting. Colin said that our private irc server is going to be ready by that date, so if that's still true, Colin - could you please provide details for those who don't remember where to connect? Proposed agenda is: 1. New release of ReactOS 2. Website work status 3. GSoC status 4. Developers status. With the best regards, Aleksey Bragin.

11 23

Re: [ros-dev] [ros-diffs] [osiejka] 52486: [TRANSLATION] - CACLS, CALC and CHARMAP UTF8 co
by Pierre Schweitzer 29 Jun '11

29 Jun '11

I'm definitely not sure that the header[1] added to all converted files was absolute necessity. AFAIK, that's SVN logs purpose... Unless someone has a real justification to such line? Many files even don't have a translator copyright but this line... Weird! [1]: /* UTF-8 Conversion: Elton Chung aka MfldElton <elton328(a)gmail.com> (June, 2011) */

5 5

Re: [ros-dev] [ros-diffs] [ekohl] 52470: [NDK] Add missing interrupt resource descriptor flags.
by Alex Ionescu 27 Jun '11

27 Jun '11

Hi Erik, The NDK is for *undocumented* types. These flags are documented. -- Best regards, Alex Ionescu On 2011-06-26, at 7:29 AM, ekohl(a)svn.reactos.org wrote: > CM_RESOURCE_INTERRUPT_LEVEL_SENSITIVE

3 2

LDR rewrite
by Aleksey Bragin 26 Jun '11

26 Jun '11

Hello, as all of you could notice, I committed the LDR rewrite recently. I tried to get rid of as much regressions as possible (any rewrite should introduce improvements of course, rewrites are not done to introduce regressions, however there is no rewrite without some particulars problems). So, dear developers, I need your help. Gabriel did a very nice work and bugzilled all kinds of problems which new LDR introduced. Here is the meta-bug: http://www.reactos.org/bugzilla/show_bug.cgi?id=6346 Please look into the bugs, check something and add your findings to bugzilla. The new LDR code is perfectly organized, very well documented, so most of those bugs should be quite simple to fix, but my time is not infinite, so I'm asking for collaboration. I'm always available via IRC for any questions about the new code, so feel free to ask. Put away your usual stuff for an hour or for a day and look into those. It would help greatly and motivate me to finish other parts of the rewrite quicker. Thanks, Aleksey Bragin.

1 0

dmesg of #6018 Re: [ros-diffs] [rharabien] 52409: [BOOTVID] - Revert part of r52239: Fix support for \r and do not handle backspace - Simplify it a bit [NTOSKRNL] - Add backspace support to KdpScreenPrint - Do not draw boot text...
by Minas Abrahamyan 21 Jun '11

21 Jun '11

Dear Rafal, Since you are touching the code of /ntoskrnl/kd/kdio.c, wouldn't you be kind enough to review and possibly apply my "dmesg command patch"? Issue in bugzilla: http://www.reactos.org/bugzilla/show_bug.cgi?id=6018 patch itself: http://www.reactos.org/bugzilla/attachment.cgi?id=6055 It contains much of code of KdbpPrint() function, in function KdbpPager(), etc. The is explanations about it in issue description. *** To all: This patch is suspended in bugzilla from March, although I noticed some weak attempts to do something with it, say reassign to somebody, but yet without any advance. Hope something will be changed with this. Thanks for attention -Minas Abrahamyan On Wed, Jun 22, 2011 at 12:47 AM, <rharabien(a)svn.reactos.org> wrote: > Author: rharabien > Date: Tue Jun 21 19:47:13 2011 > New Revision: 52409 > > URL: http://svn.reactos.org/svn/reactos?rev=52409&view=rev > Log: > [BOOTVID] > - Revert part of r52239: Fix support for \r and do not handle backspace > - Simplify it a bit > > [NTOSKRNL] > - Add backspace support to KdpScreenPrint > - Do not draw boot text bitmap if InbvDisplayString is called with "" or "." (matches NT behavior) > > Modified: > trunk/reactos/drivers/base/bootvid/i386/vga.c > trunk/reactos/ntoskrnl/inbv/inbv.c > trunk/reactos/ntoskrnl/kd/kdio.c > > Modified: trunk/reactos/drivers/base/bootvid/i386/vga.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/base/bootvid/i386/… > ============================================================================== > --- trunk/reactos/drivers/base/bootvid/i386/vga.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/base/bootvid/i386/vga.c [iso-8859-1] Tue Jun 21 19:47:13 2011 > @@ -66,6 +66,7 @@ > ULONG TextColor = 0xF; > ULONG curr_x = 0; > ULONG curr_y = 0; > +BOOLEAN CarriageReturn = FALSE; > ULONG_PTR VgaRegisterBase = 0; > ULONG_PTR VgaBase = 0; > > @@ -279,14 +280,8 @@ > NTAPI > VgaScroll(ULONG Scroll) > { > - ULONG Top; > - ULONG SourceOffset, DestOffset; > - ULONG Offset; > - ULONG i, j; > - > - /* Set memory positions of the scroll */ > - SourceOffset = VgaBase + (ScrollRegion[1] * 80) + (ScrollRegion[0] >> 3); > - DestOffset = SourceOffset + (Scroll * 80); > + ULONG Top, RowSize, i; > + PUCHAR OldPosition, NewPosition; > > /* Clear the 4 planes */ > __outpw(0x3C4, 0xF02); > @@ -296,56 +291,27 @@ > > /* Set Mode 1 */ > ReadWriteMode(1); > - > - /* Save top and check if it's above the bottom */ > - Top = ScrollRegion[1]; > - if (Top > ScrollRegion[3]) return; > + > + RowSize = (ScrollRegion[2] - ScrollRegion[0] + 1) / 8; > > /* Start loop */ > - do > - { > - /* Set number of bytes to loop and start offset */ > - Offset = ScrollRegion[0] >> 3; > - j = SourceOffset; > - > - /* Check if this is part of the scroll region */ > - if (Offset <= (ScrollRegion[2] >> 3)) > - { > - /* Update position */ > - i = DestOffset - SourceOffset; > - > - /* Loop the X axis */ > - do > - { > - /* Write value in the new position so that we can do the scroll */ > - WRITE_REGISTER_UCHAR(UlongToPtr(j), > - READ_REGISTER_UCHAR(UlongToPtr(j + i))); > - > - /* Move to the next memory location to write to */ > - j++; > - > - /* Move to the next byte in the region */ > - Offset++; > - > - /* Make sure we don't go past the scroll region */ > - } while (Offset <= (ScrollRegion[2] >> 3)); > - } > - > - /* Move to the next line */ > - SourceOffset += 80; > - DestOffset += 80; > - > - /* Increase top */ > - Top++; > - > - /* Make sure we don't go past the scroll region */ > - } while (Top <= ScrollRegion[3]); > + for(Top = ScrollRegion[1]; Top <= ScrollRegion[3]; ++Top) > + { > + /* Calculate the position in memory for the row */ > + OldPosition = (PUCHAR)VgaBase + (Top + Scroll) * 80 + ScrollRegion[0] / 8; > + NewPosition = (PUCHAR)VgaBase + Top * 80 + ScrollRegion[0] / 8; > + > + /* Scroll the row */ > + for(i = 0; i < RowSize; ++i) > + WRITE_REGISTER_UCHAR(NewPosition + i, READ_REGISTER_UCHAR(OldPosition + i)); > + } > } > > VOID > NTAPI > PreserveRow(IN ULONG CurrentTop, > - IN ULONG TopDelta) > + IN ULONG TopDelta, > + IN BOOLEAN Direction) > { > PUCHAR Position1, Position2; > ULONG Count; > @@ -359,9 +325,19 @@ > /* Set Mode 1 */ > ReadWriteMode(1); > > - /* Calculate the position in memory for the row */ > - Position1 = (PUCHAR)VgaBase + 0x9600; > - Position2 = (PUCHAR)VgaBase + CurrentTop * 80; > + /* Check which way we're preserving */ > + if (Direction) > + { > + /* Calculate the position in memory for the row */ > + Position1 = (PUCHAR)VgaBase + CurrentTop * 80; > + Position2 = (PUCHAR)VgaBase + 0x9600; > + } > + else > + { > + /* Calculate the position in memory for the row */ > + Position1 = (PUCHAR)VgaBase + 0x9600; > + Position2 = (PUCHAR)VgaBase + CurrentTop * 80; > + } > > /* Set the count and make sure it's above 0 */ > Count = TopDelta * 80; > @@ -378,33 +354,6 @@ > Position1++; > } while (--Count); > } > -} > - > -VOID > -NTAPI > -CleanCharacter(IN ULONG Left, > - IN ULONG Top, > - IN ULONG TopDelta) > -{ > - PUCHAR Position1, Position2; > - ULONG i; > - > - /* Clear the 4 planes */ > - __outpw(0x3C4, 0xF02); > - > - /* Set the bitmask to 0xFF for all 4 planes */ > - __outpw(0x3CE, 0xFF08); > - > - /* Set Mode 1 */ > - ReadWriteMode(1); > - > - /* Calculate the position in memory for the character */ > - Position1 = (PUCHAR)VgaBase + 0x9600 + Left / 8; > - Position2 = (PUCHAR)VgaBase + Top * 80 + Left / 8; > - > - /* Copy data from preserved row */ > - for(i = 0; i < TopDelta; ++i) > - WRITE_REGISTER_UCHAR(Position2 + i * 80, READ_REGISTER_UCHAR(Position1)); > } > > VOID > @@ -772,35 +721,34 @@ > } > else > { > - /* Preserve the current row */ > - PreserveRow(curr_y, TopDelta); > + /* Preserve row */ > + PreserveRow(curr_y, TopDelta, FALSE); > } > > /* Update current X */ > curr_x = ScrollRegion[0]; > + > + /* Do not clear line if "\r\n" is given */ > + CarriageReturn = FALSE; > } > else if (*String == '\r') > { > /* Update current X */ > curr_x = ScrollRegion[0]; > - } > - else if (*String == '\b') > - { > - /* Update current X */ > - if (curr_x > ScrollRegion[0]) > - curr_x -= 8; > - else > - { > - /* We are at line begin - move to previous row */ > - curr_x = ScrollRegion[0]; > - curr_y -= TopDelta; > + > + /* Check if we're being followed by a new line */ > + CarriageReturn = TRUE; > + } > + else > + { > + /* check if we had a '\r' last time */ > + if (CarriageReturn) > + { > + /* We did, clear the current row */ > + PreserveRow(curr_y, TopDelta, TRUE); > + CarriageReturn = FALSE; > } > - > - /* Clean current character */ > - CleanCharacter(curr_x, curr_y, TopDelta); > - } > - else > - { > + > /* Display this character */ > DisplayCharacter(*String, curr_x, curr_y, TextColor, 16); > curr_x += 8; > @@ -819,7 +767,7 @@ > else > { > /* Preserve the current row */ > - PreserveRow(curr_y, TopDelta); > + PreserveRow(curr_y, TopDelta, FALSE); > } > > /* Update X */ > > Modified: trunk/reactos/ntoskrnl/inbv/inbv.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/inbv/inbv.c?rev=5… > ============================================================================== > --- trunk/reactos/ntoskrnl/inbv/inbv.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/inbv/inbv.c [iso-8859-1] Tue Jun 21 19:47:13 2011 > @@ -717,11 +717,15 @@ > INIT_FUNCTION > DisplayFilter(PCHAR *String) > { > - /* Remove the filter */ > - InbvInstallDisplayStringFilter(NULL); > - > - /* Draw text screen */ > - DisplayBootBitmap(TRUE); > + /* Ignore empty and "." strings */ > + if(*String && strcmp(String, ".") != 0) > + { > + /* Remove the filter */ > + InbvInstallDisplayStringFilter(NULL); > + > + /* Draw text screen */ > + DisplayBootBitmap(TRUE); > + } > } > > VOID > > Modified: trunk/reactos/ntoskrnl/kd/kdio.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/kd/kdio.c?rev=524… > ============================================================================== > --- trunk/reactos/ntoskrnl/kd/kdio.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/kd/kdio.c [iso-8859-1] Tue Jun 21 19:47:13 2011 > @@ -28,6 +28,10 @@ > > /* Current Port in use. FIXME: Do we support more then one? */ > ULONG KdpPort; > + > +#define KdpScreenLineLenght 80 > +CHAR KdpScreenLineBuffer[KdpScreenLineLenght + 1] = ""; > +ULONG KdpScreenLineBufferPos = 0, KdpScreenLineLength = 0; > > /* DEBUG LOG FUNCTIONS *******************************************************/ > > @@ -316,8 +320,50 @@ > KdpScreenPrint(LPSTR Message, > ULONG Length) > { > - /* Call HAL */ > - HalDisplayString(Message); > + PCHAR pch = (PCHAR) Message; > + > + while (*pch) > + { > + if(*pch == '\b') > + { > + /* HalDisplayString does not support '\b'. Workaround it and use '\r' */ > + if(KdpScreenLineLength > 0) > + { > + /* Remove last character from buffer */ > + KdpScreenLineBuffer[--KdpScreenLineLength] = '\0'; > + KdpScreenLineBufferPos = KdpScreenLineLength; > + > + /* Clear row and print line again */ > + HalDisplayString("\r"); > + HalDisplayString(KdpScreenLineBuffer); > + } > + } > + else > + { > + KdpScreenLineBuffer[KdpScreenLineLength++] = *pch; > + KdpScreenLineBuffer[KdpScreenLineLength] = '\0'; > + } > + > + if(*pch == '\n' || KdpScreenLineLength == KdpScreenLineLenght) > + { > + /* Print buffered characters */ > + if(KdpScreenLineBufferPos != KdpScreenLineLength) > + HalDisplayString(KdpScreenLineBuffer + KdpScreenLineBufferPos); > + > + /* Clear line buffer */ > + KdpScreenLineBuffer[0] = '\0'; > + KdpScreenLineLength = KdpScreenLineBufferPos = 0; > + } > + > + ++pch; > + } > + > + /* Print buffered characters */ > + if(KdpScreenLineBufferPos != KdpScreenLineLength) > + { > + HalDisplayString(KdpScreenLineBuffer + KdpScreenLineBufferPos); > + KdpScreenLineBufferPos = KdpScreenLineLength; > + } > } > > VOID > > >

1 0

Re: [ros-dev] [ros-diffs] [sir_richard] 52098: [FREELDR]: Some ARM architectures do not necessarily have CS0_BASE at 0x00000000, for example, most Ti OMAP Platforms have DDR at 0x80000000. The current FreeLDR algorithms wou...
by Gabriel ilardi 21 Jun '11

21 Jun '11

Hi sir_richard and welcome back! Just to make sure you know, it seems this commit introduces a regression, ros hangs while loading ndis.sys, see testbot logs: http://build.reactos.org/builders/Windows_AMD64_1%20VBox-Test/builds/1342/s… I've filed http://www.reactos.org/bugzilla/show_bug.cgi?id=6292 Could you please take a look? Thanks. > Date: Sun, 5 Jun 2011 20:48:34 +0000 > To: ros-diffs(a)reactos.org > From: sir_richard(a)svn.reactos.org > Subject: [ros-diffs] [sir_richard] 52098: [FREELDR]: Some ARM architectures do not necessarily have CS0_BASE at 0x00000000, for example, most Ti OMAP Platforms have DDR at 0x80000000. The current FreeLDR algorithms wou... > > Author: sir_richard > Date: Sun Jun 5 20:48:34 2011 > New Revision: 52098 > > URL: http://svn.reactos.org/svn/reactos?rev=52098&view=rev > Log: > [FREELDR]: Some ARM architectures do not necessarily have CS0_BASE at 0x00000000, for example, most Ti OMAP Platforms have DDR at 0x80000000. The current FreeLDR algorithms would build FreeLDR "page entries" for every page from 0 to 0x7FFF0000 and mark it as unusable, then build the actual valid entries from 0x80000000 -> end of RAM, thus resulting in large memory consumption (and in the bloat of the PFN database later once NTOS loads) and boot time. Therefore, the algorithm is changed to start the PFN database at the lowest valid RAM page described by the Firemware descriptors, and entries therefore will be offset. This means a 128MB embedded system no longer appears to have 2048+128MB of RAM worth of PFN entries. > NOTE: Windows does not do this, opting instead to force manufacturers/use pull-up resistors/reconfigure the ARM Bus to map RAM at 0x00000000. For wider portability, I believe it makes more sense to simply do this "trick" in the boot loader. > > Modified: > trunk/reactos/boot/freeldr/freeldr/arcemul/mm.c > trunk/reactos/boot/freeldr/freeldr/mm/meminit.c >

1 1

freeldr
by Timo Kreuzer 20 Jun '11

20 Jun '11

Hi, I'd like to change the Vtbl based architecture of freeldr into a normal function call system. Currently we have stuff like #define MachHwDetect() MachVtbl.HwDetect() MachVtbl.HwDetect = PcHwDetect; This is IHO simply useless, since these functions don't change. I suggest simply renaming PcHwDetect to MachHwDetect and do that will all of those and get rid of the MachVtbl. Any objections? Regards, Timo

5 10

Re: [ros-dev] [ros-diffs] [gedmurphy] 52364: [BROWSEUI] - Set the prototypes to be long instead of LONG. This only worked in rbuild previously because WIDL incorrectly generates a LONG for long types. - define SHANDLE_PTR a...
by Colin Finck 19 Jun '11

19 Jun '11

gedmurphy(a)svn.reactos.org wrote: > +// WIDL temp hack : [...] Even though we all like to see a full MSVC build in the future, does this really justify such an even bigger hack on top of the existing ones? Would a proper fix really require that much more time? If we don't want to end up in a new mess, this pretty much forces someone to fix it in the coming days or the hack/commit will be forgotten again. I'm certain about this, because nobody on #reactos-dev really knew the reason behind the older __ROS_LONG64__ hack either. Alternatively, you could open a detailed bug report about this issue and assign some CMake people to it. But in any case, such hacks should be tracked in our Bugzilla, in particular when more information about a solution is known already. - Colin

3 4

Re: [ros-dev] [ros-diffs] [jgardou] 52365: [GDI32] - remove useless check.
by Timo Kreuzer 19 Jun '11

19 Jun '11

Am 19.06.2011 15:11, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Sun Jun 19 13:11:39 2011 > New Revision: 52365 > > URL: http://svn.reactos.org/svn/reactos?rev=52365&view=rev > Log: > [GDI32] > - remove useless check. > > > + _SEH2_TRY > + { > + RtlCopyMemory( pvSafeBits, Bits, cjBmpScanSize); > + } > + _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > + { > + Hit = TRUE; > + } > + _SEH2_END > + > + if (Hit) > + { > + // We don't die, we continue on with a allocated safe pointer to kernel > + // space..... > + DPRINT1("SetDIBitsToDevice fail to read BitMapInfo: %x or Bits: %x& Size: %d\n",pConvertedInfo,Bits,cjBmpScanSize); > + } > + DPRINT("SetDIBitsToDevice Allocate Bits %d!!!\n", cjBmpScanSize); > + } > > if (!GdiGetHandleUserData(hdc, GDI_OBJECT_TYPE_DC, (PVOID)&pDc_Attr)) > { This code looks retarded as well. Especially the comment about the "safe" pointer...

1 0

Re: [ros-dev] [ros-diffs] [jgardou] 52339: [NTOSKRNL] - don't rely on a boolean being 1 or 0, it's a bad idea (tm)
by Alex Ionescu 19 Jun '11

19 Jun '11

??? This is retarded. You're doing 0 ? 0 : 1 Best regards, Alex Ionescu On Sat, Jun 18, 2011 at 3:45 PM, <jgardou(a)svn.reactos.org> wrote: > Author: jgardou > Date: Sat Jun 18 14:45:08 2011 > New Revision: 52339 > > URL: http://svn.reactos.org/svn/reactos?rev=52339&view=rev > Log: > [NTOSKRNL] > - don't rely on a boolean being 1 or 0, it's a bad idea (tm) > > Modified: > trunk/reactos/ntoskrnl/ke/i386/traphdlr.c > > 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 Jun 18 14:45:08 2011 > @@ -1510,7 +1510,7 @@ > > /* Set thread fields */ > Thread->TrapFrame = TrapFrame; > - Thread->PreviousMode = KiUserTrap(TrapFrame); > + Thread->PreviousMode = KiUserTrap(TrapFrame) ? UserMode : KernelMode; > > /* Enable interrupts */ > _enable(); > > >

2 4

Suggestion for signed driver
by Javier Agustìn Fernàndez Arroyo 17 Jun '11

17 Jun '11

Hi folks, have you taken a look into this driver? what about signing it? http://code.google.com/p/cmediadrivers/

4 3

Re: [ros-dev] [ros-diffs] [cgutman] 52288: [FILESYSTEMS] - Handle IRP_MN_KERNEL_CALL for k
by Pierre Schweitzer 17 Jun '11

17 Jun '11

FAT & CDFS FSDs are not supposed to handle IRP_MN_KERNEL_CALL.

1 0

Re: [ros-dev] [ros-diffs] [cgutman] 52277: [NTOSKRNL] - Use the IopParseDevice hack for floppies too (needed for format and chkdsk to work)
by Alex Ionescu 16 Jun '11

16 Jun '11

You think they might try requesting valid attributes instead? :) Best regards, Alex Ionescu On Thu, Jun 16, 2011 at 9:31 AM, <cgutman(a)svn.reactos.org> wrote: > Author: cgutman > Date: Thu Jun 16 13:31:12 2011 > New Revision: 52277 > > URL: http://svn.reactos.org/svn/reactos?rev=52277&view=rev > Log: > [NTOSKRNL] > - Use the IopParseDevice hack for floppies too (needed for format and chkdsk to work) > > 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] Thu Jun 16 13:31:12 2011 > @@ -408,7 +408,8 @@ > if (!(DirectOpen) && > !(RemainingName->Length) && > !(OpenPacket->RelatedFileObject) && > - ((wcsstr(CompleteName->Buffer, L"Harddisk"))) && > + ((wcsstr(CompleteName->Buffer, L"Harddisk")) || > + (wcsstr(CompleteName->Buffer, L"Floppy"))) && > !(UseDummyFile)) > { > DPRINT1("Using IopParseDevice() hack. Requested invalid attributes: %lx\n", > > >

1 0

Removing usbdriver.sys from build
by Colin Finck 15 Jun '11

15 Jun '11

Hello all, Edijus from #reactos has just tried ReactOS on his system, but the boot process got stuck at "usbdriver.sys". When reading his notice, I was wondering why we still include this ancient driver in every ReactOS build. As far as I know ... * it has never worked for us * it is incomplete and not well-tested * it has obvious code bugs (e.g. just look in ehci.c:3465 how it enumerates more PCI devices and functions than possible, consequently enumerating the first function twice due to bitshifts) * better USB work by Johannes and Michael is progressing well Although it might be useful as a testcase for the legacy HAL functions (like HalAssignSlotResources), it should still be removed from the build process for now. If there are no objections, I'll do this change on the weekend. - Colin

2 3

freeldr
by Timo Kreuzer 15 Jun '11

15 Jun '11

Hi, While taking a short break from my GSOC work, I like to do some work on freeldr. Final goal is to make it work with MSVC, but first I'd like to do a little cleanup, since its a bit messy. First I'd like to know how the state of the old bootcode is and if we still need it and whats left to do to get rid of it. Then I'd suggest to remove the code that draws purple unicorns like it was done for ARM (afaik, we don't use it anyway) I'd also like to fix formatting (tabs -> spaces) Any remarks, objections, wishes, doubts? Regards, Timo

5 10

Re: [ros-dev] [ros-diffs] [tkreuzer] 52237: [DDK] according to WDK FsRtlRemoveBaseMcbEntry
by Pierre Schweitzer 15 Jun '11

15 Jun '11

Thanks for being that efficient for reverting. Less than two days after message on ML. Congratz. Next time I take days off, I won't take four days any longer, in case you would question some other of my patches. I'll also send you my next patches, that way you'll be able to commit them, or just to skip them to prevent any revert.

1 0

Re: [ros-dev] [ros-diffs] [rharabien] 52244: [NTOSKRNL] - Disable displaying string by bootvid after successful kernel phase 1 initialization, so there won't be graphical glitches at the top of screen if system has screen d...
by Alex Ionescu 15 Jun '11

15 Jun '11

Or another way of putting this... ""Fix" 100% correct reverse engineered NT code and break it so that it matches ReactOS's broken Video Driver Framework behaviour, instead of fixing the latter". Never gets old~ -- Best regards, Alex Ionescu On 2011-06-15, at 8:53 AM, rharabien(a)svn.reactos.org wrote: > Author: rharabien > Date: Wed Jun 15 12:53:32 2011 > New Revision: 52244 > > URL: http://svn.reactos.org/svn/reactos?rev=52244&view=rev > Log: > [NTOSKRNL] > - Disable displaying string by bootvid after successful kernel phase 1 initialization, so there won't be graphical glitches at the top of screen if system has screen debugging enabled > - Make screen black right after phase 1 initialization finish instead of waiting 5 seconds. It removes black rectangle which appeared for me in explorer. > - Initialize some global variables in inbv.c (it was done by compiler before) > > Modified: > trunk/reactos/ntoskrnl/ex/init.c > trunk/reactos/ntoskrnl/inbv/inbv.c > trunk/reactos/ntoskrnl/io/iomgr/iomgr.c > > Modified: trunk/reactos/ntoskrnl/ex/init.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ex/init.c?rev=522… > ============================================================================== > --- trunk/reactos/ntoskrnl/ex/init.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ex/init.c [iso-8859-1] Wed Jun 15 12:53:32 2011 > @@ -1313,7 +1313,7 @@ > size_t Remaining; > PRTL_USER_PROCESS_INFORMATION ProcessInfo; > KEY_VALUE_PARTIAL_INFORMATION KeyPartialInfo; > - UNICODE_STRING KeyName, DebugString; > + UNICODE_STRING KeyName; > OBJECT_ATTRIBUTES ObjectAttributes; > HANDLE KeyHandle, OptionHandle; > PRTL_USER_PROCESS_PARAMETERS ProcessParameters = NULL; > @@ -1925,18 +1925,19 @@ > /* Update progress bar */ > InbvUpdateProgressBar(100); > > - /* Allow strings to be displayed */ > - InbvEnableDisplayString(TRUE); > - > - /* Wait 5 seconds for it to initialize */ > + /* Disallow strings to be displayed */ > + InbvEnableDisplayString(FALSE); > + > + /* Clean the screen */ > + if (InbvBootDriverInstalled) FinalizeBootLogo(); > + > + /* Wait 5 seconds for initial process to initialize */ > Timeout.QuadPart = Int32x32To64(5, -10000000); > Status = ZwWaitForSingleObject(ProcessInfo->ProcessHandle, FALSE, &Timeout); > - if (InbvBootDriverInstalled) FinalizeBootLogo(); > if (Status == STATUS_SUCCESS) > { > /* Failed, display error */ > - RtlInitUnicodeString(&DebugString, L"INIT: Session Manager terminated."); > - ZwDisplayString(&DebugString); > + DPRINT1("INIT: Session Manager terminated.\n"); > > /* Bugcheck the system if SMSS couldn't initialize */ > KeBugCheck(SESSION5_INITIALIZATION_FAILED); > > Modified: trunk/reactos/ntoskrnl/inbv/inbv.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/inbv/inbv.c?rev=5… > ============================================================================== > --- trunk/reactos/ntoskrnl/inbv/inbv.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/inbv/inbv.c [iso-8859-1] Wed Jun 15 12:53:32 2011 > @@ -10,16 +10,16 @@ > KSPIN_LOCK BootDriverLock; > KIRQL InbvOldIrql; > INBV_DISPLAY_STATE InbvDisplayState; > -BOOLEAN InbvBootDriverInstalled; > -BOOLEAN InbvDisplayDebugStrings; > +BOOLEAN InbvBootDriverInstalled = FALSE; > +BOOLEAN InbvDisplayDebugStrings = FALSE; > INBV_DISPLAY_STRING_FILTER InbvDisplayFilter; > ULONG ProgressBarLeft, ProgressBarTop; > -BOOLEAN ShowProgressBar; > +BOOLEAN ShowProgressBar = FALSE; > INBV_PROGRESS_STATE InbvProgressState; > INBV_RESET_DISPLAY_PARAMETERS InbvResetDisplayParameters; > ULONG ResourceCount; > PUCHAR ResourceList[64]; > -BOOLEAN SysThreadCreated; > +BOOLEAN SysThreadCreated = FALSE; > ROT_BAR_TYPE RotBarSelection; > ULONG PltRotBarStatus; > BT_PROGRESS_INDICATOR InbvProgressIndicator = {0, 25, 0}; > > Modified: trunk/reactos/ntoskrnl/io/iomgr/iomgr.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/iomgr/iomgr.c?… > ============================================================================== > --- trunk/reactos/ntoskrnl/io/iomgr/iomgr.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/io/iomgr/iomgr.c [iso-8859-1] Wed Jun 15 12:53:32 2011 > @@ -480,10 +480,18 @@ > KeSetTimerEx(&IopTimer, ExpireTime, 1000, &IopTimerDpc); > > /* Create Object Types */ > - if (!IopCreateObjectTypes()) return FALSE; > + if (!IopCreateObjectTypes()) > + { > + DPRINT1("IopCreateObjectTypes failed!\n"); > + return FALSE; > + } > > /* Create Object Directories */ > - if (!IopCreateRootDirectories()) return FALSE; > + if (!IopCreateRootDirectories()) > + { > + DPRINT1("IopCreateRootDirectories failed!\n"); > + return FALSE; > + } > > /* Initialize PnP manager */ > IopInitializePlugPlayServices(); > @@ -511,10 +519,19 @@ > IopLoaderBlock = NULL; > > /* Create ARC names for boot devices */ > - if (!NT_SUCCESS(IopCreateArcNames(LoaderBlock))) return FALSE; > + Status = IopCreateArcNames(LoaderBlock); > + if (!NT_SUCCESS(Status)) > + { > + DPRINT1("IopCreateArcNames failed: %lx\n", Status); > + return FALSE; > + } > > /* Mark the system boot partition */ > - if (!IopMarkBootPartition(LoaderBlock)) return FALSE; > + if (!IopMarkBootPartition(LoaderBlock)) > + { > + DPRINT1("IopMarkBootPartition failed!\n"); > + return FALSE; > + } > > /* Initialize PnP root relations */ > IopEnumerateDevice(IopRootDeviceNode->PhysicalDeviceObject); > @@ -539,7 +556,11 @@ > > /* Convert SystemRoot from ARC to NT path */ > Status = IopReassignSystemRoot(LoaderBlock, &NtBootPath); > - if (!NT_SUCCESS(Status)) return FALSE; > + if (!NT_SUCCESS(Status)) > + { > + DPRINT1("IopReassignSystemRoot failed: %lx\n", Status); > + return FALSE; > + } > > /* Set the ANSI_STRING for the root path */ > RootString.MaximumLength = NtSystemRoot.MaximumLength / sizeof(WCHAR); > @@ -550,7 +571,11 @@ > > /* Convert the path into the ANSI_STRING */ > Status = RtlUnicodeStringToAnsiString(&RootString, &NtSystemRoot, FALSE); > - if (!NT_SUCCESS(Status)) return FALSE; > + if (!NT_SUCCESS(Status)) > + { > + DPRINT1("RtlUnicodeStringToAnsiString failed: %lx\n", Status); > + return FALSE; > + } > > /* Assign drive letters */ > IoAssignDriveLetters(LoaderBlock, > @@ -560,10 +585,19 @@ > > /* Update system root */ > Status = RtlAnsiStringToUnicodeString(&NtSystemRoot, &RootString, FALSE); > - if (!NT_SUCCESS(Status)) return FALSE; > + if (!NT_SUCCESS(Status)) > + { > + DPRINT1("RtlAnsiStringToUnicodeString failed: %lx\n", Status); > + return FALSE; > + } > > /* Load the System DLL and its Entrypoints */ > - if (!NT_SUCCESS(PsLocateSystemDll())) return FALSE; > + Status = PsLocateSystemDll(); > + if (!NT_SUCCESS(Status)) > + { > + DPRINT1("PsLocateSystemDll failed: %lx\n", Status); > + return FALSE; > + } > > /* Return success */ > return TRUE; > >

2 5

Ge Van Geldorp
by Ged Murphy 14 Jun '11

14 Jun '11

Hi all, I write this mail with great sadness, but I've recently been informed that Ge Van Geldorp, one of the original and important contributers to the ReactOS project has recently passed away. Having met up with him personally, I can say with some confidence that he was not only blessed with an impressive skill in the hobby / industry we all love, but was also a man of great integrity. Being one of my original mentors in reactos, and having spent time busting our guts at various linux projects with him trying to convince the unix fanatics of the merits of NT, I can assure you that this he was both a great colleague and friend. I'm sure all the old school reactos devs would more than agree. I propose we have some sort of eulogy on our homepage. I'd be more than willing to compose something. If people would like to send their thoughts, wishes or memories, I'd be more than happy to compile them. Ged.

5 4

[ros-diffs] [pschweitzer] 49851: [DDK] FsRtlRemoveBaseMcbEntry() return is VOID
by Timo Kreuzer 11 Jun '11

11 Jun '11

>Author: pschweitzer >Date: Sun Nov 28 16:43:40 2010 >New Revision: 49851 > >URL:http://svn.reactos.org/svn/reactos?rev=49851&view=rev <http://svn.reactos.org/svn/reactos?rev=49851&view=rev> >Log: >[DDK] >FsRtlRemoveBaseMcbEntry() return is VOID > >Modified: > trunk/reactos/include/ddk/ntifs.h According to WDK this is wrong. Please revert.

1 0

Re: [ros-dev] Ge Van Geldorp
by caemyr＠myopera.com 11 Jun '11

11 Jun '11

Hiya Managed to find Greg brother's letter to Wine, with bit more details regarding this tragedy. Since GvG was also our man, not only Wine's, perhaps some collaborative effort could be set to commemorate him. With best regards Caemyr -------- Original Message -------- Subject: Date: From: To: RE: Ge van Geldorp Thu, 9 Jun 2011 23:05:46 +0200 Erven Gé van Geldorp <erven.van.geldorp <at> gmail.com> 'Paul Vriens' <paul.vriens.wine <at> gmail.com> Hi all, My name is Arno van Geldorp. I’m the brother of Gé (Greg) van Geldorp. I’m very sorry that I have to inform you that Greg has passed away almost 3 weeks ago. 2 Months earlier he was diagnosed with cancer in a very aggressive form. I know he made his contribution to the Wine project. And that one of them is the WineTestBot. His passing away went so fast that he didn’t have the time to inform me all about it. What he did ask me is to make sure that the server where the WineTestBot is running on will be hosted for at least 2 more years. So we will take care of that. But I don’t know if anyone took over the administration off the server. If anyone took over the administration from Greg could you please contact me at erven.van.geldorp at gmail.com Kind regards, Arno van Geldorp

1 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 52133: [OBJ2BIN] - Add new tool obj2bin, that converts a coff object file into a raw binary file - Move pe/coff types into a common header file pecoff.h
by Alex Ionescu 09 Jun '11

09 Jun '11

Why is this needed? ie: what missing functionality of obj2dump does this tool add? I'm only asking because whenever I build ARM binaries with GCC I use obj2dump to do exactly this -- convert a PE/COFF to a raw binary for the boot-loader or firmware. So maybe I'm missing something? Best regards, Alex Ionescu On Tue, Jun 7, 2011 at 3:29 PM, <tkreuzer(a)svn.reactos.org> wrote: > Author: tkreuzer > Date: Tue Jun 7 19:29:09 2011 > New Revision: 52133 > > URL: http://svn.reactos.org/svn/reactos?rev=52133&view=rev > Log: > [OBJ2BIN] > - Add new tool obj2bin, that converts a coff object file into a raw binary file > - Move pe/coff types into a common header file pecoff.h > > Added: > trunk/reactos/tools/obj2bin/ (with props) > trunk/reactos/tools/obj2bin/CMakeLists.txt (with props) > trunk/reactos/tools/obj2bin/obj2bin.c (with props) > trunk/reactos/tools/pecoff.h (with props) > Modified: > trunk/reactos/tools/CMakeLists.txt > trunk/reactos/tools/rsym/rsym.h > > Modified: trunk/reactos/tools/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/CMakeLists.txt?rev=5… > ============================================================================== > --- trunk/reactos/tools/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/tools/CMakeLists.txt [iso-8859-1] Tue Jun 7 19:29:09 2011 > @@ -6,6 +6,7 @@ > add_subdirectory(gendib) > add_subdirectory(geninc) > add_subdirectory(mkhive) > +add_subdirectory(obj2bin) > add_subdirectory(spec2def) > add_subdirectory(unicode) > > > Propchange: trunk/reactos/tools/obj2bin/ > ------------------------------------------------------------------------------ > --- bugtraq:logregex (added) > +++ bugtraq:logregex Tue Jun 7 19:29:09 2011 > @@ -1,0 +1,2 @@ > +([Ii]ssue|[Bb]ug)s? #?(\d+)(,? ?#?(\d+))*(,? ?(and |or )?#?(\d+))? > +(\d+) > > Propchange: trunk/reactos/tools/obj2bin/ > ------------------------------------------------------------------------------ > bugtraq:message = See issue #%BUGID% for more details. > > Propchange: trunk/reactos/tools/obj2bin/ > ------------------------------------------------------------------------------ > bugtraq:url = http://www.reactos.org/bugzilla/show_bug.cgi?id=%BUGID% > > Propchange: trunk/reactos/tools/obj2bin/ > ------------------------------------------------------------------------------ > tsvn:logminsize = 10 > > Added: trunk/reactos/tools/obj2bin/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/obj2bin/CMakeLists.t… > ============================================================================== > --- trunk/reactos/tools/obj2bin/CMakeLists.txt (added) > +++ trunk/reactos/tools/obj2bin/CMakeLists.txt [iso-8859-1] Tue Jun 7 19:29:09 2011 > @@ -1,0 +1,1 @@ > +add_executable(obj2bin obj2bin.c) > > Propchange: trunk/reactos/tools/obj2bin/CMakeLists.txt > ------------------------------------------------------------------------------ > svn:eol-style = native > > Added: trunk/reactos/tools/obj2bin/obj2bin.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/obj2bin/obj2bin.c?re… > ============================================================================== > --- trunk/reactos/tools/obj2bin/obj2bin.c (added) > +++ trunk/reactos/tools/obj2bin/obj2bin.c [iso-8859-1] Tue Jun 7 19:29:09 2011 > @@ -1,0 +1,112 @@ > +#include <stdio.h> > +#include <stdlib.h> > +#include "../pecoff.h" > + > +static > +void > +Usage(void) > +{ > + printf("Converts a coff object file into a raw binary file.\n" > + "Syntax: obj2bin <source file> <dest file>\n"); > +} > + > +int main(int argc, char *argv[]) > +{ > + char *pszSourceFile; > + char *pszDestFile; > + FILE *pSourceFile, *pDestFile; > + IMAGE_FILE_HEADER FileHeader; > + IMAGE_SECTION_HEADER SectionHeader; > + unsigned int i, nSize; > + void *pData; > + > + if ((argc != 3) || (strcmp(argv[1], "--help") == 0)) Usage(); > + > + pszSourceFile = argv[1]; > + pszDestFile = argv[2]; > + > + pSourceFile = fopen(pszSourceFile, "rb"); > + if (!pSourceFile) > + { > + fprintf(stderr, "Couldn't open source file '%s'\n", pszSourceFile); > + return -1; > + } > + > + pDestFile = fopen(pszDestFile, "wb"); > + if (!pszDestFile) > + { > + fprintf(stderr, "Couldn't open dest file '%s'\n", pszDestFile); > + return -2; > + } > + > + /* Load the coff header */ > + nSize = fread(&FileHeader, 1, sizeof(FileHeader), pSourceFile); > + if (nSize != sizeof(FileHeader)) > + { > + fprintf(stderr, "Failed to read source file\n"); > + return -3; > + } > + > + /* Jump to section headers (skip optional header) */ > + if (fseek(pSourceFile, FileHeader.SizeOfOptionalHeader, SEEK_CUR)) > + { > + fprintf(stderr, "Failed to set file pointer\n"); > + return -4; > + } > + > + /* Loop all sections */ > + for (i = 0; i < FileHeader.NumberOfSections; i++) > + { > + /* Read section header */ > + nSize = fread(&SectionHeader, 1, sizeof(SectionHeader), pSourceFile); > + if (nSize != sizeof(SectionHeader)) > + { > + fprintf(stderr, "Failed to read section %ld file\n", i); > + return -5; > + } > + > + /* Check if this is '.text' section */ > + if (strcmp(SectionHeader.Name, ".text") == 0) break; > + } > + > + if (i == FileHeader.NumberOfSections) > + { > + fprintf(stderr, "No .text section found\n"); > + return -6; > + } > + > + /* Move file pointer to the start of the section*/ > + if (fseek(pSourceFile, SectionHeader.PointerToRawData, SEEK_SET)) > + { > + fprintf(stderr, "Failed to set file pointer\n"); > + return -7; > + } > + > + /* Allocate memory for the section */ > + pData = malloc(SectionHeader.SizeOfRawData); > + if (!pData) > + { > + fprintf(stderr, "Failed to allocate %ld bytes\n", SectionHeader.SizeOfRawData); > + return -8; > + } > + > + /* Read section data */ > + if (!fread(pData, SectionHeader.SizeOfRawData, 1, pSourceFile)) > + { > + fprintf(stderr, "Failed to read section %ld file\n", i); > + return -5; > + } > + > + /* Write the section to the destination file */ > + if (!fwrite(pData, SectionHeader.SizeOfRawData, 1, pDestFile)) > + { > + fprintf(stderr, "Failed to write data\n"); > + return -9; > + } > + > + fclose(pDestFile); > + fclose(pSourceFile); > + > + return 0; > +} > + > > Propchange: trunk/reactos/tools/obj2bin/obj2bin.c > ------------------------------------------------------------------------------ > svn:eol-style = native > > Added: trunk/reactos/tools/pecoff.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/pecoff.h?rev=52133&v… > ============================================================================== > --- trunk/reactos/tools/pecoff.h (added) > +++ trunk/reactos/tools/pecoff.h [iso-8859-1] Tue Jun 7 19:29:09 2011 > @@ -1,0 +1,207 @@ > +#pragma once > + > +#define IMAGE_NT_OPTIONAL_HDR32_MAGIC 0x010b > +#define IMAGE_NT_OPTIONAL_HDR64_MAGIC 0x020b > + > +#define IMAGE_DOS_MAGIC 0x5a4d > +#define IMAGE_PE_MAGIC 0x00004550 > +#define IMAGE_SIZEOF_SHORT_NAME 8 > + > +#define IMAGE_FILE_LINE_NUMS_STRIPPED 0x0004 > +#define IMAGE_FILE_LOCAL_SYMS_STRIPPED 0x0008 > +#define IMAGE_FILE_DEBUG_STRIPPED 0x0200 > + > +#define IMAGE_FILE_MACHINE_I386 0x14c > +#define IMAGE_FILE_MACHINE_AMD64 0x8664 > +#define IMAGE_FILE_MACHINE_IA64 0x0200 > + > +#define IMAGE_DIRECTORY_ENTRY_BASERELOC 5 > + > +#define IMAGE_SCN_TYPE_NOLOAD 0x00000002 > +#define IMAGE_SCN_TYPE_NO_PAD 0x00000008 > +#define IMAGE_SCN_CNT_CODE 0x00000020 > +#define IMAGE_SCN_CNT_INITIALIZED_DATA 0x00000040 > +#define IMAGE_SCN_CNT_UNINITIALIZED_DATA 0x00000080 > +#define IMAGE_SCN_LNK_OTHER 0x00000100 > +#define IMAGE_SCN_LNK_INFO 0x00000200 > +#define IMAGE_SCN_LNK_REMOVE 0x00000800 > +#define IMAGE_SCN_NO_DEFER_SPEC_EXC 0x00004000 > +#define IMAGE_SCN_GPREL 0x00008000 > +#define IMAGE_SCN_MEM_PURGEABLE 0x00020000 > +#define IMAGE_SCN_MEM_LOCKED 0x00040000 > +#define IMAGE_SCN_MEM_PRELOAD 0x00080000 > +#define IMAGE_SCN_LNK_NRELOC_OVFL 0x01000000 > +#define IMAGE_SCN_MEM_DISCARDABLE 0x02000000 > +#define IMAGE_SCN_MEM_NOT_CACHED 0x04000000 > +#define IMAGE_SCN_MEM_NOT_PAGED 0x08000000 > +#define IMAGE_SCN_MEM_SHARED 0x10000000 > +#define IMAGE_SCN_MEM_EXECUTE 0x20000000 > +#define IMAGE_SCN_MEM_READ 0x40000000 > +#define IMAGE_SCN_MEM_WRITE 0x80000000 > + > +#define IMAGE_NUMBEROF_DIRECTORY_ENTRIES 16 > + > +typedef unsigned char BYTE; > +typedef unsigned char UCHAR; > +typedef unsigned short WORD; > +typedef unsigned short USHORT; > +typedef unsigned long long ULONGLONG; > +#if defined(__x86_64__) && !defined(_WIN64) > +typedef signed int LONG; > +typedef unsigned int ULONG; > +typedef unsigned int DWORD; > +#else > +typedef signed long LONG; > +typedef unsigned long ULONG; > +typedef unsigned long DWORD; > +#endif > +#if defined(_WIN64) > +typedef unsigned __int64 ULONG_PTR; > +#else > +#if defined(__x86_64__) && !defined(_WIN64) > +typedef unsigned int ULONG_PTR; > +#else > +typedef unsigned long ULONG_PTR; > +#endif > +#endif > + > +#pragma pack(push,2) > +typedef struct _IMAGE_DOS_HEADER { > + WORD e_magic; > + WORD e_cblp; > + WORD e_cp; > + WORD e_crlc; > + WORD e_cparhdr; > + WORD e_minalloc; > + WORD e_maxalloc; > + WORD e_ss; > + WORD e_sp; > + WORD e_csum; > + WORD e_ip; > + WORD e_cs; > + WORD e_lfarlc; > + WORD e_ovno; > + WORD e_res[4]; > + WORD e_oemid; > + WORD e_oeminfo; > + WORD e_res2[10]; > + LONG e_lfanew; > +} IMAGE_DOS_HEADER,*PIMAGE_DOS_HEADER; > +#pragma pack(pop) > + > +#pragma pack(push,4) > +typedef struct _IMAGE_FILE_HEADER { > + WORD Machine; > + WORD NumberOfSections; > + DWORD TimeDateStamp; > + DWORD PointerToSymbolTable; > + DWORD NumberOfSymbols; > + WORD SizeOfOptionalHeader; > + WORD Characteristics; > +} IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER; > +#pragma pack(pop) > + > +typedef struct _IMAGE_DATA_DIRECTORY { > + DWORD VirtualAddress; > + DWORD Size; > +} IMAGE_DATA_DIRECTORY,*PIMAGE_DATA_DIRECTORY; > + > +typedef struct _IMAGE_OPTIONAL_HEADER32 { > + WORD Magic; > + BYTE MajorLinkerVersion; > + BYTE MinorLinkerVersion; > + DWORD SizeOfCode; > + DWORD SizeOfInitializedData; > + DWORD SizeOfUninitializedData; > + DWORD AddressOfEntryPoint; > + DWORD BaseOfCode; > + DWORD BaseOfData; > + DWORD ImageBase; > + DWORD SectionAlignment; > + DWORD FileAlignment; > + WORD MajorOperatingSystemVersion; > + WORD MinorOperatingSystemVersion; > + WORD MajorImageVersion; > + WORD MinorImageVersion; > + WORD MajorSubsystemVersion; > + WORD MinorSubsystemVersion; > + DWORD Win32VersionValue; > + DWORD SizeOfImage; > + DWORD SizeOfHeaders; > + DWORD CheckSum; > + WORD Subsystem; > + WORD DllCharacteristics; > + DWORD SizeOfStackReserve; > + DWORD SizeOfStackCommit; > + DWORD SizeOfHeapReserve; > + DWORD SizeOfHeapCommit; > + DWORD LoaderFlags; > + DWORD NumberOfRvaAndSizes; > + IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES]; > +} IMAGE_OPTIONAL_HEADER32,*PIMAGE_OPTIONAL_HEADER32; > + > +typedef struct _IMAGE_OPTIONAL_HEADER64 { > + WORD Magic; > + BYTE MajorLinkerVersion; > + BYTE MinorLinkerVersion; > + DWORD SizeOfCode; > + DWORD SizeOfInitializedData; > + DWORD SizeOfUninitializedData; > + DWORD AddressOfEntryPoint; > + DWORD BaseOfCode; > + ULONGLONG ImageBase; > + DWORD SectionAlignment; > + DWORD FileAlignment; > + WORD MajorOperatingSystemVersion; > + WORD MinorOperatingSystemVersion; > + WORD MajorImageVersion; > + WORD MinorImageVersion; > + WORD MajorSubsystemVersion; > + WORD MinorSubsystemVersion; > + DWORD Win32VersionValue; > + DWORD SizeOfImage; > + DWORD SizeOfHeaders; > + DWORD CheckSum; > + WORD Subsystem; > + WORD DllCharacteristics; > + ULONGLONG SizeOfStackReserve; > + ULONGLONG SizeOfStackCommit; > + ULONGLONG SizeOfHeapReserve; > + ULONGLONG SizeOfHeapCommit; > + DWORD LoaderFlags; > + DWORD NumberOfRvaAndSizes; > + IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES]; > +} IMAGE_OPTIONAL_HEADER64,*PIMAGE_OPTIONAL_HEADER64; > + > +#ifdef _TARGET_PE64 > +typedef IMAGE_OPTIONAL_HEADER64 IMAGE_OPTIONAL_HEADER; > +typedef PIMAGE_OPTIONAL_HEADER64 PIMAGE_OPTIONAL_HEADER; > +#else > +typedef IMAGE_OPTIONAL_HEADER32 IMAGE_OPTIONAL_HEADER; > +typedef PIMAGE_OPTIONAL_HEADER32 PIMAGE_OPTIONAL_HEADER; > +#endif > + > +typedef struct _IMAGE_SECTION_HEADER { > + BYTE Name[IMAGE_SIZEOF_SHORT_NAME]; > + union { > + DWORD PhysicalAddress; > + DWORD VirtualSize; > + } Misc; > + DWORD VirtualAddress; > + DWORD SizeOfRawData; > + DWORD PointerToRawData; > + DWORD PointerToRelocations; > + DWORD PointerToLinenumbers; > + WORD NumberOfRelocations; > + WORD NumberOfLinenumbers; > + DWORD Characteristics; > +} IMAGE_SECTION_HEADER,*PIMAGE_SECTION_HEADER; > + > +#pragma pack(push,4) > +typedef struct _IMAGE_BASE_RELOCATION { > + DWORD VirtualAddress; > + DWORD SizeOfBlock; > + WORD TypeOffset[1]; > +} IMAGE_BASE_RELOCATION,*PIMAGE_BASE_RELOCATION; > +#pragma pack(pop) > + > > Propchange: trunk/reactos/tools/pecoff.h > ------------------------------------------------------------------------------ > svn:eol-style = native > > Modified: trunk/reactos/tools/rsym/rsym.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/rsym/rsym.h?rev=5213… > ============================================================================== > --- trunk/reactos/tools/rsym/rsym.h [iso-8859-1] (original) > +++ trunk/reactos/tools/rsym/rsym.h [iso-8859-1] Tue Jun 7 19:29:09 2011 > @@ -1,209 +1,7 @@ > /* rsym.h */ > > #pragma once > - > -#define IMAGE_NT_OPTIONAL_HDR32_MAGIC 0x010b > -#define IMAGE_NT_OPTIONAL_HDR64_MAGIC 0x020b > - > -#define IMAGE_DOS_MAGIC 0x5a4d > -#define IMAGE_PE_MAGIC 0x00004550 > -#define IMAGE_SIZEOF_SHORT_NAME 8 > - > -#define IMAGE_FILE_LINE_NUMS_STRIPPED 0x0004 > -#define IMAGE_FILE_LOCAL_SYMS_STRIPPED 0x0008 > -#define IMAGE_FILE_DEBUG_STRIPPED 0x0200 > - > -#define IMAGE_DIRECTORY_ENTRY_BASERELOC 5 > - > -#define IMAGE_SCN_TYPE_NOLOAD 0x00000002 > -#define IMAGE_SCN_TYPE_NO_PAD 0x00000008 > -#define IMAGE_SCN_CNT_CODE 0x00000020 > -#define IMAGE_SCN_CNT_INITIALIZED_DATA 0x00000040 > -#define IMAGE_SCN_CNT_UNINITIALIZED_DATA 0x00000080 > -#define IMAGE_SCN_LNK_OTHER 0x00000100 > -#define IMAGE_SCN_LNK_INFO 0x00000200 > -#define IMAGE_SCN_LNK_REMOVE 0x00000800 > -#define IMAGE_SCN_NO_DEFER_SPEC_EXC 0x00004000 > -#define IMAGE_SCN_GPREL 0x00008000 > -#define IMAGE_SCN_MEM_PURGEABLE 0x00020000 > -#define IMAGE_SCN_MEM_LOCKED 0x00040000 > -#define IMAGE_SCN_MEM_PRELOAD 0x00080000 > -#define IMAGE_SCN_LNK_NRELOC_OVFL 0x01000000 > -#define IMAGE_SCN_MEM_DISCARDABLE 0x02000000 > -#define IMAGE_SCN_MEM_NOT_CACHED 0x04000000 > -#define IMAGE_SCN_MEM_NOT_PAGED 0x08000000 > -#define IMAGE_SCN_MEM_SHARED 0x10000000 > -#define IMAGE_SCN_MEM_EXECUTE 0x20000000 > -#define IMAGE_SCN_MEM_READ 0x40000000 > -#define IMAGE_SCN_MEM_WRITE 0x80000000 > - > -#define IMAGE_NUMBEROF_DIRECTORY_ENTRIES 16 > - > -typedef unsigned char BYTE; > -typedef unsigned char UCHAR; > -typedef unsigned short WORD; > -typedef unsigned short USHORT; > -typedef unsigned long long ULONGLONG; > -#if defined(__x86_64__) && !defined(_WIN64) > -typedef signed int LONG; > -typedef unsigned int ULONG; > -typedef unsigned int DWORD; > -#else > -typedef signed long LONG; > -typedef unsigned long ULONG; > -typedef unsigned long DWORD; > -#endif > -#if defined(_WIN64) > -typedef unsigned __int64 ULONG_PTR; > -#else > -#if defined(__x86_64__) && !defined(_WIN64) > -typedef unsigned int ULONG_PTR; > -#else > -typedef unsigned long ULONG_PTR; > -#endif > -#endif > - > -#pragma pack(push,2) > - > -typedef struct _IMAGE_DOS_HEADER { > - WORD e_magic; > - WORD e_cblp; > - WORD e_cp; > - WORD e_crlc; > - WORD e_cparhdr; > - WORD e_minalloc; > - WORD e_maxalloc; > - WORD e_ss; > - WORD e_sp; > - WORD e_csum; > - WORD e_ip; > - WORD e_cs; > - WORD e_lfarlc; > - WORD e_ovno; > - WORD e_res[4]; > - WORD e_oemid; > - WORD e_oeminfo; > - WORD e_res2[10]; > - LONG e_lfanew; > -} IMAGE_DOS_HEADER,*PIMAGE_DOS_HEADER; > -#pragma pack(pop) > - > -#pragma pack(push,4) > -typedef struct _IMAGE_FILE_HEADER { > - WORD Machine; > - WORD NumberOfSections; > - DWORD TimeDateStamp; > - DWORD PointerToSymbolTable; > - DWORD NumberOfSymbols; > - WORD SizeOfOptionalHeader; > - WORD Characteristics; > -} IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER; > -#pragma pack(pop) > - > -typedef struct _IMAGE_DATA_DIRECTORY { > - DWORD VirtualAddress; > - DWORD Size; > -} IMAGE_DATA_DIRECTORY,*PIMAGE_DATA_DIRECTORY; > - > -typedef struct _IMAGE_OPTIONAL_HEADER32 { > - WORD Magic; > - BYTE MajorLinkerVersion; > - BYTE MinorLinkerVersion; > - DWORD SizeOfCode; > - DWORD SizeOfInitializedData; > - DWORD SizeOfUninitializedData; > - DWORD AddressOfEntryPoint; > - DWORD BaseOfCode; > - DWORD BaseOfData; > - DWORD ImageBase; > - DWORD SectionAlignment; > - DWORD FileAlignment; > - WORD MajorOperatingSystemVersion; > - WORD MinorOperatingSystemVersion; > - WORD MajorImageVersion; > - WORD MinorImageVersion; > - WORD MajorSubsystemVersion; > - WORD MinorSubsystemVersion; > - DWORD Win32VersionValue; > - DWORD SizeOfImage; > - DWORD SizeOfHeaders; > - DWORD CheckSum; > - WORD Subsystem; > - WORD DllCharacteristics; > - DWORD SizeOfStackReserve; > - DWORD SizeOfStackCommit; > - DWORD SizeOfHeapReserve; > - DWORD SizeOfHeapCommit; > - DWORD LoaderFlags; > - DWORD NumberOfRvaAndSizes; > - IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES]; > -} IMAGE_OPTIONAL_HEADER32,*PIMAGE_OPTIONAL_HEADER32; > - > -typedef struct _IMAGE_OPTIONAL_HEADER64 { > - WORD Magic; > - BYTE MajorLinkerVersion; > - BYTE MinorLinkerVersion; > - DWORD SizeOfCode; > - DWORD SizeOfInitializedData; > - DWORD SizeOfUninitializedData; > - DWORD AddressOfEntryPoint; > - DWORD BaseOfCode; > - ULONGLONG ImageBase; > - DWORD SectionAlignment; > - DWORD FileAlignment; > - WORD MajorOperatingSystemVersion; > - WORD MinorOperatingSystemVersion; > - WORD MajorImageVersion; > - WORD MinorImageVersion; > - WORD MajorSubsystemVersion; > - WORD MinorSubsystemVersion; > - DWORD Win32VersionValue; > - DWORD SizeOfImage; > - DWORD SizeOfHeaders; > - DWORD CheckSum; > - WORD Subsystem; > - WORD DllCharacteristics; > - ULONGLONG SizeOfStackReserve; > - ULONGLONG SizeOfStackCommit; > - ULONGLONG SizeOfHeapReserve; > - ULONGLONG SizeOfHeapCommit; > - DWORD LoaderFlags; > - DWORD NumberOfRvaAndSizes; > - IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES]; > -} IMAGE_OPTIONAL_HEADER64,*PIMAGE_OPTIONAL_HEADER64; > - > - > -#ifdef _TARGET_PE64 > -typedef IMAGE_OPTIONAL_HEADER64 IMAGE_OPTIONAL_HEADER; > -typedef PIMAGE_OPTIONAL_HEADER64 PIMAGE_OPTIONAL_HEADER; > -#else > -typedef IMAGE_OPTIONAL_HEADER32 IMAGE_OPTIONAL_HEADER; > -typedef PIMAGE_OPTIONAL_HEADER32 PIMAGE_OPTIONAL_HEADER; > -#endif > - > -typedef struct _IMAGE_SECTION_HEADER { > - BYTE Name[IMAGE_SIZEOF_SHORT_NAME]; > - union { > - DWORD PhysicalAddress; > - DWORD VirtualSize; > - } Misc; > - DWORD VirtualAddress; > - DWORD SizeOfRawData; > - DWORD PointerToRawData; > - DWORD PointerToRelocations; > - DWORD PointerToLinenumbers; > - WORD NumberOfRelocations; > - WORD NumberOfLinenumbers; > - DWORD Characteristics; > -} IMAGE_SECTION_HEADER,*PIMAGE_SECTION_HEADER; > - > -#pragma pack(push,4) > -typedef struct _IMAGE_BASE_RELOCATION { > - DWORD VirtualAddress; > - DWORD SizeOfBlock; > - WORD TypeOffset[1]; > -} IMAGE_BASE_RELOCATION,*PIMAGE_BASE_RELOCATION; > -#pragma pack(pop) > +#include "../pecoff.h" > > typedef struct { > USHORT f_magic; /* magic number */ > > >

3 6

Re: [ros-dev] [ros-diffs] [tkreuzer] 52156: [BOOTSECTOR] - export obj2bin on gcc builds, too - Add new macro CreateBootSectorTarget2, which uses portable assembly and use it with isoboot.S. I will replace all bootsectors wi...
by Timo Kreuzer 09 Jun '11

09 Jun '11

Am 09.06.2011 15:56, schrieb tkreuzer(a)svn.reactos.org: > Author: tkreuzer > Date: Thu Jun 9 13:56:44 2011 > New Revision: 52156 > > URL: http://svn.reactos.org/svn/reactos?rev=52156&view=rev > Log: > [BOOTSECTOR] > - export obj2bin on gcc builds, too > - Add new macro CreateBootSectorTarget2, which uses portable assembly and use it with isoboot.S. I will replace all bootsectors with the new code one at a time, and in the end we can eventually drop nmake > - add wrapper isobtrt.S, which defines ROS_REGTEST and includes isoboot.S > I mean of course "drop nasm" not "drop nmake"

1 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 52065: [NTOSKRNL] - renamed Io volumes global to match Windows names (in case of debug) - renamed IopDereferenceVpb() to IopDereferenceVpbAndFree(), IopReferenceVpbForVerify() to IopR...
by Alex Ionescu 07 Jun '11

07 Jun '11

The notification routine can change the list, as there is no lock involved. Therefore, you should grab the next entry before notifying the driver, to maintain a consistent list state. -- Best regards, Alex Ionescu On 2011-06-02, at 1:43 PM, pschweitzer(a)svn.reactos.org wrote: > + DriverNotificationRoutine(DeviceObject, TRUE); > + > + /* Go to the next entry */ > + ListEntry = ListEntry->Flink;

4 15

Re: [ros-dev] [ros-diffs] [cgutman] 52125: [AFD] - Fix IoModifyAccess vs IoReadAccess confusion
by Timo Kreuzer 07 Jun '11

07 Jun '11

I can't get the logic behind this change. Can you explain? Am 07.06.2011 00:55, schrieb cgutman(a)svn.reactos.org: > Author: cgutman > Date: Mon Jun 6 22:55:17 2011 > New Revision: 52125 > > URL: http://svn.reactos.org/svn/reactos?rev=52125&view=rev > Log: > [AFD] > - Fix IoModifyAccess vs IoReadAccess confusion > > Modified: > trunk/reactos/drivers/network/afd/afd/lock.c > > Modified: trunk/reactos/drivers/network/afd/afd/lock.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/network/afd/afd/lo… > ============================================================================== > --- trunk/reactos/drivers/network/afd/afd/lock.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/network/afd/afd/lock.c [iso-8859-1] Mon Jun 6 22:55:17 2011 > @@ -123,7 +123,7 @@ > AFD_DbgPrint(MID_TRACE,("Probe and lock pages\n")); > _SEH2_TRY { > MmProbeAndLockPages( MapBuf[i].Mdl, KernelMode, > - Write ? IoModifyAccess : IoReadAccess ); > + Write ? IoReadAccess : IoModifyAccess ); > } _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) { > LockFailed = TRUE; > } _SEH2_END; > > >

2 1

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