I think if it's a generic buffer-allocating function, its callers
should not rely on the memory being zeroed. (like they don't rely on
pool and heap allocations, unless called with zero-heap flag).
At least the comments to the function does not say "it returns a
zeroed buffer".
WBR,
Aleksey.
On Sep 20, 2008, at 4:31 AM, cgutman(a)svn.reactos.org wrote:
> Author: cgutman
> Date: Fri Sep 19 19:31:02 2008
> New Revision: 36337
>
> URL: http://svn.reactos.org/svn/reactos?rev=36337&view=rev
> Log:
> - Zero the memory after we allocate it
>
> Modified:
> branches/aicom-network-fixes/drivers/network/tcpip/tcpip/pool.c
Our LoadIcon is broken and can result in badly drawn / ugly icons.
You should use LoadImage instead.
LoadIcon is deprecated anyway, no one should be using it anymore.
Ged.
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of janderwald(a)svn.reactos.org
Sent: 17 September 2008 22:59
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [janderwald] 36295: - Update Status Icon when there is activity - Also update the Taskbar Notification Icon
+ hIcon = NULL;
+ if (pContext->dwInOctets == IfEntry.dwInOctets && pContext->dwOutOctets == IfEntry.dwOutOctets && pContext->Status != 0)
+ {
+ hIcon = LoadIcon(netshell_hInstance, MAKEINTRESOURCE(IDI_NET_IDLE));
+ pContext->Status = 0;
+ }
+ else if (pContext->dwInOctets != IfEntry.dwInOctets && pContext->dwOutOctets !=
In my recent endeavors into porting ReactOS to the amd64 architecture I have
discovered that the the x86_64-pc-mingw32 target uses DWARF debugging
symbols by default.
The reason for this change was very simple, stabs are strictly 32bit. A
stabs record only has 32 bits to represent an address, it represents less
information, was never properly standardized, so gdb is pretty much the only
debugger which can handle gcc stabs in their full glory, and it is larger to
boot. DWARF is better in every aspect. There is no reason to use stabs these
days.
encoded • does i386-mingw32 support DWARF2 ?
NightStrike • the plan is that gcc4.3 will
NightStrike • more specifically, it will also drop support for sjlj
Dwarf 2 Unwind frames for mingw32/cygwin
patch<http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00133.html>
mingw32-gcc4.3 packages are so patched afaics:
http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=241304
Right now ReactOS has a tool called rsym that parses stabs and coff symbol
data.
arty • rsym was made to keep compact line number info
Ask yourself:
Could we eliminate an entire build step that is imposed on all ros binaries?
How hard would it be to teach the kernel about DWARF? (If we really wanted
to)
sedwards • wine dbghelp supports pdb too
sedwards • CV, PDB, Stabs and Dwarf
sedwards • as far as I know
Reading Material:
http://dwarfstd.org/dwarf-2.0.0.pdfhttp://dwarfstd.org/Dwarf3.pdf
All these recent umode network commits need to be reverted. Public definitions don't belong in a private header.
As I said in my original commit " It won't build yet as it will rely on a rewrite of the network headers".
When the header rewrites are committed (maybe a week from now) everything will build. It's at this point that people can get involved in getting the new umode architecture working in ros.
Cheers,
Ged.
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of cgutman(a)svn.reactos.org
Sent: 17 September 2008 04:07
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [cgutman] 36275: - Add ADDRINFOW
Author: cgutman
Date: Tue Sep 16 22:07:15 2008
New Revision: 36275
URL: http://svn.reactos.org/svn/reactos?rev=36275&view=rev
Log:
- Add ADDRINFOW
Modified:
branches/umode-network-branch/dll/win32/ws2_32/inc/ws2_32p.h
Modified: branches/umode-network-branch/dll/win32/ws2_32/inc/ws2_32p.h
URL: http://svn.reactos.org/svn/reactos/branches/umode-network-branch/dll/win32/…
==============================================================================
--- branches/umode-network-branch/dll/win32/ws2_32/inc/ws2_32p.h [iso-8859-1] (original)
+++ branches/umode-network-branch/dll/win32/ws2_32/inc/ws2_32p.h [iso-8859-1] Tue Sep 16 22:07:15 2008
@@ -21,6 +21,18 @@
WsAsyncGetServByPort,
WsAsyncTerminate,
} WSASYNCOPS;
+
+typedef struct _ADDRINFOW
+{
+ INT ai_flags;
+ INT ai_family;
+ INT ai_socktype;
+ INT ai_protocol;
+ SIZE_T ai_addrlen;
+ PWSTR ai_canonname;
+ struct SOCKADDR *ai_addr;
+ struct ADDRINFOW *ai_next;
+} ADDRINFOW, *PADDRINFOW;
typedef struct _WSASYNCBLOCK
{
I would prefer to have a log message saying what was NOT synced too.
On Sep 13, 2008, at 7:52 PM, cwittich(a)svn.reactos.org wrote:
> Author: cwittich
> Date: Sat Sep 13 10:52:50 2008
> New Revision: 36188
>
> URL: http://svn.reactos.org/svn/reactos?rev=36188&view=rev
> Log:
> sync most of rpcrt4 to wine 1.1.4
Hi,
the change done in r36137 on cdfs/fsctl.c appears to me to be wrong. For CDFS, IoCreateDevice should have its 4th parameter set to FILE_DEVICE_CD_ROM_FILE_SYSTEM and not to FILE_DEVICE_DISK_FILE_SYSTEM. For fastfat driver, it's OK.
WBR,
P. Schweitzer
_________________________________________________________________
Installez gratuitement les 20 émôticones Windows Live Messenger les plus fous ! Cliquez ici !
http://www.emoticones-messenger.fr/
On Mon, Sep 8, 2008 at 9:48 AM, <dchapyshev(a)svn.reactos.org> wrote:
> Author: dchapyshev
> Date: Mon Sep 8 08:48:25 2008
> New Revision: 36054
>
> URL: http://svn.reactos.org/svn/reactos?rev=36054&view=rev
> Log:
> - Import pstorec from wine head
Here is a patch from the CrossOver wine that are not in the Winehq
tree. Feel free to fork for a while as no one in winehq has touched
this dll for a while.
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
On Sat, Sep 6, 2008 at 5:02 PM, <sginsberg(a)svn.reactos.org> wrote:
> - Make sure we get a Subkey in RegDeleteKeyA/W. Fixes Winetests causing a system crash, but (for now) hides a bug in CM.
Maybe we should throw a DPRINT1 here so we are reminded that the bug
is still there.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Greetings,
I would like to formerly invite the ReactOS community to participate at
the Southern California Linux Expo. The show will be taking place
February 20th - 22nd, 2009 at the Westin LAX in Los Angeles, CA. I am
including both a link to our "Call For dotORG Exhibitors" as well as our
"Call for Papers" if anyone from the ReactOS community is interested in
submitting a talk for consideration.
More information about the show can be found at
http://www.socallinuxexpo.org
Thanks!
Gareth
http://scale7x.socallinuxexpo.org/s7x_cfphttp://scale7x.socallinuxexpo.org/s7x_call_for_dotOrg_exhibitors
--
Gareth J. Greenaway <g(a)socallinuxexpo.org>
Voice - 877-831-2569 x130
Southern California Linux Expo
http://www.socallinuxexpo.org
On Sun, Aug 31, 2008 at 2:07 PM, <janderwald(a)svn.reactos.org> wrote:
> #define REACTOS_STR_ORIGINAL_FILENAME "netshell.dll\0"
> #define REACTOS_STR_PRODUCT_VERSION "5.1.2600.3264\0"
> #define REACTOS_STR_FILE_VERSION "5.1.2600.3264\0"
> +#define REACTOS_STR_COMPANY_NAME "Microsoft Corporation"
Is there an application that actually depends on the string "Microsoft
Corporation" here? If not then you need to remove it otherwise someone
will think your ripping Microsoft's code.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
ntoskrnl/io/iomgr/file.c: In function 'IopCloseFile':
ntoskrnl/io/iomgr/file.c:1407: error: expected expression before '<<' token
ntoskrnl/io/iomgr/file.c:1410: error: expected expression before '==' token
ntoskrnl/io/iomgr/file.c:1413: error: expected expression before '>>' token
mingw32-make: *** [obj-i386/ntoskrnl/io/iomgr/file_ntoskrnl.o] Error 1
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
But, this was reported to me as working: abiword & firefox install,
vmwinst (which exposes vectored handler test) works.
I experienced triple fault on a clean build too, so it's not a random
problem.
How so? People demand explanations about testing techniques Stefan uses.
WBR,
Aleksey Bragin.
On Sep 1, 2008, at 1:58 AM, pschweitzer(a)svn.reactos.org wrote:
> Author: pschweitzer
> Date: Sun Aug 31 16:58:44 2008
> New Revision: 35846
>
> URL: http://svn.reactos.org/svn/reactos?rev=35846&view=rev
> Log:
> Reverted r35812 because of unwanted triple fault bug.
> See issue #3704,3706 for more details.
>
> Modified:
> trunk/reactos/dll/ntdll/dispatch/ (props changed)
> trunk/reactos/dll/ntdll/dispatch/dispatch.c
> trunk/reactos/dll/ntdll/dispatch/i386/dispatch.S
> trunk/reactos/lib/rtl/i386/except.c
> trunk/reactos/lib/rtl/rtlp.h
> trunk/reactos/lib/rtl/vectoreh.c
>
err, sorry. that should be ntddk.h and not winddk.h ;0)
>"Umtypes is only included for user-mode, not for drivers."
>
>ketypes.h imports umtypes.h --
>
>#include <umtypes.h>
>#ifndef NTOS_MODE_USER
>#include <haltypes.h>
>#include <potypes.h>
>#include <ifssupp.h>
>#endif
>
>"Drivers do not import winnt.h"
>they (still) do in ros as winddk.h imports winnt.h...
_________________________________________________________________
Explore the seven wonders of the world
http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE
Umtypes is only included for user-mode, not for drivers.
My e-mail was about drivers.
Drivers do not import winnt.h
Drivers import ntifs, wdm and ntddk.
Ntifs, wdm and ntddk are the headers that drivers import.
Not winnt.h.
My e-mail specifically listed those three headers and talked about drivers.
You guys come back saying "it's in winnt.h so it's okay!"
Are you blind, illiterate, or what?
Best regards,
Alex Ionescu
On Sun, Aug 31, 2008 at 10:35 PM, Alex Ionescu <aionescu(a)gmail.com> wrote:
> Umtypes is only included for user-mode, not for drivers.
>
> My e-mail was about drivers.
>
> Drivers do not import winnt.h
>
> Drivers import ntifs, wdm and ntddk.
>
> Ntifs, wdm and ntddk are the headers that drivers import.
>
> Not winnt.h.
>
> My e-mail specifically listed those three headers and talked about drivers.
>
> You guys come back saying "it's in winnt.h so it's okay!"
>
> Are you blind, illiterate, or what?
>
> Best regards,
> Alex Ionescu
>
>
>
> 2008/8/31 Stefan Ginsberg <stefan__100__(a)hotmail.com>:
>> The NDK includes winnt.h through umtypes.h -> windef.h -> winnt.h (MS PSDK's
>> windef.h includes winnt.h too, so I assumed this was correct).
>> If this is wrong then how should it be done?
>>
>>> Date: Sun, 31 Aug 2008 01:00:18 +0200
>>> From: ionucu(a)videotron.ca
>>> To: ros-dev(a)reactos.org
>>> Subject: Re: [ros-dev] [ros-diffs] [sginsberg] 35819: - CACHE_DESCRIPTOR
>>> and PROCESSOR_CACHE_TYPE are public and defined in winnt.h, so no need to
>>> define them in the NDK (the NDK includes winnt.h through windef.h, so this
>>> breaks build)
>>>
>>> Please make sure that these types are available for DRIVERS as well --
>>> otherwise, they belong in the NDK. (Check with WDK
>>> wdm.h/ntddk.h/ntifs.h -- if it's not there, and drivers can access
>>> pointers/structures of this type, it must be in the NDK).
>>>
>>> Also, the NDK does not include winnt.h -- at least it's not supposed
>>> to, unless someone broke it.
>>>
>>> For the future, please make suer to review NDK changes with me, since
>>> I'm still its owner.
>>>
>>> Best regards,
>>> Alex Ionescu
>>>
>>>
>>>
>>> On Sat, Aug 30, 2008 at 11:34 PM, <sginsberg(a)svn.reactos.org> wrote:
>>> > Author: sginsberg
>>> > Date: Sat Aug 30 16:34:56 2008
>>> > New Revision: 35819
>>> >
>>> > URL: http://svn.reactos.org/svn/reactos?rev=35819&view=rev
>>> > Log:
>>> > - CACHE_DESCRIPTOR and PROCESSOR_CACHE_TYPE are public and defined in
>>> > winnt.h, so no need to define them in the NDK (the NDK includes winnt.h
>>> > through windef.h, so this breaks build)
>>> >
>>> > Modified:
>>> > trunk/reactos/include/ndk/ketypes.h
>>> >
>>> > Modified: trunk/reactos/include/ndk/ketypes.h
>>> > URL:
>>> > http://svn.reactos.org/svn/reactos/trunk/reactos/include/ndk/ketypes.h?rev=…
>>> >
>>> > ==============================================================================
>>> > --- trunk/reactos/include/ndk/ketypes.h [iso-8859-1] (original)
>>> > +++ trunk/reactos/include/ndk/ketypes.h [iso-8859-1] Sat Aug 30 16:34:56
>>> > 2008
>>> > @@ -542,17 +542,6 @@
>>> > } KAPC_ENVIRONMENT;
>>> >
>>> > //
>>> > -// CPU Cache Types
>>> > -//
>>> > -typedef enum _PROCESSOR_CACHE_TYPE
>>> > -{
>>> > - CacheUnified,
>>> > - CacheInstruction,
>>> > - CacheData,
>>> > - CacheTrace,
>>> > -} PROCESSOR_CACHE_TYPE;
>>> > -
>>> > -//
>>> > // PRCB DPC Data
>>> > //
>>> > typedef struct _KDPC_DATA
>>> > @@ -571,18 +560,6 @@
>>> > struct _GENERAL_LOOKASIDE *P;
>>> > struct _GENERAL_LOOKASIDE *L;
>>> > } PP_LOOKASIDE_LIST, *PPP_LOOKASIDE_LIST;
>>> > -
>>> > -//
>>> > -// CPU Cache Descriptor
>>> > -//
>>> > -typedef struct _CACHE_DESCRIPTOR
>>> > -{
>>> > - UCHAR Level;
>>> > - UCHAR Associativity;
>>> > - USHORT LineSize;
>>> > - ULONG Size;
>>> > - PROCESSOR_CACHE_TYPE Type;
>>> > -} CACHE_DESCRIPTOR, *PCACHE_DESCRIPTOR;
>>> >
>>> > //
>>> > // Architectural Types
>>> >
>>> >
>>> _______________________________________________
>>> Ros-dev mailing list
>>> Ros-dev(a)reactos.org
>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>> ________________________________
>> Connect to the next generation of MSN Messenger Get it now!
>> _______________________________________________
>> Ros-dev mailing list
>> Ros-dev(a)reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>>
>
Please make sure that these types are available for DRIVERS as well --
otherwise, they belong in the NDK. (Check with WDK
wdm.h/ntddk.h/ntifs.h -- if it's not there, and drivers can access
pointers/structures of this type, it must be in the NDK).
Also, the NDK does not include winnt.h -- at least it's not supposed
to, unless someone broke it.
For the future, please make suer to review NDK changes with me, since
I'm still its owner.
Best regards,
Alex Ionescu
On Sat, Aug 30, 2008 at 11:34 PM, <sginsberg(a)svn.reactos.org> wrote:
> Author: sginsberg
> Date: Sat Aug 30 16:34:56 2008
> New Revision: 35819
>
> URL: http://svn.reactos.org/svn/reactos?rev=35819&view=rev
> Log:
> - CACHE_DESCRIPTOR and PROCESSOR_CACHE_TYPE are public and defined in winnt.h, so no need to define them in the NDK (the NDK includes winnt.h through windef.h, so this breaks build)
>
> Modified:
> trunk/reactos/include/ndk/ketypes.h
>
> Modified: trunk/reactos/include/ndk/ketypes.h
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/ndk/ketypes.h?rev=…
> ==============================================================================
> --- trunk/reactos/include/ndk/ketypes.h [iso-8859-1] (original)
> +++ trunk/reactos/include/ndk/ketypes.h [iso-8859-1] Sat Aug 30 16:34:56 2008
> @@ -542,17 +542,6 @@
> } KAPC_ENVIRONMENT;
>
> //
> -// CPU Cache Types
> -//
> -typedef enum _PROCESSOR_CACHE_TYPE
> -{
> - CacheUnified,
> - CacheInstruction,
> - CacheData,
> - CacheTrace,
> -} PROCESSOR_CACHE_TYPE;
> -
> -//
> // PRCB DPC Data
> //
> typedef struct _KDPC_DATA
> @@ -571,18 +560,6 @@
> struct _GENERAL_LOOKASIDE *P;
> struct _GENERAL_LOOKASIDE *L;
> } PP_LOOKASIDE_LIST, *PPP_LOOKASIDE_LIST;
> -
> -//
> -// CPU Cache Descriptor
> -//
> -typedef struct _CACHE_DESCRIPTOR
> -{
> - UCHAR Level;
> - UCHAR Associativity;
> - USHORT LineSize;
> - ULONG Size;
> - PROCESSOR_CACHE_TYPE Type;
> -} CACHE_DESCRIPTOR, *PCACHE_DESCRIPTOR;
>
> //
> // Architectural Types
>
>
pschweitzer(a)svn.reactos.org wrote:
> +DWORD WINAPI sfc_8()
>
I hope you guys realize that sfc_8 () compiled as C is different from
what it'd be when compiled as C++. In C this means that it is a cdecl
function with variable arguments (I guess WINAPI overrides cdecl, but
still). If it is compiled as C++, it means the same as sfc_8 (void). So
better have a void argument list.
Thomas