Maybe _tcscat_s should be used instead ?
Kind regards,
Sylvain Petreolle (aka Usurp)
Support artists, not multinationals - http://Iwouldntsteal.net
Supportez les artistes, pas les multinationales - http://Iwouldntsteal.net
----- Message d'origine ----
> De : Alex Ionescu <ionucu(a)videotron.ca>
> À : ros-dev(a)reactos.org
> Envoyé le : Samedi, 17 Mai 2008, 16h00mn 00s
> Objet : Re: [ros-dev] [ros-diffs] [cfinck] 33547: Make 100% sure that the correct "regedit.exe" is launched by using GetWindowsDirectory and appending "\regedit.exe" as suggested by Alex on ros-dev.
>
> This is still wrong. Tcscat is completely unsafe and can result in you
> overwriting the path as soon as the user has a windows path longer
> than MAX_PATH - sizeof("regedit.exe").
>
> Please use the PathAppend API for this.
>
> On Sat, May 17, 2008 at 5:39 PM, wrote:
> > Author: cfinck
> > Date: Sat May 17 04:39:36 2008
> > New Revision: 33547
> >
> > URL: http://svn.reactos.org/svn/reactos?rev=33547&view=rev
> > Log:
> > Make 100% sure that the correct "regedit.exe" is launched by using
> GetWindowsDirectory and appending "\regedit.exe" as suggested by Alex on
> ros-dev.
> >
> > Modified:
> > trunk/reactos/base/applications/regedt32/regedt32.c
> >
> > Modified: trunk/reactos/base/applications/regedt32/regedt32.c
> > URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/regedt32…
> > ==============================================================================
> > --- trunk/reactos/base/applications/regedt32/regedt32.c [iso-8859-1]
> (original)
> > +++ trunk/reactos/base/applications/regedt32/regedt32.c [iso-8859-1] Sat May
> 17 04:39:36 2008
> > @@ -5,7 +5,12 @@
> > int WINAPI _tWinMain(HINSTANCE hCurInst, HINSTANCE hPrevInst,
> > LPTSTR lpsCmdLine, int nCmdShow)
> > {
> > - ShellExecute(NULL, NULL, _T("regedit.exe"), lpsCmdLine, NULL, nCmdShow);
> > + TCHAR szPath[MAX_PATH];
> > +
> > + GetWindowsDirectory(szPath, MAX_PATH);
> > + _tcscat(szPath, _T("\\regedit.exe"));
> > +
> > + ShellExecute(NULL, NULL, szPath, lpsCmdLine, NULL, nCmdShow);
> >
> > return 0;
> > }
> >
> >
>
>
>
> --
> Best regards,
> Alex Ionescu
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
This is still wrong. Tcscat is completely unsafe and can result in you
overwriting the path as soon as the user has a windows path longer
than MAX_PATH - sizeof("regedit.exe").
Please use the PathAppend API for this.
On Sat, May 17, 2008 at 5:39 PM, <cfinck(a)svn.reactos.org> wrote:
> Author: cfinck
> Date: Sat May 17 04:39:36 2008
> New Revision: 33547
>
> URL: http://svn.reactos.org/svn/reactos?rev=33547&view=rev
> Log:
> Make 100% sure that the correct "regedit.exe" is launched by using GetWindowsDirectory and appending "\regedit.exe" as suggested by Alex on ros-dev.
>
> Modified:
> trunk/reactos/base/applications/regedt32/regedt32.c
>
> Modified: trunk/reactos/base/applications/regedt32/regedt32.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/regedt32…
> ==============================================================================
> --- trunk/reactos/base/applications/regedt32/regedt32.c [iso-8859-1] (original)
> +++ trunk/reactos/base/applications/regedt32/regedt32.c [iso-8859-1] Sat May 17 04:39:36 2008
> @@ -5,7 +5,12 @@
> int WINAPI _tWinMain(HINSTANCE hCurInst, HINSTANCE hPrevInst,
> LPTSTR lpsCmdLine, int nCmdShow)
> {
> - ShellExecute(NULL, NULL, _T("regedit.exe"), lpsCmdLine, NULL, nCmdShow);
> + TCHAR szPath[MAX_PATH];
> +
> + GetWindowsDirectory(szPath, MAX_PATH);
> + _tcscat(szPath, _T("\\regedit.exe"));
> +
> + ShellExecute(NULL, NULL, szPath, lpsCmdLine, NULL, nCmdShow);
>
> return 0;
> }
>
>
--
Best regards,
Alex Ionescu
Hi,
I thought it was a handle management problem but it seems to be just a
GetDC one. I found out when a pOWNED dc or dc owned by a window or
window class after the first GetDC the DCX_CACHE bit become set. This
is wrong behavior. Our UserGetDCEx code is a hodgepodge of wine and
poorly RE, coded by the original authors and does not comply with
known semantics. Sorry I guess? Well~ still rewriting it has become a
headache for me and I guess I'm asking for help. I have attempted more
than twice to rewrite it with porting wine code, etc. All ended in
major crashes, thus validating my claim, if you write code based on
bad code you end up with more bad code.
Using wine testing, Use32 dce test, everything works upto line 93.
hdc = GetDC( hwnd_owndc ); <----------------- first GetDC call
SetROP2( hdc, R2_WHITE );
rop = GetROP2( hdc );
ok( rop == R2_WHITE, "wrong ROP2 %d\n", rop );
old_hdc = hdc;
ReleaseDC( hwnd_owndc, hdc ); <---------------------- first ReleaseDC
hdc = GetDC( hwnd_owndc ); <---------------------------2nd GetDC
ok( old_hdc == hdc, "didn't get same DC %p/%p\n", old_hdc, hdc );
rop = GetROP2( hdc );
-> ok( rop == R2_WHITE, "wrong ROP2 %d after release\n", rop );
ReleaseDC( hwnd_owndc, hdc );
rop = GetROP2( hdc );
ok( rop == R2_WHITE, "wrong ROP2 %d after second release\n", rop );
After the first GetDC the DC is cached by setting bit DCX_CACHE and
this is wrong (BUG) since this DC is owned by a window. The second
GetDC is called and the DC is now a DCX_CACHE. The original data is
now lost due to the first ReleaseDC freeing DC_ATTR, thus normal
behavior for this type of DC with DCX_CACHE set. This results in the
failure at line 93 with the data in the DC_ATTR is set to a CleanDC
state. This is correct for DCX_CACHE'ed DC but not for DCX_WINDOW DC.
DCX_WINDOW DCs keep the original DC_ATTR data and it is not freed
after a ReleaseDC call. The same goes on with class DC tests.
The BUG is in UserGetDCEx, the freeing and allocating DC_ATTR is
correct but somewhere the DCX_CACHE bit get set and that should not
happen for window/class owned DCs.
I hope this clears it up.
I need someone with fresh eyes to help us fix this.
Thanks,
James
I've had enough of dealing with the suckiness of rbuild. The time has
come for action. Or, missing that, a wiki page:
<URL: http://www.reactos.org/wiki/index.php/Rbuild_sucks>
Add your own favourite issue with rbuild. Let's debate the more
controversial points in the wiki page's discussion page. We are now in
the "whining" phase, so sky's the limit, add any feature you find useful
or even just kind of "cool". We will sort them out in the upcoming
"procrastinating" phase
Hello,
this message is inspired by a lot of thinking, and yesterdays talk in
#reactos, when Magnus Olsen's proposition to add support for more
than one graphic adapter was a last drop into my cup of tolerancy.
Thus I want to say, one very important idea. But what I want even
more, for our developers to understand it. The key idea is that our
work on the project now MUST be aimed at bugfixing, not at adding
even more nice features. There are already quite enough of them
(features)!
As I said 1000 times, our general "users" don't care about ability to
insert 3 graphic cards into their PC, and get ReactOS using them!
They care about ReactOS crashing after closing regedit. Or during
Office 2003 installation. And if it continues to crash this way, I'm
sorry, but noone could feel the pleasure of multiple graphic cards
support, or any other feature which is useless for 99% of potential
users.
Moreover, I don't understand why noone ever bothered to work through
the winetests for reactos-specific parts of the system, like GDI,
user32/win32k testing, kernel32 testing. There are lots of failures,
and wine test results show APIs which are used for REAL, and by REAL
applications, not some historic APIs implemented by Magnus (no
offence, I'm just using him as an example, please excuse me if I
sound harsh anywhere) which are unused by any real application nowadays.
I clearly want to stress, that there is a strong misconcept in
ReactOS way of development of its Win32 subsystem. There were a lot
of positive events happening (win32k native tests library, great work
by Timo at fixing various small issues, handles, memory leaks, etc).
But it must be continued!
Ged Murphy said very right about the problem: small problems prevent
big apps from working. Wine already supports Office 2003 for years,
and noone except me was trying to make support it better. The same
applies to everywhere, there is no need to have some special skills
to improve ReactOS. You know, there are not that many people who
*really* worked on win32k in Microsoft, and they obviously can't code
for us anyway, so everyone had to learn how to develop one or another
part of the system. Look at Stefan Ginsberg - a guy who didn't know
anything about C development 3 months ago, but learnt just by reading
ros-diffs (well, and constant private messaging me in IRC asking
questions, but that doesn't count), and yesterday spotted a couple of
important real problems.
Especially that counts for Win32-subsystem (the kernel must stay as
strict NT-alike as legally possible, so it takes time to read all
available literature), but for Win32-subsystem, just maintaining its
code would result in a hundred less crashes now! I don't even say
about rewriting bad written parts. Or just simply, very-very simply,
syncing Wine's changes back into ReactOS!
But nobody cares to do that.
I especially delay the 0.3.5 release, because I want people to
concentrate more on bugfixes. We could easily release in the
beginning of may, there are enough of good changes for a usual
reactos release. But I want this particular release to be *unusual*.
If ReactOS wants to hit beta this year, developers must concentrate
on a boring work first, believe me, there will be lots more fun when
amount of people trying out reactos increases at least 100x.
And if no beta this year, I'm sorry to say, but it may be too late.
Thanks for thorough reading. Comments are welcome.
With the best regards,
Aleksey Bragin.
Actually this change may not be enough to fix the underlying issue. I
believe there are some cases when straight calling of IoVerifyVolume
could lead to deadlock. Maybe someone can lend a helping hand here and
verify if the code is actually correct? If not I will probably get to
it myself, but it may take a few days or even weeks.
Thanks,
Filip
On Sun, May 11, 2008 at 10:04 PM, <navaraf(a)svn.reactos.org> wrote:
> Author: navaraf
> Date: Sun May 11 15:04:47 2008
> New Revision: 33449
>
> URL: http://svn.reactos.org/svn/reactos?rev=33449&view=rev
> Log:
> Fix incorrect parameters to IoSetDeviceToVerify/IoVerifyVolume. Spotted by R.T.Sivakumar <rtshiva(a)gmail.com>.
>
> Modified:
> trunk/reactos/drivers/filesystems/fastfat/create.c
>
> Modified: trunk/reactos/drivers/filesystems/fastfat/create.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfa…
> ==============================================================================
> --- trunk/reactos/drivers/filesystems/fastfat/create.c [iso-8859-1] (original)
> +++ trunk/reactos/drivers/filesystems/fastfat/create.c [iso-8859-1] Sun May 11 15:04:47 2008
> @@ -382,11 +382,10 @@
> DPRINT ("Media change detected!\n");
> DPRINT ("Device %p\n", DeviceExt->StorageDevice);
>
> + /* Find the device to verify and reset the thread field to empty value again. */
> DeviceToVerify = IoGetDeviceToVerify (PsGetCurrentThread ());
> -
> - IoSetDeviceToVerify (PsGetCurrentThread (),
> - NULL);
> - Status = IoVerifyVolume (DeviceExt->StorageDevice,
> + IoSetDeviceToVerify (PsGetCurrentThread (), NULL);
> + Status = IoVerifyVolume (DeviceToVerify,
> FALSE);
> }
> if (!NT_SUCCESS(Status))
>
>
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
Hello ROS dev-team,
i am currently working on qemu/kqemu and found that ROS sets the gdt
limit to 0x800. At least this is what i see in qemu, i did not check
ROS source.
http://www.intel.com/design/processor/manuals/253668.pdf (3.5.1 p. 3-21)
>> the GDT limit should always be one less than an integral multiple of
>> eight (that is, 8N – 1)
This may or may not be a problem.
For all i can say ROS was the only of many different OSs that triggered
the check in my setup. I may be wrong and wont investigate this any
further. Just wanted to let you know.
I used this version:
http://prdownloads.sourceforge.net/reactos/ReactOS-0.3.4-REL-qemu.zip
and that are the values i saw:
base = 0x808bdac0
limit = 0x00000800
regards,
Henning
Hi Team,
I came across this site: http://www.acc.umu.se/~bosse/
which has some windows drivers examples, and talks about filesystem
drivers, it has a gnu version of ntifs.h (http://www.acc.umu.se/~bosse/ntifs.h), I've taken a look at it, and
noticed that ours misses some defines and some definitions use other types instead of
ours. I thought perhaps someone from the team would want to take a look
at it, perhaps we could use it.
Thanks.
Best regards,
Gabriel ilardi.
PS: If you already knew about it please ignore this email.
_________________________________________________________________
Racconta le tue emozioni sul blog!
http://home.services.spaces.live.com/
Fireball, could you commit the bug writing guidelignes change to avoid this, please ?
*saying Pleaase ... Help as Milla Jovovitch in the Fifth Element*
Kind regards,Sylvain Petreolle (aka Usurp)
Support artists, not multinationals - http://Iwouldntsteal.net
Supportez les artistes, pas les multinationales - http://Iwouldntsteal.net
----- Message d'origine ----
> De : "ReactOS.Bugzilla(a)www.reactos.org" <ReactOS.Bugzilla(a)www.reactos.org>
> À : ros-bugs(a)reactos.org
> Envoyé le : Samedi, 12 Avril 2008, 22h08mn 14s
> Objet : [ros-bugs] [Bug 3177] New: I try ReactOS-0.3.4-QEMU. When i try screensaver it gives bluescreen
>
> http://www.reactos.org/bugzilla/show_bug.cgi?id=3177
>
> Summary: I try ReactOS-0.3.4-QEMU. When i try screensaver it
> gives bluescreen
> Product: ReactOS
> Version: 0.3.4
> Platform: QEmu
> OS/Version: Microsoft Windows XP
> Status: UNCONFIRMED
> Severity: normal
> Priority: P3
> Component: Win32
> AssignedTo: ros-bugs(a)reactos.org
> ReportedBy: maviates(a)gmail.com
> QAContact: ros-bugs(a)reactos.org
>
>
> Created an attachment (id=2431)
> --> (http://www.reactos.org/bugzilla/attachment.cgi?id=2431)
> BlueScreen
>
> I try ReactOS-0.3.4-QEMU. When i try screensaver it gives bluescreen
>
>
> --
> 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.
> You are the assignee for the bug.
> _______________________________________________
> Ros-bugs mailing list
> Ros-bugs(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-bugs
>
I thought those are on auto-winesync, aren't they? If you come to agreement
with Herve, I don't mind.
But anyway, Apostolos should submit those translation updates to Wine
project.
WBR,
Aleksey Bragin.
----- Original Message -----
From: <cfinck(a)svn.reactos.org>
To: <ros-diffs(a)reactos.org>
Sent: Friday, April 11, 2008 1:00 AM
Subject: [ros-diffs] [cfinck] 32909: Manually sync "comctl32" and "comdlg32"
on request of Apostolos Alexiadis. Just translation updates
> Author: cfinck
> Date: Thu Apr 10 16:00:16 2008
> New Revision: 32909
>
> URL: http://svn.reactos.org/svn/reactos?rev=32909&view=rev
> Log:
> Manually sync "comctl32" and "comdlg32" on request of Apostolos Alexiadis.
> Just translation updates
>
> Modified:
> trunk/reactos/dll/win32/comctl32/comctl_El.rc
> trunk/reactos/dll/win32/comctl32/comctl_Si.rc
> trunk/reactos/dll/win32/comdlg32/cdlg_El.rc
> trunk/reactos/dll/win32/comdlg32/cdlg_No.rc
> trunk/reactos/dll/win32/comdlg32/cdlg_Si.rc
I looked at the ReactOS website and noticed that you guys are having
problems getting an installer written for an ext2 driver for Windows XP? I
would be happy to write an NSIS-based installer for the ext2 driver, if
either someone could compile the driver for me, or tell me where the driver
is in the ReactOS tree so I can build it myself and create an installer for
it. I have written NSIS installers before, some that have advanced
functionalities using Component Manager and ExperienceUI. Please let me know
if you guys would like me to make this installer....
I am currently trying to clean up our win32k headers.
The situation so far:
- ntgdi.h in psdk which should be compatible to ms version of ntgdi.h
from the sdk
- ntgdytyp.h containing a bunch of gdi related types in
include/reactos/win32k
- ntgdihdl.h containing handle related types and macros in
include/reactos/win32k
- ntgdibad.h containing private and ms incompatible functions and
structures in include/reactos/win32k
- ntuser.h containing ntuser functions and types in include/reactos/win32k
- ntusertyp.h containing ntuser related types in include/reactos/win32k
- W32CLIENTINFO is defined in both ntusertyp.h and ntgdityp.h (less
complete).
- there is the PATRECT structure in ntuser.h, and if ntuser.h is not
included, also in ntgdityp.h, this should be named POLYPATBLT as defined
in ntgdi.h, but there is only an incomplete type without the structure
definition. (IMO ms should have put this structure into wingdi.h
together with PolyPatBlt, but they don't seem to want anyone use that
gdi32 exported function.)
I wonder why ms put ntgdi.h into the sdk at all, as it's completely
useless to user mode application writers, but well, ncie to have the
prototypes ;-)
So how do we clean up this mess?
Suggestions:
- when ms puts ntgdi.h into the sdk, we could also put ntuser.h there.
- if we want to stay 100% compatible with sdk headers, we can add a
define, like
#ifdef USE_NON_SDK
// put non sdk compatible but still windows compatible definitions here
#endif
- use a version definition, like I did with the simplecall definitions
in ntuser.h to make it compatible to different windows versions
- keep ntgdibad.h and create ntuserbad.h for incompatible definitions
- ntgdihdl.h is used by win32k and gdi32, both also import ntgdityp.h.
So I'd suggest merging that stuff into ntgdityp.h
- maybe merge types into ntgdi.h and ntuser.h? Some definitions are
already in there.
- create win32ktypes.h and put ntuser/ntgdi shared stuff there, like
W32CLIENTINFO
- maybe add POLYPATBLT and PolyPatBlt() (others?) to wingdi.h inside
USE_NON_SDK ifdef plus a POLYPATBLT_DEFINED
I don't think it's a problem to make our sdk headers more complete than
ms ones. This might help if we don't want a header mess or extra
definitions inside the .c files.
Comments appreciated.
Thanks,
Timo
Hi!
Thank you Timo, I can not believe I missed this one....
This fixes a commit back at rev 14041.
With out starting a review in real world history,, once an enemy gains
control the first thing they do is erase history. New eras evolve and
build on top of old ones. Our old world ruins are a good example. Look
at Cuzco, Greece and Rome. You see them now uncovering the past.
Thanks again!
James
SepCreateSystemProcessToken calls ObCreateObject like this:
Status = ObCreateObject(KernelMode,
SepTokenObjectType,
NULL,
KernelMode,
NULL,
sizeof(TOKEN),
0,
0,
(PVOID*)&AccessToken);
the ObjectAttributes parameter is set to NULL,and ObCreateObject passes
ObjectAttributes to call ObpCaptureObjectAttributes like this:
Status = ObpCaptureObjectAttributes(ObjectAttributes,
ProbeMode,
FALSE,
ObjectCreateInfo,
&ObjectName);
and in ObpCaptureObjectAttributes ,there's a check condition that checks if
ObjectAttributes is NULL, if ObjectAttributes is NULL,it will cause
ObpCaptureObjectAttributes fail,and then cause ObCreateObject fail,then
cause SepCreateSystemProcessToken fail,and the return value of
SepCreateSystemProcessToken will ever be NULL.
Could someone explain why???am i wrong??