[ros-dev] Let's push winetests farther!

[Jérôme Gardou]

As you all know, reactos is tested against the wine test suite. While 
this is a great tool, I think this is not enough to be sure that ReactOS 
is fully tested.


I've been trying to fix some kernel32 tests. As you all know, in ReactOS 
it is written on top of ntdll. So I wanted to fix some tests, and then a 
question arose : is it that kernel32 calls ntdll the wrong way, or is it 
that ntdll does the wrong job? The only way to verify this would be to 
test kernel32.dll out of reactOS, meaning replacing the windows one with 
the reactos one, and run the test.


To be brief : I think that a weekly "reactos dlls against windows" test 
would be very helpful to be sure that things are done the right way!


I began with the kernel32:file winetest. I managed to not make it crash 
when used on winXP, the resulting patch is there : 
http://www.reactos.org/bugzilla/show_bug.cgi?id=4728 and the result of 
this test is attached there. As miracles happen, it also fixes some 
tests on ReactOS. Seems like this is a good approach.


Jérôme Gardou (aka zefklop on IRC and forums)

file.c:583: Test failed: failed to open source file
file.c:585: Test failed: WriteFile error 6
file.c:587: Test failed: source file has wrong size
file.c:590: Test failed: GetFileTime error 6
file.c:593: Test failed: SetFileTime error 6
file.c:602: Test failed: CopyFileA: unexpected error 5
file.c:606: Test failed: CopyFileA: error 5
file.c:610: Test failed: failed to open destination file
file.c:612: Test failed: destination file has wrong size -1
file.c:616: Test failed: GetFileTime error 6
file.c:617: Test failed: destination file has wrong filetime
file.c:621: Test failed: CopyFileA: ret = 0, unexpected error 5
file.c:626: Test failed: destination file has wrong size -1
file.c:628: Test failed: ReadFile: error 6
file.c:630: Test failed: buffer contents mismatch
file.c:634: Test failed: DeleteFileA: error 5
file.c:636: Test failed: DeleteFileA: error 5
file.c:662: Test failed: CopyFileW: unexpected error 5
file.c:666: Test failed: CopyFileW: error 5
file.c:669: Test failed: DeleteFileW: error 5
file.c:671: Test failed: DeleteFileW: error 5
file.c:747: Test failed: CREATE_NEW should fail if file exists and last error 
value should be ERROR_FILE_EXISTS
file.c:753: Test failed: hFile , last error 5
file.c:761: Test failed: hFile , last error 5
file.c:767: Test failed: DeleteFileA: error 5
file.c:772: Test failed: hFile , last error 5
file.c:778: Test failed: DeleteFileA: error 5
file.c:791: Test failed: Createdirectory failed, gle=183
file.c:827: Tests skipped: Either no authority to volume, or is todo_wine for 
C:\WINDOWS\TEMP\ err=5 should be 3
file.c:829: Tests skipped: Do not have authority to access volumes. Test for 
C:\WINDOWS\TEMP\ skipped
file.c:827: Tests skipped: Either no authority to volume, or is todo_wine for 
C:\WINDOWS\TEMP\removeme\ err=5 should be 3
file.c:829: Tests skipped: Do not have authority to access volumes. Test for C: 
skipped
file.c:827: Tests skipped: Either no authority to volume, or is todo_wine for 
C:\ err=5 should be 3
file.c:829: Tests skipped: Do not have authority to access volumes. Test for 
C:\ skipped
file.c:829: Tests skipped: Do not have authority to access volumes. Test for 
\\?\C: skipped
file.c:827: Tests skipped: Either no authority to volume, or is todo_wine for 
\\?\C:\ err=5 should be 3
file.c:851: Test failed: RemoveDirectoryA: error 87
file.c:879: Tests skipped: Probable Win9x, got ERROR_PATH_NOT_FOUND w/ 
FILE_FLAG_BACKUP_SEMANTICS or C:\WINDOWS\TEMP\
file.c:964: Tests skipped: Do not have authority to access volumes. Tests 
skipped
file.c:974: Test failed: GetVolumeNameForVolumeMountPointA failed, for C:\, 
last error=5
file.c:1053: Tests skipped: GetVolumeNameForVolumeMountPointA not functioning
file.c:1084: Test failed: CREATE_NEW should fail if file exists and last error 
value should be ERROR_FILE_EXISTS
file.c:1090: Test failed: hFile , last error 5
file.c:1098: Test failed: hFile , last error 5
file.c:1104: Test failed: DeleteFileW: error 5
file.c:1109: Test failed: hFile , last error 5
file.c:1115: Test failed: DeleteFileW: error 5
file.c:1138: Test failed: couldn't create temporary directory
file.c:1145: Test failed: DeleteFileW: error 87
file.c:1240: Test failed: couldn't create directory deletefile
file.c:1244: Test failed: expected to remove directory deletefile
file.c:1248: Test failed: couldn't create directory deletefile
file.c:1250: Test failed: couldn't create directory deletefile\sub
file.c:1254: Test failed: expected to remove directory deletefile\sub
file.c:1256: Test failed: expected to remove directory deletefile
file.c:1279: Test failed: MoveFileA: unexpected error 5
file.c:1283: Test failed: DeleteFileA: error 5
file.c:1290: Test failed: CreateDirectoryA failed
file.c:1298: Test failed: MoveFileA: with wildcards, unexpected error 6
file.c:1325: Test failed: DeleteFileA: error 5
file.c:

Re: [ros-dev] Let's push winetests farther!

[Jérôme Gardou]

I do get this error too, but that does not stop me from doing some 
tests. What I did was to recompile kernel32 as kernel32_test and link 
the winetest to it instead of kernel32, and launch it in winXP. This 
sounds really dirty as it is, but gave me good result. The fixed tests 
on reactos side was a mistake.

Timo Kreuzer wrote:
> Hi,
>
> Some dlls cannot be properly tested on Window. These are:
>
> ntdll: it uses direct systemcalls and the system call numbers would 
> need to match the windows system you test it on. If you are very lucky 
> you could find one version of win2k3 that matches our syscalls, but I 
> wouldn't bet on that.
>
> kernel32: it's communication with csrss is not Windows compatible. We 
> would have to fix (rewrite) our csrss, something that would requite 
> lots of work. And noone loves csrss. (We accept patches. ;-))
>
> gdi32: It loads and partly works on Windows XP, as the handle manager 
> win32k syscall numbers are now mostly XP compatible. I'm not sure 
> whether this is still true, as there were some changes recently and I 
> don't know on what Windows version those were based. But the winetest 
> results are a desaster, it even fails CreateDC.
>
> user32: Doesn't work, for a lot of reasons. user32 is a major user of 
> kernel<->usermode shared data. Our data structures are not anywhere 
> like Windows ones and probably will never be 100%. Same for the handle 
> manager. Also incompatible is communication with csrss again and 
> several syscalls that are incompatible to Windows. And finally we 
> don't (didn't?) properly initialize the kernel callbacks, making it 
> crash on systemcalls.That may actually be fixed by Jim's recent commits.
>
> Btw: what are the results you sent? kernel32 on windows XP? I wonder 
> how you managed to get any console output as that wouldn't work with 
> our kernel32 on Windows. For me it doesn't load, even with your patch. 
> WinDbg shows the following debug message:
>
> "output-i386\modules\rostests\winetests\kernel32\kernel32.dll 
> (dll\win32\kernel32\misc\dllmain.c:203) CSR Failed to give us a console"
>
> So I guess you made a mistake ;-)
>
> Regards,
> Timo
>
> Jérôme Gardou wrote:
>> As you all know, reactos is tested against the wine test suite. While 
>> this is a great tool, I think this is not enough to be sure that 
>> ReactOS is fully tested.
>>
>> I've been trying to fix some kernel32 tests. As you all know, in 
>> ReactOS it is written on top of ntdll. So I wanted to fix some tests, 
>> and then a question arose : is it that kernel32 calls ntdll the wrong 
>> way, or is it that ntdll does the wrong job? The only way to verify 
>> this would be to test kernel32.dll out of reactOS, meaning replacing 
>> the windows one with the reactos one, and run the test.
>>
>> To be brief : I think that a weekly "reactos dlls against windows" 
>> test would be very helpful to be sure that things are done the right 
>> way!
>>
>> I began with the kernel32:file winetest. I managed to not make it 
>> crash when used on winXP, the resulting patch is there : 
>> http://www.reactos.org/bugzilla/show_bug.cgi?id=4728 and the result 
>> of this test is attached there. As miracles happen, it also fixes 
>> some tests on ReactOS. Seems like this is a good approach.
>>
>> Jérôme Gardou (aka zefklop on IRC and forums)
>>
>> 
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>
> 
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Let's push winetests farther!

[Jérôme Gardou]

I think I should explain more precisely what I want to do :
My goal is to make all kernel32:file winetests pass. What I plan to do 
is : getting the current implementation pass this tests on winXP. I 
don't really care if the stuff made to avoid crashes is not applied, but 
the functional cahnges should, IMO, get into trunk. Currently, there are 
120+ tests that don't pass. The goal is to get this number to 0.

As a side effect, it *might* make more tests pass in reactOS, although I 
expect the number of failures to increase. Once it is done, as making 
ntdll work on winXP/2003 would require too much work, I plan to use the 
native winXP fat driver in reactOS, and fix ntoskrnl to get them right. 
(whether reactOS will boot with it is another story, and fixes for that 
would be very positive IMO)

Final step would be to fix the fastfat driver...
Regards
Jérôme Gardou (aka zefklop)

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Wanting to work on ddraw.

[Jérôme Gardou]

Olaf Siejka a écrit :
> As for the proxy, you could try using java based freenode web client: 
> http://java.freenode.net/
>
> Using irc would give you a communication edge, quite important in 
> early stages of development.
Thanks for the tip, but it doesn't work :-(
> As our previous ReactX developer, GreatLord - is away from the project 
> indefinitely, you might be forced to arrange things all by yourself. 
> You should speak with Fireball about your plans. Also, the people you 
> might want to stay in touch are: jimtabor, tkreuzer (win32 subsys) and 
> Pigglesworth (wined3d, opengl).
>
Unfortunately, I'll have to stay on the ML, and send patches to 
bugzilla. Here is a first one, I'm waiting for your comments :-)
http://www.reactos.org/bugzilla/show_bug.cgi?id=4862


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[ros-dev] Wanting to work on ddraw.

[Jérôme Gardou]

Hi everybody.

It's been a long time that I follow this project, even if I was pretty 
quiet, and I think it is now time to make my own contribution.
Some of you might remind some attempts to work on kernel32 winetests., 
and it turned out that I needed something more motivational. I found 
that reactX is an abandoned field, and so I think that it would be a 
real challenge to get things working. I have already some patches, which 
get the ddraw initialization a bit further that where it manages to go 
in trunk.

Regards
Jérôme (aka zefklop)

PS: I'd like to talk with you about that on IRC, but unfortunately I am 
behind  proxy which refuses it


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Wanting to work on ddraw.

[Jérôme Gardou]

Hi everybody.

I just wanted to tell you that even if I was silent for quite some time 
now, I'm still working on this, even more now than RL has calmed down. I 
have begun working on the user side of ddraw. Currently, I implemented 
IDirectDraw:CreatePalette (needs testing!) and almost all 
ddraw->refcount winetests pass when using it on winXP.
Patch is on bugzilla : http://www.reactos.org/bugzilla/show_bug.cgi?id=4909

Regards
Jérôme


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Arwinss presentation

[Jérôme Gardou]

Could this be pushed to write a rosd3d driver? Take all d3d dlls from 
wine and write a wined3d compatible dll?
Also, users could make a choice between wine and ReactOS implementation...

Marius Przybylski wrote:
> What are the disadvantages to using ARWINSS as Win32 subsystem ?
>
> "Entry level is rather low" - What are the requirements for Arwinss developer 
> ?
>
>
>
> - Marius Przybylski
>
>
>
>
>
> Dnia 16 stycznia 2010 22:44 Aleksey Bragin  napisał(a):
>

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Arwinss presentation

[Jérôme Gardou]

Because there still exists some features of D3D that OpenGL has not or 
that some manufacturers implement in their D3D drivers but not in their 
opengl ICD.

The funny side of it is that I use wineD3D on my laptop, because intel 
drivers suck!
Jérôme.

Kamil Horníček a écrit :
> What would be the advantage of such an approach? We now use only Wine DX
> libs anyway and wined3d seems to do its job just fine.
> This would go directly against the whole arwinss idea = use tested and known
> to work code from Wine and only spend valuable dev time on parts that are
> reactos specific.
>
> Kamil
>


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] RosBE 1.5 Release Candidates

[Jérôme Gardou]

Here is what I get when typing 'make kernel32' :

[LD]   output-i386/dll/win32/kernel32/kernel32.dll
/usr/local/RosBE/i386/lib/gcc/mingw32/4.4.3/libgcc.a(_enable_execute_stack.o): 
In function `_enable_execute_stack':
/home/jeje/Downloads/RosBE-Unix-1.5-RC2/sources/gcc-
build/mingw32/libgcc/../../../gcc/libgcc/../gcc/libgcc2.c:2038: 
undefined reference to `abort'
make: *** [output-i386/dll/win32/kernel32/kernel32.dll] Error 1

This is on fedora 12 64 bits.

Regards
Jérôme.



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Roadmap I'm sticking to

[Jérôme Gardou]

You seem to forget that linux is just the kernel. They let the graphics 
side to X.org/Xfree, the shell to KDE/Gnome, the C library to GNU, 
etc... You can't really compare ReactOS and Linux!


Peter Millerchip wrote:

Ged - I actually agree with everything you're saying! However, I see
it as a "do what you want" ethic - I'll explain inline below:

On 9 April 2010 12:45, Ged Murphy  wrote:
   

Basically, there's many branches, stable and experimental, and many teams to
look after these branches. These people are experts in the areas which their
branch targets, e.g. scheduler, memory manager, etc.
 

Yes, these people are "doing what they want" in that they maintain a
branch which is of interest to them. These branches started because
someone would say "you know, I want to improve Linux's memory manager,
that's my kind of fun", and they just did it in a branch. Nobody told
them to, nobody held a big meeting and assigned this task to them -
they just did it because they wanted to.

   

All patches, no matter which branch you send it to, goes through various
stages. If it's irrelevant it gets dumped straight away. If it's deemed
relevant then it's heavily vetted by various members of the team, usually
argued about and modified, then added to that particular branch.
 

You're of course totally right here. People who are "doing what they
want" in their own branch will not want to accept bad quality patches
from people - and why should they? This branch is their "fun thing"
and they don't want it ruined. Because the maintainer feels like that
branch is "theirs", it makes for good code quality.

   

It's also worth considering that whatever makes it into each release of the
official kernel is then taken by distros and modified again, sometimes parts
are removed, sometimes replaced and sometimes improved.
 

Exactly! People do what they want. Distro maintainers may have a
different focus than upstream (for example, Debian with their
packaging and legal policies), and so they are quite free to make
changes. This is good! Because distro maintainers are able to do what
they want, they are more happy doing it and their work is higher
quality. Competition with different distros gives them further
incentive to do good work.

   

The chances of you "working on whatever you want" and getting it into the
mainline linux tree are virtually zero.
 

This is true, but not really relevant to this discussion because
that's only due to Linux's greater size. The point is that when Linux
was the size of ReactOS, Linus Torvalds did not try to get a team to
agree on what to do - he just went ahead and did it. We can learn from
what Linus did when Linux was as small as we are.

   

You really can't compare reactos to linux. Linux has a _vast_ number of
developers and testers, we have about 10.
 

Sure you can! ReactOS and Linux are directly comparable because
they're both open source operating systems. Linux's management style
seems to work well and so we can certainly talk about whether it would
work for us and move the project forwards.

Pete.

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


   



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Build process changes...

[Jérôme Gardou]

I already have "ported" an autotools project to cmake, so I might 
help there. The big plus of cmake is that it is documented(tm) 
and that we don't have to care of its maintenance. Also, with 
good macros, adding a dll to the build might be as simple as 
"REACTOS_ADD_DLL(gdi32)" into a txt file.

Le mercredi 16 juin 2010 17:53:13, Timo Kreuzer a écrit :
> Timo Kreuzer schrieb:
> > Make a little now.
> 
> Uhm.. ? No I dea what I wanted to say. Just ignore this 
sentence ;-)
> 
> 
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Re : Removing the autoregister feature from rbuild

[Jérôme Gardou]

What about making the relink depend on the modification of the 
spec file?

Le mercredi 16 juin 2010 21:59:31, Timo Kreuzer a écrit :
> Sylvain Petreolle wrote:
> > I fully agree on this.
> > This will also remove the need to rebuild the dll (and possibly 
other
> > dependant modules) if we have to disable a registration for
> > testing/debugging purposes.
> 
> Speaking of dlls and dependencies: I think our current approach 
(all
> modules depend on the dlls it links) is retarded. A clean rebuild 
of
> ntdll leads to a massive relink orgy. I suggest to use libraries 
from
> RosBE by default. To make sure we have all exports we ever 
need, we
> should build our own import libraries with all exports for all 
windows
> versions. We could begin with an rbuild switch that tells 
whether to use
> the import lib from reactos or from RosBE. another approach 
would be to
> seperate the dll target from the import library target, so that 
remake
> ntdll will not cause the import library to be rebuild. another 
problem I
> see with the current dependencies is that you can't remove 
some modules
> from the build because other modules depend on it.
> 
> Regards,
> Timo
> 
> 
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [dreimer] 48036: Bug 5501: [PATCH] Adding Wing32support by Carlo Bramini

[Jérôme Gardou]

Alphabetical reordering ?

Aleksey Bragin wrote:


What's that massive reactos.dff change introduced with this rev?

--
From: 
Sent: Wednesday, July 14, 2010 2:59 PM
To: 
Subject: [ros-diffs] [dreimer] 48036: Bug 5501: [PATCH] Adding 
Wing32support by Carlo Bramini



Author: dreimer
Date: Wed Jul 14 10:59:32 2010
New Revision: 48036

URL: http://svn.reactos.org/svn/reactos?rev=48036&view=rev
Log:
Bug 5501: [PATCH] Adding Wing32 support by Carlo Bramini

Added:
   trunk/reactos/dll/win32/wing32/
   trunk/reactos/dll/win32/wing32/wing32.c   (with props)
   trunk/reactos/dll/win32/wing32/wing32.rbuild   (with props)
   trunk/reactos/dll/win32/wing32/wing32.spec   (with props)
Modified:
   trunk/reactos/boot/bootdata/packages/reactos.dff
   trunk/reactos/dll/win32/win32.rbuild




___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev





___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [akhaldi] 48236: Create a branch for cmake bringup.

[Jérôme Gardou]

wasn't there already a branch for that task?

Zachary Gorden wrote:
I also support a reshuffling of the directories, but not in the cmake 
branch.  Let that be used JUST for getting cmake up and running and 
if/once that is merged into trunk, then we look into changing the 
structure.  Best not to complicate one task by adding more to it.



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Tree restructure

[Jérôme Gardou]

I’d much prefer to go to the audio directory to work on everything from
portcls.sys up to mmsys.cpl. Things could be committed together instead
of separately forcing 2 separate builds on buildbot
 

Yes, but imagine someone who's going to work on Control Panel Applets, e.g.
a UI person (if we had one), who would need to work with all CPLs in the
system. He would need to find them throughout whole tree, ask in ros-dev ML
if he missed any and abandon his idea soon after starting.

   

Isn't it possible to do hard links with svn, git or whatever?

So as in your example, mmsys.cpl would be located in the audio sub tree, 
and hardlinked to the UI/cpl directory.


All modern filesystems support hard links, that wouldn't suprise me if 
modern version control systems would do the same.


What do you think?

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Tree restructure

[Jérôme Gardou]

And here is what I said.
http://svnbook.red-bean.com/en/1.0/ch07s03.html

Jérôme Gardou wrote:




I’d much prefer to go to the audio directory to work on everything from
portcls.sys up to mmsys.cpl. Things could be committed together instead
of separately forcing 2 separate builds on buildbot
Yes, but imagine someone who's going to work on Control Panel 
Applets, e.g.

a UI person (if we had one), who would need to work with all CPLs in the
system. He would need to find them throughout whole tree, ask in 
ros-dev ML

if he missed any and abandon his idea soon after starting.


Isn't it possible to do hard links with svn, git or whatever?

So as in your example, mmsys.cpl would be located in the audio sub 
tree, and hardlinked to the UI/cpl directory.


All modern filesystems support hard links, that wouldn't suprise me if 
modern version control systems would do the same.


What do you think?

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev





___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 48359: [WIN32K] - Rewrite NtGdiGetDIBitsInternal, with WINE as a reference. - Get back DIB Section creation to classic BITMAPINFO. This si the beginnig of the end f

[Jérôme Gardou]

That's why I began to revert all of this stuff, which is horrible :-)
Regards.
Jérôme.

James Tabor wrote:

Hi!

BitmapCoreInfo !Should Be! handled in Gdi32 and converted there! The
latest BitmapInfo "must be" handled in win32k. So not get it confused.
James

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


   



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [akhaldi] 48236: Create a branch forcmake bringup.

[Jérôme Gardou]

Having a proper build system and a good tree structure is a mandatory 
step to work efficiently. As long as we have neither of them, it is a 
priority.

That's just my opinion, though...

Gabriel ilardi wrote:
I think that the tree reshuffle should be done separately from the 
cmake branch. I also agree with Ged that it isn't very logical, so 
from this point of view I support the tree restructure.
On the other hand ReactOS is in a really bad shape form a user point 
of view and all the resources should focus on fix the most important 
bugs and regressions listed in http://www.reactos.org/wiki/Buglist. 
The rest of the things
is of a minor importance to me. We can't do everything at the same 
time, we should focus and things of major importance at the moment.

Just my 2 cents.

Gabriel.




___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 48359: [WIN32K] - Rewrite NtGdiGetDIBitsInternal, with WINE as a reference. - Get back DIB Section creation to classic BITMAPINFO. This si the beginnig of the end f

[Jérôme Gardou]

Timo Kreuzer wrote:

Jérôme Gardou schrieb:
   

That's why I began to revert all of this stuff, which is horrible :-)
 

While I completely agree on removing BITMAPCOREHEADER support, I don't
really like other parts.

- Probing the BITMAPINFO and then passing the usermode buffer to the
internal and unprotected function is not enough. The buffer must be copied.
   

OK, it's safer this way.

- The BITMAPV5HEADER is only ~120 bytes and only used once per function
call, so putting the safe buffer on the stack is appropriate. The buffer
needs be large enough for V5 anyway, so why not fixup some values and
make it a full V5 header?
   
No, all values added by V4/V5 headers are for ICM. If there is only a 
BITMAPINFOHEADER there, then we don't have to care about ICM. If we 
"convert" it to a V5 header, all values will be 0, that's not worth the 
effort.

- The ProbeAndConvert function was added to simplify the code and move
all code that handles the small differences into one central place
instead of having a bunch of if (size>  bla) checks in multiple places
just to check whether I can or can not access some member of the
BITMAPINFO or where to get the color masks from. With the conversion all
of the internal code can work the same simple way assuming a full
BITMAPV5INFO is available.
   
The only "effort" to make here is to take care of where the color buffer 
is : bmi + bmi->bmiHeader.biSize and not bmi->bmiColors. Then check in 
some functions if we have a V4/V5 header to take care of the features 
they have. If we're good enough, we'll just need to call 
DIB_CreateDIBSection, and work with this bitmap created here. That's 
what I did in NtGdiStretchBitmapInternal, NtGdiGetDIBits and 
IntGdiSetDIBits. The major problem is to get the palette created properly.

- When support for BITMAPCOREHEADER gets removed the code become much
less "horrible"
   

Agree.

Timo

   

Jérôme.

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 48465: [WIN32K] - Rewrite NtGdiStretchDIBitsInternal : clearer, faster, stronger (+1 wine test)

[Jérôme Gardou]

Le vendredi 06 août 2010 19:03:57, Timo Kreuzer a écrit :
> Hi,
> 
> Please take care about proper protection of the user mode buffer. The
> current solution: probe and forget is not safe.
> 
> Possibilities are:
> 1) SEH protected copying of the buffer, pass the copy of the buffer to
> lower level functions -> Easy to do, large overhead for large bitmaps.
> 2) SEH protected call to a lower level function, passing the user mode
> buffer. -> Not possible if the lower level function is either allocating
> any resources (unless also protected by SEH + finally) or can pass
> execution to 3rd party provided code, like drivers.
> 3) Be sure to have SEH at the lowest level (DIB) -> Not possible as the
> function might end up in a driver.
> 4) Use Mm to protect the buffer. Either with MmSecureVirtualMemory or
> double mapping using MmProbeAndLockPages + MmGetSystemAddressForMdlSafe.
> 
> I think 4 is the way to go. While the overhead of remapping should be
> relatively small compared to a full copy, we are still wasting large
> ammounts of system address space.
> MmSecureVirtualMemory might at first sound like a good solution, but
> beware, it has some pitfalls. While it protects a memory range from
> being freed, it doesn't protect it from being paged out. That wouldn't
> be a problem, unless the memory is not backed by the page file, but let
> say a network resource, which becomes unavailable after a page was paged
> out. In this case we would get an in page error when trying to access
> the page, leading to a kernel crash. So unless we can be sure that the
> memory is backed by the page file, we need to additionally lock the
> pages into memory to be safe. Final thing to note is that
> MmSecureVirtualMemory is not implemented yet, but I hope with current
> work on the VAD code, we'll soon get a present (hint).
> 
> Regards,
> Timo
> 
I'm OK for 4. Looking for MmSecureVirtualMemory to be implemented.
Please note that for now, SURFACE::hSecure is hacked to be (HANDLE)1 so we can 
detect if the bitmap is a DIB. As now all **DIB** functions create a DIB, it 
will be securised in the process. Others bits can be PSEH-accessed during the 
DIB creation, as it the only place it's used.

Regards.
Jérôme.

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 49281: [PSDK] - Add MIDL_user_allocate and MIDL_user_free definitions - #ifdef a GCC hack

[Jérôme Gardou]

good, tell WINE then :-/

Timo Kreuzer wrote:

Am 26.10.2010 18:01, schrieb jgar...@svn.reactos.org:
   

+#ifdef __GCC__
  /* Note: this should return a CLIENT_CALL_RETURN, but calling convention for
   * returning structures/unions is different between Windows and gcc on i386. 
*/
  LONG_PTR RPC_VAR_ENTRY
@@ -659,6 +663,13 @@
NdrAsyncClientCall( PMIDL_STUB_DESC pStubDescriptor, PFORMAT_STRING 
pFormat, ... );
  LONG_PTR RPC_VAR_ENTRY
NdrDcomAsyncClientCall( PMIDL_STUB_DESC pStubDescriptor, PFORMAT_STRING 
pFormat, ... );
+#else
+CLIENT_CALL_RETURN RPC_VAR_ENTRY NdrClientCall2(
+  PMIDL_STUB_DESC pStubDescriptor,
+  PFORMAT_STRING pFormat,
+  ...
+);
+#endif

 

Is this hack even neccessary? I couldn't see any difference between gcc
and msvc with the correct prototype.
Both return the result in eax.


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


   



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Networking

[Jérôme Gardou]

As someone who's regularly behind an unfriendly proxy, I have to agree.

Ged Murphy wrote:


Aaggh!!! Why is everything always done over IRC

The neglection of the reactos mailing lists is one of this _/big/_ 
things this project does wrong.


- It forces the community into a sort of hidden niche group and 
alienates people who don’t use IRC


- It gives the impression that reactos activity is low. There are 
thousands of people who follow this project aren’t on IRC and have no 
idea of what is going on.


- It arguably deters new people from joining because they can’t really 
get to grips with the project without becoming a slave to IRC


- It means important discussions are missed, even by the core team, if 
they aren’t watching the IRC chat 24/7 or miss a PM


I could go on and on with reasons of why you neglect the mailing lists 
is so harmful, but I fear no one will listen to my cries.


Maybe I should vent my frustration in IRC for the niche community, and 
we can all have an internal discussion about it???


Ged.

*From:* ros-dev-boun...@reactos.org 
[mailto:ros-dev-boun...@reactos.org] *On Behalf Of *Aleksey Bragin

*Sent:* 27 October 2010 13:54
*To:* ReactOS Development List
*Subject:* Re: [ros-dev] Networking

Yes, please feel free to join our channel when you have any questions. 
I will create a branch for your coming work, if you like.


Thanks!

WBR,

Aleksey.

On Oct 27, 2010, at 2:47 PM, Olaf Siejka wrote:



Hiya

Discussing issues on ros-dev maillist is fine. I asked Aleksiej to 
pass you the irc channel discussion mostly for helping you out with 
basic ROS stuff like compilation, VM setup and testing issues.


Regards

2010/10/27 Oleg Baikalow >


Hi,

I see you're busy discussing other stuff and my message went unnoticed 
:) I made a look to existing network branches, found many of them. 
LWIP is interesting. Alexey said the best way is to join your irc 
channel. I will try to occasionally join, but in your project, mailing 
list must be a primary point of discussion not irc channel.


I think I start from making a simple, but robust tcpip driver (with 
help of numerously available source code of tcp/ip protocol 
implementations). Hopefully you could give me branch access, it's 
gonna be hard to develop it with patches.


// Oleg Baikalow.

P.S. I really like your "kernel coding style", quite rare to see that 
in opensource projects. Most of foss projects utilize linux-alike 
stlye, whic is harder to read and not that clean.



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[ros-dev] Static - dynamic generation of reactos.dff

[Jérôme Gardou]

Hi reactos developers.

As many of you know, the cmake branch development is going along and is 
the occasion of many innovations in the way reactos is built.


One of this way is the reactos.dff file. Currently, it is a static file, 
meaning that each time you want to add a module to reactos, you have to 
edit this file. What I propose is to create this file dynamically, when 
parsing the build system file. Adding a reactos module twould then be as 
simple as (!) creating a new build file for this module.


For those who are concerned about slipstreaming or optional files like 
wallpapers or whatever hacking they do with the current reactos.dff, it 
will be as easy as before. There will be a file to edit, which will be 
the "static" part of it. Whatever you'll write in this file will be 
written back to reactos.dff, so there is no need to worry about that.


What do you think?

Regards.
Jérôme.

PS : The patch is there. It waits for your approval :-)

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Static - dynamic generation of reactos.dff

[Jérôme Gardou]

As long as they are included in the build system, they will be added to 
reactos.dff. If they're not, they won't ever be mentioned.


Ged Murphy wrote:

how does this work for rosapps and other such optional inclusions?

2010/10/30 Jérôme Gardou <mailto:jerome.gar...@laposte.net>>


Hi reactos developers.

As many of you know, the cmake branch development is going along
and is the occasion of many innovations in the way reactos is built.

One of this way is the reactos.dff file. Currently, it is a static
file, meaning that each time you want to add a module to reactos,
you have to edit this file. What I propose is to create this file
dynamically, when parsing the build system file. Adding a reactos
module twould then be as simple as (!) creating a new build file
for this module.

For those who are concerned about slipstreaming or optional files
like wallpapers or whatever hacking they do with the current
reactos.dff, it will be as easy as before. There will be a file to
edit, which will be the "static" part of it. Whatever you'll write
in this file will be written back to reactos.dff, so there is no
need to worry about that.

What do you think?

Regards.
Jérôme.

PS : The patch is there. It waits for your approval :-)

___
Ros-dev mailing list
Ros-dev@reactos.org <mailto:Ros-dev@reactos.org>
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Please revert changes to ClassPnp in CMAKE Branch

[Jérôme Gardou]

OK, I'll revert that.

Hey, how did this work?

Ros Arm wrote:

Hello,

The jgardou changes add thousands of whitespace changes which make it extremely 
hard to understand what is going on. Please to not arbitrarily change 
whitespace across 18 files in a patch!

Also, there is nothing wrong with the way ClassPNP was defined before. If you think "How on 
Earth did this work in trunk?", as quoted from the commit log, maybe you should ask others 
"Hey, how did this work?".

Please revert the changes and come ask how it worked, I'll be happy to help.

-r

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


   



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 49396: [CMAKE] - put ntdll.def in source files

[Jérôme Gardou]

This should work now. Thanks for reporting.

Ged Murphy wrote:

I've just tried to build the cmake branch for the first time and hit the 
following error :


-- xmllite has no base address
-- win32csr has no base address
-- Configuring done
CMake Error in dll/ntdll/CMakeLists.txt:
   Cannot find source file "ntdll.def".  Tried extensions .c .C .c++ .cc .cpp
   .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx



Reverting the changes in this revision fixed it.
I know nothing about cmake, but this change appears to have broken the build?

Ged.



-Original Message-
From: ros-diffs-boun...@reactos.org [mailto:ros-diffs-boun...@reactos.org] On 
Behalf Of jgar...@svn.reactos.org
Sent: 01 November 2010 09:32
To: ros-di...@reactos.org
Subject: [ros-diffs] [jgardou] 49396: [CMAKE] - put ntdll.def in source files

Author: jgardou
Date: Mon Nov  1 09:32:04 2010
New Revision: 49396

URL: http://svn.reactos.org/svn/reactos?rev=49396&view=rev
Log:
[CMAKE]
   - put ntdll.def in source files

Modified:
 branches/cmake-bringup/dll/ntdll/CMakeLists.txt

Modified: branches/cmake-bringup/dll/ntdll/CMakeLists.txt
URL: 
http://svn.reactos.org/svn/reactos/branches/cmake-bringup/dll/ntdll/CMakeLists.txt?rev=49396&r1=49395&r2=49396&view=diff
==
--- branches/cmake-bringup/dll/ntdll/CMakeLists.txt [iso-8859-1] (original)
+++ branches/cmake-bringup/dll/ntdll/CMakeLists.txt [iso-8859-1] Mon Nov  1 
09:32:04 2010
@@ -21,10 +21,8 @@
  rtl/libsupp.c
  rtl/version.c
  def/ntdll.rc
-def/ntdll.def)
+${CMAKE_CURRENT_BINARY_DIR}/def/ntdll.def)

-set_source_files_properties(def/ntdll.def PROPERTIES EXTERNAL_OBJECT TRUE)
-
  if(ARCH MATCHES i386)
  list(APPEND SOURCE dispatch/i386/dispatch.S)
  elseif(ARCH MATCHES amd64)
@@ -48,7 +46,6 @@
  endif()

  target_link_libraries(ntdll
-${CMAKE_CURRENT_BINARY_DIR}/def/ntdll.def
ntdllsys
libcntpr
pseh)



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


   



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[ros-dev] ReactOS official compatibility target and the new build system

[Jérôme Gardou]

Dear reactos developers.

Once again, bringing reactos build to cmake arises questions. When this 
"port" has begun, it was decided that import libraries would be shipped 
with build environment, the now famous RosBE.


This decision was made considering that :
1) functions exported by dlls do not change often.
2) Building an import library is a process that requires unneeded 
extra time.

3) 1 makes 2 unworthy.
4) If dll A imports function from dll B, it's not necessary to 
build B before A.

5) Solving 4 solves the problem of cross-dependency.

As our target is win2k3 sp1 compatibility, a wise choice would be to 
choose import libraries that expose function only present on win2k3 sp1. 
The problem is that some wine dlls export functions that are from other 
windows versions, and, worse, use them.

Let's see why this is a problem.
- function A is a vista function from dll foo
- function B is an XP function from dll bar
- for some reasons, B implementation calls A.
As you're clever developers ;-), you've seen that this would raise an 
error from the linker, as A is not present in our libfoo.a


Hopefully, those cases are not too widespread, but they exist.

Let's consider solutions that have arisen as of now :
1) Implement A as an inline function in headers, so anyone 
requiring it has it.
2) Linking bar.dll to some winefoo.dll, which forwards everything 
from foo.dll and exports the function A.
3) Add a "#if WIN32_WINNT > 0x502" before the guilty part of code, 
and "#else" with a win2k3 compliant implementation.
4) Oh dreams -> Ideally, convince wine to do it themself 
(./configure --wintarget=2k3sp1).

5) Change our target to win7, so we're ahead of wine. :-p
6) Do not change anything, and let our user mode libraries be a 
complete inconsistent anarchy.


As 4 and 5 won't happen in a short time, let's consider 1, 2, 3 and 6:
1 is the best solution for easy winesyncs. We guard inline 
implementation by #ifndef BUILDING_FOO_DLL
2 would put a whole mess in system32 directory, but should be the 
most easy thing to do.
3 requires some extra work when syncing wine dlls. Though doing it 
often would reduce hassle.

6 isn't what I'd wish.

What do you think? Your input is much appreciated.
Best regards.
The french speaking cmake team :-)

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS official compatibility target and the new build system

[Jérôme Gardou]

This policy is inconsistent with the fact that we advertise reactos as 
win2k3 sp1. Otherwise we should as well provide a config applet to let 
the user choose that, as wine does.


Le 13/11/2010 03:10, Ged Murphy a écrit :
The target is only win2k3 in the kernel. Everything else is open to 
discussion (in fact, IMO even the kernel compatibility is open to 
discussion)


You should, and must, provide as much functionality as possible with 
the latest versions of Windows.
You can still provide many of the capabilities of Windows 7 using only 
an NT5.2 kernel. It's only the internal architecture which limits 
this, and in terms of many win7 capabilities, this kernel isn't a 
limiting factor.


2010/11/13 Jérôme Gardou <mailto:jerome.gar...@laposte.net>>



As our target is win2k3 sp1 compatibility,


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS official compatibility target and the new build system

[Jérôme Gardou]

Then let's have a kernelbase.dll, as win7 does.

Le 13/11/2010 12:16, Timo Kreuzer a écrit :


I have thought about the multiple Windows version thing some time ago
and had some ideas.
One idea is to Reorganize the functionality, similar to the way it's
done in Windows 7.
some of the win32 dlls would become wrapper dlls and forwarding to the
actual implementations. These wrapper dlls would be tiny and we could
have different sets of wrapper dlls for different windows versions. They
might also forward to different implementations of the same api on
different versions if required. This could be done on runtime, with
something similar to sxs, only user configurable rather than manifest based.

So instead of importing the vista function RegDeleteTree from
kernel32.dll a wine dll would import it from something like
API-ROS-Core-Registry.dll

This way we could as well cleanup our dependency tree and layout stuff
more window 7 alike


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev




___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS official compatibility target and the new build system

[Jérôme Gardou]

So, for kernel we keep our own importibs, adding exports one after the 
other while we implement them, and for user mode dlls we keep win7 
compatible ones?


We need an official stance on this matter.

Le 13/11/2010 03:10, Ged Murphy a écrit :
The target is only win2k3 in the kernel. Everything else is open to 
discussion (in fact, IMO even the kernel compatibility is open to 
discussion)


You should, and must, provide as much functionality as possible with 
the latest versions of Windows.
You can still provide many of the capabilities of Windows 7 using only 
an NT5.2 kernel. It's only the internal architecture which limits 
this, and in terms of many win7 capabilities, this kernel isn't a 
limiting factor.


2010/11/13 Jérôme Gardou <mailto:jerome.gar...@laposte.net>>



As our target is win2k3 sp1 compatibility,


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS official compatibility target and the new build system

[Jérôme Gardou]

Imagine an even worse written application :
fptr = GetProcAdress(hDll, "SomeVistaExport");
if(fptr)
Vista = TRUE;

I know at least one application that does it, and this is... wine tests!

Le 13/11/2010 19:41, Colin Finck a écrit :


Ged Murphy  wrote:

Usermode should and does report as NT5.2.
It actually doesn't have a choice as the APIs which you use in usermode
to discover the version (GetVersionEx, VerifyVersionInfo) actually query
hardcoded values stored in the kernel.


Sure, but you don't consider the example I've given (VMware Tools 
Installer).
We were already reporting ReactOS as NT 5.2 at that time, but 
obviously the installer just queried the msvcrt.dll version to 
determine its features. And when finding out that it's 42.4.0.0, it 
consequently expected Vista features we were missing.


What I want to say is that we cannot just report ReactOS as NT 5.2 
through the common version functions, but also need to ensure that the 
DLLs have the same versions as their NT 5.2 counterparts.
And when this has been changed, adding APIs of newer Windows versions 
(like wcsncpy_s) would hardly make any sense if we don't need them to 
please some Wine-synced DLLs using newer APIs.



Colin

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev




___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Getting a Windows Server 2003 license for the project?

[Jérôme Gardou]

I for one, only have a winXP pro license on which I do my tests.

Le 14/01/2011 16:46, Colin Finck a écrit :


Hi everybody,

I've been thinking about getting a license of an English Windows 
Server 2003 Standard 32-Bit for the project.


It could be installed on one of our servers and be made available over 
RDP. This would enable project members to do development and testing 
work on our actual target platform. Considering that some developers 
even use a non-Windows platform for development work, it might 
simplify their work as well.


We may as well use the license for other purposes (Buildslave, 
Testslave, whatever), but at least native building could be done by 
any Windows version. And in this case, I might be able to donate an XP 
Pro license myself (German though).


As I don't know about the needs of the other members, I'd like to hear 
your opinion about my idea. It would also be nice to hear if anybody 
knows a cheap (but legal!) way to get such a license or can even 
donate one (e.g. unused OEM license shipped with a server, unused 
license after getting Server 2008, etc.)
English Windows licenses are rare/expensive on German eBay, so this 
would only be a last resort :-)


Cheers,

Colin


P.S.: If you have the opposite problem and actually need a Linux VM 
available over SSH/RDP (e.g. for testing build system changes), just 
let me know and I could set it up.


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [tkreuzer] 50942: [WIN32K] Do raster operation on 4 bytes instead of only 3. Fixes ... maybe noone has noticed yet ; -)

[Jérôme Gardou]

Colin Finck a écrit :


tkreu...@svn.reactos.org wrote:
> Do raster operation on 4 bytes instead of only 3.

Quoting jgardou's commit before:
>   - When applying raster operation, do so only on 24 bits, we don't
> support alpha channel in win32k

I have no idea about DIB code, but just from the commit message I 
presume that this change to 24 bits has happened deliberately.



- Colin

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



You broke VLC icons in 32bpp


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 50991: [NTOSKRNL] - Print supported CPU features. - Simplify detection of non working but claimed SYSENTER support for intel processors - Workaround a virtualbox "f

[Jérôme Gardou]

Official intel documentation :
http://www.intel.com/Assets/PDF/appnote/241618.pdf, page 30.

As to know how it's made on windows, well, I hope they follow intel docs ;-)

Le 07/03/2011 21:49, Aleksey Bragin a écrit :



On Mar 7, 2011, at 4:33 PM, jgar...@svn.reactos.org wrote:


Author: jgardou
 /* Check if the CPU is too old to support SYSENTER */
-if ((Prcb->CpuType < 6) ||
-((Prcb->CpuType == 6) && (Prcb->CpuStep < 0x0303)))
+if ((Reg[0] & 0x0FFF3FFF) < 0x0633)
 {
It was intentionally done over CpuType and CpuStep. Now you criptified 
it back to a raw Reg[0] value and weird hardcoded constant. Could you 
please 1) elaborate this change and 2) if you still think it's 
correct, and if you still tihnk(!) Windows does it same way, then 
rework it to use Prcb->Cpu* instead of these magic values?


Not to say adding a hack for VirtualBox is far from being a beautiful, 
and would need to be *at least* marked so that it's not forgotten.


Thanks,
Aleksey Bragin.

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Meeting on Thursday

[Jérôme Gardou]

Unfortunately, I won't be able to make it either. By the way, even if my 
late activity is hindered by life schedule being quite erratic, could I 
request the honor of being considered as a ReactOS team member.


I'm looking forward the results of this meeting.

Best regards.
Jérôme.

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[ros-dev] Fwd: [NOTEPAD] Patch by Edijs Kolesnikovics: Write default font, weight and point...

[Jérôme Gardou]

SaveDword(hKey, _T("iPointSize"),   Globals.lfFont.lfHeight);

shouldn't it be

SaveDword(hKey, _T("iPointSize"), 
PointSizeFromHeight(Globals.lfFont.lfHeight));


Also, this would permit to simplify code a bit :-)

http://cia.vc/stats/project/ReactOS/.message/3522f92


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] 52061 [jgardou] [CMAKE], "According to gcc doc, if header.h is precompiled, the output should be named "header.h.gch" and not anything else.", Knowing it was the first step before actual

[Jérôme Gardou]

no, _basename is with .h here.

as for the other problem, it's the case. For now gcc falls back to using 
non precompiled header. But I have other plans, this is just a quick and 
dirty little thing.

cmake team will have some patches to deal with in weeks to come :-)

Le 02/06/2011 22:42, Colin Finck a écrit :


jgar...@svn.reactos.org wrote:
> -  set(_gch_filename "${_target_name}_${_FILE}.gch")
> +  set(_gch_filename "${_FILE}.gch")

Looks like we're going through the same mess of GNU precompiled 
headers, which we already had in rbuild:


1) Giving the GCH file a custom name.
   Problem: It is simply ignored in the build process.
2) Just renaming it to the name of the header file.
   Problem: If two modules use the same header file with different
   build options (like #defines), the compiler can only choose one
   precompiled header and we have a corrupted build.

The solution now is to give every GCH file an individual directory 
whose name contains the module name (like ".gch_smlib", this is what 
we currently have in rbuild).


Concluding from what I see in rbuild, please also note that the GCH 
file needs to be named "header.h.gch", not "header.gch". Your 
${basename} variable sounds like this is not done either in the CMake 
branch.



- Colin

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev





___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] 1296 [dreimer] Get the cmake path from a system variable called _ROSBE_CMAKEPATH. Hard coding is eeevul!

[Jérôme Gardou]

Fact is that we currently use the bleeding edge fersion of cmake, and we 
may be ahead of it. And it's not that big actually.


Le 03/06/2011 00:01, Zachary Gorden a écrit :
I object highly to the idea of bundling cmake with the BE.  Most 
platforms already have binaries built of cmake, either by the distro 
or for Windows, the people who make cmake provide an installer.  We 
provide the compilers and linkers and we provided rbuild because it 
was our own thing, but cmake is not and has its own environment.


On Thu, Jun 2, 2011 at 4:53 PM, Colin Finck > wrote:


drei...@svn.reactos.org  wrote:
> Get the cmake path from a system variable called _ROSBE_CMAKEPATH.

I hope we're not thinking about requiring the user to install
RosBE and CMake separately.
This would pretty much kill the point of RosBE if people are
forced to get random versions of their build tools from multiple
sources again..


- Colin

___
Ros-dev mailing list
Ros-dev@reactos.org 
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] 1296 [dreimer] Get the cmake path from a system variable called _ROSBE_CMAKEPATH. Hard coding is eeevul!

[Jérôme Gardou]

Guess what...

Cmake provides such a GUI

Le 03/06/2011 12:26, victor martinez a écrit :

I am agree with Colin.
The idea of having a Build Environment is not just to make the life 
easier to our devs, but also to have ISOs which we can compare.
If the Environment doesnt bundle *ALL* the tools, then we can have 
devs/testers with different Tools combinations...it can lead to break 
walls with our head.
Also we should try to do the compilation as easier as possible, why 
not creating RosBE 2.0 with GUI frontend? :3



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 52339: [NTOSKRNL] - don't rely on a boolean being 1 or 0, it's a bad idea (tm)

[Jérôme Gardou]

Well, just try this snippet of code in VS 2010, and tell me what you see 
as result :-)

BOOLEAN is what it is : a typedef to BYTE.
PS : no fancy optimization option or whatever

// test_boolean.cpp : définit le point d'entrée pour l'application console.
//

#include 
#include 
#include 

using namespace std;

BOOLEAN test0x10(int i)
{
return i & 0x10;
}


int _tmain(int argc, _TCHAR* argv[])
{
if(test0x10(0x10) == 1)
cout << "Alex Ionescu is right" << endl;
else if(test0x10(0x10))
cout << "Sometimes Alex Ionescu is wrong" << endl;
else
cout << "Unexpected behaviour!!!" << endl;

return 0;
}


Le 18/06/2011 17:22, Alex Ionescu a écrit :

Or rather

1 ? 1 : 0

(just as retarded).

Of course a BOOLEAN is 0 or 1!!!

Best regards,
Alex Ionescu



On Sat, Jun 18, 2011 at 4:22 PM, Alex Ionescu  wrote:

???

This is retarded.

You're doing

0 ? 0 : 1

Best regards,
Alex Ionescu



On Sat, Jun 18, 2011 at 3:45 PM,  wrote:

Author: jgardou
Date: Sat Jun 18 14:45:08 2011
New Revision: 52339

URL: http://svn.reactos.org/svn/reactos?rev=52339&view=rev
Log:
[NTOSKRNL]
  - don't rely on a boolean being 1 or 0, it's a bad idea (tm)

Modified:
trunk/reactos/ntoskrnl/ke/i386/traphdlr.c

Modified: trunk/reactos/ntoskrnl/ke/i386/traphdlr.c
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/traphdlr.c?rev=52339&r1=52338&r2=52339&view=diff
==
--- trunk/reactos/ntoskrnl/ke/i386/traphdlr.c [iso-8859-1] (original)
+++ trunk/reactos/ntoskrnl/ke/i386/traphdlr.c [iso-8859-1] Sat Jun 18 14:45:08 
2011
@@ -1510,7 +1510,7 @@

 /* Set thread fields */
 Thread->TrapFrame = TrapFrame;
-Thread->PreviousMode = KiUserTrap(TrapFrame);
+Thread->PreviousMode = KiUserTrap(TrapFrame) ? UserMode : KernelMode;

 /* Enable interrupts */
 _enable();




___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 52339: [NTOSKRNL] - don't rely on a boolean being 1 or 0, it's a bad idea (tm)

[Jérôme Gardou]

I'm not confonding anything, I just consider that calling a function 
which returns a BOOLEAN expecting it will return 0 or 1 is a bad idea, 
because someone might have written the exact same function I've shown 
you as an example.

As a general rule, consider something true when it's not false :-).

Le 19/06/2011 15:29, Alex Ionescu a écrit :

This is a completely different issue. You're confusing bitmask math
with BOOLEAN.

Best regards,
Alex Ionescu



2011/6/19 Jérôme Gardou:

Well, just try this snippet of code in VS 2010, and tell me what you see as
result :-)
BOOLEAN is what it is : a typedef to BYTE.
PS : no fancy optimization option or whatever

// test_boolean.cpp : définit le point d'entrée pour l'application console.
//

#include
#include
#include

using namespace std;

BOOLEAN test0x10(int i)
{
return i&  0x10;
}


int _tmain(int argc, _TCHAR* argv[])
{
if(test0x10(0x10) == 1)
cout<<  "Alex Ionescu is right"<<  endl;
else if(test0x10(0x10))
cout<<  "Sometimes Alex Ionescu is wrong"<<  endl;
else
cout<<  "Unexpected behaviour!!!"<<  endl;

return 0;
}


Le 18/06/2011 17:22, Alex Ionescu a écrit :

Or rather

1 ? 1 : 0

(just as retarded).

Of course a BOOLEAN is 0 or 1!!!

Best regards,
Alex Ionescu



On Sat, Jun 18, 2011 at 4:22 PM, Alex Ionescuwrote:

???

This is retarded.

You're doing

0 ? 0 : 1

Best regards,
Alex Ionescu



On Sat, Jun 18, 2011 at 3:45 PM,wrote:

Author: jgardou
Date: Sat Jun 18 14:45:08 2011
New Revision: 52339

URL: http://svn.reactos.org/svn/reactos?rev=52339&view=rev
Log:
[NTOSKRNL]
  - don't rely on a boolean being 1 or 0, it's a bad idea (tm)

Modified:
trunk/reactos/ntoskrnl/ke/i386/traphdlr.c

Modified: trunk/reactos/ntoskrnl/ke/i386/traphdlr.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/traphdlr.c?rev=52339&r1=52338&r2=52339&view=diff

==
--- trunk/reactos/ntoskrnl/ke/i386/traphdlr.c [iso-8859-1] (original)
+++ trunk/reactos/ntoskrnl/ke/i386/traphdlr.c [iso-8859-1] Sat Jun 18
14:45:08 2011
@@ -1510,7 +1510,7 @@

 /* Set thread fields */
 Thread->TrapFrame = TrapFrame;
-Thread->PreviousMode = KiUserTrap(TrapFrame);
+Thread->PreviousMode = KiUserTrap(TrapFrame) ? UserMode :
KernelMode;

 /* Enable interrupts */
 _enable();




___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Monthly meeting reminder

[Jérôme Gardou]

Hi!

I'll gladly participate this time. By the way, can I be added to te list?

Regards.
Jérôme.

Le 26/06/2011 19:56, Aleksey Bragin a écrit :
Colin, thanks for providing all required information and setting up 
the irc server. Just a small correction - the list of allowed 
participants now includes Alex Ionescu.


Yes, I beg my pardon about the time, the meeting is going to take 
place at 19:00 UTC. Don't forget to update your calendars!


Updated agenda:
1. Cmake switching
2. New release of ReactOS
3. Website work status
4. GSoC status
5. Developers status.

I don't think we should add more topics, otherwise meeting will take 
too much time. (e.g. DLL wine sync questions could be solved during 
"new release" discussion).


WBR,
Aleksey.

On Jun 26, 2011, at 5:23 PM, Colin Finck wrote:


Aleksey Bragin  wrote:
> Last thursday of this month is quite close, 30th of June, 20:00 UTC

We have voted to begin all further meetings at 19:00 UTC in the last 
meeting.




Colin said that our
private irc server is going to be ready by that date, so if that's 
still

true, Colin - could you please provide details for those who don't
remember where to connect?


Yes, the crash we experienced in March has been fixed, so we can use 
our own server with one-time passwords, logging, voting capabilities 
and without the possibility of netsplits again.


The meeting will be at irc://fezile.reactos.org (Port 6667, no SSL) 
in the channel #meeting.
Note that the IRC service will only be started shortly before the 
meeting.


Please take a look at the list of participants below and reply 
instantly if your name is missing. The list really matters this time 
as it is maintained in the IRC server and you won't get a one-time 
password if you're not on the list.
Observers can always join without being on the list, but not 
participate in the discussions and votings then.


I will wait for additional names till Wednesday before sending out 
the passwords.


Aleksey, please also address the recent inquiries about additional 
points on the meeting agenda and publish an updated agenda.



- Colin


List of participants
=
- Giannis Adamopoulos (smiley1_)
- Johannes Anderwald (janderwald)
- Javier Agustìn Fernàndez Arroyo (elhoir)
- Maciej Bialas (niski)
- Jan Blomqvist-Kinander (JaixBly)
- Aleksey Bragin (abragin)
- Thomas Faber (ThFabba)
- Colin Finck (Colin_Finck)
- Danny Götte (dangerground)
- Andrew Green (greeniekin)
- Cameron Gutman (aicom)
- Ziliang Guo (ZWabbit)
- Rafal Harabien (rafalh)
- Andrew Hill (ash77)
- Kamil Hornicek (Pigglesworth)
- Gabriel Ilardi (gabriel_it)
- Amine Khaldi (AmineKhaldi)
- Timo Kreuzer (tkreuzer)
- Matthias Kupfer (Collibri)
- Michael Martin (mjmartin)
- Victor Martinez (vicmarcal)
- Roel Messiant (Mephisto)
- Claudiu Mihail (KlausM)
- Andrew Munger (WaxDragon)
- Ged Murphy (GedMurphy)
- Sylvain Petreolle (Usurp)
- Hervé Poussineau (hpoussin)
- Daniel Reimer (dreimer)
- Pierre Schweitzer (HeisSpiter)
- Samuel Serapion (encoded)
- Olaf Siejka (Caemyr)
- James Tabor (jimtabor)
- Christoph von Wittich (Christoph_vW)
- Neeraj Yadav (neeraj_rct)
- Art Yerkes (arty)

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] cmake rant

[Jérôme Gardou]

+1 for Ged.

Le 21/07/2011 18:51, Ged Murphy a écrit :

I'm all for deleting rbuild now and dealing with the consequences.
That would be better than the current situation, which seems rather
ridiculous at the moment.

Right now if you change something, you have to :
- edit the cmakefiles.txt file
- edit the rbuild file
- possibly edit a pspec and spec file
- build with rbuild to check for breakages
- build with cmake to check for breakages

Only then can you commit your changes.
It's not ideal for the people working on this stuff regularly.

Ged.



-Original Message-
From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On
Behalf Of Timo Kreuzer
Sent: 21 July 2011 17:39
To: ReactOS Development List
Subject: [ros-dev] cmake rant

Hi,

Several times now cmake build has been broken. Time for some action!

Last meeting I asked everyone to test/use cmake. It was also mentioned that
if questions arise, we (Amine and me) would be happy to help out. I can't
remember anyone has asked how it works, so I assume noone had any problems.
There's also a pretty good wiki entry describing the whole procedure for
n00bs.

Now people tell me it's complicated, people are complaining that its
ridiculous to have 2 build systems, etc.
And probably noone has ever tried it.

We really need to move on.
I don't like having 2 build systems as well.

Current blocker is the debugging which has some issues, Arty is working on
that. Another problem is a boot problem on real hardware, but no I don't
know on which configuration it doesn't work, so we need more people testing
it on their real hardware setup and report any issues.

Here's a list with current issues:
http://www.reactos.org/wiki/CMake_Todo

So please:
If you are missing something, let us know.
If you like to make it better, make suggestions.
But stop ignoring cmake!

If noone cares and everyone just thinks he can give a s^Z damn until we
officially switch, then we can as well delete all cmake stuff and keep
rbuild. It has a lot of awesome advantages, like you only have to type one
command to build everything and you don't need to install cmake and you can
export whatever you want from kernel32 even if the functions don't exist.
Also you can enjoy the rbuild-loop again and again.

Or we can do it the hard way and delete rbuild, so people are forced to use
cmake. I'm sure this approach would be *really* appreaciated.

Thanks,
Timo


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 52840: [CRT] - get back atexit handling as it was before. (reverts 52838, 52829, 52828) Thanks to Kai and Timo for the explanation

[Jérôme Gardou]

Reverts 52836, 52829 and 52828, sorry.

Le 24/07/2011 18:45, jgar...@svn.reactos.org a écrit :

Author: jgardou
Date: Sun Jul 24 16:45:41 2011
New Revision: 52840

URL: http://svn.reactos.org/svn/reactos?rev=52840&view=rev
Log:
[CRT]
- get back atexit handling as it was before.
(reverts 52838, 52829, 52828)
Thanks to Kai and Timo for the explanation

Modified:
 trunk/reactos/dll/win32/msvcrt/msvcrt.spec
 trunk/reactos/dll/win32/msvcrt20/msvcrt20.spec
 trunk/reactos/dll/win32/msvcrt40/msvcrt40.spec
 trunk/reactos/lib/3rdparty/mingw/crtexe.c
 trunk/reactos/lib/3rdparty/mingw/mingw.rbuild
 trunk/reactos/lib/sdk/crt/msvcrtex.cmake
 trunk/reactos/lib/sdk/crt/startup/crtdll.c
 trunk/reactos/lib/sdk/crt/startup/crtexe.c

Modified: trunk/reactos/dll/win32/msvcrt/msvcrt.spec
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msvcrt/msvcrt.spec?rev=52840&r1=52839&r2=52840&view=diff
==
--- trunk/reactos/dll/win32/msvcrt/msvcrt.spec [iso-8859-1] (original)
+++ trunk/reactos/dll/win32/msvcrt/msvcrt.spec [iso-8859-1] Sun Jul 24 16:45:41 
2011
@@ -1156,7 +1156,7 @@
  @ cdecl asin(double)
  @ cdecl atan(double)
  @ cdecl atan2(double double)
-@ cdecl atexit(ptr)
+@ extern atexit #<-- keep this as an extern, thank you
  @ cdecl atof(str)
  @ cdecl atoi(str)
  @ cdecl atol(str)

Modified: trunk/reactos/dll/win32/msvcrt20/msvcrt20.spec
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msvcrt20/msvcrt20.spec?rev=52840&r1=52839&r2=52840&view=diff
==
--- trunk/reactos/dll/win32/msvcrt20/msvcrt20.spec [iso-8859-1] (original)
+++ trunk/reactos/dll/win32/msvcrt20/msvcrt20.spec [iso-8859-1] Sun Jul 24 
16:45:41 2011
@@ -937,7 +937,7 @@
  @ cdecl asin(double)
  @ cdecl atan(double)
  @ cdecl atan2(double double)
-@ cdecl atexit(ptr)
+@ extern atexit #<-- do not touch this!
  @ cdecl atof(str)
  @ cdecl atoi(str)
  @ cdecl atol(str)

Modified: trunk/reactos/dll/win32/msvcrt40/msvcrt40.spec
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msvcrt40/msvcrt40.spec?rev=52840&r1=52839&r2=52840&view=diff
==
--- trunk/reactos/dll/win32/msvcrt40/msvcrt40.spec [iso-8859-1] (original)
+++ trunk/reactos/dll/win32/msvcrt40/msvcrt40.spec [iso-8859-1] Sun Jul 24 
16:45:41 2011
@@ -975,7 +975,7 @@
  @ cdecl asin(double)
  @ cdecl atan(double)
  @ cdecl atan2(double double)
-@ cdecl atexit(ptr)
+@ extern atexit #<-- changing this will kill your cat, understand?
  @ cdecl atof(str)
  @ cdecl atoi(str)
  @ cdecl atol(str)

Modified: trunk/reactos/lib/3rdparty/mingw/crtexe.c
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/lib/3rdparty/mingw/crtexe.c?rev=52840&r1=52839&r2=52840&view=diff
==
--- trunk/reactos/lib/3rdparty/mingw/crtexe.c [iso-8859-1] (original)
+++ trunk/reactos/lib/3rdparty/mingw/crtexe.c [iso-8859-1] Sun Jul 24 16:45:41 
2011
@@ -71,8 +71,8 @@
  /* TLS initialization hook.  */
  extern const PIMAGE_TLS_CALLBACK __dyn_tls_init_callback;

-//extern _PVFV *__onexitbegin;
-//extern _PVFV *__onexitend;
+extern _PVFV *__onexitbegin;
+extern _PVFV *__onexitend;

  extern int mingw_app_type;

@@ -119,7 +119,7 @@
  __set_app_type(_GUI_APP);
else
  __set_app_type (_CONSOLE_APP);
-//  __onexitbegin = __onexitend = (_PVFV *) _encode_pointer ((_PVFV *)(-1));
+  __onexitbegin = __onexitend = (_PVFV *) _encode_pointer ((_PVFV *)(-1));

* __MINGW_IMP_SYMBOL(_fmode) = _fmode;
* __MINGW_IMP_SYMBOL(_commode) = _commode;

Modified: trunk/reactos/lib/3rdparty/mingw/mingw.rbuild
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/lib/3rdparty/mingw/mingw.rbuild?rev=52840&r1=52839&r2=52840&view=diff
==
--- trunk/reactos/lib/3rdparty/mingw/mingw.rbuild [iso-8859-1] (original)
+++ trunk/reactos/lib/3rdparty/mingw/mingw.rbuild [iso-8859-1] Sun Jul 24 
16:45:41 2011
@@ -12,7 +12,7 @@
include/reactos/mingw-w64
kernel32
_newmode.c
-   
+   atonexit.c
binmode.c
charmax.c
cinitexe.c

Modified: trunk/reactos/lib/sdk/crt/msvcrtex.cmake
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/lib/sdk/crt/msvcrtex.cmake?rev=52840&r1=52839&r2=52840&view=diff
==
--- trunk/reactos/lib/sdk/crt/msvcrtex.cmake [iso-8859-1] (original)
+++ trunk/reactos/lib/sdk/crt/msvcrtex.cmake [iso-8859-1] Sun Jul 24 16:45:41 
2011
@@ -17,7 +17,7 @@
  startup/natstart.c
  startup/charmax.c
  startup/merr.c
-#startup/atonexit.c
+startup/atonexit.c
  startup/txtmode.c
  startup/pesect.c
  startup/tlsmcrt.c

Modified: trunk/reactos/lib/sdk/crt/startup/crtdll.

Re: [ros-dev] [ros-diffs] [rharabien] 52892: [DESK] - Fix #6262: each new applied color scheme increase the window title height by one - Don't read REG_QWORD directly to DWORD variable

[Jérôme Gardou]

Le 26/07/2011 12:51, rharab...@svn.reactos.org a écrit :

-   theme->Size[i] = 
GetSystemMetrics(g_SizeMetric[i]);
+   theme->Size[i] = 
GetSystemMetrics(g_SizeMetric[i]); if(i == SIZE_CAPTION_Y) 
OutputDebugStringA("GetSystemMetrics!\n");


This looks strange ;-)

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Broken Windows_AMD64_1 VBox-Test

[Jérôme Gardou]

Hi!

Author: osiejka
Date: Tue Aug  2 22:54:30 2011
New Revision: 53038

URL:http://svn.reactos.org/svn/reactos?rev=53038&view=rev
Log:
[CSRSRV]
- don't hack the dll entry point name. Patch by Thomas Faber

I think this fixed it, no?



Le 03/08/2011 09:06, James Tabor a écrit :

Hi!
I think this broke it
[ros-diffs] [jgardou] 53025: [CMAKE/GCC] - fix entry point for native dlls

Thanks,
James

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 53085: [FREELDR] - Add back apparently lost line of r52098. Patch by Alex Ionescu, tested by Igor Paliychuk. See issue #6292 for more details.

[Jérôme Gardou]

Credits go to Cameron Gutman for the idea.

Le 05/08/2011 19:54, jgar...@svn.reactos.org a écrit :

Author: jgardou
Date: Fri Aug  5 17:54:06 2011
New Revision: 53085

URL: http://svn.reactos.org/svn/reactos?rev=53085&view=rev
Log:
[FREELDR]
- Add back apparently lost line of r52098.
Patch by Alex Ionescu, tested by Igor Paliychuk.
See issue #6292 for more details.

Modified:
 trunk/reactos/boot/freeldr/freeldr/arcemul/mm.c

Modified: trunk/reactos/boot/freeldr/freeldr/arcemul/mm.c
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arcemul/mm.c?rev=53085&r1=53084&r2=53085&view=diff
==
--- trunk/reactos/boot/freeldr/freeldr/arcemul/mm.c [iso-8859-1] (original)
+++ trunk/reactos/boot/freeldr/freeldr/arcemul/mm.c [iso-8859-1] Fri Aug  5 
17:54:06 2011
@@ -30,6 +30,7 @@
  { { MemoryFirmwareTemporary, 0x80, 0x10 }, 4, }, // File system read 
buffer. FILESYSBUFFER
  { { MemoryFirmwareTemporary, 0x90, 0x10 }, 5, }, // Disk read buffer for 
int 13h. DISKREADBUFFER
  { { MemoryFirmwarePermanent, 0xA0, 0x60 }, 6, }, // ROM / Video
+   { { MemorySpecialMemory, 0xFFF, 1 }, 7, }, // unusable memory
  #elif __arm__ // This needs to be done per-platform specific way

  #endif





___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 53152: [RPCRT4] - restore lost ros specific change. Thanks Vic.

[Jérôme Gardou]

Don't worry, it's part of the plan!

Le 09/08/2011 23:29, Ged Murphy a écrit :

Call me nuts, but why don't you add a ros_diff patch so it doesn't get
lost again???
From: jgar...@svn.reactos.org
Sent: 09 August 2011 18:43
To: ros-di...@reactos.org
Subject: [ros-diffs] [jgardou] 53152: [RPCRT4] - restore lost ros
specific change. Thanks Vic.
Author: jgardou
Date: Tue Aug  9 17:43:37 2011
New Revision: 53152

URL: http://svn.reactos.org/svn/reactos?rev=53152&view=rev
Log:
[RPCRT4]
- restore lost ros specific change.
Thanks Vic.

Modified:
 trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c

Modified: trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c?rev=53152&r1=53151&r2=53152&view=diff
==
--- trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c [iso-8859-1] (original)
+++ trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c [iso-8859-1] Tue Aug
  9 17:43:37 2011
@@ -6159,6 +6159,7 @@
  case RPC_FC_WCHAR:
  case RPC_FC_SHORT:
  case RPC_FC_USHORT:
+case RPC_FC_ENUM16:
  {
  USHORT d;
  align_pointer(&pStubMsg->Buffer, sizeof(USHORT));

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 53158: [TOOLS] - sync wpp, widl and wrc with wine 1.3.26

[Jérôme Gardou]

CMake users : please don't forget to rebuild your host tools :-)

Non cmake user : don't worry, this user unfriendly-ness is being worked on.

Le 10/08/2011 00:51, jgar...@svn.reactos.org a écrit :

Author: jgardou
Date: Tue Aug  9 22:51:55 2011
New Revision: 53158

URL: http://svn.reactos.org/svn/reactos?rev=53158&view=rev
Log:
[TOOLS]
- sync wpp, widl and wrc with wine 1.3.26

Added:
 trunk/reactos/tools/wrc/po.c   (with props)
Modified:
 trunk/reactos/include/host/nls.h
 trunk/reactos/include/host/wine/wpp.h
 trunk/reactos/tools/widl/client.c
 trunk/reactos/tools/widl/expr.c
 trunk/reactos/tools/widl/hash.c
 trunk/reactos/tools/widl/header.c
 trunk/reactos/tools/widl/header.h
 trunk/reactos/tools/widl/parser.l
 trunk/reactos/tools/widl/parser.tab.c
 trunk/reactos/tools/widl/parser.tab.h
 trunk/reactos/tools/widl/parser.y
 trunk/reactos/tools/widl/parser.yy.c
 trunk/reactos/tools/widl/proxy.c
 trunk/reactos/tools/widl/register.c
 trunk/reactos/tools/widl/server.c
 trunk/reactos/tools/widl/typegen.c
 trunk/reactos/tools/widl/typegen.h
 trunk/reactos/tools/widl/typelib.c
 trunk/reactos/tools/widl/typelib_struct.h
 trunk/reactos/tools/widl/utils.c
 trunk/reactos/tools/widl/utils.h
 trunk/reactos/tools/widl/widl.c
 trunk/reactos/tools/widl/widl.h
 trunk/reactos/tools/widl/widl.rbuild
 trunk/reactos/tools/widl/widltypes.h
 trunk/reactos/tools/widl/write_msft.c
 trunk/reactos/tools/wpp/lex.yy.c
 trunk/reactos/tools/wpp/ppl.l
 trunk/reactos/tools/wpp/ppy.tab.c
 trunk/reactos/tools/wpp/ppy.tab.h
 trunk/reactos/tools/wpp/ppy.y
 trunk/reactos/tools/wpp/preproc.c
 trunk/reactos/tools/wpp/wpp.c
 trunk/reactos/tools/wpp/wpp_private.h
 trunk/reactos/tools/wrc/CMakeLists.txt
 trunk/reactos/tools/wrc/dumpres.c
 trunk/reactos/tools/wrc/genres.c
 trunk/reactos/tools/wrc/lex.yy.c
 trunk/reactos/tools/wrc/newstruc.c
 trunk/reactos/tools/wrc/newstruc.h
 trunk/reactos/tools/wrc/parser.h
 trunk/reactos/tools/wrc/parser.l
 trunk/reactos/tools/wrc/parser.tab.c
 trunk/reactos/tools/wrc/parser.tab.h
 trunk/reactos/tools/wrc/parser.y
 trunk/reactos/tools/wrc/translation.c
 trunk/reactos/tools/wrc/utils.c
 trunk/reactos/tools/wrc/utils.h
 trunk/reactos/tools/wrc/wrc.c
 trunk/reactos/tools/wrc/wrc.h
 trunk/reactos/tools/wrc/wrc.rbuild
 trunk/reactos/tools/wrc/wrcrostypes.h
 trunk/reactos/tools/wrc/wrctypes.h

[This mail would be too long, it was shortened to contain the URLs only.]

Modified: trunk/reactos/include/host/nls.h
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/include/host/nls.h?rev=53158&r1=53157&r2=53158&view=diff

Modified: trunk/reactos/include/host/wine/wpp.h
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/include/host/wine/wpp.h?rev=53158&r1=53157&r2=53158&view=diff

Modified: trunk/reactos/tools/widl/client.c
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/client.c?rev=53158&r1=53157&r2=53158&view=diff

Modified: trunk/reactos/tools/widl/expr.c
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/expr.c?rev=53158&r1=53157&r2=53158&view=diff

Modified: trunk/reactos/tools/widl/hash.c
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/hash.c?rev=53158&r1=53157&r2=53158&view=diff

Modified: trunk/reactos/tools/widl/header.c
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/header.c?rev=53158&r1=53157&r2=53158&view=diff

Modified: trunk/reactos/tools/widl/header.h
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/header.h?rev=53158&r1=53157&r2=53158&view=diff

Modified: trunk/reactos/tools/widl/parser.l
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/parser.l?rev=53158&r1=53157&r2=53158&view=diff

Modified: trunk/reactos/tools/widl/parser.tab.c
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/parser.tab.c?rev=53158&r1=53157&r2=53158&view=diff

Modified: trunk/reactos/tools/widl/parser.tab.h
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/parser.tab.h?rev=53158&r1=53157&r2=53158&view=diff

Modified: trunk/reactos/tools/widl/parser.y
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/parser.y?rev=53158&r1=53157&r2=53158&view=diff

Modified: trunk/reactos/tools/widl/parser.yy.c
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/parser.yy.c?rev=53158&r1=53157&r2=53158&view=diff

Modified: trunk/reactos/tools/widl/proxy.c
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/proxy.c?rev=53158&r1=53157&r2=53158&view=diff

Modified: trunk/reactos/tools/widl/register.c
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/register.c?rev=53158&r1=53157&r2=53158&view=diff

Modified: trunk/reactos/tools/widl/server.c
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/server.c?rev=53158&r1=53157&r2=53158&vie

Re: [ros-dev] [ros-diffs] [ekohl] 53201: [ADVAPI32] Fix EnumServicesStatusEx[A/W]: - If lpServices is NULL or cbBufSize is less than sizeof(ENUM_SERVICE_STATUS_PROCESS) pass a pointer to an internal s

[Jérôme Gardou]

Passing [in] and [unique] to RQueryServiceonfigW is not a solution 
either. It was a quick and dirty hack to get things working.


I'm working on a proper solution right now, unless you already have 
something in your hat :-)


Le 13/08/2011 12:53, ek...@svn.reactos.org a écrit :

Author: ekohl
Date: Sat Aug 13 10:53:15 2011
New Revision: 53201

URL: http://svn.reactos.org/svn/reactos?rev=53201&view=rev
Log:
[ADVAPI32]
Fix EnumServicesStatusEx[A/W]:
- If lpServices is NULL or cbBufSize is less than 
sizeof(ENUM_SERVICE_STATUS_PROCESS) pass a pointer to an internal status buffer 
to REnumServicesStatusExA/W. Adding 'in' and 'unique' attributes in the idl 
file is NOT an option because this is not compatible with Windows.
- Check the InfoLevel.

Modified:
 trunk/reactos/dll/win32/advapi32/service/scm.c

Modified: trunk/reactos/dll/win32/advapi32/service/scm.c
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/advapi32/service/scm.c?rev=53201&r1=53200&r2=53201&view=diff
==
--- trunk/reactos/dll/win32/advapi32/service/scm.c [iso-8859-1] (original)
+++ trunk/reactos/dll/win32/advapi32/service/scm.c [iso-8859-1] Sat Aug 13 
10:53:15 2011
@@ -1150,7 +1150,9 @@
LPDWORD lpResumeHandle,
LPCSTR pszGroupName)
  {
+ENUM_SERVICE_STATUS_PROCESSA ServiceStatus;
  LPENUM_SERVICE_STATUS_PROCESSA lpStatusPtr;
+DWORD dwBufferSize;
  DWORD dwError;
  DWORD dwCount;

@@ -1166,6 +1168,18 @@
  {
  SetLastError(ERROR_INVALID_HANDLE);
  return FALSE;
+}
+
+if (lpServices == NULL ||
+cbBufSize<  sizeof(ENUM_SERVICE_STATUS_PROCESSA))
+{
+lpStatusPtr =&ServiceStatus;
+dwBufferSize = sizeof(ENUM_SERVICE_STATUS_PROCESSA);
+}
+else
+{
+lpStatusPtr = (LPENUM_SERVICE_STATUS_PROCESSA)lpServices;
+dwBufferSize = cbBufSize;
  }

  RpcTryExcept
@@ -1174,8 +1188,8 @@
   InfoLevel,
   dwServiceType,
   dwServiceState,
- (LPBYTE)lpServices,
- cbBufSize,
+ (LPBYTE)lpStatusPtr,
+ dwBufferSize,
   pcbBytesNeeded,
   lpServicesReturned,
   lpResumeHandle,
@@ -1189,18 +1203,20 @@

  if (dwError == ERROR_SUCCESS || dwError == ERROR_MORE_DATA)
  {
-lpStatusPtr = (LPENUM_SERVICE_STATUS_PROCESSA)lpServices;
-for (dwCount = 0; dwCount<  *lpServicesReturned; dwCount++)
+if (InfoLevel == SC_ENUM_PROCESS_INFO)
  {
-if (lpStatusPtr->lpServiceName)
-lpStatusPtr->lpServiceName =
-(LPSTR)((ULONG_PTR)lpServices + 
(ULONG_PTR)lpStatusPtr->lpServiceName);
-
-if (lpStatusPtr->lpDisplayName)
-lpStatusPtr->lpDisplayName =
-(LPSTR)((ULONG_PTR)lpServices + 
(ULONG_PTR)lpStatusPtr->lpDisplayName);
-
-lpStatusPtr++;
+for (dwCount = 0; dwCount<  *lpServicesReturned; dwCount++)
+{
+if (lpStatusPtr->lpServiceName)
+lpStatusPtr->lpServiceName =
+(LPSTR)((ULONG_PTR)lpServices + 
(ULONG_PTR)lpStatusPtr->lpServiceName);
+
+if (lpStatusPtr->lpDisplayName)
+lpStatusPtr->lpDisplayName =
+(LPSTR)((ULONG_PTR)lpServices + 
(ULONG_PTR)lpStatusPtr->lpDisplayName);
+
+lpStatusPtr++;
+}
  }
  }

@@ -1234,11 +1250,31 @@
LPDWORD lpResumeHandle,
LPCWSTR pszGroupName)
  {
+ENUM_SERVICE_STATUS_PROCESSW ServiceStatus;
  LPENUM_SERVICE_STATUS_PROCESSW lpStatusPtr;
+DWORD dwBufferSize;
  DWORD dwError;
  DWORD dwCount;

  TRACE("EnumServicesStatusExW() called\n");
+
+if (InfoLevel != SC_ENUM_PROCESS_INFO)
+{
+SetLastError(ERROR_INVALID_LEVEL);
+return FALSE;
+}
+
+if (lpServices == NULL ||
+cbBufSize<  sizeof(ENUM_SERVICE_STATUS_PROCESSW))
+{
+lpStatusPtr =&ServiceStatus;
+dwBufferSize = sizeof(ENUM_SERVICE_STATUS_PROCESSW);
+}
+else
+{
+lpStatusPtr = (LPENUM_SERVICE_STATUS_PROCESSW)lpServices;
+dwBufferSize = cbBufSize;
+}

  RpcTryExcept
  {
@@ -1246,8 +1282,8 @@
   InfoLevel,
   dwServiceType,
   dwServiceState,
- (LPBYTE)lpServices,
- cbBufSize,
+   

Re: [ros-dev] August meeting

[Jérôme Gardou]

Hi.

I won't be able to attend the meeting tonight. As for the votings, Amine 
knows my feelings about the two issues concerned, so I give him my vote, 
if such a thing is doable.


Regards.
Jérôme.

Le 25/08/2011 18:14, Pierre Schweitzer a écrit :

Hi,
I've just sent the emails containing the credentials to all the users.

As a public reminder, the meeting will take place on the IRC server 
fezile.reactos.org port 6667, no SSL) on channel #meeting.

Please don't forget to log in with the given nickname and then provide the 
password you received.
The meeting will be open for reading to everyone.

The IRC server will be open a short time before meeting starts (at 19UTC, so in 
a bit less than 3 hours).

Regards,
Pierre.

ReactOS Development List  wrote on Wed, August 24th, 2011, 
11:30 AM:

Hi,
this is a reminder about the Status meeting, which is to happen
tomorrow, 25th of August at 19:00 UTC. Please don't miss it.

Proposed agenda for the meeting:
1. Arwinss adoption voting.
2. CMake adoption voting.
3. Release preparation status report, deciding on the next release date.
4. Driver signing. Discussing possible threats and deciding on an
official position wrt driver signing in future.
4. Party related to GSoC results.

I propose to move individual devs status reports to ros-dev mailing
list, because there is no reason to just sit in the irc channel and
listen to them for hours.

List of participants:
- Giannis Adamopoulos (smiley1_)
- Johannes Anderwald (janderwald)
- Javier Agustìn Fernàndez Arroyo (elhoir)
- Maciej Bialas (niski)
- Jan Blomqvist-Kinander (JaixBly)
- Aleksey Bragin (abragin)
- Thomas Faber (ThFabba)
- Colin Finck (Colin_Finck)
- Jérôme Gardou (zefklop)
- Danny Götte (dangerground)
- Cameron Gutman (aicom)
- Ziliang Guo (ZWabbit)
- Rafal Harabien (rafalh)
- Andrew Hill (ash77)
- Kamil Hornicek (Pigglesworth)
- Gabriel Ilardi (gabriel_it)
- Alex Ionescu (Alex_Ionescu)
- Amine Khaldi (AmineKhaldi)
- Igor Koshpaev (tower)
- Timo Kreuzer (tkreuzer)
- Matthias Kupfer (Collibri)
- Michael Martin (mjmartin)
- Victor Martinez (vicmarcal)
- Roel Messiant (Mephisto)
- Claudiu Mihail (KlausM)
- Andrew Munger (WaxDragon)
- Ged Murphy (GedMurphy)
- Igor Paliychuk (igorko)
- Sylvain Petreolle (Usurp)
- Hervé Poussineau (hpoussin)
- Daniel Reimer (dreimer)
- Pierre Schweitzer (HeisSpiter)
- Samuel Serapion (encoded)
- Olaf Siejka (Caemyr)
- James Tabor (jimtabor)
- Christoph von Wittich (Christoph_vW)
- Art Yerkes (arty)

WBR,
Aleksey Bragin.
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [ekohl] 53469: [WIDL] Revert parts of r53171: Remove the -Oif flag for WIDL because the NT4 stub code generated by the current WIDL is heavily broken with respect to the rang

[Jérôme Gardou]

HI Eric!

I'm not sure about what you mean for range attribute, but I notice that
typedef [context_handle] PVOID my_handle;
makes widl thinks that any value of the my_handle type is passed by 
pointer, whereas midl considers it is passed by value.


Could you be more precise about "range attributes and others?" please.

Regards.
Jérôme.

Le 27/08/2011 18:24, ek...@svn.reactos.org a écrit :

Author: ekohl
Date: Sat Aug 27 16:24:40 2011
New Revision: 53469

URL: http://svn.reactos.org/svn/reactos?rev=53469&view=rev
Log:
[WIDL]
Revert parts of r53171:
Remove the -Oif flag for WIDL because the NT4 stub code generated by the 
current WIDL is heavily broken with respect to the range attribute and others. 
Please enable the -Oif feature only after these bugs are fixed in WIDL!

Modified:
 trunk/reactos/cmake/idl-support.cmake
 trunk/reactos/tools/rbuild/backend/mingw/rules.mak

Modified: trunk/reactos/cmake/idl-support.cmake
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/cmake/idl-support.cmake?rev=53469&r1=53468&r2=53469&view=diff
==
--- trunk/reactos/cmake/idl-support.cmake [iso-8859-1] (original)
+++ trunk/reactos/cmake/idl-support.cmake [iso-8859-1] Sat Aug 27 16:24:40 2011
@@ -22,8 +22,8 @@
  set(IDL_HEADER_ARG -h -o) #.h
  set(IDL_HEADER_ARG2 -h -H) #.h
  set(IDL_TYPELIB_ARG -t -o) #.tlb
-set(IDL_SERVER_ARG -Oif -s -o) #.c for server library
-set(IDL_CLIENT_ARG -Oif -c -o) #.c for stub client library
+set(IDL_SERVER_ARG -s -o) #.c for server library
+set(IDL_CLIENT_ARG -c -o) #.c for stub client library
  set(IDL_PROXY_ARG -p -o)
  set(IDL_INTERFACE_ARG -u -o)
  if(ARCH MATCHES i386)
@@ -169,6 +169,6 @@
  list(APPEND IID_SOURCES ${NAME}_i.c)
  endforeach()
  add_library(${TARGET} ${IID_SOURCES})
-   add_dependencies(${TARGET} psdk)
+add_dependencies(${TARGET} psdk)
  set_target_properties(${TARGET} PROPERTIES EXCLUDE_FROM_ALL TRUE)
  endfunction()

Modified: trunk/reactos/tools/rbuild/backend/mingw/rules.mak
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/tools/rbuild/backend/mingw/rules.mak?rev=53469&r1=53468&r2=53469&view=diff
==
--- trunk/reactos/tools/rbuild/backend/mingw/rules.mak [iso-8859-1] (original)
+++ trunk/reactos/tools/rbuild/backend/mingw/rules.mak [iso-8859-1] Sat Aug 27 
16:24:40 2011
@@ -264,7 +264,7 @@

  ${call RBUILD_intermediate_path_noext,$(2)}_c: $(2) $(3) $$(widl_TARGET) | 
${call RBUILD_intermediate_dir,$(2)}
$$(ECHO_WIDL)
-   $$(Q)$$(widl_TARGET) ${call RBUILD_midlflags,$(1),$(4),-I${call 
RBUILD_dir,$(2)}} -Oif -h -H ${call RBUILD_intermediate_path_noext,$(2)}_c.h -c 
-C ${call RBUILD_intermediate_path_noext,$(2)}_c.c $(2)
+   $$(Q)$$(widl_TARGET) ${call RBUILD_midlflags,$(1),$(4),-I${call 
RBUILD_dir,$(2)}} -h -H ${call RBUILD_intermediate_path_noext,$(2)}_c.h -c -C 
${call RBUILD_intermediate_path_noext,$(2)}_c.c $(2)
$${checkpoint} $$@>$(NUL)

  ${call RBUILD_CC,$(1),${call 
RBUILD_intermediate_path_noext,$(2)}_c.c,,,${call 
RBUILD_intermediate_path_noext,$(2)}_c.o}
@@ -280,7 +280,7 @@

  ${call RBUILD_intermediate_path_noext,$(2)}_s: $(2) $(3) $$(widl_TARGET) | 
${call RBUILD_intermediate_dir,$(2)}
$$(ECHO_WIDL)
-   $$(Q)$$(widl_TARGET) ${call RBUILD_midlflags,$(1),$(4),-I${call 
RBUILD_dir,$(2)}} -Oif -h -H ${call RBUILD_intermediate_path_noext,$(2)}_s.h -s 
-S ${call RBUILD_intermediate_path_noext,$(2)}_s.c $(2)
+   $$(Q)$$(widl_TARGET) ${call RBUILD_midlflags,$(1),$(4),-I${call 
RBUILD_dir,$(2)}} -h -H ${call RBUILD_intermediate_path_noext,$(2)}_s.h -s -S 
${call RBUILD_intermediate_path_noext,$(2)}_s.c $(2)
$${checkpoint} $$@>$(NUL)

  ${call RBUILD_CC,$(1),${call 
RBUILD_intermediate_path_noext,$(2)}_s.c,,,${call 
RBUILD_intermediate_path_noext,$(2)}_s.o}





___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [ekohl] 53469: [WIDL] Revert parts of r53171: Remove the -Oif flag for WIDL because the NT4 stub code generated by the current WIDL is heavily broken with respect to the rang

[Jérôme Gardou]

Please see inlined answers.

Le 28/08/2011 00:29, Eric Kohl a écrit :

Hello Jérôme!


I'm not sure about what you mean for range attribute, but I notice that
typedef [context_handle] PVOID my_handle;
makes widl thinks that any value of the my_handle type is passed by
pointer, whereas midl considers it is passed by value.

Did you try to find the bug in WIDL?

In fact, it was our bug, fixed in r53477.



Could you be more precise about "range attributes and others?" please.

I should better have written "range attributes and probably others"!

The range attribute is used in the svcctl.idl file and enables range 
checks in rpcrt4.dll. This is a nice feature, but WIDL is messing up 
the ranges if a range attribute is used with function parameters.


For example:
DWORD Test(
[in] SC_RPC_HANDLE hSCManager,
[in, range(0, 1024)] DWORD dwParam1,
[in, range(0, 255)] DWORD dwParam2);

WIDL will emit the same range type (range 0-255) for both parameters 
because the range attribute is assigned to the DWORD type and it is 
overwritten whenever a new range attribute is used with the DWORD type.
In the end all DWORD type parameters that have a range attribute will 
use the range that is used by the last DWORD type with a range 
attribute (dwParam2 in this case) in the idl file. This will cause 
some 'funny' effects if dwParam1 is greater than 255. :-/
OK, I guess we'd have to open a bug on wine side, I'm not comfortable 
enough with WIDL code to fix it myself.
BTW, I think it is more important to have a working RPC system in 
ReactOS than a windows-compatible one. The compatibility issues can be 
fixed later, but if you break RPC today by fixing compatibility issues 
you will render ReactOS unusable. So please be very careful when you 
make changes to rpcrt4 or WIDL.
I fully agree with that, but just try to reenable -Oif, and look at 
advapi32:service winetest results. You'd be surprised : no skipped 
tests, and some others are actually fixed! (while others are broken, 
most probably because of this range thing) So it's more than a "nice 
feature". You can already see it fixes one eventlog test by looking at 
the link Olaf provided (look for eventlog.c:206).


Regards,
Eric

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Regards.
Jérôme.

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 53481: [WIDL] - reenable -Oif flag, it's too good to be disabled With this commit, advapi32:service winetest suffers only 2 failures.

[Jérôme Gardou]

Feel free to disable it again if probems occur.

"Probable bugs" are hard to test alone, so I'm waiting for test bot to 
confirm this fixes things without breaking others.


Regards.
Jérôme.

Le 28/08/2011 17:37, jgar...@svn.reactos.org a écrit :

Author: jgardou
Date: Sun Aug 28 15:37:01 2011
New Revision: 53481

URL: http://svn.reactos.org/svn/reactos?rev=53481&view=rev
Log:
[WIDL]
- reenable -Oif flag, it's too good to be disabled
With this commit, advapi32:service winetest suffers only 2 failures.

Modified:
 trunk/reactos/cmake/idl-support.cmake
 trunk/reactos/tools/rbuild/backend/mingw/rules.mak

Modified: trunk/reactos/cmake/idl-support.cmake
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/cmake/idl-support.cmake?rev=53481&r1=53480&r2=53481&view=diff
==
--- trunk/reactos/cmake/idl-support.cmake [iso-8859-1] (original)
+++ trunk/reactos/cmake/idl-support.cmake [iso-8859-1] Sun Aug 28 15:37:01 2011
@@ -22,8 +22,8 @@
  set(IDL_HEADER_ARG -h -o) #.h
  set(IDL_HEADER_ARG2 -h -H) #.h
  set(IDL_TYPELIB_ARG -t -o) #.tlb
-set(IDL_SERVER_ARG -s -o) #.c for server library
-set(IDL_CLIENT_ARG -c -o) #.c for stub client library
+set(IDL_SERVER_ARG -Oif -s -o) #.c for server library
+set(IDL_CLIENT_ARG -Oif -c -o) #.c for stub client library
  set(IDL_PROXY_ARG -p -o)
  set(IDL_INTERFACE_ARG -u -o)
  if(ARCH MATCHES i386)
@@ -169,6 +169,6 @@
  list(APPEND IID_SOURCES ${NAME}_i.c)
  endforeach()
  add_library(${TARGET} ${IID_SOURCES})
-add_dependencies(${TARGET} psdk)
+   add_dependencies(${TARGET} psdk)
  set_target_properties(${TARGET} PROPERTIES EXCLUDE_FROM_ALL TRUE)
  endfunction()

Modified: trunk/reactos/tools/rbuild/backend/mingw/rules.mak
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/tools/rbuild/backend/mingw/rules.mak?rev=53481&r1=53480&r2=53481&view=diff
==
--- trunk/reactos/tools/rbuild/backend/mingw/rules.mak [iso-8859-1] (original)
+++ trunk/reactos/tools/rbuild/backend/mingw/rules.mak [iso-8859-1] Sun Aug 28 
15:37:01 2011
@@ -264,7 +264,7 @@

  ${call RBUILD_intermediate_path_noext,$(2)}_c: $(2) $(3) $$(widl_TARGET) | 
${call RBUILD_intermediate_dir,$(2)}
$$(ECHO_WIDL)
-   $$(Q)$$(widl_TARGET) ${call RBUILD_midlflags,$(1),$(4),-I${call 
RBUILD_dir,$(2)}} -h -H ${call RBUILD_intermediate_path_noext,$(2)}_c.h -c -C 
${call RBUILD_intermediate_path_noext,$(2)}_c.c $(2)
+   $$(Q)$$(widl_TARGET) ${call RBUILD_midlflags,$(1),$(4),-I${call 
RBUILD_dir,$(2)}} -Oif -h -H ${call RBUILD_intermediate_path_noext,$(2)}_c.h -c 
-C ${call RBUILD_intermediate_path_noext,$(2)}_c.c $(2)
$${checkpoint} $$@>$(NUL)

  ${call RBUILD_CC,$(1),${call 
RBUILD_intermediate_path_noext,$(2)}_c.c,,,${call 
RBUILD_intermediate_path_noext,$(2)}_c.o}
@@ -280,7 +280,7 @@

  ${call RBUILD_intermediate_path_noext,$(2)}_s: $(2) $(3) $$(widl_TARGET) | 
${call RBUILD_intermediate_dir,$(2)}
$$(ECHO_WIDL)
-   $$(Q)$$(widl_TARGET) ${call RBUILD_midlflags,$(1),$(4),-I${call 
RBUILD_dir,$(2)}} -h -H ${call RBUILD_intermediate_path_noext,$(2)}_s.h -s -S 
${call RBUILD_intermediate_path_noext,$(2)}_s.c $(2)
+   $$(Q)$$(widl_TARGET) ${call RBUILD_midlflags,$(1),$(4),-I${call 
RBUILD_dir,$(2)}} -Oif -h -H ${call RBUILD_intermediate_path_noext,$(2)}_s.h -s 
-S ${call RBUILD_intermediate_path_noext,$(2)}_s.c $(2)
$${checkpoint} $$@>$(NUL)

  ${call RBUILD_CC,$(1),${call 
RBUILD_intermediate_path_noext,$(2)}_s.c,,,${call 
RBUILD_intermediate_path_noext,$(2)}_s.o}





___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [rharabien] 53542: [FREELDR] - Introduce WINE-like debug macros ERR, FIXME, WARN and TRACE - Always show ERR and FIXME information - WARN and TRACE are enabled by DebugPrintM

[Jérôme Gardou]

That livecd freeldr wasn't named setupldr.sys

Le 03/09/2011 13:57, Alex Ionescu a écrit :

And the bug was...?

Best regards,
Alex Ionescu


On Sat, Sep 3, 2011 at 11:56 AM, > wrote:


Author: rharabien
Date: Sat Sep  3 10:56:36 2011
New Revision: 53542

URL: http://svn.reactos.org/svn/reactos?rev=53542&view=rev

Log:
[FREELDR]
- Introduce WINE-like debug macros ERR, FIXME, WARN and TRACE
- Always show ERR and FIXME information
- WARN and TRACE are enabled by DebugPrintMask in debug.c as before
- Thanks to new macros find bug in CMake livecd creation and fix it

Modified:
   trunk/reactos/boot/freeldr/freeldr/CMakeLists.txt
   trunk/reactos/boot/freeldr/freeldr/arch/amd64/winldr.c
   trunk/reactos/boot/freeldr/freeldr/arch/i386/drivemap.c
   trunk/reactos/boot/freeldr/freeldr/arch/i386/hardware.c
   trunk/reactos/boot/freeldr/freeldr/arch/i386/hwacpi.c
   trunk/reactos/boot/freeldr/freeldr/arch/i386/hwapm.c
   trunk/reactos/boot/freeldr/freeldr/arch/i386/hwpci.c
   trunk/reactos/boot/freeldr/freeldr/arch/i386/i386disk.c
   trunk/reactos/boot/freeldr/freeldr/arch/i386/i386vid.c
   trunk/reactos/boot/freeldr/freeldr/arch/i386/pcdisk.c
   trunk/reactos/boot/freeldr/freeldr/arch/i386/pcmem.c
   trunk/reactos/boot/freeldr/freeldr/arch/i386/pcvideo.c
   trunk/reactos/boot/freeldr/freeldr/arch/i386/winldr.c
   trunk/reactos/boot/freeldr/freeldr/arch/i386/xboxdisk.c
   trunk/reactos/boot/freeldr/freeldr/arch/i386/xboxhw.c
   trunk/reactos/boot/freeldr/freeldr/cache/blocklist.c
   trunk/reactos/boot/freeldr/freeldr/cache/cache.c
   trunk/reactos/boot/freeldr/freeldr/debug.c
   trunk/reactos/boot/freeldr/freeldr/disk/disk.c
   trunk/reactos/boot/freeldr/freeldr/disk/partition.c
   trunk/reactos/boot/freeldr/freeldr/disk/scsiport.c
   trunk/reactos/boot/freeldr/freeldr/freeldr.c
   trunk/reactos/boot/freeldr/freeldr/fs/ext2.c
   trunk/reactos/boot/freeldr/freeldr/fs/fat.c
   trunk/reactos/boot/freeldr/freeldr/fs/fs.c
   trunk/reactos/boot/freeldr/freeldr/fs/iso.c
   trunk/reactos/boot/freeldr/freeldr/fs/ntfs.c
   trunk/reactos/boot/freeldr/freeldr/fs/pxe.c
   trunk/reactos/boot/freeldr/freeldr/include/debug.h
   trunk/reactos/boot/freeldr/freeldr/inifile/inifile.c
   trunk/reactos/boot/freeldr/freeldr/inifile/parse.c
   trunk/reactos/boot/freeldr/freeldr/linuxboot.c
   trunk/reactos/boot/freeldr/freeldr/mm/meminit.c
   trunk/reactos/boot/freeldr/freeldr/mm/mm.c
   trunk/reactos/boot/freeldr/freeldr/reactos/binhive.c
   trunk/reactos/boot/freeldr/freeldr/reactos/registry.c
   trunk/reactos/boot/freeldr/freeldr/ui/ui.c
   trunk/reactos/boot/freeldr/freeldr/windows/conversion.c
   trunk/reactos/boot/freeldr/freeldr/windows/peloader.c
   trunk/reactos/boot/freeldr/freeldr/windows/setupldr.c
   trunk/reactos/boot/freeldr/freeldr/windows/winldr.c
   trunk/reactos/boot/freeldr/freeldr/windows/wlmemory.c
   trunk/reactos/boot/freeldr/freeldr/windows/wlregistry.c

[This mail would be too long, it was shortened to contain the URLs
only.]

Modified: trunk/reactos/boot/freeldr/freeldr/CMakeLists.txt
URL:

http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/CMakeLists.txt?rev=53542&r1=53541&r2=53542&view=diff



Modified: trunk/reactos/boot/freeldr/freeldr/arch/amd64/winldr.c
URL:

http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/amd64/winldr.c?rev=53542&r1=53541&r2=53542&view=diff



Modified: trunk/reactos/boot/freeldr/freeldr/arch/i386/drivemap.c
URL:

http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/i386/drivemap.c?rev=53542&r1=53541&r2=53542&view=diff



Modified: trunk/reactos/boot/freeldr/freeldr/arch/i386/hardware.c
URL:

http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/i386/hardware.c?rev=53542&r1=53541&r2=53542&view=diff



Modified: trunk/reactos/boot/freeldr/freeldr/arch/i386/hwacpi.c
URL:

http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/i386/hwacpi.c?rev=53542&r1=53541&r2=53542&view=diff

Re: [ros-dev] [ros-diffs] [cmihail] 53543: [shell32.dll] - Fix bug related to correct error code returning in delete_files. The value of 1026 was revealed to be returned by windows 2003 server. Score

[Jérôme Gardou]

Hello Claudiu!

I notice some weird tab/spaces modifications here.

Regards.
Jérôme.

Le 03/09/2011 16:20, cmih...@svn.reactos.org a écrit :

Author: cmihail
Date: Sat Sep  3 14:20:03 2011
New Revision: 53543

URL: http://svn.reactos.org/svn/reactos?rev=53543&view=rev
Log:
[shell32.dll]
- Fix bug related to correct error code returning in delete_files. The value of 
1026 was revealed to be returned by windows 2003 server. Score several passed 
winetests.
- Fix a bug in ShellLink::SetShowCmd and score one more passed winetest

Modified:
 branches/shell32_new-bringup/dll/win32/shell32/shelllink.cpp
 branches/shell32_new-bringup/dll/win32/shell32/shlfileop.cpp





___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 53547: [VGA_NEW] - fix some warnings

[Jérôme Gardou]

Yuou're right... It was a bad mistake in my local copy which caused the 
warnings to appear.


Thanks for pointing this out.
BTW, I took a look at it, and our headers have the NTAPI calling 
convention, whereas WDK ones haven't.


Le 03/09/2011 18:21, Alex Ionescu a écrit :

These changes are wrong :(

Please use the correct compiler flag instead (-mrtd)

Best regards,
Alex Ionescu




___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 53547: [VGA_NEW] - fix some warnings

[Jérôme Gardou]

May I ask what the change is?

Le 03/09/2011 22:53, Dmitry Gorbachev a écrit :

BTW, -mrtd has recently (in April) changed its behavior in GCC trunk.
If reactos needs this flag, then maybe somebody should ask the author
of that change (Kai) to provide another flag (say, -mold-rtd) instead
of it.

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [tkreuzer] 53399: [VMWINST] Fix amd64 build [NTDLL] add missing amd64 specific exports [MSVCRT*] Fix mangled c++ exports for amd64 [OLEAUT32] Add amd64 adm stub for call_meth

[Jérôme Gardou]

Le 23/08/2011 10:58, tkreu...@svn.reactos.org a écrit :

Author: tkreuzer
Date: Tue Aug 23 08:58:15 2011
New Revision: 53399

URL: http://svn.reactos.org/svn/reactos?rev=53399&view=rev
Log:
[VMWINST] Fix amd64 build


What about :
[VMWINST] Get rid of this useless relic.
I mean it's something we have to maintain, it was written for 
antediluvian vmware versions, and I see no reason to have such a thing. 
I may as well write an application to install specific ATI card drivers, 
or intel chipset drivers...


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [tkreuzer] 53399: [VMWINST] Fix amd64 build

[Jérôme Gardou]

Le 04/09/2011 17:29, Bernd Blaauw a écrit :

Op 4-9-2011 17:10, Jérôme Gardou schreef:

Le 23/08/2011 10:58, tkreu...@svn.reactos.org a écrit :
What about :
[VMWINST] Get rid of this useless relic.
I mean it's something we have to maintain, it was written for
antediluvian vmware versions, and I see no reason to have such a thing.
I may as well write an application to install specific ATI card drivers,
or intel chipset drivers...


Well you got multiple options:
* ensure the VMware installer (MSI) can run properly so people can 
install their drivers. Makes VMWINST obsolete.
* ensure ReactOS can deal with a directory containing the bare VMware 
drivers (requiring 7zip to extract them from VMware 7 ISO).

* convert the Linux opensource VMware drivers into NT ones
* update this relic tool to finally (also) work with modern VMware ISO 
contents structure.


Nice and all that people can show off Quake2, Furmark etc in 
VirtualBox..now prove the same for other virtualisation products and 
real hardware graphics cards (Nvidia and AMD/ATI for starters, Intel 
graphics if you aim at business desktops).


Demonstrate equal progress in all used/supported platforms. Show 
VMWINST is an obsolete relic by proving VMware drivers can install on 
trunk ReactOS, including the added 3D support (OpenGL only I guess, 
but good enough for now).


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Please, stop asking us to "port opensource linux drivers into NT ones". 
And also don't answer to this sentence and try to explain us why it 
would be so good for this project.
There's no offence meant, it's just that we don't have interest into it, 
and we lack manpower anyway.


Also, Aleksey noted that he still had use of this, I won't touch it.

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [dgorbachev] 53730: [CMAKE] Allow to specify prefix/suffix for GCC and Binutils.

[Jérôme Gardou]

Hello.

May I ask why you removed the -nodefaultlibs flag?

Regards.
Jérôme.

Le 18/09/2011 02:57, dgorbac...@svn.reactos.org a écrit :

Author: dgorbachev
Date: Sun Sep 18 00:57:17 2011
New Revision: 53730

URL: http://svn.reactos.org/svn/reactos?rev=53730&view=rev
Log:
[CMAKE]
Allow to specify prefix/suffix for GCC and Binutils.

Modified:
 trunk/reactos/cmake/gcc.cmake
 trunk/reactos/lib/3rdparty/mingw/CMakeLists.txt
 trunk/reactos/lib/sdk/crt/oldnames.cmake
 trunk/reactos/toolchain-gcc.cmake

Modified: trunk/reactos/cmake/gcc.cmake
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/cmake/gcc.cmake?rev=53730&r1=53729&r2=53730&view=diff
==
--- trunk/reactos/cmake/gcc.cmake [iso-8859-1] (original)
+++ trunk/reactos/cmake/gcc.cmake [iso-8859-1] Sun Sep 18 00:57:17 2011
@@ -86,7 +86,7 @@

  set(CMAKE_CXX_LINK_EXECUTABLE "  
  -o  ")

-set(CMAKE_EXE_LINKER_FLAGS "-nodefaultlibs -nostdlib -Wl,--enable-auto-image-base 
-Wl,--disable-auto-import -Wl,--disable-stdcall-fixup")
+set(CMAKE_EXE_LINKER_FLAGS "-nostdlib 
-Wl,--enable-auto-image-base,--disable-auto-import,--disable-stdcall-fixup")

  set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS_INIT} 
-Wl,--disable-stdcall-fixup")

@@ -134,7 +134,7 @@
  endif()

  if(${TYPE} STREQUAL kernelmodedriver)
-add_target_link_flags(${MODULE} "-Wl,--exclude-all-symbols 
-Wl,-file-alignment=0x1000 -Wl,-section-alignment=0x1000")
+add_target_link_flags(${MODULE} 
"-Wl,--exclude-all-symbols,-file-alignment=0x1000,-section-alignment=0x1000")
  endif()
  endfunction()

@@ -190,25 +190,25 @@
  add_custom_command(
  OUTPUT ${CMAKE_BINARY_DIR}/importlibs/lib${_name}.a
  COMMAND native-spec2def -n=${_name}${_suffix} -a=${ARCH2} 
-d=${CMAKE_CURRENT_BINARY_DIR}/${_name}_implib.def 
${CMAKE_CURRENT_SOURCE_DIR}/${_exports_file}
-COMMAND ${MINGW_PREFIX}dlltool --def 
${CMAKE_CURRENT_BINARY_DIR}/${_name}_implib.def --kill-at 
--output-lib=${CMAKE_BINARY_DIR}/importlibs/lib${_name}.a
+COMMAND ${CMAKE_DLLTOOL} --def 
${CMAKE_CURRENT_BINARY_DIR}/${_name}_implib.def --kill-at 
--output-lib=${CMAKE_BINARY_DIR}/importlibs/lib${_name}.a
  DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${_exports_file} 
native-spec2def)

  # Delayed importlib creation
  add_custom_command(
  OUTPUT ${CMAKE_BINARY_DIR}/importlibs/lib${_name}_delayed.a
  COMMAND native-spec2def -n=${_name}${_suffix} -a=${ARCH2} 
-d=${CMAKE_CURRENT_BINARY_DIR}/${_name}_delayed_implib.def 
${CMAKE_CURRENT_SOURCE_DIR}/${_exports_file}
-COMMAND ${MINGW_PREFIX}dlltool --def 
${CMAKE_CURRENT_BINARY_DIR}/${_name}_delayed_implib.def --kill-at 
--output-delaylib ${CMAKE_BINARY_DIR}/importlibs/lib${_name}_delayed.a
+COMMAND ${CMAKE_DLLTOOL} --def 
${CMAKE_CURRENT_BINARY_DIR}/${_name}_delayed_implib.def --kill-at 
--output-delaylib ${CMAKE_BINARY_DIR}/importlibs/lib${_name}_delayed.a
  DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${_exports_file} 
native-spec2def)

  elseif(${_extension} STREQUAL ".def")
  message("Use of def files for import libs is deprecated: 
${_exports_file}")
  add_custom_command(
  OUTPUT ${CMAKE_BINARY_DIR}/importlibs/lib${_name}.a
-COMMAND ${MINGW_PREFIX}dlltool --def 
${CMAKE_CURRENT_SOURCE_DIR}/${_exports_file} --kill-at 
--output-lib=${CMAKE_BINARY_DIR}/importlibs/lib${_name}.a
+COMMAND ${CMAKE_DLLTOOL} --def 
${CMAKE_CURRENT_SOURCE_DIR}/${_exports_file} --kill-at 
--output-lib=${CMAKE_BINARY_DIR}/importlibs/lib${_name}.a
  DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${_exports_file})
  add_custom_command(
  OUTPUT ${CMAKE_BINARY_DIR}/importlibs/lib${_name}_delayed.a
-COMMAND ${MINGW_PREFIX}dlltool --def 
${CMAKE_CURRENT_SOURCE_DIR}/${_exports_file} --kill-at --output-delaylib 
${CMAKE_BINARY_DIR}/importlibs/lib${_name}_delayed.a
+COMMAND ${CMAKE_DLLTOOL} --def 
${CMAKE_CURRENT_SOURCE_DIR}/${_exports_file} --kill-at --output-delaylib 
${CMAKE_BINARY_DIR}/importlibs/lib${_name}_delayed.a
  DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${_exports_file})
  else()
  message(FATAL_ERROR "Unsupported exports file extension: 
${_extension}")
@@ -243,7 +243,7 @@
  endfunction()

  macro(macro_mc FILE)
-set(COMMAND_MC ${MINGW_PREFIX}windmc -A -b 
${CMAKE_CURRENT_SOURCE_DIR}/${FILE}.mc -r ${REACTOS_BINARY_DIR}/include/reactos 
-h ${REACTOS_BINARY_DIR}/include/reactos)
+set(COMMAND_MC ${CMAKE_MC_COMPILER} -A -b 
${CMAKE_CURRENT_SOURCE_DIR}/${FILE}.mc -r ${REACTOS_BINARY_DIR}/include/reactos 
-h ${REACTOS_BINARY_DIR}/include/reactos)
  endmacro()

  #pseh lib, needed with mingw

Modified: trunk/reactos/lib/3rdparty/mingw/CMakeLists.txt
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/lib/3rdparty/mingw/CMakeLists.txt?rev=53730&r1=53729&r2

Re: [ros-dev] Qemu Recoverable Assertion when Loading Gecko

[Jérôme Gardou]

Le 18/11/2011 01:07, James Tabor a écrit :

Head up on this one. It's recoverable by just typing "cont" and it goes on.

(dll/ntdll/ldr/ldrutils.c:1177) Overlapping DLL:
C:\ReactOS\system32\oleaut32.dll
WARNING:  MmFlushVirtualMemory at ntoskrnl/mm/ARM3/virtual.c:1044 is
UNIMPLEMENTED!
fixme:(dll/win32/wintrust/register.c:1161) stub
(dll/ntdll/ldr/ldrutils.c:1138) LDR: LdrpMapDll Relocating Image Name
C:\ReactOS\system32\mshtml.dll (7665 ->  014C)
(dll/ntdll/ldr/ldrutils.c:1177) Overlapping DLL:
C:\ReactOS\System32\setupapi.dll
(ntoskrnl/se/semgr.c:299) SidInToken Calls: 4
Assertion 'RtlCheckBit(&MiUserPfnBitMap, (ULONG)Page)' failed at
ntoskrnl/mm/freelist.c line 127
Entered debugger on embedded INT3 at 0x0008:0x80904efe.
kdb:>  bt
Eip:

Frames:
















<0001>
kdb:>  cont
Assertion 'RtlCheckBit(&MiUserPfnBitMap, (ULONG)Page)' failed at
ntoskrnl/mm/freelist.c line 127
Entered debugger on embedded INT3 at 0x0008:0x80904efe.
kdb:>  cont
(subsystems/win32/win32k/ntuser/keyboard.c:1066) err: No Window for Translate.
(dll/ntdll/ldr/ldrutils.c:1138) LDR: LdrpMapDll Relocating Image Name
xul.dll (1000 ->  01DB)
(dll/ntdll/ldr/ldrutils.c:1177) Overlapping DLL: C:\ReactOS\system32\
\1.0.0\wine_gecko\xpcom.dll

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Hi James!

I put this ASSERT here to check, as Cameron just pointed, that we don't 
remove a PFN entry from user bitmap when it already has or never was in 
it. I hoped someone would trigger it. I think you deserve a "thank you" :-)


So let's just fix this one, it can't do any harm.

Btw, do you mean by "loading gecko", the very instant when mshtml.dll 
gets registered in 3rd stage? Isn't it startling how it coincides with 
bug 5857 ?


Best regards.
Jérôme

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Qemu Recoverable Assertion when Loading Gecko

[Jérôme Gardou]

Le 18/11/2011 21:08, James Tabor a écrit :

Hi!

2011/11/18 Jérôme Gardou:

Hi James!

I put this ASSERT here to check, as Cameron just pointed, that we don't
remove a PFN entry from user bitmap when it already has or never was in it.
I hoped someone would trigger it. I think you deserve a "thank you" :-)

So let's just fix this one, it can't do any harm.

Btw, do you mean by "loading gecko", the very instant when mshtml.dll gets
registered in 3rd stage? Isn't it startling how it coincides with bug 5857 ?

Best regards.
Jérôme

Something the installer was doing I guess, in most cases more than 10
hits at this point. Running DOSEmu hits it every time to the point of
having to kill Qemu. The fix for me last night was commenting the
assert out. To continue my testing.

Hoping I'm not the only one but if I am, QEMU emulator version 0.13.0
(qemu-kvm-0.13.0) Fedroa 12/13/14. Haven't tested Slackware 13.x and
hardware yet.

Thanks,
James

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Out of curiosity, how much RAm did you allocate for your VM ?

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 54462: [RTL] - explicitly truncate some values, so it doesn't count as an error for compiler/MSVC runtime checker

[Jérôme Gardou]

Here the variable is an ULONGLONG and we pass it to a macro that casts 
it to a DWORD, and that's what it should do. Although casting and 
truncating is the same from a "normal" compiler point of view, a run 
time checker would raise a warning if you cast a value superior to 
0x to a DWORD. Truncating it explicitly tells it "yes, I 
truncate this value, not for avoiding compiler warning, but because 
that's what I want". See r54460 to see which kind of bugs such checkers 
could help to fix.


See also http://msdn.microsoft.com/en-us/magazine/cc301374.aspx for some 
in depth details, and, of course, cl documentation.

Also, gcc has this kind of functionalities, it's called GNAT.

Mit freundlichen Grüssen. :-)
Jérôme

Le 24/11/2011 00:03, Timo Kreuzer a écrit :

That doesn't make much sense.
Whats the point of the LOWORD() macro, if not truncating it ?
Fix the macro if its broken.


Am 20.11.2011 20:45, schrieb jgar...@svn.reactos.org:

Author: jgardou
Date: Sun Nov 20 19:45:06 2011
New Revision: 54462

URL: http://svn.reactos.org/svn/reactos?rev=54462&view=rev
Log:
[RTL]
- explicitly truncate some values, so it doesn't count as an error 
for compiler/MSVC runtime checker


Modified:
 trunk/reactos/lib/rtl/image.c

Modified: trunk/reactos/lib/rtl/image.c
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/lib/rtl/image.c?rev=54462&r1=54461&r2=54462&view=diff
== 


--- trunk/reactos/lib/rtl/image.c [iso-8859-1] (original)
+++ trunk/reactos/lib/rtl/image.c [iso-8859-1] Sun Nov 20 19:45:06 2011
@@ -369,7 +369,7 @@
  {
  SHORT Offset;
  USHORT Type;
-USHORT i;
+ULONG i;
  PUSHORT ShortPtr;
  PULONG LongPtr;
  PULONGLONG LongLongPtr;
@@ -379,7 +379,6 @@
  Offset = SWAPW(*TypeOffset)&  0xFFF;
  Type = SWAPW(*TypeOffset)>>  12;
  ShortPtr = (PUSHORT)(RVA(Address, Offset));
-
  /*
  * Don't relocate within the relocation section itself.
  * GCC/LD generates sometimes relocation records for the 
relocation section.

@@ -398,16 +397,16 @@
  break;

  case IMAGE_REL_BASED_HIGH:
-*ShortPtr = HIWORD(MAKELONG(0, *ShortPtr) + (LONG)Delta);
+*ShortPtr = HIWORD(MAKELONG(0, *ShortPtr) + (Delta&  
0x));

  break;

  case IMAGE_REL_BASED_LOW:
-*ShortPtr = SWAPW(*ShortPtr) + LOWORD(Delta);
+*ShortPtr = SWAPW(*ShortPtr) + LOWORD(Delta&  0x);
  break;

  case IMAGE_REL_BASED_HIGHLOW:
  LongPtr = (PULONG)RVA(Address, Offset);
-*LongPtr = SWAPD(*LongPtr) + (ULONG)Delta;
+*LongPtr = SWAPD(*LongPtr) + (Delta&  0x);
  break;

  case IMAGE_REL_BASED_DIR64:






___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 54462: [RTL] - explicitly truncate some values, so it doesn't count as an error for compiler/MSVC runtime checker

[Jérôme Gardou]

Le 24/11/2011 09:04, Aleksey Bragin a écrit :

On 24.11.2011 3:27, Jérôme Gardou wrote:

-*ShortPtr = SWAPW(*ShortPtr) + LOWORD(Delta);
+*ShortPtr = SWAPW(*ShortPtr) + LOWORD(Delta&  0x); 
Maybe turn off this "feature" of MSVC checker then? Excuse me, but 
it's literally a code pollution. Especially the above case, of firstly 
ANDing with 0x, and *then* applying LOWORD (which would not change 
anything at all).


Or, as Timo said, maybe fix the macro? Move the cast elsewhere, so at 
first you &, and only then cast?



WBR,
Aleskey.

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

This one is a mistake on my side.

And the macro is correct. The right thing to do is & and then casting, 
as you say.
BTW, this feature is of by default, you have to turn it on with the /RTC 
flag.


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[ros-dev] November meeting minutes are there.

[Jérôme Gardou]

You will find them on the forum :
http://reactos.org/forum/viewtopic.php?f=2&t=9918

Best regards.
Jérôme

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 54793: [NEWINFLIB] - use _snwprintf instead of swprintf (MSVC is not compliant with standard here)

[Jérôme Gardou]

Hey Thomas.

I thought _snwprintf was a standard function. Apparently I was wrong.

This is confusing. Is _CRT_NON_CONFORMING_SWPRINTFS a valid GCC define 
too, or does it follow broken behaviour unless -std=c99 is given?


Hapy new year too!
Jérôme.

Le 31/12/2011 16:37, Thomas Faber a écrit :

Hey,

On 2011-12-31 15:33, jgar...@svn.reactos.org wrote:

Author: jgardou
Date: Sat Dec 31 14:33:35 2011
New Revision: 54793

URL: http://svn.reactos.org/svn/reactos?rev=54793&view=rev
Log:
[NEWINFLIB]
- use _snwprintf instead of swprintf (MSVC is not compliant with standard here)

since _snwprintf seems unavailable on Unix, perhaps
-D_CRT_NON_CONFORMING_SWPRINTFS
would be an appropriate solution? That should cause VS2010 (2008 seems to have
the version without a length) to use the non-standard no-length version just
like GCC.
That [1] gets rid of the warnings for me.

Regards (and a happy new year :p),
Tom

[1] http://pastebin.com/4XU2SCXR

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[ros-dev] December 2011 meeting minutes

[Jérôme Gardou]

Hello everybody.

You will find attached to this e-mail the minutes for the meeting of 2011.
A topic as also been opened on the ReactOS forum 
:http://reactos.org/forum/viewtopic.php?f=2&t=10352 



I'm deeply sorry for the delay.

Regards.
Jérôme


2011-12.meeting_minutes.rtf
Description: MS-Word document
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [project-tools] Revision 1363: [ROSBE-UNIX] Implement support for pre-build & post-build hook scripts in RosBE-Unix.

[Jérôme Gardou]

Le 28/01/2012 23:30, Colin Finck a écrit :

pschweit...@svn.reactos.org wrote:
> touch boot/bootdata/packages/reactos.dff.in

We can't put this one-liner into the CMakeLists.txt file?
execute_process should do the job if there is no "touch" command in 
CMake itself.


Your change makes RosBE depend on a very specific file in a very 
specific path of the source tree (=> tree change only possible with an 
updated RosBE). In addition, these hooks separate the build logic 
between CMake and RosBE and pave the way for even more source tree 
dependent changes in RosBE. I like to avoid this.



- Colin

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
I don't know why this is needed at all, but in cmake files you can use 
"cmake -E touch" for portability (windows have no default touch afaik)


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [janderwald] 55447: [DISK_NEW] - Fix compilation of new disk driver - Patch by Alex Ionescu

[Jérôme Gardou]

Le 06/02/2012 07:50, janderw...@svn.reactos.org a écrit :


+if(ARCH MATCHES i386)
+add_target_compile_flags(disk "-mrtd -fno-builtin -Wno-unused-variable 
-Wno-pointer-sign")
+endif()
+


Hey!

Those look very GCC centric. The corresponding flag for MSVC to -mrtd 
would be /Gz. As for other flags, I'm unsure of what -fno-builtin would 
correspond to, and others are only for warnings.


Cheers.
Jérôme.

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [janderwald] 55447: [DISK_NEW] - Fix compilation of new disk driver - Patch by Alex Ionescu

[Jérôme Gardou]

Le 06/02/2012 19:58, Alex Ionescu a écrit :

All of these are only for GCC because MSVC already compiles this correctly.

On 2012-02-06, at 10:07 AM, Jérôme Gardou wrote:


Le 06/02/2012 07:50, janderw...@svn.reactos.org a écrit :

+if(ARCH MATCHES i386)
+add_target_compile_flags(disk "-mrtd -fno-builtin -Wno-unused-variable 
-Wno-pointer-sign")
+endif()
+


Hey!

Those look very GCC centric. The corresponding flag for MSVC to -mrtd would be 
/Gz. As for other flags, I'm unsure of what -fno-builtin would correspond to, 
and others are only for warnings.

Cheers.
Jérôme.

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Are you sure that /Gz is default with cl.exe ? Anyway, those flags 
should be wrapped with if (NOT MSVC) condition.


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 55770: [NTOSKRNL/MM] - finally, release user shared data at process address space cleanup. - release PDE pages that might not be freed at process end. - Let the cal

[Jérôme Gardou]

Le 21/02/2012 01:32, jgar...@svn.reactos.org a écrit :

Author: jgardou
Date: Tue Feb 21 00:32:24 2012
New Revision: 55770

URL: http://svn.reactos.org/svn/reactos?rev=55770&view=rev
Log:
[NTOSKRNL/MM]
  - finally, release user shared data at process address space cleanup.
  - release PDE pages that might not be freed at process end.
  - Let the caller handle PDE release when deleting a PTE
  - restore Richard's ASSERT : All user PDE pages are now freed!

Addendum to log :
When a page maps a Prototype PTE, we can't know if it must be 
deleted before dropping shared reference. Modify ASSERT accordingly.
Restore the ASSERTion that only page fault should provocate the 
creation of the PDE and modify PDE refcounting in pageout code accordingly.


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 56082: [DAMN_IT] - addendum to r56081

[Jérôme Gardou]

Hey!

Can't we add tests to the regular tree, and disable them with a onig 
flag or something. This is getting retarded, and we must be the only 
project separating tests and runtime in their tree.
Every tester should just build them (not speaking about developers...), 
and we include them in nightly builds. For me this separation is just 
pointless...


regards.
Jérôme

Le 07/03/2012 22:46, jgar...@svn.reactos.org a écrit :

Author: jgardou
Date: Wed Mar  7 21:46:15 2012
New Revision: 56082

URL: http://svn.reactos.org/svn/reactos?rev=56082&view=rev
Log:
[DAMN_IT]
  - addendum to r56081

Modified:
 trunk/rostests/apitests/w32kdll/w32kdll_2k3sp2/CMakeLists.txt
 trunk/rostests/apitests/w32kdll/w32kdll_ros/CMakeLists.txt
 trunk/rostests/apitests/w32kdll/w32kdll_vista/CMakeLists.txt
 trunk/rostests/apitests/w32kdll/w32kdll_xpsp2/CMakeLists.txt

Modified: trunk/rostests/apitests/w32kdll/w32kdll_2k3sp2/CMakeLists.txt
URL: 
http://svn.reactos.org/svn/reactos/trunk/rostests/apitests/w32kdll/w32kdll_2k3sp2/CMakeLists.txt?rev=56082&r1=56081&r2=56082&view=diff
==
--- trunk/rostests/apitests/w32kdll/w32kdll_2k3sp2/CMakeLists.txt [iso-8859-1] 
(original)
+++ trunk/rostests/apitests/w32kdll/w32kdll_2k3sp2/CMakeLists.txt [iso-8859-1] 
Wed Mar  7 21:46:15 2012
@@ -1,5 +1,5 @@

-spec2def(w32kdll_2k3sp2.dll w32kdll_2k3sp2.spec)
+spec2def(w32kdll_2k3sp2.dll w32kdll_2k3sp2.spec ADD_IMPORTLIB)

  add_library(w32kdll_2k3sp2 SHARED
  main.c
@@ -9,4 +9,3 @@
  set_entrypoint(w32kdll_2k3sp2 0)

  add_dependencies(w32kdll_2k3sp2 psdk )
-add_importlib_target(w32kdll_2k3sp2.spec w32kdll_2k3sp2.dll)

Modified: trunk/rostests/apitests/w32kdll/w32kdll_ros/CMakeLists.txt
URL: 
http://svn.reactos.org/svn/reactos/trunk/rostests/apitests/w32kdll/w32kdll_ros/CMakeLists.txt?rev=56082&r1=56081&r2=56082&view=diff
==
--- trunk/rostests/apitests/w32kdll/w32kdll_ros/CMakeLists.txt [iso-8859-1] 
(original)
+++ trunk/rostests/apitests/w32kdll/w32kdll_ros/CMakeLists.txt [iso-8859-1] Wed 
Mar  7 21:46:15 2012
@@ -1,5 +1,5 @@

-spec2def(w32kdll_ros.dll w32kdll_ros.spec)
+spec2def(w32kdll_ros.dll w32kdll_ros.spec ADD_IMPORTLIB)

  add_library(w32kdll_ros SHARED
  main.c
@@ -10,4 +10,3 @@
  target_link_libraries(w32kdll_ros win32ksys)

  add_dependencies(w32kdll_ros psdk)
-add_importlib_target(w32kdll_ros.spec w32kdll_ros.dll)

Modified: trunk/rostests/apitests/w32kdll/w32kdll_vista/CMakeLists.txt
URL: 
http://svn.reactos.org/svn/reactos/trunk/rostests/apitests/w32kdll/w32kdll_vista/CMakeLists.txt?rev=56082&r1=56081&r2=56082&view=diff
==
--- trunk/rostests/apitests/w32kdll/w32kdll_vista/CMakeLists.txt [iso-8859-1] 
(original)
+++ trunk/rostests/apitests/w32kdll/w32kdll_vista/CMakeLists.txt [iso-8859-1] 
Wed Mar  7 21:46:15 2012
@@ -1,5 +1,5 @@

-spec2def(w32kdll_dll.spec w32kdll_vista.spec)
+spec2def(w32kdll_vista.spec w32kdll_vista.spec ADD_IMPORTLIB)

  add_library(w32kdll_vista SHARED
  main.c
@@ -8,4 +8,3 @@
  set_entrypoint(w32kdll_vista 0)

  add_dependencies(w32kdll_vista psdk )
-add_importlib_target(w32kdll_vista.spec w32kdll_dll.spec)

Modified: trunk/rostests/apitests/w32kdll/w32kdll_xpsp2/CMakeLists.txt
URL: 
http://svn.reactos.org/svn/reactos/trunk/rostests/apitests/w32kdll/w32kdll_xpsp2/CMakeLists.txt?rev=56082&r1=56081&r2=56082&view=diff
==
--- trunk/rostests/apitests/w32kdll/w32kdll_xpsp2/CMakeLists.txt [iso-8859-1] 
(original)
+++ trunk/rostests/apitests/w32kdll/w32kdll_xpsp2/CMakeLists.txt [iso-8859-1] 
Wed Mar  7 21:46:15 2012
@@ -1,4 +1,4 @@
-spec2def(w32kdll_xpsp2.dll w32kdll_xpsp2.spec)
+spec2def(w32kdll_xpsp2.dll w32kdll_xpsp2.spec ADD_IMPORTLIB)

  add_library(w32kdll_xpsp2 SHARED
  main.c
@@ -6,5 +6,4 @@
  ${CMAKE_CURRENT_BINARY_DIR}/w32kdll_xpsp2.def)
  set_entrypoint(w32kdll_xpsp2 0)

-add_dependencies(w32kdll_xpsp2 psdk )
-add_importlib_target(w32kdll_xpsp2.spec w32kdll_xpsp2.dll)
+add_dependencies(w32kdll_xpsp2 psdk)





___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 56082: [DAMN_IT] - addendum to r56081

[Jérôme Gardou]

Le 07/03/2012 22:50, Jérôme Gardou a écrit :

Hey!

Can't we add tests to the regular tree, and disable them with a onig 
flag or something. This is getting retarded, and we must be the only 
project separating tests and runtime in their tree.
Every tester should just build them (not speaking about 
developers...), and we include them in nightly builds. For me this 
separation is just pointless...


regards.
Jérôme

In "onig flag", you should read "config flag"...

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [akhaldi] 56104: [CMAKE] * Fix a typo.

[Jérôme Gardou]

Le 10/03/2012 19:02, akha...@svn.reactos.org a écrit :

Author: akhaldi
Date: Sat Mar 10 18:02:40 2012
New Revision: 56104

URL: http://svn.reactos.org/svn/reactos?rev=56104&view=rev
Log:
[CMAKE]
* Fix a typo.

Modified:
 trunk/reactos/cmake/msvc.cmake

Modified: trunk/reactos/cmake/msvc.cmake
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/cmake/msvc.cmake?rev=56104&r1=56103&r2=56104&view=diff
==
--- trunk/reactos/cmake/msvc.cmake [iso-8859-1] (original)
+++ trunk/reactos/cmake/msvc.cmake [iso-8859-1] Sat Mar 10 18:02:40 2012
@@ -178,7 +178,7 @@

  # add our library
  # NOTE: as stub file and def file are generated in one pass, 
depending on one is like depending on the other
-_add_library(lib${_file} STATIC EXCLUDE_FROM_ALL
+add_library(lib${_file} STATIC EXCLUDE_FROM_ALL
  ${CMAKE_CURRENT_BINARY_DIR}/lib${_file}_stubs.asm)

  # set correct "link rule"



it wasn't a typo :-)

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 56947: [WIN32SS/GDI]

[Jérôme Gardou]

OOPS.. Sorry. Changelog should have been:
[WIN32SS/NTGDI]
- Associate NULL surface for newly created memory DCs.

jgar...@svn.reactos.org a écrit :

Author: jgardou
Date: Mon Jul 23 10:12:53 2012
New Revision: 56947

URL: http://svn.reactos.org/svn/reactos?rev=56947&view=rev
Log:
[WIN32SS/GDI]

Modified:
 trunk/reactos/win32ss/gdi/eng/engbrush.c
 trunk/reactos/win32ss/gdi/ntgdi/bitblt.c
 trunk/reactos/win32ss/gdi/ntgdi/bitmaps.c
 trunk/reactos/win32ss/gdi/ntgdi/dclife.c
 trunk/reactos/win32ss/gdi/ntgdi/dcobjs.c

Modified: trunk/reactos/win32ss/gdi/eng/engbrush.c
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/eng/engbrush.c?rev=56947&r1=56946&r2=56947&view=diff
==
--- trunk/reactos/win32ss/gdi/eng/engbrush.c [iso-8859-1] (original)
+++ trunk/reactos/win32ss/gdi/eng/engbrush.c [iso-8859-1] Mon Jul 23 10:12:53 
2012
@@ -67,6 +67,9 @@
  pebo->crCurrentText = pdc->pdcattr->crForegroundClr;

  pebo->psurfTrg = pdc->dclevel.pSurface;
+/* We are initializing for a new memory DC */
+if(!pebo->psurfTrg)
+pebo->psurfTrg = psurfDefaultBitmap;
  ASSERT(pebo->psurfTrg);
  ASSERT(pebo->psurfTrg->ppal);


Modified: trunk/reactos/win32ss/gdi/ntgdi/bitblt.c
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/bitblt.c?rev=56947&r1=56946&r2=56947&view=diff
==
--- trunk/reactos/win32ss/gdi/ntgdi/bitblt.c [iso-8859-1] (original)
+++ trunk/reactos/win32ss/gdi/ntgdi/bitblt.c [iso-8859-1] Mon Jul 23 10:12:53 
2012
@@ -807,9 +807,11 @@
  SURFACE *psurf;
  POINTL BrushOrigin;
  BOOL ret;
-PBRUSH pbrush = pebo->pbrush;
+PBRUSH pbrush;

  ASSERT(pebo);
+pbrush = pebo->pbrush;
+ASSERT(pbrush);

  FIXUP_ROP(dwRop);


Modified: trunk/reactos/win32ss/gdi/ntgdi/bitmaps.c
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/bitmaps.c?rev=56947&r1=56946&r2=56947&view=diff
==
--- trunk/reactos/win32ss/gdi/ntgdi/bitmaps.c [iso-8859-1] (original)
+++ trunk/reactos/win32ss/gdi/ntgdi/bitmaps.c [iso-8859-1] Mon Jul 23 10:12:53 
2012
@@ -259,6 +259,7 @@
  DIBSECTION dibs;
  INT Count;
  PSURFACE psurf = Dc->dclevel.pSurface;
+if(!psurf) psurf = psurfDefaultBitmap;
  Count = BITMAP_GetObject(psurf, sizeof(dibs), &dibs);

  if (Count == sizeof(BITMAP))

Modified: trunk/reactos/win32ss/gdi/ntgdi/dclife.c
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/dclife.c?rev=56947&r1=56946&r2=56947&view=diff
==
--- trunk/reactos/win32ss/gdi/ntgdi/dclife.c [iso-8859-1] (original)
+++ trunk/reactos/win32ss/gdi/ntgdi/dclife.c [iso-8859-1] Mon Jul 23 10:12:53 
2012
@@ -180,7 +180,7 @@
  pdc->dclevel.pSurface = NULL;

  // FIXME: HACK, because our code expects a surface
-pdc->dclevel.pSurface = 
SURFACE_ShareLockSurface(StockObjects[DEFAULT_BITMAP]);
+// pdc->dclevel.pSurface = 
SURFACE_ShareLockSurface(StockObjects[DEFAULT_BITMAP]);

  pdc->erclBounds.left = 0;
  pdc->erclBounds.top = 0;
@@ -271,12 +271,9 @@
pdc->dclevel.ptlBrushOrigin.x = 0;
pdc->dclevel.ptlBrushOrigin.y = 0;
pdc->dcattr.ptlBrushOrigin = pdc->dclevel.ptlBrushOrigin;
-
-/* Initialize EBRUSHOBJs */
-EBRUSHOBJ_vInit(&pdc->eboFill, pdc->dclevel.pbrFill, pdc);
-EBRUSHOBJ_vInit(&pdc->eboLine, pdc->dclevel.pbrLine, pdc);
+
+/* Init text brush */
  EBRUSHOBJ_vInit(&pdc->eboText, pbrDefaultBrush, pdc);
-EBRUSHOBJ_vInit(&pdc->eboBackground, pbrDefaultBrush, pdc);

  /* Setup fill data */
pdc->dcattr.jROP2 = R2_COPYPEN;
@@ -424,9 +421,8 @@
  pdc->dclevel.pbrFill = BRUSH_ShareLockBrush(pdc->pdcattr->hbrush);
  pdc->dclevel.pbrLine = PEN_ShareLockPen(pdc->pdcattr->hpen);

-/* Update the EBRUSHOBJs */
-EBRUSHOBJ_vUpdate(&pdc->eboFill, pdc->dclevel.pbrFill, pdc);
-EBRUSHOBJ_vUpdate(&pdc->eboLine, pdc->dclevel.pbrLine, pdc);
+/* Mark them as dirty */
+pdc->pdcattr->ulDirty_ |= DIRTY_FILL|DIRTY_LINE;

  /* Allocate or free DC attribute */
  if (ulOwner == GDI_OBJ_HMGR_PUBLIC || ulOwner == GDI_OBJ_HMGR_NONE)
@@ -796,7 +792,7 @@
  DC_bAllocDcAttr(pdcNew);

  // HACK!
-DC_vSelectSurface(pdcNew, psurfDefaultBitmap);
+//DC_vSelectSurface(pdcNew, psurfDefaultBitmap);

  DC_UnlockDc(pdcNew);


Modified: trunk/reactos/win32ss/gdi/ntgdi/dcobjs.c
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/dcobjs.c?rev=56947&r1=56946&r2=56947&view=diff
==
--- trunk/reactos/win32ss/gdi/ntgdi/dcobjs.c [iso-8859-1] (original)
+++ trunk/reactos/win32ss/gdi/ntgdi/dc

Re: [ros-dev] [ros-diffs] [jgardou] 57124: [WINED3D] - MSVC needs INFINITY and NAN from wine/port.h. It can't be included from a header Will be sent upstream

[Jérôme Gardou]

Hi.

I have no idea. I wanted to send the first patch to wine, and when 
testing the compilation under linux, I had this error "wine/port.h can't 
be included from a header." (or something like this).


That was before I discovered that Wine code base is good regarding this 
issue, all source files include it before wined3d_private.h. It's just 
that our wined3d is slightly outdated. A sync would permanently solve 
this issue.


Cheers!
Jérôme.

Thomas Faber a écrit :

Hi,

On 2012-08-21 15:38, jgar...@svn.reactos.org wrote:

URL:http://svn.reactos.org/svn/reactos?rev=57124&view=rev
Log:
[WINED3D]
- MSVC needs INFINITY and NAN from wine/port.h.
It can't be included from a header
Will be sent upstream


can you explain what's wrong with including it from a header?
I was under the impression we had fixed the infinity/nan stuff properly
on Wine's side by adding it all to port.h.

Thanks!

-Thomas

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 57129: [WIN32K] - Use the right surface for direct DCs in DIB transfer functions It could have changed with a display settings change

[Jérôme Gardou]

Oh, right, I forgot about the lock...

Commit your rewrite :-)

Timo Kreuzer a écrit :


Hmmm
I don't think that this is a good idea. We must call DC_vPrepareForBlit
to lock the surfaces, otherwise we run into race conditions.
And we should really also care for the mouse cursor, otherwise we might
make it unhappy.
Anyway, I don't care about this code, since I already rewrote it :D
Anyway, I think it's time to ASSERT device locks.

Am 22.08.2012 18:45, schrieb jgar...@svn.reactos.org:

Author: jgardou
Date: Wed Aug 22 16:45:49 2012
New Revision: 57129

URL: http://svn.reactos.org/svn/reactos?rev=57129&view=rev
Log:
[WIN32K]
- Use the right surface for direct DCs in DIB transfer functions
It could have changed with a display settings change

Modified:
 trunk/reactos/win32ss/gdi/ntgdi/dibobj.c

Modified: trunk/reactos/win32ss/gdi/ntgdi/dibobj.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/dibobj.c?rev=57129&r1=57128&r2=57129&view=diff

==

--- trunk/reactos/win32ss/gdi/ntgdi/dibobj.c [iso-8859-1] (original)
+++ trunk/reactos/win32ss/gdi/ntgdi/dibobj.c [iso-8859-1] Wed Aug 22
16:45:49 2012
@@ -447,8 +447,16 @@
  DC_UnlockDc(pDC);
  goto Exit2;
  }
-
-pSurf = pDC->dclevel.pSurface;
+
+/*
+ * Select the right surface.
+ * NOTE: we don't call DC_vPrepareDCsForBlit, because we don't
+ * care about mouse, visible region or brushes in this API.
+ */
+if(pDC->dctype == DCTYPE_DIRECT)
+pSurf = pDC->ppdev->pSurface;
+else
+pSurf = pDC->dclevel.pSurface;
  if (!pSurf)
  {
  DC_UnlockDc(pDC);
@@ -1113,7 +1121,15 @@
  goto cleanup;
  }
-psurfDst = pdc->dclevel.pSurface;
+/*
+ * Select the right surface.
+ * NOTE: we don't call DC_vPrepareDCsForBlit, because we don't
+ * care about mouse, visible region or brushes in this API.
+ */
+if(pdc->dctype == DCTYPE_DIRECT)
+psurfDst = pdc->ppdev->pSurface;
+else
+psurfDst = pdc->dclevel.pSurface;
  if (!psurfDst)
  {
  // CHECKME






___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 57171: [MINGWEX] - mark DllMain as a weak symbol for GCC. - supply a stubbed DllMain for MSVC. - DllMain is optional, and some DLLs don't implement it. That doesn't

[Jérôme Gardou]

Hi.

Please see the inlined answers.

Timo Kreuzer a écrit :

Hi,

I don't agree with these changes.

If we need a DllEntry in the lib, then we should use the one that is
provided by mingw-w64 (all this code is 100% mingw-w64). It simply
returns true (thats exactly what the one in MS CRT does) and works for
gcc and MSVC.

There is DllEntryPoint in the code base, but no DllMain. Is it what you
are talking about?


Also what's the point of DisableThreadLibraryCalls() here? As you wrote
yourself, no DllMain only means "I have nothing more to initialize than
the CRT". But this disables the CRT thread initializion, too.
You have a point. If nothing is given, then the programmer could assume 
that nothing happens.
Regarding CRT thread initialization: DisableThreadLibraryCalls means 
that the DLLs ahs nothing to initialize on thread creation, and that the 
loader can gain some performance in skipping this DLL. We have some Dlls 
that call it, and if this is a problem with our CRT, then this is bad.

Quoting MSDN:
"Do not call this function from a DLL that is linked to the static C 
run-time library (CRT). The static CRT requires DLL_THREAD_ATTACH and 
DLL_THREAD_DETATCH notifications to function properly"
Reading between the lines, that means that every CRT thread 
initialization is done in msvcrt.dll, and nowhere else. What we link 
statically to our DLLs shouldn't have anything to do on thread 
initializations.



There is also no need for weak symbols, we can simply call the stub
DllMain, since it doesn't (shouldn't) do anything.
As said in the comment, link.exe choses symbols defined in the object 
files it is given, and then in the libraries. So adding a stubbed 
version of dllmain in our library is harmless (unless someone puts his 
DllMain in a static library and links to that library.) I don't really 
know about ld behaviour regarding this case, and the 
"--allow-multiple-definition" option of ld (see 
http://sourceware.org/binutils/docs-2.22/ld/Options.html#Options ) 
scares me.




Regards,
Timo


Regards.
Jérôme



Am 27.08.2012 01:31, schrieb jgar...@svn.reactos.org:

Author: jgardou
Date: Sun Aug 26 23:31:49 2012
New Revision: 57171

URL: http://svn.reactos.org/svn/reactos?rev=57171&view=rev
Log:
[MINGWEX]
- mark DllMain as a weak symbol for GCC.
- supply a stubbed DllMain for MSVC.
- DllMain is optional, and some DLLs don't implement it. That doesn't
mean that they have no entry point, it means "I have nothing more to
initialize than the CRT".

Added:
 trunk/reactos/lib/sdk/crt/startup/mscdllmain.c   (with props)
Modified:
 trunk/reactos/lib/sdk/crt/msvcrtex.cmake
 trunk/reactos/lib/sdk/crt/startup/crtdll.c

Modified: trunk/reactos/lib/sdk/crt/msvcrtex.cmake
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/lib/sdk/crt/msvcrtex.cmake?rev=57171&r1=57170&r2=57171&view=diff

==

--- trunk/reactos/lib/sdk/crt/msvcrtex.cmake [iso-8859-1] (original)
+++ trunk/reactos/lib/sdk/crt/msvcrtex.cmake [iso-8859-1] Sun Aug 26
23:31:49 2012
@@ -66,7 +66,9 @@
  endif()
  if(MSVC)
-list(APPEND MSVCRTEX_SOURCE startup/mscmain.c)
+list(APPEND MSVCRTEX_SOURCE
+startup/mscmain.c
+startup/mscdllmain.c)
  else()
  list(APPEND MSVCRTEX_SOURCE startup/gccmain.c)
  endif()

Modified: trunk/reactos/lib/sdk/crt/startup/crtdll.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/lib/sdk/crt/startup/crtdll.c?rev=57171&r1=57170&r2=57171&view=diff

==

--- trunk/reactos/lib/sdk/crt/startup/crtdll.c [iso-8859-1] (original)
+++ trunk/reactos/lib/sdk/crt/startup/crtdll.c [iso-8859-1] Sun Aug 26
23:31:49 2012
@@ -50,7 +50,19 @@
  extern int mingw_app_type;
+/*
+ * It is possible that a DLL provides no DllMain entry point.
+ * Mark it as a weak symbol for GCC.
+ * Tests show that at link time, MSVC looks for a function first in
the object files provided, and then
+ * in the libraries. This means that we must provide a basic
implementation in msvcrtex, which will be used
+ * if none is found in the object files provided to link.exe.
+ * This also means that we can't rely on a DllMain function
implemented in a static library when linking a DLL.
+ */
+#ifdef __GNUC__
+extern WINBOOL WINAPI DllMain (HANDLE hDllHandle, DWORD dwReason,
LPVOID lpreserved) __attribute__((weak));
+#else
  extern WINBOOL WINAPI DllMain (HANDLE hDllHandle, DWORD dwReason,
LPVOID lpreserved);
+#endif
  extern WINBOOL WINAPI DllEntryPoint (HANDLE, DWORD, LPVOID);
@@ -198,10 +210,12 @@
  }
if (dwReason == DLL_PROCESS_ATTACH)
  __main ();
-  retcode = DllMain(hDllHandle,dwReason,lpreserved);
+  if(DllMain)
+retcode = DllMain(hDllHandle,dwReason,lpreserved);
if (dwReason == DLL_PROCESS_ATTACH && ! retcode)
  {
-DllMain (hDllHandle, DLL_PROCESS_DETACH, lpreserved);
+if(DllMain)
+  DllMain (hDllHandle, DLL_PROCESS_DETACH, lpreserved);

Re: [ros-dev] [ros-diffs] [tfaber] 57485: [SHELL32] - Fix what might finally be the last missing "this->" instances left over from the C++ conversion (used a regex this time)

[Jérôme Gardou]

Isn't there somewhere some compiler warning for such ambiguation?

Le Fri, 05 Oct 2012 10:41:47 +0200,
Thomas Faber  a écrit :

> Yeah, that would certainly be a more sensible convention.
> I wasn't planning on refactoring all of shell32 any time soon
> though. :|
> 
> We accept patches™ ;)
> 
> 
> On 2012-10-05 10:30, Timo Kreuzer wrote:
> > Shouldn't member variables rather be prefixed with m_?
> > 
> > 
> > Am 05.10.2012 01:46, schrieb tfa...@svn.reactos.org:
> >> Author: tfaber
> >> Date: Thu Oct  4 23:46:59 2012
> >> New Revision: 57485
> >>
> >> URL: http://svn.reactos.org/svn/reactos?rev=57485&view=rev
> >> Log:
> >> [SHELL32]
> >> - Fix what might finally be the last missing "this->" instances
> >> left over from the C++ conversion (used a regex this time)
> >>
> >> Modified:
> >>  trunk/reactos/dll/win32/shell32/folders/cpanel.cpp
> >>  trunk/reactos/dll/win32/shell32/folders/mycomp.cpp
> >>  trunk/reactos/dll/win32/shell32/shlview.cpp
> >>
> >> Modified: trunk/reactos/dll/win32/shell32/folders/cpanel.cpp
> >> URL:
> >> http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/shell32/folders/cpanel.cpp?rev=57485&r1=57484&r2=57485&view=diff
> >> ==
> >> --- trunk/reactos/dll/win32/shell32/folders/cpanel.cpp
> >> [iso-8859-1] (original) +++
> >> trunk/reactos/dll/win32/shell32/folders/cpanel.cpp [iso-8859-1]
> >> Thu Oct  4 23:46:59 2012 @@ -540,7 +540,7 @@ // pObj =
> >> (IContextMenu *)this; this->apidl = apidl;
> >> -cidl = cidl;
> >> +this->cidl = cidl;
> >>   pObj->AddRef();
> >>   hr = S_OK;
> >>   } else if (IsEqualIID(riid, IID_IDataObject) && (cidl >=
> >> 1)) {
> >>
> >> Modified: trunk/reactos/dll/win32/shell32/folders/mycomp.cpp
> >> URL:
> >> http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/shell32/folders/mycomp.cpp?rev=57485&r1=57484&r2=57485&view=diff
> >> ==
> >> --- trunk/reactos/dll/win32/shell32/folders/mycomp.cpp
> >> [iso-8859-1] (original) +++
> >> trunk/reactos/dll/win32/shell32/folders/mycomp.cpp [iso-8859-1]
> >> Thu Oct  4 23:46:59 2012 @@ -728,7 +728,7 @@ wcscpy(sName, lpName);
> >>   SHFree(sName);
> >> -sName = sName;
> >> +this->sName = sName;
> >>   TRACE("result %s\n", debugstr_w(sName));
> >>   return S_OK;
> >>   }
> >>
> >> Modified: trunk/reactos/dll/win32/shell32/shlview.cpp
> >> URL:
> >> http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/shell32/shlview.cpp?rev=57485&r1=57484&r2=57485&view=diff
> >> ==
> >> --- trunk/reactos/dll/win32/shell32/shlview.cpp [iso-8859-1]
> >> (original) +++ trunk/reactos/dll/win32/shell32/shlview.cpp
> >> [iso-8859-1] Thu Oct  4 23:46:59 2012 @@ -2828,7 +2828,7 @@
> >> FIXME("partial stub: %p %08x %08x %p\n", this, aspects, advf,
> >> pAdvSink); /* FIXME: we set the AdviseSink, but never use it to
> >> send any advice */
> >> -pAdvSink = pAdvSink;
> >> +this->pAdvSink = pAdvSink;
> >>   dwAspects = aspects;
> >>   dwAdvf = advf;
> 
> 
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 57909: [INCLUDE/CRT] - _CRT_NON_CONFORMING_SWPRINTFS is not relevant for us.

[Jérôme Gardou]

Windows XP and windows 2k3 msvcrt.dll don't export _swprintf, making
any test compiled with this define unusable on them and using swprintf
unusable on this platforms.

Also, from a pure testing point of view, we'd better test functions
that we should export ;-)


Le Fri, 14 Dec 2012 21:33:47 +0100,
Timo Kreuzer  a écrit :

> 
> The reason for this define is to allow swprintf etc., wich is then an 
> alias for _swprintf, which we do implement.
> I don't see why this should be disabled.
> 
> 
> 
> Am 13.12.2012 20:21, schrieb jgar...@svn.reactos.org:
> > Author: jgardou
> > Date: Thu Dec 13 19:21:30 2012
> > New Revision: 57909
> >
> > URL: http://svn.reactos.org/svn/reactos?rev=57909&view=rev
> > Log:
> > [INCLUDE/CRT]
> >   - _CRT_NON_CONFORMING_SWPRINTFS is not relevant for us.
> >
> > Modified:
> >  trunk/reactos/include/crt/stdio.h
> >  trunk/reactos/include/crt/wchar.h
> >
> > Modified: trunk/reactos/include/crt/stdio.h
> > URL:
> > http://svn.reactos.org/svn/reactos/trunk/reactos/include/crt/stdio.h?rev=57909&r1=57908&r2=57909&view=diff
> > ==
> > --- trunk/reactos/include/crt/stdio.h [iso-8859-1] (original) +++
> > trunk/reactos/include/crt/stdio.h [iso-8859-1] Thu Dec 13 19:21:30
> > 2012 @@ -322,12 +322,14 @@ #include 
> >   #endif
> >   
> > +#if 0 //this is for MSVCRT80 and higher, which we don't use nor
> > implement #ifdef _CRT_NON_CONFORMING_SWPRINTFS
> >   #ifndef __cplusplus
> >   #define swprintf _swprintf
> >   #define vswprintf _vswprintf
> >   #define _swprintf_l __swprintf_l
> >   #define _vswprintf_l __vswprintf_l
> > +#endif
> >   #endif
> >   #endif
> >   
> >
> > Modified: trunk/reactos/include/crt/wchar.h
> > URL:
> > http://svn.reactos.org/svn/reactos/trunk/reactos/include/crt/wchar.h?rev=57909&r1=57908&r2=57909&view=diff
> > ==
> > --- trunk/reactos/include/crt/wchar.h [iso-8859-1] (original) +++
> > trunk/reactos/include/crt/wchar.h [iso-8859-1] Thu Dec 13 19:21:30
> > 2012 @@ -561,12 +561,14 @@ _CRTIMP int __cdecl __swprintf_l(wchar_t
> > *_Dest,const wchar_t *_Format,_locale_t _Plocinfo,...); _CRTIMP int
> > __cdecl __vswprintf_l(wchar_t *_Dest,const wchar_t
> > *_Format,_locale_t _Plocinfo,va_list _Args); +#if 0 //this is for
> > MSVCRT80 and higher, which we don't use nor implement #ifdef
> > _CRT_NON_CONFORMING_SWPRINTFS #ifndef __cplusplus
> >   #define swprintf _swprintf
> >   #define vswprintf _vswprintf
> >   #define _swprintf_l __swprintf_l
> >   #define _vswprintf_l __vswprintf_l
> > +#endif
> >   #endif
> >   #endif
> >   
> >
> >
> >
> 
> 
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [hbelusca] 58016: [MSVCRT] Export __crtLCMapStringW and correct __crtLCMapStringA: their prototypes are : int CDECL __crtLCMapStringW(LCID lcid, DWORD mapflags, const wchar_t

[Jérôme Gardou]

I think that in the spec files semantics, destination strings are just 
buffers and should be considered as pointers.


hbelu...@svn.reactos.org a écrit :

Author: hbelusca
Date: Wed Dec 26 19:26:08 2012
New Revision: 58016

URL: http://svn.reactos.org/svn/reactos?rev=58016&view=rev
Log:
[MSVCRT]
Export __crtLCMapStringW and correct __crtLCMapStringA: their prototypes are :

int CDECL __crtLCMapStringW(LCID lcid, DWORD mapflags, const wchar_t *src,
 int srclen, wchar_t *dst, int dstlen, unsigned int codepage, int xflag)

and

int CDECL __crtLCMapStringA(LCID lcid, DWORD mapflags, const char* src,
 int srclen, char* dst, int dstlen, unsigned int codepage, int xflag)

Needed by SVN.

Modified:
 trunk/reactos/dll/win32/msvcrt/msvcrt.spec

Modified: trunk/reactos/dll/win32/msvcrt/msvcrt.spec
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msvcrt/msvcrt.spec?rev=58016&r1=58015&r2=58016&view=diff
==
--- trunk/reactos/dll/win32/msvcrt/msvcrt.spec [iso-8859-1] (original)
+++ trunk/reactos/dll/win32/msvcrt/msvcrt.spec [iso-8859-1] Wed Dec 26 19:26:08 
2012
@@ -143,8 +143,8 @@
  @ cdecl __crtCompareStringW(long long wstr long wstr long) 
kernel32.CompareStringW
  @ cdecl __crtGetLocaleInfoW(long long ptr long) kernel32.GetLocaleInfoW
  @ cdecl __crtGetStringTypeW(long long wstr long ptr)
-@ cdecl __crtLCMapStringA(long long str long ptr long long long)
-# stub __crtLCMapStringW
+@ cdecl __crtLCMapStringA(long long str long str long long long)
+@ cdecl __crtLCMapStringW(long long wstr long wstr long long long)
  @ cdecl __daylight() __p__daylight
  @ cdecl __dllonexit(ptr ptr ptr)
  @ cdecl __doserrno()




___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [hbelusca] 58016: [MSVCRT] Export __crtLCMapStringW and correct __crtLCMapStringA: their prototypes are : int CDECL __crtLCMapStringW(LCID lcid, DWORD mapflags, const wchar_t

[Jérôme Gardou]

For input strings. I think that's not relevant to us anyway, as wine 
uses this for relay tracing, that we don't use nor have any 
implementation of.


Jérôme.

Hermès BÉLUSCA - MAÏTO a écrit :

So why do 'str' and 'wstr' exist ?

Hermès.

-Message d'origine-
De : ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] De la 
part de Jérôme Gardou
Envoyé : vendredi 28 décembre 2012 00:17
À : ros-dev@reactos.org
Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 58016: [MSVCRT] Export 
__crtLCMapStringW and correct __crtLCMapStringA: their prototypes are : int 
CDECL __crtLCMapStringW(LCID lcid, DWORD mapflags, const wchar_t *src, int 
srclen, wcha...

I think that in the spec files semantics, destination strings are just buffers 
and should be considered as pointers.

hbelu...@svn.reactos.org a écrit :

Author: hbelusca
Date: Wed Dec 26 19:26:08 2012
New Revision: 58016

URL: http://svn.reactos.org/svn/reactos?rev=58016&view=rev
Log:
[MSVCRT]
Export __crtLCMapStringW and correct __crtLCMapStringA: their prototypes are :

int CDECL __crtLCMapStringW(LCID lcid, DWORD mapflags, const wchar_t *src,
  int srclen, wchar_t *dst, int dstlen, unsigned int codepage, int
xflag)

and

int CDECL __crtLCMapStringA(LCID lcid, DWORD mapflags, const char* src,
  int srclen, char* dst, int dstlen, unsigned int codepage, int
xflag)

Needed by SVN.

Modified:
  trunk/reactos/dll/win32/msvcrt/msvcrt.spec

Modified: trunk/reactos/dll/win32/msvcrt/msvcrt.spec
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msvcrt/msvc
rt.spec?rev=58016&r1=58015&r2=58016&view=diff
==

--- trunk/reactos/dll/win32/msvcrt/msvcrt.spec [iso-8859-1] (original)
+++ trunk/reactos/dll/win32/msvcrt/msvcrt.spec [iso-8859-1] Wed Dec 26
+++ 19:26:08 2012
@@ -143,8 +143,8 @@
   @ cdecl __crtCompareStringW(long long wstr long wstr long) 
kernel32.CompareStringW
   @ cdecl __crtGetLocaleInfoW(long long ptr long) kernel32.GetLocaleInfoW
   @ cdecl __crtGetStringTypeW(long long wstr long ptr) -@ cdecl
__crtLCMapStringA(long long str long ptr long long long) -# stub
__crtLCMapStringW
+@ cdecl __crtLCMapStringA(long long str long str long long long) @
+cdecl __crtLCMapStringW(long long wstr long wstr long long long)
   @ cdecl __daylight() __p__daylight
   @ cdecl __dllonexit(ptr ptr ptr)
   @ cdecl __doserrno()




___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [tkreuzer] 58101: [WIN32K] Revert the revert from r58091 and apply a correct fix (passed parameters to RECTL_vSetRect() in wrong order)

[Jérôme Gardou]

Thank you for looking into this, I am not really available for coding in 
reactos at the moment.


Greetings.
Jérôme

tkreu...@svn.reactos.org a écrit :

Author: tkreuzer
Date: Wed Jan  2 14:52:34 2013
New Revision: 58101

URL: http://svn.reactos.org/svn/reactos?rev=58101&view=rev
Log:
[WIN32K]
Revert the revert from r58091 and apply a correct fix (passed parameters to 
RECTL_vSetRect() in wrong order)

Modified:
 trunk/reactos/win32ss/gdi/ntgdi/dib.h
 trunk/reactos/win32ss/gdi/ntgdi/dibobj.c
 trunk/reactos/win32ss/user/ntuser/clipboard.c
 trunk/reactos/win32ss/user/ntuser/misc/file.c

Modified: trunk/reactos/win32ss/gdi/ntgdi/dib.h
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/dib.h?rev=58101&r1=58100&r2=58101&view=diff
==
--- trunk/reactos/win32ss/gdi/ntgdi/dib.h [iso-8859-1] (original)
+++ trunk/reactos/win32ss/gdi/ntgdi/dib.h [iso-8859-1] Wed Jan  2 14:52:34 2013
@@ -7,8 +7,11 @@
  INT APIENTRY DIB_GetDIBImageBytes (INT  width, INT height, INT depth);
  HPALETTE FASTCALL DIB_MapPaletteColors(PPALETTE ppal, CONST BITMAPINFO* 
lpbmi);
  HPALETTE FASTCALL BuildDIBPalette (CONST BITMAPINFO *bmi);
+
+/* Those functions permit to tranparently work with a BITMAPCOREINFO structure 
*/
  BITMAPINFO* FASTCALL DIB_ConvertBitmapInfo(CONST BITMAPINFO* bmi, DWORD 
Usage);
-VOID FASTCALL DIB_FreeConvertedBitmapInfo(BITMAPINFO* converted, BITMAPINFO* 
orig);
+/* Pass Usage = -1 if you don't want to convert the BITMAPINFO back to 
BITMAPCOREINFO */
+VOID FASTCALL DIB_FreeConvertedBitmapInfo(BITMAPINFO* converted, BITMAPINFO* 
orig, DWORD Usage);

  INT
  APIENTRY

Modified: trunk/reactos/win32ss/gdi/ntgdi/dibobj.c
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/dibobj.c?rev=58101&r1=58100&r2=58101&view=diff
==
--- trunk/reactos/win32ss/gdi/ntgdi/dibobj.c [iso-8859-1] (original)
+++ trunk/reactos/win32ss/gdi/ntgdi/dibobj.c [iso-8859-1] Wed Jan  2 14:52:34 
2013
@@ -584,7 +584,6 @@
  DWORD compr, size ;
  USHORT i;
  int bitmap_type;
-RGBTRIPLE* rgbTriples;
  RGBQUAD* rgbQuads;
  VOID* colorPtr;

@@ -594,7 +593,6 @@
  return 0;

  colorPtr = (LPBYTE)Info + Info->bmiHeader.biSize;
-rgbTriples = colorPtr;
  rgbQuads = colorPtr;

  bitmap_type = DIB_GetBitmapInfo(&Info->bmiHeader,
@@ -643,15 +641,6 @@
  switch(bpp)
  {
  case 0: /* Only info */
-if(pbmci)
-{
-pbmci->bmciHeader.bcWidth = (WORD)psurf->SurfObj.sizlBitmap.cx;
-pbmci->bmciHeader.bcHeight = (WORD)((psurf->SurfObj.fjBitmap & 
BMF_TOPDOWN) ?
- -psurf->SurfObj.sizlBitmap.cy :
- psurf->SurfObj.sizlBitmap.cy);
-pbmci->bmciHeader.bcPlanes = 1;
-pbmci->bmciHeader.bcBitCount = 
BitsPerFormat(psurf->SurfObj.iBitmapFormat);
-}
  Info->bmiHeader.biWidth = psurf->SurfObj.sizlBitmap.cx;
  Info->bmiHeader.biHeight = (psurf->SurfObj.fjBitmap & BMF_TOPDOWN) ?
 -psurf->SurfObj.sizlBitmap.cy :
@@ -702,16 +691,6 @@
  if(Usage == DIB_RGB_COLORS)
  {
  ULONG colors = min(psurf->ppal->NumColors, 256);
-
-if(pbmci)
-{
-for(i = 0; i < colors; i++)
-{
-rgbTriples[i].rgbtRed = 
psurf->ppal->IndexedColors[i].peRed;
-rgbTriples[i].rgbtGreen = 
psurf->ppal->IndexedColors[i].peGreen;
-rgbTriples[i].rgbtBlue = 
psurf->ppal->IndexedColors[i].peBlue;
-}
-}
  if(colors != 256) Info->bmiHeader.biClrUsed = colors;
  for(i = 0; i < colors; i++)
  {
@@ -724,10 +703,7 @@
  else
  {
  for(i = 0; i < 256; i++)
-{
-if(pbmci) ((WORD*)rgbTriples)[i] = i;
  ((WORD*)rgbQuads)[i] = i;
-}
  }
  }
  else
@@ -736,7 +712,6 @@
  {
  for(i = 0; i < 256; i++)
  {
-if(pbmci) ((WORD*)rgbTriples)[i] = i;
  ((WORD*)rgbQuads)[i] = i;
  }
  }
@@ -753,13 +728,6 @@
  }
  for (i = 0; i < pDcPal->NumColors; i++)
  {
-if (pbmci)
-{
-rgbTriples[i].rgbtRed   = 
pDcPal->IndexedColors[i].peRed;
-rgbTriples[i].rgbtGreen = 
pDcPal->IndexedColors[i].peGreen;
-rgbTriples[i].rgbtBlue  = 
pDcPal->IndexedColors[i].peBlue;
-}
-
  rgbQuads[i].rgbRed  = pD

Re: [ros-dev] ReactOS On ARM/Raspberry Pi

[Jérôme Gardou]

Before you put too much hope on it, ReactOS needs a Memory Managing
Unit (basically, virtual memory support), which is present only on
ARMv7. Raspberry Pi has an ARM11 CPU, which only implements
ARMv6. (yeah, don't be confused with all those numberings...)

Le Thu, 10 Jan 2013 21:41:10 -0600,
"J. C. Jones"  a écrit :

> Hi All,
> 
>  
> 
> Before I reach the point where I am thinking the same way as everyone
> else, which will inevitably happen (The Borg - resistance is futile),
> I wanted to get some thoughts out:
> 
> 
> 
> A question that many have asked is, "Why not port ReactOS to ARM?"
> 
>  
> 
> The answer is usually something like, "We cannot afford the resources
> to port to ARM."
> 
>  
> 
> I think on the contrary, the opposite might be true: 
> 
> 1.   There is a hoard of developers over on the Raspberry Pi
> site right now who would enjoy seeing ReactOS on the RaspPi.
> 
> 2.   There are device manufacturers who would like to free
> themselves from the Apple/Google/Microsoft triumvirate and
> iOS/Android/Windows Phone 8 lock-in. Samsung recently announced its
> intent to explore other operating systems. 
> http://news.cnet.com/8301-1035_3-57455054-94/would-samsung-ever-leave-androi
> d-new-ceo-drops-hints/
> 
> 3.   The operating systems are not exactly easy to develop for. I
> have read credible articles that  Android is a mess from a development
> perspective. ReactOS would be the operating system of choice for
> straightforward development.
> 
> 4.   There are embedded systems companies who struggled in vain
> to get Windows CE to behave like "Big Windows", but were unsuccessful
> because restrictions in the Windows CE kernel. Many of them switch to
> Linux, but quite a few still use some form of embedded Windows, and
> would welcome an open-source Windows-like OS.
> 
> 5.   The United States Military has very large base of software
> that they would like to put on lower-power systems (ARM) that is
> written for Windows/i386. They are currently trying to port this
> software to Linux, with varying degrees of success, not because they
> like Linux, but because they need as much of the software to be open
> as possible. They would be particularly attracted by the open-source
> nature of ReactOS, because the USA national security vetting process
> requires that certain classes of software be reviewed, line by line,
> by a certain US security agency. The singular, totally exposed nature
> of ReactOS makes it attractive in this regard.
> 
> 6.   ReactOS.ORG would likely receive real money from device
> manufacturers. Even a few dollars per-device would add-up very
> quickly.
> 
> 7.   There is NO mobile platform right now, among the Big Three,
> that allows true, native, C/C++ development. Each of these platform
> plays a game where the native code is invoked by some shell, even in
> the case of Windows Phone 8, despite Microsoft's claim that Windows
> Phone 8 supports native development. [It depends on what your
> interpretation of native development is.]
> 
>  
> 
> ARM device manufacturers are all stuck in the same boat. Most of these
> companies are actually not very good at OS design. Think about it:
> Nokia was a multi-billion-$US company that was using an operating
> system (Symbian) that was so broken and toxic to innovation that it
> almost drowned their company. What did they do to fix this problem?
> They adopted a closed OS from Microsoft. Manufacturers, actually, do
> not like having closed software. It eliminates their opportunity for
> differentiation. If ReactOS were made to run on a single
> manufacturer's device, the other manufacturers would become nervous,
> and insist on having the same access as does their competitor. There
> is nothing wrong with making these manufacturers pay a small fee to
> support the ReactOS Foundation, and they would gladly pay it, if we
> developed killer applications for their devices.
> 
>  
> 
> Of course, because most of ReactOS, in theory, should be portable,
> software working on ARM is software working on x86_32/x86_64. I would
> also like to mention here that there are a lot of developers who
> would much rather have a stable kernel, and a paucity of user-mode
> applications, versus an unstable kernel, and a plethora of user-mode
> applications. User mode applications will be created by the hoard,
> *if* the kernel is stable. If the kernel is not stable, the incentive
> to do anything else is greatly reduced.
> 
>  
> 
> This is the opportunity I see. My biological clock is telling me that
> 2013 is the year to pursue this effort. The market is waiting. But an
> effort like porting to ARM should not be done haphazardly or
> opportunistically. It should be done with deliberation and intent. 
> 
>  
> 
> Just my opinion.
> 
>  
> 
> -John
> 


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 58660: [MESA32] * Disable SSE optimizations, as they only cause mayhem.

[Jérôme Gardou]

It causes some kernel mode exception. The code deliberately throws an 
SSE exception to see if the OS supports them. The trap handler considers 
this as a k-mode exception and bug checks.


See http://jira.reactos.org/browse/CORE-6776

Timo Kreuzer a écrit :


What exactly does it cause? And shouldn't we rather fix that, instead of
disabling optimizations? mesa is already slow enough.

Am 03.04.2013 14:02, schrieb jgar...@svn.reactos.org:

Author: jgardou
Date: Wed Apr  3 12:02:58 2013
New Revision: 58660

URL: http://svn.reactos.org/svn/reactos?rev=58660&view=rev
Log:
[MESA32]
  * Disable SSE optimizations, as they only cause mayhem.

Modified:
 trunk/reactos/dll/opengl/mesa/src/mesa/CMakeLists.txt

Modified: trunk/reactos/dll/opengl/mesa/src/mesa/CMakeLists.txt
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/opengl/mesa/src/mesa/CMakeLists.txt?rev=58660&r1=58659&r2=58660&view=diff

==

--- trunk/reactos/dll/opengl/mesa/src/mesa/CMakeLists.txt [iso-8859-1]
(original)
+++ trunk/reactos/dll/opengl/mesa/src/mesa/CMakeLists.txt [iso-8859-1]
Wed Apr  3 12:02:58 2013
@@ -33,17 +33,18 @@
  x86/3dnow_xform3.S
  x86/3dnow_xform4.S
  x86/3dnow_normal.S
-x86/sse_xform1.S
-x86/sse_xform2.S
-x86/sse_xform3.S
-x86/sse_xform4.S
-x86/sse_normal.S
+# x86/sse_xform1.S
+# x86/sse_xform2.S
+# x86/sse_xform3.S
+# x86/sse_xform4.S
+# x86/sse_normal.S
  x86/read_rgba_span_x86.S)
  add_definitions(
  -DUSE_X86_ASM
  -DUSE_MMX_ASM
  -DUSE_3DNOW_ASM
--DUSE_SSE_ASM)
+# -DUSE_SSE_ASM
+)
  endif()
  list(APPEND SOURCE






___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [hbelusca] 58824: [KDCOM] - Use the UCHAR type directly instead

[Jérôme Gardou]

Hey Hermès !

> +
> +long atol(const char *str);
> +
 Shouldn't this belong to some standard header ?

Cheers
Jérôme

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [pschweitzer] 58960: [RTL] Finally reenable RtlAcquirePrivilege

[Jérôme Gardou]

Hey Pierre!

Nice patch series, that takes ReactOS nearer to being secure. A remark though :

>  /*
> - * enable the SeSystemtimePrivilege privilege
> + * Call SetLocalTime twice to ensure correct results
>   */
> +Ret = SetLocalTime(&SetupData->SystemTime) &&
> +  SetLocalTime(&SetupData->SystemTime);

This is a bit confusing, and the comment doesn't really help. Why would calling 
the function twice ansure correct result ? Also, this is likely to be optimized 
away by the compiler, or at least produce a report in static code analysers.

I know this isn't pure chance. Any hint as to why you wrote it like this ?

Cheers
Jérôme

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [pschweitzer] 58960: [RTL] Finally reenable RtlAcquire

[Jérôme Gardou]

Thanks for the clarification. For some reason, I missed that bit.

ReactOS Development List  wrote on lun., mai 6th, 2013, 
8:25 :
> On 06.05.2013 17:48, Jérôme Gardou wrote:
> > Hey Pierre!
> >
> > Nice patch series, that takes ReactOS nearer to being secure. A remark 
> > though :
> >
> >>   /*
> >> - * enable the SeSystemtimePrivilege privilege
> >> + * Call SetLocalTime twice to ensure correct results
> >>*/
> >> +Ret = SetLocalTime(&SetupData->SystemTime) &&
> >> +  SetLocalTime(&SetupData->SystemTime);
> >
> > This is a bit confusing, and the comment doesn't really help. Why would 
> > calling the function twice ansure correct result ? Also, this is likely to 
> > be optimized away by the compiler, or at least produce a report in static 
> > code analysers.
> >
> > I know this isn't pure chance. Any hint as to why you wrote it like this ?
> 
> Even MSDN states that it might be necessary to call SetLocalTime twice: 
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms724936%28v=vs.85%29.aspx
> 
> Regards,
> Sven
> 
> 
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 59174: [WIN32K] - Don't crash if the focus m

[Jérôme Gardou]

It happened if explorer.exe get stopped for whatever reason (taskmgr) and there 
are no other window opened. Then press ctrl - alt -del => BSOD.

To my understanding, this is valid for this variable is NULL, so checking it is 
necessary.

Any comments ?

Regards.
Jérôme

ReactOS Development List  wrote on mer., juin 5th, 2013, 
11:30 :
> What application failed?
> Thanks,
> James
> 
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [aandrejevic] 60757: [SOFTX86] Remove softx86, as it is no longer used by anything.

[Jérôme Gardou]

Hello.

Just nitpicking a bit:

>> -target_link_libraries(ntvdm softx86 softx87 fast486)
>> +target_link_libraries(ntvdm fast486)
>> add_importlibs(ntvdm msvcrt user32 gdi32 kernel32 ntdll)
>> -add_dependencies(ntvdm softx86 softx87)
>> +add_dependencies(ntvdm fast486)

The call to add_dependencies is useless here, as a call to 
target_link_libraries adds an implicit dependency.

Regards
Jérôme
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [akhaldi] 60074: [WINE/TEST] * Introduce a way to properly mark the todos instead of counting them as failures. Brought to you by Thomas Faber.

[Jérôme Gardou]

Hi James,

I agree that this doesn't make sense for our in-house modules (WIN32 
subsystem, kernel32, ntdll, you name it...), but this should be used for 
modules that we import from wine, thus permitting us to clearly 
differentiate between features that wine doesn't implement and failed 
tests that fail because of a bug in our underlying modules.


This is not cheating, this is pinpointing issues are ours, and where 
they are wine's.


Regards
Jérôme

James Tabor a écrit :

Hi.

This should be removed, we are not wine and I personally work "hard on"
getting wine todos fixed in ReactOS! This also breaks the DCE test.


Background, GvG and then the old guard back in the day thought the same
way as I do about this issue. We should count the todo's as failures and
not bypass these failues. Why? It may point to a critical bug that could
break functionality somewhere else. That was the reasoning then and I
agree with it. Cheating the tests is just plain cheating..


James



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [pschweitzer] 62442: [NTOSKRNL] - Implement FsRtlNotifyFilterReportChange - Implement FsRtlNotifyUpdateBuffer - Implement FsRtlCancelNotify - Implement FsRtlNotifyGetLastPart

[Jérôme Gardou]

Awesomeness, in its purest art.

Le 07.03.2014 20:33, pschweit...@svn.reactos.org a écrit :

Author: pschweitzer
Date: Fri Mar  7 19:33:38 2014
New Revision: 62442

URL: http://svn.reactos.org/svn/reactos?rev=62442&view=rev
Log:
[NTOSKRNL]
- Implement FsRtlNotifyFilterReportChange
- Implement FsRtlNotifyUpdateBuffer
- Implement FsRtlCancelNotify
- Implement FsRtlNotifyGetLastPartOffset
- Fix implementation of FsRtlNotifyFilterChangeDirectory

This finishes the implementation of file system notifications inside the kernel.
Data are properly returned to the caller on changes.

CORE-2582

Modified:
 trunk/reactos/ntoskrnl/fsrtl/notify.c
 trunk/reactos/ntoskrnl/include/internal/fsrtl.h

Modified: trunk/reactos/ntoskrnl/fsrtl/notify.c
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/fsrtl/notify.c?rev=62442&r1=62441&r2=62442&view=diff
==
--- trunk/reactos/ntoskrnl/fsrtl/notify.c   [iso-8859-1] (original)
+++ trunk/reactos/ntoskrnl/fsrtl/notify.c   [iso-8859-1] Fri Mar  7 
19:33:38 2014
@@ -12,6 +12,55 @@
  #define NDEBUG
  #include 
  
+/* INLINED FUNCTIONS */

+
+/*
+ * @implemented
+ */
+FORCEINLINE
+VOID
+FsRtlNotifyAcquireFastMutex(IN PREAL_NOTIFY_SYNC RealNotifySync)
+{
+ULONG_PTR CurrentThread = (ULONG_PTR)KeGetCurrentThread();
+
+/* Only acquire fast mutex if it's not already acquired by the current 
thread */
+if (RealNotifySync->OwningThread != CurrentThread)
+{
+ExAcquireFastMutexUnsafe(&(RealNotifySync->FastMutex));
+RealNotifySync->OwningThread = CurrentThread;
+}
+/* Whatever the case, keep trace of the attempt to acquire fast mutex */
+RealNotifySync->OwnerCount++;
+}
+
+/*
+ * @implemented
+ */
+FORCEINLINE
+VOID
+FsRtlNotifyReleaseFastMutex(IN PREAL_NOTIFY_SYNC RealNotifySync)
+{
+RealNotifySync->OwnerCount--;
+/* Release the fast mutex only if no other instance needs it */
+if (!RealNotifySync->OwnerCount)
+{
+ExReleaseFastMutexUnsafe(&(RealNotifySync->FastMutex));
+RealNotifySync->OwningThread = (ULONG_PTR)0;
+}
+}
+
+#define FsRtlNotifyGetLastPartOffset(FullLen, TargLen, Type, Chr)  
   \
+for (FullPosition = 0; FullPosition < FullLen; ++FullPosition) 
   \
+if (((Type)NotifyChange->FullDirectoryName->Buffer)[FullPosition] == 
Chr) \
+++FullNumberOfParts;   
   \
+for (LastPartOffset = 0; LastPartOffset < TargLen; ++LastPartOffset) { 
   \
+if ( ((Type)TargetDirectory.Buffer)[LastPartOffset] == Chr) {  
   \
+++TargetNumberOfParts; 
   \
+if (TargetNumberOfParts == FullNumberOfParts)  
   \
+break; 
   \
+}  
   \
+}
+
  /* PRIVATE FUNCTIONS 
*/
  
  VOID

@@ -22,13 +71,161 @@
  FsRtlNotifySetCancelRoutine(IN PIRP Irp,
  IN PNOTIFY_CHANGE NotifyChange OPTIONAL);
  
+/*

+ * @implemented
+ */
  VOID
  NTAPI
  FsRtlCancelNotify(IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp)
  {
+PVOID Buffer;
+PIRP NotifyIrp;
+ULONG BufferLength;
+PIO_STACK_LOCATION Stack;
+PNOTIFY_CHANGE NotifyChange;
+PREAL_NOTIFY_SYNC RealNotifySync;
+PSECURITY_SUBJECT_CONTEXT SubjectContext = NULL;
+
+/* Get the NOTIFY_CHANGE struct and reset it */
+NotifyChange = (PNOTIFY_CHANGE)Irp->IoStatus.Information;
+Irp->IoStatus.Information = 0;
+/* Reset the cancel routine */
+IoSetCancelRoutine(Irp, NULL);
+/* And release lock */
  IoReleaseCancelSpinLock(Irp->CancelIrql);
-UNIMPLEMENTED;
+/* Get REAL_NOTIFY_SYNC struct */
+RealNotifySync = NotifyChange->NotifySync;
+
+FsRtlNotifyAcquireFastMutex(RealNotifySync);
+
+   _SEH2_TRY
+   {
+   /* Remove the IRP from the notifications list and mark it pending */
+   RemoveEntryList(&(Irp->Tail.Overlay.ListEntry));
+   IoMarkIrpPending(Irp);
+
+   /* Now, the tricky part - let's find a buffer big enough to hold the 
return data */
+   if (NotifyChange->Buffer && NotifyChange->AllocatedBuffer == NULL &&
+   ((Irp->MdlAddress && MmGetSystemAddressForMdl(Irp->MdlAddress) == 
NotifyChange->Buffer) ||
+   NotifyChange->Buffer == Irp->AssociatedIrp.SystemBuffer))
+   {
+   /* Assume we didn't find any */
+   Buffer = NULL;
+   BufferLength = 0;
+
+   /* If we don't have IRPs, check if current buffer is big enough */
+   if (IsListEmpty(&NotifyChange->NotifyIrps))
+   {
+   if (NotifyChange->BufferLength >= NotifyChange->DataLength)
+  

Re: [ros-dev] [ros-diffs] [tfaber] 63928: [FASTFAT] - Properly handle errors in CcInitializeCacheMap, CcCopyRead and CcCopyWrite CORE-8410

[Jérôme Gardou]

Hey Thomas

I think that you want to use _SEH2_YIELD in a few places here, that is, 
unless we want to completely ditch pseh2 in favor of pseh3 ;-)


Regards
Jérôme

Le 24/08/2014 05:28, tfa...@svn.reactos.org a écrit :

Author: tfaber
Date: Sun Aug 24 03:28:01 2014
New Revision: 63928

URL: http://svn.reactos.org/svn/reactos?rev=63928&view=rev
Log:
[FASTFAT]
- Properly handle errors in CcInitializeCacheMap, CcCopyRead and CcCopyWrite
CORE-8410

Modified:
 trunk/reactos/drivers/filesystems/fastfat/CMakeLists.txt
 trunk/reactos/drivers/filesystems/fastfat/fcb.c
 trunk/reactos/drivers/filesystems/fastfat/fsctl.c
 trunk/reactos/drivers/filesystems/fastfat/rw.c
 trunk/reactos/drivers/filesystems/fastfat/vfat.h

Modified: trunk/reactos/drivers/filesystems/fastfat/CMakeLists.txt
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfat/CMakeLists.txt?rev=63928&r1=63927&r2=63928&view=diff
==
--- trunk/reactos/drivers/filesystems/fastfat/CMakeLists.txt[iso-8859-1] 
(original)
+++ trunk/reactos/drivers/filesystems/fastfat/CMakeLists.txt[iso-8859-1] 
Sun Aug 24 03:28:01 2014
@@ -26,6 +26,7 @@
  add_library(fastfat SHARED ${SOURCE} vfatfs.rc)
  
  set_module_type(fastfat kernelmodedriver)

+target_link_libraries(fastfat ${PSEH_LIB})
  add_importlibs(fastfat ntoskrnl hal)
  
  add_pch(fastfat vfat.h SOURCE)


Modified: trunk/reactos/drivers/filesystems/fastfat/fcb.c
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfat/fcb.c?rev=63928&r1=63927&r2=63928&view=diff
==
--- trunk/reactos/drivers/filesystems/fastfat/fcb.c [iso-8859-1] (original)
+++ trunk/reactos/drivers/filesystems/fastfat/fcb.c [iso-8859-1] Sun Aug 24 
03:28:01 2014
@@ -340,12 +340,14 @@
  {
  PFILE_OBJECT fileObject;
  PVFATCCB newCCB;
+NTSTATUS status;
  
  fileObject = IoCreateStreamFileObject (NULL, vcb->StorageDevice);
  
  newCCB = ExAllocateFromNPagedLookasideList(&VfatGlobalData->CcbLookasideList);

  if (newCCB == NULL)
  {
+ObDereferenceObject(fileObject);
  return STATUS_INSUFFICIENT_RESOURCES;
  }
  RtlZeroMemory(newCCB, sizeof (VFATCCB));
@@ -356,11 +358,24 @@
  fcb->FileObject = fileObject;
  fcb->RefCount++;
  
-CcInitializeCacheMap(fileObject,

- (PCC_FILE_SIZES)(&fcb->RFCB.AllocationSize),
- TRUE,
- &VfatGlobalData->CacheMgrCallbacks,
- fcb);
+_SEH2_TRY
+{
+CcInitializeCacheMap(fileObject,
+ (PCC_FILE_SIZES)(&fcb->RFCB.AllocationSize),
+ TRUE,
+ &VfatGlobalData->CacheMgrCallbacks,
+ fcb);
+}
+_SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER)
+{
+status = _SEH2_GetExceptionCode();
+fcb->RefCount--;
+fcb->FileObject = NULL;
+ExFreeToNPagedLookasideList(&VfatGlobalData->CcbLookasideList, newCCB);
+ObDereferenceObject(fileObject);
+return status;
+}
+_SEH2_END;
  
  fcb->Flags |= FCB_CACHE_INITIALIZED;

  return STATUS_SUCCESS;

Modified: trunk/reactos/drivers/filesystems/fastfat/fsctl.c
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfat/fsctl.c?rev=63928&r1=63927&r2=63928&view=diff
==
--- trunk/reactos/drivers/filesystems/fastfat/fsctl.c   [iso-8859-1] (original)
+++ trunk/reactos/drivers/filesystems/fastfat/fsctl.c   [iso-8859-1] Sun Aug 24 
03:28:01 2014
@@ -550,11 +550,20 @@
  Fcb->RFCB.ValidDataLength = Fcb->RFCB.FileSize;
  Fcb->RFCB.AllocationSize = Fcb->RFCB.FileSize;
  
-CcInitializeCacheMap(DeviceExt->FATFileObject,

- (PCC_FILE_SIZES)(&Fcb->RFCB.AllocationSize),
- TRUE,
- &VfatGlobalData->CacheMgrCallbacks,
- Fcb);
+_SEH2_TRY
+{
+CcInitializeCacheMap(DeviceExt->FATFileObject,
+ (PCC_FILE_SIZES)(&Fcb->RFCB.AllocationSize),
+ TRUE,
+ &VfatGlobalData->CacheMgrCallbacks,
+ Fcb);
+}
+_SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER)
+{
+Status = _SEH2_GetExceptionCode();
+goto ByeBye;
+}
+_SEH2_END;
  
  DeviceExt->LastAvailableCluster = 2;

  ExInitializeResourceLite(&DeviceExt->FatResource);

Modified: trunk/reactos/drivers/filesystems/fastfat/rw.c
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfat/rw.c?rev=63928&r1=63927&r2=63928&view=diff
==
--- trunk/reactos/drivers/fil

Re: [ros-dev] [ros-diffs] [akhaldi] 64094: [CMAKE/CLANG] * Globally link mingwex for C modules. CORE-8516

[Jérôme Gardou]

Hey Amine

Is there any reason to not use our own mingwex build ?

Le 09/09/2014 20:11, akha...@svn.reactos.org a écrit :

Author: akhaldi
Date: Tue Sep  9 18:11:10 2014
New Revision: 64094

URL: http://svn.reactos.org/svn/reactos?rev=64094&view=rev
Log:
[CMAKE/CLANG]
* Globally link mingwex for C modules.
CORE-8516

Modified:
 trunk/reactos/toolchain-clang.cmake

Modified: trunk/reactos/toolchain-clang.cmake
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/toolchain-clang.cmake?rev=64094&r1=64093&r2=64094&view=diff
==
--- trunk/reactos/toolchain-clang.cmake [iso-8859-1] (original)
+++ trunk/reactos/toolchain-clang.cmake [iso-8859-1] Tue Sep  9 18:11:10 2014
@@ -56,7 +56,7 @@
  set(CMAKE_ASM_CREATE_STATIC_LIBRARY ${CMAKE_C_CREATE_STATIC_LIBRARY})
  
  # Don't link with anything by default unless we say so

-set(CMAKE_C_STANDARD_LIBRARIES "-lgcc" CACHE STRING "Standard C Libraries")
+set(CMAKE_C_STANDARD_LIBRARIES "-lmingwex -lgcc" CACHE STRING "Standard C 
Libraries")
  
  #MARK_AS_ADVANCED(CLEAR CMAKE_CXX_STANDARD_LIBRARIES)

  set(CMAKE_CXX_STANDARD_LIBRARIES "-lgcc" CACHE STRING "Standard C++ 
Libraries")





___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 64121: [KDGDB] - introduce KDGDB, a KDCOM-like DLL, wrapping the KD protocol and the GDB remote protocol together. It is not fully functional, but for now it permit

[Jérôme Gardou]

Sure, I will write one as soon as it is functional, but to make it 
short, it is as simple as launching gdb and using target remote 



On ReactOS side, /DEBUGPORT=COMx and you're ready to go.

Enjoy
Jérôme

Le 12/09/2014 17:35, Pierre Schweitzer a écrit :

Awesome, indeed! Any info or tuto about how to use it? About how to plug
GDB to it?

Cheers,

On 09/12/2014 12:57 AM, Timo Kreuzer wrote:

Awesome stuff!


Am 11.09.2014 22:55, schrieb jgar...@svn.reactos.org:

Author: jgardou
Date: Thu Sep 11 20:55:42 2014
New Revision: 64121

URL: http://svn.reactos.org/svn/reactos?rev=64121&view=rev
Log:
[KDGDB]
  - introduce KDGDB, a KDCOM-like DLL, wrapping the KD protocol and the GDB 
remote protocol together.
It is not fully functional, but for now it permits source-level debugging in 
some modules. More will be added as I feel the need and find the time to work a 
bit more on it. (That is, unless an angel comes and resume the work)
To use it, set GDB and _WINKD_ to TRUE in your CMakeCache.txt. Using separate 
debug symbols is also a good idea.



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev




___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 64121: [KDGDB] - introduce KDGDB, a KDCOM-like DLL, wrapping the KD protocol and the GDB remote protocol together. It is not fully functional, but for now it permit

[Jérôme Gardou]

I thought about that, but considering the fact that using windbg for a 
GCC compiled OS or GDB for a MSVC compiled OS makes little sense 
(although one could use that for mixed kernel+drivers setup), I decided 
to go the KDCOM way.


I am open to good arguments for doing that another way though.

Jérôme

Le 12/09/2014 18:42, Hermès BÉLUSCA - MAÏTO a écrit :


Ah and I forgot : Jérôme, now you can use /DEBUGPORT=foo to load 
KDfoo.DLL ;) Then your KDfoo.DLL can implement a simple line parser in 
order to interpret any other hypothetical parameters present in the 
bootloader command line (some other KDxxx use that, for example KD1394 
or KDUSB iirc.). One can imagine something like: /DEBUGPORT=GDB:COM1 
to say: “Load KDGDB.DLL and use COM1 for it”. Currently it’s not what 
you did, maybe it would be great to have that? (and using 
/DEBUGPORT=COM1 just for loading KDCOM.DLL, the KD layer for WinDbg ?)


Hermès.

*De :*Ros-dev [mailto:ros-dev-boun...@reactos.org] *De la part de* 
Jérôme Gardou

*Envoyé :* vendredi 12 septembre 2014 18:20
*À :* ros-dev@reactos.org
*Objet :* Re: [ros-dev] [ros-diffs] [jgardou] 64121: [KDGDB] - 
introduce KDGDB, a KDCOM-like DLL, wrapping the KD protocol and the 
GDB remote protocol together. It is not fully functional, but for now 
it permits source-level debuggin...


Sure, I will write one as soon as it is functional, but to make it 
short, it is as simple as launching gdb and using target remote 



On ReactOS side, /DEBUGPORT=COMx and you're ready to go.

Enjoy
Jérôme

Le 12/09/2014 17:35, Pierre Schweitzer a écrit :

Awesome, indeed! Any info or tuto about how to use it? About how to plug

GDB to it?

  


Cheers,

  


On 09/12/2014 12:57 AM, Timo Kreuzer wrote:

Awesome stuff!

  

  


Am 11.09.2014 22:55, schriebjgar...@svn.reactos.org  
<mailto:jgar...@svn.reactos.org>:

Author: jgardou

Date: Thu Sep 11 20:55:42 2014

New Revision: 64121

  


URL:http://svn.reactos.org/svn/reactos?rev=64121&view=rev

Log:

[KDGDB]

  - introduce KDGDB, a KDCOM-like DLL, wrapping the KD protocol and 
the GDB remote protocol together.

It is not fully functional, but for now it permits source-level 
debugging in some modules. More will be added as I feel the need and find the 
time to work a bit more on it. (That is, unless an angel comes and resume the 
work)

To use it, set GDB and _WINKD_ to TRUE in your CMakeCache.txt. 
Using separate debug symbols is also a good idea.

  

  

  


___

Ros-dev mailing list

Ros-dev@reactos.org  <mailto:Ros-dev@reactos.org>

http://www.reactos.org/mailman/listinfo/ros-dev

  

  





___

Ros-dev mailing list

Ros-dev@reactos.org  <mailto:Ros-dev@reactos.org>

http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 64121: [KDGDB] - introduce KDGDB, a KDCOM-like DLL, wrapping the KD protocol and the GDB remote protocol together. It is not fully functional, but for now it permit

[Jérôme Gardou]

This will go away eventually.

Le 12/09/2014 18:40, Hermès BÉLUSCA - MAÏTO a écrit :


And what about this GDB stub there: 
trunk/reactos/ntoskrnl/kd/wrappers/ ? Do we still need it?


Hermès.

*De :*Ros-dev [mailto:ros-dev-boun...@reactos.org] *De la part de* 
Jérôme Gardou

*Envoyé :* vendredi 12 septembre 2014 18:20
*À :* ros-dev@reactos.org
*Objet :* Re: [ros-dev] [ros-diffs] [jgardou] 64121: [KDGDB] - 
introduce KDGDB, a KDCOM-like DLL, wrapping the KD protocol and the 
GDB remote protocol together. It is not fully functional, but for now 
it permits source-level debuggin...


Sure, I will write one as soon as it is functional, but to make it 
short, it is as simple as launching gdb and using target remote 



On ReactOS side, /DEBUGPORT=COMx and you're ready to go.

Enjoy
Jérôme

Le 12/09/2014 17:35, Pierre Schweitzer a écrit :

Awesome, indeed! Any info or tuto about how to use it? About how to plug

GDB to it?

  


Cheers,

  


On 09/12/2014 12:57 AM, Timo Kreuzer wrote:

Awesome stuff!

  

  


Am 11.09.2014 22:55, schriebjgar...@svn.reactos.org  
<mailto:jgar...@svn.reactos.org>:

Author: jgardou

Date: Thu Sep 11 20:55:42 2014

New Revision: 64121

  


URL:http://svn.reactos.org/svn/reactos?rev=64121&view=rev

Log:

[KDGDB]

  - introduce KDGDB, a KDCOM-like DLL, wrapping the KD protocol and 
the GDB remote protocol together.

It is not fully functional, but for now it permits source-level 
debugging in some modules. More will be added as I feel the need and find the 
time to work a bit more on it. (That is, unless an angel comes and resume the 
work)

To use it, set GDB and _WINKD_ to TRUE in your CMakeCache.txt. 
Using separate debug symbols is also a good idea.

  

  

  


___

Ros-dev mailing list

Ros-dev@reactos.org  <mailto:Ros-dev@reactos.org>

http://www.reactos.org/mailman/listinfo/ros-dev

  

  





___

Ros-dev mailing list

Ros-dev@reactos.org  <mailto:Ros-dev@reactos.org>

http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 64127: [KDGDB] - Add a callback mechanism permitting to "simulate" KD send <-> receive loop without having to actually communicate to GDB - Use that to update the p

[Jérôme Gardou]

Yeah you're not the first one to tell me that, and I wasn't really happy 
to write it either.


I like your approach. I will try to do as you suggest.

Thanks
Jérôme

Le 12/09/2014 22:53, Timo Kreuzer a écrit :

while(1); is not really a good solution. It should be something that is
visible in GDB.
But I fear that a KeBugCheck() won't work here, since it will rely on a
working KD connection.
Maybe a KD_ASSERT() macro, that calls KdAssert() on failure or
something, resets the GDB connection somehow, issues a debug print and
then halts.


Am 12.09.2014 22:23, schrieb jgar...@svn.reactos.org:

Author: jgardou
Date: Fri Sep 12 20:23:08 2014
New Revision: 64127

URL: http://svn.reactos.org/svn/reactos?rev=64127&view=rev
Log:
[KDGDB]
  - Add a callback mechanism permitting to "simulate" KD send <-> receive loop 
without having to actually communicate to GDB
  - Use that to update the program counter when cont'ing a breakpoint
Now cont'ing an assertion failure is possible, since we actually get beyond the 
int 3 instruction

Modified:
 trunk/reactos/drivers/base/kdgdb/gdb_input.c
 trunk/reactos/drivers/base/kdgdb/kdgdb.h
 trunk/reactos/drivers/base/kdgdb/kdpacket.c

+)
+{
+DBGKD_MANIPULATE_STATE64* State = 
(DBGKD_MANIPULATE_STATE64*)MessageHeader->Buffer;
+
+/* We just confirm that all went well */
+if ((PacketType != PACKET_TYPE_KD_STATE_MANIPULATE)
+|| (State->ApiNumber != DbgKdSetContextApi)
+|| (State->ReturnStatus != STATUS_SUCCESS))
+{
+/* Should we bugcheck ? */
+while (1);
+}
+}
+
+static
+KDSTATUS
+SetContext(
+_Out_ DBGKD_MANIPULATE_STATE64* State,
+_Out_ PSTRING MessageData,
+_Out_ PULONG MessageLength,
+_Inout_ PKD_CONTEXT KdContext,
+_In_opt_ KDP_MANIPULATESTATE_HANDLER ManipulateStateHandler
+)
+{
+State->ApiNumber = DbgKdSetContextApi;
+State->Processor = CurrentStateChange.Processor;
+State->ReturnStatus = STATUS_SUCCESS;
+State->ProcessorLevel = CurrentStateChange.ProcessorLevel;
+MessageData->Length = sizeof(CurrentContext);
+
+if (MessageData->MaximumLength < sizeof(CurrentContext))
+{
+while (1);
+}
+



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 64121: [KDGDB] - introduce KDGDB, a KDCOM-like DLL, wrapping the KD protocol and the GDB remote protocol together. It is not fully functional, but for now it permit

[Jérôme Gardou]

I guess so, I didn't try. But feel free to do! :-p

Regards
Jérôme

Le 12/09/2014 23:25, Aleksey Bragin a écrit :

Absolutely great stuff!

And does it work in Windows? :-)
(not that there is so much demand in that, just for fun)

Regards,
Aleksey


On 12.09.2014 19:35, Pierre Schweitzer wrote:

Awesome, indeed! Any info or tuto about how to use it? About how to plug
GDB to it?

Cheers,

On 09/12/2014 12:57 AM, Timo Kreuzer wrote:

Awesome stuff!


Am 11.09.2014 22:55, schrieb jgar...@svn.reactos.org:

Author: jgardou
Date: Thu Sep 11 20:55:42 2014
New Revision: 64121

URL: http://svn.reactos.org/svn/reactos?rev=64121&view=rev
Log:
[KDGDB]
  - introduce KDGDB, a KDCOM-like DLL, wrapping the KD protocol and 
the GDB remote protocol together.
It is not fully functional, but for now it permits source-level 
debugging in some modules. More will be added as I feel the need 
and find the time to work a bit more on it. (That is, unless an 
angel comes and resume the work)
To use it, set GDB and _WINKD_ to TRUE in your CMakeCache.txt. 
Using separate debug symbols is also a good idea.








___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev