Ros-dev April 2007

ros-dev@reactos.org

38 participants
41 discussions

[ros-diffs] [jimtabor] 22523: GetGlyphOutline, large wine port. Still testing.

by James Tabor

Hi, I have it half way done. Run the test program and you can see. Program works in W2k, XP and Wine. mingw32-gcc -mwindows -Os GetGlyphOutline.c -o ggo.exe I stopped messing with it two weeks ago, I needed to work on something else. When testing you can select the alphanumeric character with the keyboard. The original program had "a" but I changed it to "L" something simple to draw at first. You will see the problem. The test program from Dr. Dobb's Journal http://www.ddj.com/184409154?pgno=12 Thanks, James Runs and hides~

17 years, 3 months

Re: [ros-dev] [ros-diffs] [dgorbachev] 26483: Undo r26482 change, waste more stack space.

by Alex Ionescu

Perhaps you could try convincing the GCC folks to actually properly support declspec_align like MSVC does, instead of claiming to support it, but actually ignoring it. Then you could also convince them to support SEH, PDBs, STDCALL-default calling convention, etc ;) -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of dgorbachev(a)svn.reactos.org Sent: April-24-07 1:06 AM To: ros-diffs(a)reactos.org Subject: [ros-diffs] [dgorbachev] 26483: Undo r26482 change, waste more stack space. Author: dgorbachev Date: Tue Apr 24 09:05:49 2007 New Revision: 26483 URL: http://svn.reactos.org/svn/reactos?rev=26483&view=rev Log: Undo r26482 change, waste more stack space. Modified: trunk/reactos/ntoskrnl/include/internal/ex.h Modified: trunk/reactos/ntoskrnl/include/internal/ex.h URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/internal/… ============================================================================== --- trunk/reactos/ntoskrnl/include/internal/ex.h (original) +++ trunk/reactos/ntoskrnl/include/internal/ex.h Tue Apr 24 09:05:49 2007 @@ -106,9 +106,15 @@ // #ifdef __GNUC__ -#define DEFINE_WAIT_BLOCK(x) \ - PEX_PUSH_LOCK_WAIT_BLOCK x = __builtin_alloca(sizeof(EX_PUSH_LOCK_WAIT_BLOCK)); - +#define DEFINE_WAIT_BLOCK(x) \ + struct _AlignHack \ + { \ + UCHAR Hack[15]; \ + EX_PUSH_LOCK_WAIT_BLOCK UnalignedBlock; \ + } WaitBlockBuffer; \ + PEX_PUSH_LOCK_WAIT_BLOCK x = (PEX_PUSH_LOCK_WAIT_BLOCK) \ + ((ULONG_PTR)&WaitBlockBuffer.UnalignedBlock &~ 0xF); + #else // @@ -116,8 +122,8 @@ // local variable (the actual pointer) away, so we don't take any perf hit // by doing this. // -#define DEFINE_WAIT_BLOCK(x) \ - EX_PUSH_LOCK_WAIT_BLOCK WaitBlockBuffer; \ +#define DEFINE_WAIT_BLOCK(x) \ + EX_PUSH_LOCK_WAIT_BLOCK WaitBlockBuffer; \ PEX_PUSH_LOCK_WAIT_BLOCK x = &WaitBlockBuffer; #endif

17 years, 6 months

Re: [ros-dev] About translation

by Aleksey

Hi Lucio, I must say, that there were a lot of efforts to get our tools working as easy as possible. Even a global login system was introduced way back so that you don't need to create an account for wiki, for bugzilla, for forum, for wiki, for the main website - you just create one. A lot of time was spent in order to do this (every piece of software needed to be customised - Ge and Klemens put a lot of their personal time into this). I will answer between the lines below so it makes better sense. ----- Original Message ----- From: "Lucio Diaz" <reactos_translate(a)yahoo.es> To: <ros-dev(a)reactos.org> Sent: Tuesday, April 17, 2007 2:08 AM Subject: [ros-dev] About translation -= skip =- > -Many like me can install SVN, and get the source > code, but never have made a patch, or even used > bugzilla(and probably wont have the time). If a contributor has SO small time that he can't even submit his work to a bugzilla or, at least, send a patch to a relevant person (the same language native speaker developer or another translator who has more time), then it's better to wait when he/she has more free time to contribute. -= skip =- > files, but sending them to bugzilla... i dont know how > to send them to bugzilla, i dont have a bugzilla > acount, it was tiring trying to find someone to send > the files, and i dont have the time or will to learn > bugzilla. That shows you really did not even slightly investigated how the website works. And instead you're proposing a whole workflow for developers, so they mandatory spent a few hours per week maintaining all the stuff you. During that 2 years you should have spent just a bit of time, even 20 minutes, to overview our website and systems we have there, and another 20 minutes to read online manuals/help for them. Excuses like "I didn't have time" hardly apply here. WBR, Aleksey Bragin.

17 years, 6 months

Re : DbgPrint() - DPRINT() - DPRINT1()

by Sylvain Petreolle

Hi, You actually have to define YDEBUG to see messages produced by DPRINT() If NDEBUG is defined (default), no message is shown. DPRINT1 is used in case of error/ fix needed. Kind regards, Sylvain Petreolle (aka Usurp) --- --- --- --- --- --- --- --- --- --- --- --- --- Run your favorite Windows apps with free ReactOS : http://www.reactos.org Listen to non-DRMised Music: http://www.jamendo.com ----- Message d'origine ---- De : "breakoutbox(a)web.de" <breakoutbox(a)web.de> À : Ros-dev(a)reactos.org Envoyé le : Jeudi, 19 Avril 2007, 16h21mn 55s Objet : [ros-dev] DbgPrint() - DPRINT() - DPRINT1() Hello, can please anybody explain me how You want DbgPrint() - DPRINT() - DPRINT1() to be used ? I found a lot of DPRINT() _for_example_ in "win32/in32k/objects/dc.c" but it is not shown on serial debug (?) (and also SOME ot these DPRINT1() .. ) 1) If I use DPRINT1() instead, it is always shown. If I use DbgPrint() instead, it is only shown when #DEBUG is defined in the file + in *.rbuild But what's the sense of DPRINT() then ? => 2) 2nd stage: on installing from BootCD I can see serial debug only when I select DEBUG from startup options. Is this DPRINT1() suppressed when I DON'T select DEBUG ? 3) Why is there not one DbgPrint() in "win32/in32k/objects/dc.c" (and also in other files in /DRIVER/ and /NTOSKRNL/ ..) ? I now have to change every serial debug output to be able to see anything .. ( if You don't explain me ... ;-) ) Best regards, Peter. _______________________________________________________________ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev

17 years, 7 months

Bug into log10 function.

by carlo.bramix

While I was doing the final tests with ReactOS Calc before releasing the new version, I discovered that it didn't work because a bug into log10 function. This happens because the two operands are swapped into: \ReactOS-0.3.1\lib\crt\math\i386\log10_asm.s I attached the patch. Sincerely, Carlo Bramini. ------------------------------------------------------ Leggi GRATIS le tue mail con il telefonino i-mode di Wind http://i-mode.wind.it/

17 years, 7 months

Uniform Driver Interface

by Jerry

http://udi.certek.cc/ >From what I can tell the example source code of this project is BSD (new). Should we add this driver interface to ReactOS? Why or why not? How could this be implemented while keeping compatibility with native NT drivers and not have it ROS specific?

17 years, 7 months

Problem with out current NtGdiExtGetObjectW implementation

by Timo Kreuzer

Hi, although I like the way NtGdiExtGetObjectW is using the union, we will get a problem with it. We don't know how many styles an extpen has, so we cannot statically allocate a kmode buffer that is big enough. I can currently think of 3 possible solutions: 1. Add a big additional hack for GDI_OBJECT_TYPE_EXTPEN in NtGdiExtGetObjectW, that will copy the styles, wich seems to be a bad idea. 2. Use the old method of first calling IntGdiExtGetObjectW to get the needed buffer size then allocate a kernelmode buffer then call IntGdiExtGetObjectW again to tranfer the data then copy to usermode. This is slower and needs extra memory. 3. Move the copying to usermode to the XXX_GetObject functions. This would remove the need for an extra kernelmode buffer and we wouldn't really need IntGdiExtGetObjectW anymore. But it doesn't match the rest of our call chain design. Comments appreciated. Timo

17 years, 7 months

CUnit

by theUser BL

Hi! Which testing-framefork do ReactOS use? I have seen, that CUnit for example outputs the result in a nice html-format: http://cunit.sourceforge.net/ss_automated.html Looks similar to the output of GNU Classpath (which trys to rewrite Java): http://builder.classpath.org/japi/jdk15-generics.html But GNU Classpath uses JUnit. And ReactOS is written in C, so in this case CUnit would be better. Existing for ReactOS also a side like this, where everytime stands, which test are passed and which not? Greatings theuserbl _________________________________________________________________ Sie suchen E-Mails, Dokumente oder Fotos? Die neue MSN Suche Toolbar mit Windows-Desktopsuche liefert in sekundenschnelle Ergebnisse. Jetzt neu! http://desktop.msn.de/ Jetzt gratis downloaden!

17 years, 7 months

Re: [ros-dev] [ros-diffs] [tkreuzer] 26565: BRUSH_GetObject: - return sizeof(LOBRUSH) not BRUSHOBJ - don't return 0 on too small usermode buffer NtGdiExtGetObjectW: - remove unnecessary hacks - no need to align usermode buffer to words - add ENUMLOGFONTEXDVW, wich

by Alex Ionescu

Why did you randomly remove the hacks I added and call them useless? They're in Windows code, a checked GDI Server even prints out the size too big message! And why rename my variables? I don't really see the need to re-format code. -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of tkreuzer(a)svn.reactos.org Sent: April-28-07 5:53 PM To: ros-diffs(a)reactos.org Subject: [ros-diffs] [tkreuzer] 26565: BRUSH_GetObject: - return sizeof(LOBRUSH) not BRUSHOBJ - don't return 0 on too small usermode buffer NtGdiExtGetObjectW: - remove unnecessary hacks - no need to align usermode buffer to words - add ENUMLOGFONTEXDVW, wich shou Author: tkreuzer Date: Sun Apr 29 01:53:06 2007 New Revision: 26565 URL: http://svn.reactos.org/svn/reactos?rev=26565&view=rev Log: BRUSH_GetObject: - return sizeof(LOBRUSH) not BRUSHOBJ - don't return 0 on too small usermode buffer NtGdiExtGetObjectW: - remove unnecessary hacks - no need to align usermode buffer to words - add ENUMLOGFONTEXDVW, wich should be the biggest structure needed more fixes for fonts and extpens needed in the corresponding subfunctions, but all of my other tests pass now. Modified: trunk/reactos/subsystems/win32/win32k/objects/brush.c trunk/reactos/subsystems/win32/win32k/objects/dc.c Modified: trunk/reactos/subsystems/win32/win32k/objects/brush.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/ob… ============================================================================== --- trunk/reactos/subsystems/win32/win32k/objects/brush.c (original) +++ trunk/reactos/subsystems/win32/win32k/objects/brush.c Sun Apr 29 01:53:06 2007 @@ -52,9 +52,8 @@ INT FASTCALL BRUSH_GetObject (PGDIBRUSHOBJ BrushObject, INT Count, LPLOGBRUSH Buffer) { - if( Buffer == NULL ) return sizeof(BRUSHOBJ); + if( Buffer == NULL ) return sizeof(LOGBRUSH); if (Count == 0) return 0; - if ((UINT)Count < sizeof(BRUSHOBJ)) return 0; /* Set colour */ Buffer->lbColor = BrushObject->BrushAttr.lbColor; @@ -106,7 +105,7 @@ */ /* FIXME */ - return sizeof(BRUSHOBJ); + return sizeof(LOGBRUSH); } Modified: trunk/reactos/subsystems/win32/win32k/objects/dc.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/ob… ============================================================================== --- trunk/reactos/subsystems/win32/win32k/objects/dc.c (original) +++ trunk/reactos/subsystems/win32/win32k/objects/dc.c Sun Apr 29 01:53:06 2007 @@ -1817,92 +1817,44 @@ OUT LPVOID lpBuffer) { INT iRetCount = 0; - INT iObjectType; - INT cbRealCount = cbCount; + INT cbCopyCount; union { - BITMAP bmpObject; - DIBSECTION disObject; - LOGPEN lgpObject; - LOGBRUSH lgbObject; - LOGFONTW lgfObject; - EXTLOGFONTW elgfObject; + BITMAP bitmap; + DIBSECTION dibsection; + LOGPEN logpen; + LOGBRUSH logbrush; + LOGFONTW logfontw; + EXTLOGFONTW extlogfontw; + ENUMLOGFONTEXDVW enumlogfontexdvw; } Object; - // - // Get the object type - // - iObjectType = GDIOBJ_GetObjectType(hGdiObj); - - // - // Check if the given size is too large - // - if (cbCount > sizeof(Object)) - { - // - // Normalize to the largest supported object size - // - DPRINT1("cbCount too big!\n"); - cbCount = sizeof(Object); - } - - // - // Check if this is a brush - // - if (iObjectType == GDI_OBJECT_TYPE_BRUSH) - { - // - // Windows GDI Hack: Manually correct the size - // - cbCount = sizeof(LOGBRUSH); - } - - // + // Normalize to the largest supported object size + cbCount = min((UINT)cbCount, sizeof(Object)); + // Now do the actual call - // iRetCount = IntGdiGetObject(hGdiObj, cbCount, lpBuffer ? &Object : NULL); - - // - // Check if this is a brush - // - if (iObjectType == GDI_OBJECT_TYPE_BRUSH) - { - // - // Fixup the size to account for our previous fixup - // - cbCount = min(cbCount, cbRealCount); - } - - // - // Make sure we have a buffer and a return size - // - if ((iRetCount) && (lpBuffer)) - { - // + cbCopyCount = min((UINT)cbCount, (UINT)iRetCount); + + // Make sure we have a buffer and a copy size + if ((cbCopyCount) && (lpBuffer)) + { // Enter SEH for buffer transfer - // _SEH_TRY { - // // Probe the buffer and copy it - // - ProbeForWrite(lpBuffer, min(cbCount, cbRealCount), sizeof(WORD)); - RtlCopyMemory(lpBuffer, &Object, min(cbCount, cbRealCount)); + ProbeForWrite(lpBuffer, cbCopyCount, 1); + RtlCopyMemory(lpBuffer, &Object, cbCopyCount); } _SEH_HANDLE { - // // Clear the return value. // Do *NOT* set last error here! - // iRetCount = 0; } _SEH_END; } - - // // Return the count - // return iRetCount; }

17 years, 7 months

[ros-diffs] [tkreuzer] 26564: GetNonFontObject: - OBJECTTYPE_META_DC does not SetLastError() - beautify the code a little

by James Tabor

Hi! switch(dwType) { + case GDI_OBJECT_TYPE_PEN: //Check the structures and see if A & W are the same. + case GDI_OBJECT_TYPE_EXTPEN: + case GDI_OBJECT_TYPE_BRUSH: // Mixing Apples and Oranges? + case GDI_OBJECT_TYPE_BITMAP: + case GDI_OBJECT_TYPE_PALETTE: + return NtGdiExtGetObjectW(hGdiObj, cbSize, lpBuffer); + case GDI_OBJECT_TYPE_DC: case GDI_OBJECT_TYPE_REGION: case GDI_OBJECT_TYPE_METAFILE: case GDI_OBJECT_TYPE_ENHMETAFILE: case GDI_OBJECT_TYPE_EMF: - case GDI_OBJECT_TYPE_METADC: SetLastError(ERROR_INVALID_HANDLE); - return 0; This is wrong,,, you can not call NtGdiExtGetObjectW first before faulting on GDI_OBJECT_TYPE_DC. http://msdn2.microsoft.com/en-us/library/ms533268.aspx Normal DC's do not pass to kernel space. Please RTFM. Thanks, James

17 years, 8 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev April 2007