May I ask why those if (!Info) checks are required? To me it makes no
sense to call those APIs with the cruicial, mandatory working (and in
one case the only) parameter being NULL, and I would put an ASSERT
(Info) there to catch bad callers and fix them.
WBR,
Aleksey.
On Nov 18, 2008, at 8:36 AM, jimtabor(a)svn.reactos.org wrote:
> Author: jimtabor
> Date: Mon Nov 17 23:36:19 2008
> New Revision: 37436
>
> UINT
> FASTCALL
> DIB_BitmapMaxBitsSize( PBITMAPINFO Info, UINT ScanLines )
> {
> UINT MaxBits = 0;
> +
> + if (!Info) return 0;
>
>
> +UINT
> +FASTCALL
> +DIB_BitmapBitsSize( PBITMAPINFO Info )
> +{
> + UINT Ret;
> +
> + if (!Info) return 0;
This is just getting repetitive:
[WIDL] obj-i386\include\reactos\idl\lsa_c.c
include\reactos\idl\lsa.idl:17: Error: NTSTATUS: redefinition error;
original definition was at ( ť:
21
mingw32-make: *** [obj-i386\include\reactos\idl\lsa_c.c] Error 1
mingw32-make: *** Waiting for unfinished jobs....
[WIDL] obj-i386\include\reactos\idl\eventlogrpc_c.c
include\reactos\idl\eventlogrpc.idl:7: Error: NTSTATUS: redefinition error;
original definition was
at Ş■.:21
mingw32-make: *** [obj-i386\include\reactos\idl\eventlogrpc_c.c] Error 1
With all due respect, Eric, would you be so kind and test your commits on
more OS than your PC/buildbot???
Is it not time to start getting rid of IsBadWritePtr and friends?
I don't see a good reason for these in our own code, especially when we can just use SEH directly.
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of greatlrd(a)svn.reactos.org
Sent: 13 November 2008 19:52
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [greatlrd] 37343: Bugfix : Do not link to LPDDRAWI_DIRECTDRAW_INT->lpLink when we do not have any LPDDRAWI_DIRECTDRAW_INT->lpLcl
Author: greatlrd
Date: Thu Nov 13 13:52:20 2008
New Revision: 37343
URL: http://svn.reactos.org/svn/reactos?rev=37343&view=rev
Log:
Bugfix : Do not link to LPDDRAWI_DIRECTDRAW_INT->lpLink when we do not have any LPDDRAWI_DIRECTDRAW_INT->lpLcl
Modified:
branches/reactx/reactos/dll/directx/ddraw/startup.c
Modified: branches/reactx/reactos/dll/directx/ddraw/startup.c
URL: http://svn.reactos.org/svn/reactos/branches/reactx/reactos/dll/directx/ddra…
==============================================================================
--- branches/reactx/reactos/dll/directx/ddraw/startup.c [iso-8859-1] (original)
+++ branches/reactx/reactos/dll/directx/ddraw/startup.c [iso-8859-1] Thu Nov 13 13:52:20 2008
@@ -33,8 +33,8 @@
This = (LPDDRAWI_DIRECTDRAW_INT)*pIface;
- /* fixme linking too second link when we shall not doing it */
- if (IsBadReadPtr(This,sizeof(LPDIRECTDRAW)))
+ if ( (IsBadWritePtr(This,sizeof(LPDDRAWI_DIRECTDRAW_INT)) != 0) ||
+ (IsBadWritePtr(This->lpLcl,sizeof(LPDDRAWI_DIRECTDRAW_LCL)) != 0) )
{
/* We do not have a DirectDraw interface, we need alloc it*/
LPDDRAWI_DIRECTDRAW_INT memThis;
Since revisions 37313-37314 i observe repetitive problems with WIDL. Every
time WIDL is called by our BE, it throws an exception:
Faulting application widl.exe, version 0.0.0.0, time stamp 0x491c610d,
faulting module widl.exe, version 0.0.0.0, time stamp 0x491c610d, exception
code 0xc0000005, fault offset 0x00005f0a, process id 0x17f8, application
start time 0x01c945b3aefa8530.
> [WIDL] obj-i386\include\reactos\idl\svcctl_s.c
> [WIDL] obj-i386\include\reactos\idl\svcctl_s.h
> mingw32-make: *** Waiting for unfinished jobs....
> mingw32-make: *** [obj-i386\include\reactos\idl\svcctl_s.h] Error
-1073741819 (0xC0000005)
> mingw32-make: *** [obj-i386\include\reactos\idl\svcctl_s.c] Error
-1073741819 (0xC0000005)
Reverting revisions 37313 and 37314 fixes this problem. Apart from me, this
issue been noted by dreimer, encoded and Christoph_vW. Dunno about
Christoph, but me, dreimer and encoded are using Vista/2008. I couldnt
replicate this issue on XP/2003 though.
Hi folks,
during the development of the 1st-stage-GUI-setup I experienced some problems
with physical drive detection with reactos api (because it's fairly
incomplete - it works under windows). To continue the development and to
bring more benefits I want to make following suggestion. Sooner or later we
need a drive/volume/partition management tool, so i will continue with this
basing on the usetup code and replaced later by working reactos api calls.
So we can use this tool to determine the current harddisk(s) layout(s),
create/delete partitions, format with different file systems and
show/install/configure the current boot loader. Later I can use this
functions to handle the drives during installation process in a similiar way.
What do you think about this plan?
Matt
--
Matthias Kupfer Telefon +49 (0) 371 236 46 52
Wilhelm-Firl-Straße 21 Mobil +49 (0) 160 859 43 54
09122 Chemnitz
Hi,
> Todo: Get it at the end of the executable, so we can safely remove it.
I think it can be safely removed from inside of the executable — just
wasting some address space.
On Mon, Nov 10, 2008 at 9:25 AM, <gschneider(a)svn.reactos.org> wrote:
> Author: gschneider
> Date: Mon Nov 10 08:25:24 2008
> New Revision: 37281
>
> URL: http://svn.reactos.org/svn/reactos?rev=37281&view=rev
> Log:
> Implement ConvertSecurityDescriptorToStringSecurityDescriptorW based on Wine code.
Please add the appropriate copyright headers to the source file
stating the original author when implementing code based on third
party sources.
--
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
Hi,
I have recently been working on getting SEH into the x64 port. This
covers several parts. One of them is compiler support.
On x64 SEH is table based rather than code based, that means it needs
tables of unwind data. These can be generated from DWARF unwind info -
which gcc generates - and that's what I'm working on.
The x64 version of rsym shall parse the DWARF unwind data and convert it
into Windows compatible unwind data.
Now there is a problem. While older versions of mingw64 used the
".debug_frame" section, the newer versions use the ".eh_frame" section.
That is good and bad at the same time. What does that mean? What's the
difference?
The .eh_frame section isn't part of the DWARF 2 or 3 specification, it's
a GNU extension / part of the LSB-Core specification. Documentation was
hard to find, but google is your friend and it seems there's only one
major difference to the debug_frame section and that is relative
addressing rather than absolute. This is actually very good and saves
the day for all modules that live in kernel space, because the addresses
are only 32 bits.
There is still a problem left. While the .debug_frame section is by
default put into the output executable as a seperate section, the
.eh_frame section isn't. The default linker script puts it into the
".rdata" section. But there it's kinda lost and I don't want to keep it
anyway.
With ntoskrnl there's no problem as it uses it's own linker script
anyway. I can change it, so the .eh_frame section is put at the end of
the executable. But how do I do this for the other modules? Do i need to
provide a new default linkerscript for all other modules? Can I "fix"
this behavior in RosBE64 (the files in lib/ldscripts seem to be unused)?
Or does anyone know a command line option to change this default behavior?
Regards,
Timo