You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
(11) |
|
2
(5) |
3
(11) |
4
(13) |
5
(1) |
6
(15) |
7
(1) |
8
(1) |
|
9
(2) |
10
(4) |
11
(15) |
12
(2) |
13
(12) |
14
(2) |
15
(3) |
|
16
(1) |
17
(16) |
18
(1) |
19
(32) |
20
(19) |
21
(3) |
22
|
|
23
|
24
(4) |
25
|
26
(1) |
27
(19) |
28
(4) |
29
(2) |
|
30
(3) |
|
|
|
|
|
|
|
From: Nicholas N. <nj...@ca...> - 2003-11-29 12:10:41
|
On Fri, 28 Nov 2003, KJK::Hyperion wrote: > I subscribed this mailing list precisely to ask about a Windows port, but > gave up temporarily when I read on the website about Valgrind's non > existent support for multi-threaded processes > Assuming this isn't true anymore, Valgrind has supported multi-threaded processes for over a year now, maybe even 18 months. IIRC, it has supported multi-threaded processes for much longer than the mailing lists have been in existence. > I have a question for you: how does (or does) Valgrind cope with > modifications on the current process performed by other processes? Not well; there's very, very limited support. > on Windows any process can modify any other process, given sufficient > access to the target process object and related thread objects, and such > modifications include allocating pages virtual memory, mapping pages of > shared memory, writing ranges of memory, duplicating object handles, > even altering the threads' contexts and LDTs. Urgh... that sounds awful, like it would interact really badly with the way Valgrind works. > This is the only real difficulty on Windows Er, I think that might be understating things a bit. For example, I imagine it would be much easier to port to a *nix OS than to Windows. > Windows received a lot of attention from many skilled people, and Microsoft > has let a lot of information to leak, over time. As an effect, we currently > know a whole lot about its internals, including system calls (nearly all of > them are officially undocumented), internal kernel features, routines and > structures, and even the build environment used at the Microsoft labs. > ReactOS (<http://www.reactos.com/>) is probably the greatest result > achieved through this knowledge: it's an open source operating system > aiming at (and slowly reaching) 100% binary compatibility with Windows. So > this is not going to be the problem with Windows I had a look at that site. AFAICT, they started in 1997, and can now run a few programs on NT 4.0. Sure, it is possible to find out about Windows internals, but a port to an open-source OS would be *much* easier. N |
|
From: KJK::Hyperion <no...@li...> - 2003-11-29 01:02:16
|
At 10.19 27/11/2003, Nicholas Nethercote wrote: Apropos of this: >A Solaris port has been requested almost as frequently as a Windows port. I subscribed this mailing list precisely to ask about a Windows port, but gave up temporarily when I read on the website about Valgrind's non existent support for multi-threaded processes Assuming this isn't true anymore, I have a question for you: how does (or does) Valgrind cope with modifications on the current process performed by other processes? on Windows any process can modify any other process, given sufficient access to the target process object and related thread objects, and such modifications include allocating pages virtual memory, mapping pages of shared memory, writing ranges of memory, duplicating object handles, even altering the threads' contexts and LDTs. Such kind of interactions is a widely used form of inter-process communication (especially the exchange of object handles, which can also overwrite small areas of memory), and it makes the job of programs like Valgrind much harder without explicit support from the kernel. Also consider that kernel-mode code is free to write to any memory location, and some drivers may even create permanent kernel-mode threads in any process, so all of Valgrind's fancy memory checking and tracking can be quite pointless in several cases This is the only real difficulty on Windows, as system calls don't require to be run on any specific stack (in fact, the Win32 ExitThread function switches to a fixed stack allocated in the per-thread data segment before freeing the thread's real stack), all kernel-user transitions happen at well-known entry points (and this makes for easy hooking of exceptions, callbacks and APCs) and an APC (roughly equivalent to a signal), handled by a well-known function, is posted to every thread as soon as it's created, so hooking process and thread creation, and even running before any kind of initialization code, is a piece of cake >But a port would be difficult to a non-open source OS, because Valgrind >does lots of low-level OS stuff. Windows received a lot of attention from many skilled people, and Microsoft has let a lot of information to leak, over time. As an effect, we currently know a whole lot about its internals, including system calls (nearly all of them are officially undocumented), internal kernel features, routines and structures, and even the build environment used at the Microsoft labs. ReactOS (<http://www.reactos.com/>) is probably the greatest result achieved through this knowledge: it's an open source operating system aiming at (and slowly reaching) 100% binary compatibility with Windows. So this is not going to be the problem with Windows |