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
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))
>
>
