This was created for all win32k/gdi32 work which is done without any
particular goal, or for directx-related work (dxeng is allowed to go
into trunk directly).
WBR,
Aleksey Bragin.
On May 11, 2008, at 3:03 PM, fireball(a)svn.reactos.org wrote:
> Author: fireball
> Date: Sun May 11 06:03:57 2008
> New Revision: 33435
>
> URL: http://svn.reactos.org/svn/reactos?rev=33435&view=rev
> Log:
> Creating a branch for Magnus Olsen's work in win32k, GDI and
> DirectX area. Finished parts will be merged back to trunk.
>
> Added:
> branches/win32k-gdi-dx/
> - copied from r33434, /
>
"DC_BITMAP or the value are not documented in MSDN or ms header" ...
and that's precisely why the definition belongs to another (internal)
header file and not here.
F.
On Sat, May 10, 2008 at 7:37 PM, <greatlrd(a)svn.reactos.org> wrote:
> Author: greatlrd
> Date: Sat May 10 12:37:43 2008
> New Revision: 33411
>
> URL: http://svn.reactos.org/svn/reactos?rev=33411&view=rev
> Log:
> adding a new define DC_BITMAP for GetStockObject
>
> Modified:
> trunk/reactos/include/psdk/wingdi.h
>
> Modified: trunk/reactos/include/psdk/wingdi.h
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/psdk/wingdi.h?rev=…
> ==============================================================================
> --- trunk/reactos/include/psdk/wingdi.h [iso-8859-1] (original)
> +++ trunk/reactos/include/psdk/wingdi.h [iso-8859-1] Sat May 10 12:37:43 2008
> @@ -813,6 +813,12 @@
> #define SYSTEM_FONT 13
> #define SYSTEM_FIXED_FONT 16
> #define DEFAULT_PALETTE 15
> +
> +/* NOTE DC_BITMAP or the value are not documented in MSDN or ms header
> + * it return a 1x1 1Bpp Bitmap in all case from GetStockObject
> + */
> +#define DC_BITMAP 21
> +
> #if (_WIN32_WINNT >= 0x0500)
> #define DC_BRUSH 18
> #define DC_PEN 19
>
>
Hi devs,
I don't think this patch should be refused, what about "Shell32 improvements" in: http://www.reactos.org/en/newsletter_34.html?
And all the commits made recently by johannes (also in shlview.c)? After almost a year we close the bug saying it's not our code?
WBR
Gabriel ilardi.
> Date: Fri, 9 May 2008 18:13:49 +0200> From: ReactOS.Bugzilla(a)www.reactos.org> To: ros-bugs(a)reactos.org> Subject: [ros-bugs] [Bug 644] directional keys problem with Explorer> > http://www.reactos.org/bugzilla/show_bug.cgi?id=644> > > amine48rz <amine48rz(a)gmail.com> changed:> > What |Removed |Added> ----------------------------------------------------------------------------> Status|NEW |ASSIGNED> Status|ASSIGNED |NEW> CC| |amine48rz(a)gmail.com> AssignedTo|info(a)w3seek.de |johannes.anderwald(a)student.t> | |ugraz.at> > w3seek <w3seek(a)reactos.com> changed:> > What |Removed |Added> ----------------------------------------------------------------------------> CC| |w3seek(a)reactos.com> Status|NEW |RESOLVED> Resolution| |WONTFIX> > > > > --- Comment #3 from w3seek <w3seek(a)reactos.com> 2008-05-09 18:13:48 CET ---> (In reply to comment #2)> > Created an attachment (id=1341)> --> (http://www.reactos.org/bugzilla/attachment.cgi?id=1341) [details]> > LISTVIEW_GetNextItem Patch> > Here's a new patch for which i rewrote the LISTVIEW_GetNextItem routine, so> > that the ListView itself is aware of whether LVS_ALIGNTOP or LVS_ALIGNLEFT is> > set and returns the correct next item.> > But I still like the other patch just because I dislike scrolling horizontal in> > a list :).> > This patch should not be accepted for ReactOS. This is code shared with WINE> and needs to be submitted to winehq.> > > -- > Configure bugmail: http://www.reactos.org/bugzilla/userprefs.cgi?tab=email> ------- You are receiving this mail because: -------> You are the QA contact for the bug.> _______________________________________________> Ros-bugs mailing list> Ros-bugs(a)reactos.org> http://www.reactos.org/mailman/listinfo/ros-bugs
_________________________________________________________________
Crea il tuo blog su Spaces, condividi le tue esperienze con il mondo!
http://home.services.spaces.live.com/
Hi everybody,
I tracked down the Explorer startup crash we experience since r33366 and
came to some weird results.
First of all, this crash also occurs when testing under Windows. Also
Explorer runs well when it's compiled with MSVC using the supplied
"explorer.sln" file.
Then I put MessageBoxes to some code pathes to track down, where the crash
occurs.
The weird thing is: It fails in the IconCache code (which doesn't even
handle strings, so shouldn't be affected by Unicode at all).
Just put a MessageBox at explorer.cpp:389 and then after _icons[ICID_NONE]
was assigned. You will see that the second message box won't appear.
You can also put a MessageBox in the Icon constructor, it won't be shown
either.
So what's going wrong here?
Bug in our mingw startup routine, memory corruption, bug in gcc, ...? I'm
out of ideas.
Best regards,
Colin
Hi folks,
I'd like to try Reactos in Xen. Is there any image available ?
thx
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
On Tue, May 6, 2008 at 12:15 PM, <gbrunmar(a)svn.reactos.org> wrote:
> + if (IsBadWritePtr(pMode, sizeof(D3DDISPLAYMODE*)))
Is this really a good idea?
--
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
Just to clarify to anyone following this thread, the change from SystemParametersInfo to sending a message isn't incorrect.
kbswitch is meant to be a sort of makeshift ctfmon.exe, and isn't meant for switching keyboards system-wide as intl.cpl does.
The buffer overflow problems still stand though.
Ged.
> -----Original Message-----
> From: gedmurphy [mailto:gedmurphy@gmail.com]
> Sent: 22 April 2008 21:03
> To: 'ros-dev(a)reactos.org'
> Subject: RE: [ros-diffs] [dchapyshev] 33106: - Keyboard layout
> switching works now in ReactOS!
>
> dchapyshev(a)svn.reactos.org wrote:
> >
> > Author: dchapyshev
> > Date: Tue Apr 22 14:01:56 2008
> > New Revision: 33106
> >
> > URL: http://svn.reactos.org/svn/reactos?rev=33106&view=rev
> > Log:
> > - Keyboard layout switching works now in ReactOS!
>
>
> Hi, just a few points about this patch.
>
>
> > + if (RegOpenKeyEx(HKEY_CURRENT_USER, _T("Keyboard
> > Layout\\Substitutes"), 0, KEY_QUERY_VALUE, &hKey) == ERROR_SUCCESS)
> > + {
> > + dwBufLen = MAX_PATH;
> > +
> > + if (RegQueryValueEx(hKey, szTempLCID, NULL, NULL,
> > (LPBYTE)szLCID, &dwBufLen) != ERROR_SUCCESS)
>
>
> Firstly, Reg functions work on bytes, so you introduced a potential
> buffer overflow here.
> But this is irrelevant due to the next point ;)
>
>
> > - Ret = SystemParametersInfo(SPI_SETDEFAULTINPUTLANG, 0, &hKl,
> > SPIF_SENDWININICHANGE);
> > + EnumWindows(EnumWindowsProc, (LPARAM) hKl);
>
>
> This looks like a hack. The original method was correct, it just need
> implementing in win32k.
> Have a look in NtUserSystemParametersInfo.
>
> Thirdly, what is this kbswitch app? It's not a standard windows tool,
> yet it's included in our base.
> Keyboard switching is done in intl.cpl, or via ctfmon (which we don't
> yet have) on a per app basis.
>
> Regards,
> Ged.
dchapyshev(a)svn.reactos.org wrote:
>
> Author: dchapyshev
> Date: Tue Apr 22 14:01:56 2008
> New Revision: 33106
>
> URL: http://svn.reactos.org/svn/reactos?rev=33106&view=rev
> Log:
> - Keyboard layout switching works now in ReactOS!
Hi, just a few points about this patch.
> + if (RegOpenKeyEx(HKEY_CURRENT_USER, _T("Keyboard
> Layout\\Substitutes"), 0, KEY_QUERY_VALUE, &hKey) == ERROR_SUCCESS)
> + {
> + dwBufLen = MAX_PATH;
> +
> + if (RegQueryValueEx(hKey, szTempLCID, NULL, NULL,
> (LPBYTE)szLCID, &dwBufLen) != ERROR_SUCCESS)
Firstly, Reg functions work on bytes, so you introduced a potential buffer overflow here.
But this is irrelevant due to the next point ;)
> - Ret = SystemParametersInfo(SPI_SETDEFAULTINPUTLANG, 0, &hKl,
> SPIF_SENDWININICHANGE);
> + EnumWindows(EnumWindowsProc, (LPARAM) hKl);
This looks like a hack. The original method was correct, it just need implementing in win32k.
Have a look in NtUserSystemParametersInfo.
Thirdly, what is this kbswitch app? It's not a standard windows tool, yet it's included in our base.
Keyboard switching is done in intl.cpl, or via ctfmon (which we don't yet have) on a per app basis.
Regards,
Ged.
Any real explanation in the commit message about what was done in this
commit? Short, real and clean, so every developer reading the commit
messages could understand what was done and why.
I'm suspicious that it "fixes" one bug, and reopens another.
The same note applies to "start kill the bad macro DXG_GET_INDEX_FUNCTION
that is instable" (rev. 33012). Macro is a preprocessor definition, it can't
be stable or not, it's being performed before the actual compile stage.
Better to explain while enumerating through all functions to find the best
one is worse than just getting a pointer by indexing. Or why it was done so
in the beginning.
With the best regards,
Aleksey Bragin.
----- Original Message -----
From: <greatlrd(a)svn.reactos.org>
To: <ros-diffs(a)reactos.org>
Sent: Friday, April 18, 2008 4:56 AM
Subject: [ros-diffs] [greatlrd] 33014: fixed pipe working again from cmd
more investigate are need it to figout who to really solv bat and pipe and
gui apps issue so none regress and working fine in all case. rember gui apps
can resive pipe from cmd or send to cmd
> Author: greatlrd
> Date: Thu Apr 17 19:56:01 2008
> New Revision: 33014
>
> URL: http://svn.reactos.org/svn/reactos?rev=33014&view=rev
> Log:
> fixed pipe working again from cmd
> more investigate are need it to figout who to really solv bat and pipe and
> gui apps issue
> so none regress and working fine in all case. rember gui apps can resive
> pipe from cmd or send to cmd