If GetWindowsDirectory fails, you have much worse issues to worry
about than executable redirection.
Also note that regedt32.exe is usually in the system32 directory, so
how is this a security/redirection issue exactly?
This implies someone would have to:
1) Give you a malware regedit.exe in directory foo
2) Give you the legitimate regedt32.exe in directory foo
3) Somehow convince you to:
3.1) Use regedt32 instead of regedit (few people even know this tool)
3.2) Launch regedt32 from this "foo" directory instead of using
start/run regedt32
The issue you're looking for just doesn't exist.
2008/5/19 FENG Yu Ning <fengyuning1984(a)gmail.com>:
> On Sun, May 18, 2008 at 7:28 PM, Alex Ionescu <ionucu(a)videotron.ca> wrote:
>>
>> Last nitpick: if you can't get the windows directory, just
>> ShellExecute "regedit.exe" directly, as the code originally did --
>> this is the behavior on Windows, fyi.
>>
>
> Though it is the behavior on Windows, it is a bad thing, IMHO. There are
> already too many little viruses who pretend to be a system executable, say,
> explorer.exe, and they are placed in a (sub)directory of the windows
> directory to be shell executed. If we can't get the windows direcoty, we
> should let the user know, and give them the chance to fix it, instead of
> blindly execute anything.
> I used to suffer from those, and they were really annoying. Please consider
> being different from Windows in this and similar issues.
> MHO.
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
--
Best regards,
Alex Ionescu
--
Best regards,
Alex Ionescu
Hi,
I warn you guys about the menu code, so far everything looks okay.
Fireball: "guys, dlls/win32k/user32/menu.c" "line 240" "it HeapFrees
ItemInfo->dwTypeData" "but who HEapAllocates it?!", Answer the Q.
MenuGetRosMenuItemInfo does.... Please understand I worked my ass off
back on 0.3.0? to fix the mess in user32 menu. Please Think before you
Code. Have a list of test apps to make sure it does work like YOU
think it should. Wine is not enough!.
Thanks,
James
As a ReactOS-User I thoght sometimes, which is better: ReactOS or Linux with WINE.
WINE is much more mature and can also run Windows 3.11 programs.
But ReactOS - on the other side - is more Windows-like. It is a complete Operating System like Windows. And the applications for ReactOS can also be running in binary form on Windows and are not Linux-/Unix-native applications which are additional compiled against a winelib.dll.
On the ReactOS-side stand the everyone known text
"ReactOS aims to achieve complete binary compatibility with both applications and device drivers meant for NT and XP operating systems, by using a similar architecture and providing a complete and equivalent public interface."
That is one of the differences to WINE: Being also driver-compatibe to XP.
But thats also a point, where I ask myself, how much sense this make.
Windows NT could run a lot of Windows 95/98 programs. Windows XP could run most Windows NT, Windows 9x and Windows 3.x programs. Windows Vista runs not all but some of the Windows XP and Windows NT programs.
But on the driver side, Windows XP could only some Windows NT driver (like printer-driver).
As I read for some time, for Windows Vista existing lesser driver then for Linux. So, it seems not, that Vista could use some of the plenty of Windows XP driver.
Also Vista existing as 32bit and 64bit. And the 64bit system can not use 32bit driver.
Follower of Vista (for example Windows 7) will only be existing as 64bit system.
So, you want to be driver-compatibe to Windows. But Windows will itself not be drivercompatibe to older or newer versions.
I have read anywhere in the Internet, that it is planned, that in newer Windows-versions only driver can be used and installed, which are trustable. And only Microsoft dicide, which drivers are trustable and which not. And driver-creator have ro pay on Microsoft that they make the drivers authorized/trustable.
This makes it also more senseless to be driver-compatibe to Windows.
But ReactOS have the advantage, that it looks and feels in all areas like Windows. And you can run Windows-programs on it. That is really an advantage of ReactOS.
Possible ReactOS would be anytime cooperate with DeviceVM ( the company behind SplashTop http://www.splashtop.com/index.php ) . Because it is possible, that there are people who would prefer an Windows/ReactOS system which starts fast on an RAM instead of an Linux-System.
In the new Newsletter (#41) of ReactOS stands, that Steven Edwards comes back to interact again between ReactOS and WINE.
Thats a very good news. Hopefully all the WINE-developers see ReactOS in some time as legal and use again ReactOS-code for WINE, so that ReactOS and WINE could again more cooperate.
There are still some developer (like GvG and others) who have left ReactOS and thought, that ReactOS isn't legal in USA-laws. I still think, that it is a big problem, that there are some ex-developer of ReactOS and some WINE-developer, who beliefs, that ReactOS is illegal. A more intensive dialog with this people is needed I think.
Greatings
theuserbl
_________________________________________________________________
Die aktuelle Frühjahrsmode - Preise vergleichen bei MSN Shopping
http://shopping.msn.de/category/damenbekleidung/bcatid66/forsale?text=categ…
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