I've been using the Winetests in Windows quite a lot recently, both XP and
Vista, and I've noticed that a lot of the tests fail in Windows.
For anyone using the Winetests in reactos to fix our code, it's worth
testing if these functions pass or fail in Windows first as we might be
breaking reactos to pass the winetests.
Also, one of the problems I've noticed is that some tests fail on XP but
pass in Vista, and vice versa.
Does anyone know Wine's target OS? It seems that more tests are passing in
Vista than XP these days, so maybe they've moved to a more recent target?
I think the best way to move forward with this is to find out what version
Wine target, fix any broken tests we come across and submit them to Wine.
I don't envisage any problem with Wine accepting fixed test cases, even from
the most hated of reactos devs.
Anyway, I just wanted to make people aware, _don't blindly trust Winetests
when fixing reactos_
Ged.
If you are going to do more work on rbuild, I'd suggest doing it in a
branch to avoid clean rebuilds every few revisions.
Timo
hyperion(a)svn.reactos.org schrieb:
> Author: hyperion
> Date: Mon Jan 26 08:26:15 2009
> New Revision: 39111
>
> URL: http://svn.reactos.org/svn/reactos?rev=39111&view=rev
> Log:
> Begin moving rules out of modulehandler.cpp and into makefile include rules.mak, where they will be more readable and manageable. Currently implemented: target C compiler and target C++ compiler rules. Please do a clean build if possible. Testing with unusual output paths appreciated
>
>
Hi,
The TEB in psdk/winternl.h does not match with the correct one in
ndk/pstypes.h. Does anyone else see that as a problem or is it just
me? If it is for wine, then it is wrong, need to implement it as it is
in the SDK. Use it for the Tls fields only......
Thanks,
James
A general remark for this revision and r39033.
FsRtlNotifyInitializeSync and CcInitializeCacheMap both raise exception in case of failure, instead of returning a status. Should we consider adding PSEH support and usage to the new driver?
P. Schweitzer
> Date: Fri, 23 Jan 2009 12:18:39 +0000
> To: ros-diffs(a)reactos.org
> From: pschweitzer(a)svn.reactos.org
> Subject: [ros-diffs] [pschweitzer] 39040: Added notifications stuff to VCB
>
> Author: pschweitzer
> Date: Fri Jan 23 06:18:38 2009
> New Revision: 39040
>
> URL: http://svn.reactos.org/svn/reactos?rev=39040&view=rev
> Log:
> Added notifications stuff to VCB
>
> Modified:
> trunk/reactos/drivers/filesystems/fastfat_new/fat.c
> trunk/reactos/drivers/filesystems/fastfat_new/fatstruc.h
>
_________________________________________________________________
Téléphonez gratuitement à tous vos proches avec Windows Live Messenger ! Téléchargez-le maintenant !
http://www.windowslive.fr/messenger/1.asp
Hi,
I am working on a project to parse the Windows image file. To do that,
I must understand the structure of some Windows components, like
_EPROCESS. So I took some headers from ReactOS, and write *userland*
code like below:
----
#include <pstypes.h>
#include <stdio.h>
int main()
{
printf("size of EPROCESS: %d\n", sizeof(struct _EPROCESS));
return 0;
}
----
The I got the problem: g++ reported that _EPROCESS is incomplete.
Clearly this means it doesnt see the structure _EPROCESS, so I took a
closer look, and found that _EPROCESS is not defined in user-mode
(NTOS_MODE_USER). I tried to fix it by putting
#undef NTOS_MODE_USER
in front of #include <pstypes>, but that doesnt help.
Anybody please tell me if there is any way to fix this?
I think I can fix that by modifying the original headers. but that is
way too ugly.
Many thanks,
Jun
sginsberg(a)svn.reactos.org wrote:
> Author: sginsberg
> Date: Sun Jan 18 17:31:26 2009
> New Revision: 38922
>
> URL: http://svn.reactos.org/svn/reactos?rev=38922&view=rev
> Log:
> - Fix more InterlockedCompareExchangePointer warnings in crypt32 -- this to Wine, too
>
> Added:
> trunk/reactos/dll/win32/crypt32/warningfixes.diff
This is a bad idea.
It's painful enough keeping wine libs in sync without adding to the complexity with non-needed warning fixes.
Ged.
hyperion(a)svn.reactos.org schrieb:
> Author: hyperion
> Date: Sun Jan 18 00:25:43 2009
> New Revision: 38872
>
>
...
> Introduce new define __ROS_LONG64__ ("assume 64-bit long"), to use int instead of long in typedefs of 32-bit integers
> __ROS_LONG64__ automatically defined if __WINESRC__ is defined. No, __WINESRC__ alone is not enough
>
If it's defined automatically, why isn't __WINESRC__ alone enough? And
when it's not enough anyway, why define __ROS_LONG64__ automatically at
all?
...
> #else /* !_WIN64 */
> +#if !defined(__ROS_LONG64__)
> typedef int INT_PTR, *PINT_PTR;
> typedef unsigned int UINT_PTR, *PUINT_PTR;
> +#else
> +typedef long INT_PTR, *PINT_PTR;
> +typedef unsigned long UINT_PTR, *PUINT_PTR;
> +#endif
>
If we assume a 64bit long, why define INT_PTR to long on 32 bit target?
> From: Hauke Goos-Habermann <HHabermann(a)pc-kiel.de>
> Date: January 12, 2009 4:53:40 PM GMT+03:00
> To: aleksey(a)reactos.org
> Subject: ReactOS booth/speech at Linux days in Kiel?
>
> Hi Aleksey,
>
> for the Linux days in Kiel in Germany we are searching for
> interesting OSS
> projects. Can you tell me if there are members of ReactOS that may be
> interested in a booth or/and giving a presentation? The "Kieler
> Linux- und
> -OpenSource Tage" will be at 2nd and 3rd of october.
>
> Additional information (in German only) can be found at: www.kieler-
> linuxtage.de
>
> PS. Please forward the mail to interested members.
>
> Cu Hauke
>
> --
>
> Stoppt Softwarepatente, sonst wird Softwareentwicklung in Europa
> für die meisten
> illegal!
> Patentfrei sichert IT-Arbeitsplätze (www.patentfrei.de)
> Sorry I didn't quite get it. ;-) What is ok atm? How are we going to
> handle it?
Extern inline is ok atm. ;-)
I mean that it works well now. And when its behavior will be changed,
gnu_inline attribute can be used to get old (i.e., present) behavior.
> Well that was a workaround, because of "static declaration follows non
> static declaration".
> Then it needs to be done differently. But I don't see any good solution
> that doesn't require lot's of hacks atm, except disabling that warning.
It's ok atm. Attribute gnu_inline can be used to get old inline semantics.
Hi All!
Just letting everyone know that a partial fix has been found by Dmitry
aka Lentin, it is Dmitry? Well, I updated the bug report and the patch
works to a point. FF does try to minimize and there is a hook bug
exposed. Yes, not everything is fixed, since we use wine code, this
was the reason for the patch. It corrects most of the message bugs
related to wine tests. So this patch is going in soon and we need to
cleanup the related code. I have a synced User32 Mdi.c that might
require this patch to work. Just about the rest of the changes needed
are wine sync/ports to user32/win32k. I would hope that everyone can
help Dmitry/Lentin out and fix the rest of the SetWindowPos bugs. Some
window position code in User32 still needing to be updated.. ;^)
Thanks,
James
Ref:
http://www.reactos.org/bugzilla/show_bug.cgi?id=2451
There's a constant for this INVALID_HANDLE_VALUE...
On 10-Jan-09, at 7:33 AM, dchapyshev(a)svn.reactos.org wrote:
> case 0xFFFFFFFF: /* File does not exist */
Best regards,
Alex Ionescu
Hi!
Why to use extern inline there, FORCEINLINE macro uses static. Extern
inline — GCC extension — does not work as needed in c99/gnu99 mode
(non-inline functions are emitted as well). GCC documentation says it
will be the default in the future.
Since Arty just mentioned GIT, I think it's about time to uncover a
ReactOS GIT mirror I've been setting up recent couple of weeks.
It works pretty good so far, autoupdates every 10 minutes, so it
stays quite up-to-date.
URLs:
git://git.reactos.org/ - for git cloning.
http://git.reactos.org - for web viewing.
As for branches, it was actually my main intention in using a DVCS,
because SVN branches are greatly uncomfortable to develop anything
because of the need to keep the branch up-to-date.
But, to prevent any gossips, SVN stays as our main repository, and
GIT mirror is just for exploration of new possibilities, and for
comfortability of working with branches - if someone wants to try
that out. Usual SVN branches are still permitted.
WBR,
Aleksey Bragin.
Hello,
I recently spent some time experimenting with various Cc rewrites we
have in our tree, and before that I extensively tested our fastfat
driver in a real NT environment (MS Windows 2003).
The conclusion of the above work is that our fastfat driver either
needs serious bugfixing, or a rewrite is needed. It corrupts
directory tables in a real NT, leads to unusual behaviour of cc-
rewrite branch, and may have side effects on arty's newcc.
Before this is done (bugfixing or rewriting, developing and testing
against a Windows 2003 at least, not ReactOS), it's meaningless to
continue any other work on Cc and related Mm parts.
WBR,
Aleksey Bragin.
Hi all!
Here is the test program provided by BugBoy. It also shows another
bug, see bug 3971. Please test before and after the patch.
Thanks,
James
PS
Good Job, Michael!