There is a big problem with this change, originally this was added
only for "our own" .spec files, which don't have comments starting
with #.
Wine .spec files have such comments, and thus will be preprocessed
incorrectly.
WBR,
Aleksey.
On Sep 21, 2008, at 6:34 PM, tkreuzer(a)svn.reactos.org wrote:
> Author: tkreuzer
> Date: Sun Sep 21 09:34:48 2008
> New Revision: 36379
>
> URL: http://svn.reactos.org/svn/reactos?rev=36379&view=rev
> Log:
> preprocess all spec files
>
> Modified:
> branches/ros-amd64-bringup/reactos/tools/rbuild/backend/mingw/
> modulehandler.cpp
>
> Modified: branches/ros-amd64-bringup/reactos/tools/rbuild/backend/
> mingw/modulehandler.cpp
> URL: http://svn.reactos.org/svn/reactos/branches/ros-amd64-bringup/
> reactos/tools/rbuild/backend/mingw/modulehandler.cpp?
> rev=36379&r1=36378&r2=36379&view=diff
Hi,
I just joined in the mail list and I want to ask a question.
I have a question about scsiport module. I have seen the code
scsiport.c and tried to find where it create the physical device
object for scsi disk however I didn't find it. I just saw the
function SpiScanAdapter which would send inquiry scsi command to scsi
miniport driver.
So I want to know who create the pdo for scsi disk?
Gang Chen
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