- Ros-dev - ReactOS.org

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev