Re: [ros-dev] Doxygen migrated - now with a reasonable search feature!

[Ged Murphy]

This is great news, thank you Colin! 
Out doxygen is finally useful again \o/

-Original Message-
From: Ros-dev  On Behalf Of Colin Finck
Sent: Friday, 07 December 2018 11:18
To: 'ReactOS Development List' 
Subject: [ros-dev] Doxygen migrated - now with a reasonable search feature!

Hi all!

Good news! I've just migrated the last of our existing services,
Doxygen, to a new server that is a lot faster and more reliable.

But I also had a look at the often criticized search feature and enabled
the alternative EXTERNAL_SEARCH in the Doxyfile and on the server. This
doubled the runtime for Doxygen due to the additional indexing, but the
result is well worth the effort!

A simple search for a universal function like "Sleep" now instantly
yields all results, but with the definition in "winbase.h" and the
declaration in "kernel32/client/synch.c" at the very top! Results are
also a lot more readable and distributed over multiple pages.
Just try it yourself:

https://doxygen.reactos.org/search.html?query=Sleep

Hope you'll like it as much as I do! :)
We can now start tweaking the extra settings, e.g. whether we need
"Referenced by" and other information.

ReactOS is already known to many due to our Doxygen popping up whenever
they google a Windows API. This step should improve the usefulness of
our documentation even further and turn the ReactOS codebase into *the*
public reference about Windows internals again!
I hope it also motivates you to take care of Doxygen-compatible comments
during your coding :)


Cheers,

Colin



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

Re: [ros-dev] ReactOS 0.5 Planning

[Ged Murphy]

We really need to shake this idea that a 0.5 release is beta.

Beta software is close to being ready for release, which is a milestone reactos 
hasn’t yet reached.

 

We shouldn’t even be considering beta until we’re close to a 1.0 release. 

0.9 could be a possible beta candidate, or perhaps even 1.0 beta, followed by a 
1.0\1.1 final.

For now, we should continue to iterate minor releases and bump them when we’ve 
made considerable progress since the last, perhaps with a showstopper feature 
to promote it (such as USB)

I think we’re close to a stage where reactos has moved on massively since the 
0.4 release, hence this discussion.

 

All IMO of course.

Ged

 

From: Ros-dev  On Behalf Of Javier Agustìn 
Fernàndez Arroyo
Sent: Friday, 30 November 2018 08:53
To: ReactOS Development List 
Subject: Re: [ros-dev] ReactOS 0.5 Planning

 

Before setting 0.5 goals we should finally answer the question: will be 0.5 a 
beta release?

El vie., 30 nov. 2018 9:30, Colin Finck mailto:co...@reactos.org> > escribió:

Hi all!

Planning the ReactOS 0.5 release and establishing a new roadmap was one
of the points on the agenda of yesterday's meeting. This is still an
ongoing process.

Please make up your minds about what a ReactOS 0.5 release must offer in
your opinion and write it down to https://reactos.org/wiki/0.5.0

To get a realistic roadmap, it is important that we define a responsible
person for each task. It should be the person having the most in-depth
knowledge about the status of the affected ReactOS components.
Don't worry, we won't put any pressure on you to complete the task soon.
But we need someone who can give a detailed report about the current status.

If nobody can be the responsible person for a certain task, having it
for 0.5 is not realistic and it eventually needs to be removed from the
roadmap.
But that's for later! Let's first add all points we consider important
until the end of the year. If you can already add yourself as the
responsible person, even better! :)


Cheers,

Colin

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

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

Re: [ros-dev] Status Meeting (November 2018)

[Ged Murphy]

The link between 0.5 and beta was an old statement we used to have on our 
website, I’m not sure why that relationship existed other than a splitting an 
integer in half and assigning 0.5 to each stage.

I’m more of the opinion that beta products are close to release, so 0.8+ would 
be more suitable.

 

Anyway, it’s a conversation to be had internally.

 

Ged.

 

From: Ros-dev  On Behalf Of hermes.belu...@sfr.fr
Sent: Wednesday, 28 November 2018 16:51
To: ReactOS Development List 
Subject: Re: [ros-dev] Status Meeting (November 2018)

 

‌Hi!

Usually when we talk about ReactOS 0.5, we implicitly think that it will enter 
beta state there.
So unless you consider this to not completely hold anymore, we can look at what 
remains to be done/fixed (importantly) so that we may qualify as going into 
beta state.
(And yes, USB and storage sound strongly as prerequisites for 0.5 in my 
opinion).

Best,
Hermes 

De : "Ged Murphy"
A : "'ReactOS Development List'"
Envoyé: mercredi 28 novembre 2018 17:42
Objet : Re: [ros-dev] Status Meeting (November 2018)
  

Some potential talking points:

 

*   Selecting a new coordinator
*   Version bump to 0.5
*   USB / Storage (perhaps linked to a 0.5 release)
*   Mattermost
*   New website progress

 

 

From: Ros-dev mailto:ros-dev-boun...@reactos.org> 
> On Behalf Of Mark Jansen
Sent: Wednesday, 28 November 2018 16:13
To: ReactOS Development List mailto:ros-dev@reactos.org> >
Subject: Re: [ros-dev] Status Meeting (November 2018)

 

We can discuss this if you are present, but I don't see the value in discussing 
it without you.

We have seen before that something discussed without the initiator being 
present is time not well spent, since it is a bit hard to argue with only one 
side of the argument present

 

 

 

Op 26 nov. 2018 12:15 schreef hermes.belu...@sfr.fr 
<mailto:hermes.belu...@sfr.fr> :

Hello,

I may not be available as it's the day when I'm going somewhere for a 
conference; it just depends at which time I arrive at destination.

For the meeting we may talk about the best way we can move to delivering 
all-in-one ReactOS ISOs (containing livecd + installation in both text and GUI 
modes), and which changes this could imply for our infrastructure 
(buildbots/website...).

Best regards,
Hermes

De : "Javier Agustìn Fernàndez Arroyo"
A : "ReactOS Development List"
Envoyé: samedi 24 novembre 2018 22:06
Objet : Re: [ros-dev] Status Meeting (November 2018)
 

I'm at work but I will do my best to attend!

 

El sáb., 24 nov. 2018 21:38, Colin Finck mailto:co...@reactos.org> > escribió:

Hi all!

Let me invite you to the November 2018 meeting, taking place next
Thursday, November 29, 2018 at 19:00 UTC.
Invited members will again receive their credentials shortly before the
meeting.

This will be the first meeting since August and I hope we get some more
topics than just the obligatory Status Reports. Please send your
proposals by replying to this mail.


Best regards,

Colin

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




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

 

 




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

 

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

Re: [ros-dev] Status Meeting (November 2018)

[Ged Murphy]

Some potential talking points:

 

*   Selecting a new coordinator
*   Version bump to 0.5
*   USB / Storage (perhaps linked to a 0.5 release)
*   Mattermost
*   New website progress

 

 

From: Ros-dev  On Behalf Of Mark Jansen
Sent: Wednesday, 28 November 2018 16:13
To: ReactOS Development List 
Subject: Re: [ros-dev] Status Meeting (November 2018)

 

We can discuss this if you are present, but I don't see the value in discussing 
it without you.

We have seen before that something discussed without the initiator being 
present is time not well spent, since it is a bit hard to argue with only one 
side of the argument present

 

 

 

Op 26 nov. 2018 12:15 schreef hermes.belu...@sfr.fr 
 :

Hello,

I may not be available as it's the day when I'm going somewhere for a 
conference; it just depends at which time I arrive at destination.

For the meeting we may talk about the best way we can move to delivering 
all-in-one ReactOS ISOs (containing livecd + installation in both text and GUI 
modes), and which changes this could imply for our infrastructure 
(buildbots/website...).

Best regards,
Hermes 

De : "Javier Agustìn Fernàndez Arroyo"
A : "ReactOS Development List"
Envoyé: samedi 24 novembre 2018 22:06
Objet : Re: [ros-dev] Status Meeting (November 2018)
  

I'm at work but I will do my best to attend!

  

El sáb., 24 nov. 2018 21:38, Colin Finck mailto:co...@reactos.org> > escribió:

Hi all!

Let me invite you to the November 2018 meeting, taking place next
Thursday, November 29, 2018 at 19:00 UTC.
Invited members will again receive their credentials shortly before the
meeting.

This will be the first meeting since August and I hope we get some more
topics than just the obligatory Status Reports. Please send your
proposals by replying to this mail.


Best regards,

Colin

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




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

 

 

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

Re: [ros-dev] Contribution for Tracing APIs

[Ged Murphy]

There’s a hell of a lot more to implementing the kernel piece than that one 
API, but by all means implement the usermode APIs and create a PR.

 

From: Biswapriyo Nath  
Sent: Tuesday, 04 September 2018 19:14
To: ros-dev@reactos.org
Cc: gedmurphy.mailli...@gmail.com
Subject: Re: Contribution for Tracing APIs

 

I can provide only the user mode APIs in advapi32.dll and sechost.dll. I'm bit 
familiar with kernel mode but not with kernel mode APIs. Most of the user mode 
event tracing APIs connected to ntoskrnl!NtTraceControl(). If someone familiar 
with kernel mode he/she just have to apply that function in kernel.

Thanks for reply. 

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

Re: [ros-dev] Contribution for Tracing APIs

[Ged Murphy]

We’re missing the entire event tracing framework, and unless you’re interested 
in implementing the whole thing (both in user mode and kernel mode), 
unfortunately the APIs you mentioned won’t be working anytime soon.

 

 

From: Ros-dev  On Behalf Of Biswapriyo Nath
Sent: Tuesday, 04 September 2018 11:04
To: ros-dev@reactos.org
Subject: [ros-dev] Contribution for Tracing APIs

 

I've some working code for event tracing APIs like StartTrace, OpenTrace, 
ControlTrace etc. Those works in Windows 10 but are not present in ReactOS 
Advapi.dll. How can I add those APIs?

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

Re: [ros-dev] [ros-diffs] 01/01: [WLNOTIFY] Add sens service stubs

[Ged Murphy]

Hi Eric,

Do you plan on implementing sysntfy which sens is dependent upon from win7, or 
do you plan to stick with the XP way via winlogon?
If so, I have some undocumented notes and code on sysntfy which might be of 
some use.

Ged.

-Original Message-
From: Ros-diffs  On Behalf Of Eric Kohl
Sent: Tuesday, 07 August 2018 21:57
To: ros-di...@reactos.org
Subject: [ros-diffs] 01/01: [WLNOTIFY] Add sens service stubs

https://git.reactos.org/?p=reactos.git;a=commitdiff;h=fb5d5ecd64e1e47701e922e08fd97b29a1d418be

commit fb5d5ecd64e1e47701e922e08fd97b29a1d418be
Author: Eric Kohl 
AuthorDate: Tue Aug 7 22:56:33 2018 +0200
Commit: Eric Kohl 
CommitDate: Tue Aug 7 22:56:33 2018 +0200

[WLNOTIFY] Add sens service stubs
---
 dll/win32/wlnotify/CMakeLists.txt|  1 +
 dll/win32/wlnotify/{test.c => senssvc.c} | 56 +---
 dll/win32/wlnotify/test.c|  2 +-
 dll/win32/wlnotify/wlnotify.spec | 24 +++---
 4 files changed, 43 insertions(+), 40 deletions(-)

diff --git a/dll/win32/wlnotify/CMakeLists.txt 
b/dll/win32/wlnotify/CMakeLists.txt
index 1db47fffe2..6cbf00ce86 100644
--- a/dll/win32/wlnotify/CMakeLists.txt
+++ b/dll/win32/wlnotify/CMakeLists.txt
@@ -3,6 +3,7 @@ spec2def(wlnotify.dll wlnotify.spec ADD_IMPORTLIB)
 
 list(APPEND SOURCE
 schedsvc.c
+senssvc.c
 test.c
 wlnotify.c
 precomp.h)
diff --git a/dll/win32/wlnotify/test.c b/dll/win32/wlnotify/senssvc.c 
similarity index 86% copy from dll/win32/wlnotify/test.c copy to 
dll/win32/wlnotify/senssvc.c index e3911d3b75..e238a849a9 100644
--- a/dll/win32/wlnotify/test.c
+++ b/dll/win32/wlnotify/senssvc.c
@@ -1,12 +1,13 @@
 /*
  * PROJECT: ReactOS system libraries
  * LICENSE: GPL - See COPYING in the top level directory
- * FILE:dll/win32/wlnotify/test.c
- * PURPOSE: Winlogon notifications
- * PROGRAMMER:  Eric Kohl
+ * FILE:dll/win32/wlnotify/senssvc.c
+ * PURPOSE: SENS service logon notifications
+ * PROGRAMMER:  Eric Kohl 
  */
 
 #include "precomp.h"
+#include 
 
 #define _NDEBUG
 #include 
@@ -14,10 +15,10 @@
 
 VOID
 WINAPI
-TestLogonEvent(
+SensDisconnectEvent(
 PWLX_NOTIFICATION_INFO pInfo)
 {
-DPRINT("TestLogonEvent\n");
+DPRINT("SensDisconnectEvent\n");
 DPRINT("Size: %lu\n", pInfo->Size);
 DPRINT("Flags: %lx\n", pInfo->Flags);
 DPRINT("UserName: %S\n", pInfo->UserName); @@ -31,10 +32,10 @@ 
TestLogonEvent(
 
 VOID
 WINAPI
-TestLogoffEvent(
+SensLockEvent(
 PWLX_NOTIFICATION_INFO pInfo)
 {
-DPRINT("TestLogoffEvent\n");
+DPRINT("SensLockEvent\n");
 DPRINT("Size: %lu\n", pInfo->Size);
 DPRINT("Flags: %lx\n", pInfo->Flags);
 DPRINT("UserName: %S\n", pInfo->UserName); @@ -48,10 +49,10 @@ 
TestLogoffEvent(
 
 VOID
 WINAPI
-TestLockEvent(
+SensLogoffEvent(
 PWLX_NOTIFICATION_INFO pInfo)
 {
-DPRINT("TestLockEvent\n");
+DPRINT("SensLogoffEvent\n");
 DPRINT("Size: %lu\n", pInfo->Size);
 DPRINT("Flags: %lx\n", pInfo->Flags);
 DPRINT("UserName: %S\n", pInfo->UserName); @@ -65,10 +66,10 @@ 
TestLockEvent(
 
 VOID
 WINAPI
-TestUnlockEvent(
+SensLogonEvent(
 PWLX_NOTIFICATION_INFO pInfo)
 {
-DPRINT("TestUnlockEvent\n");
+DPRINT("SensLogonEvent\n");
 DPRINT("Size: %lu\n", pInfo->Size);
 DPRINT("Flags: %lx\n", pInfo->Flags);
 DPRINT("UserName: %S\n", pInfo->UserName); @@ -82,10 +83,10 @@ 
TestUnlockEvent(
 
 VOID
 WINAPI
-TestStartupEvent(
+SensPostShellEvent(
 PWLX_NOTIFICATION_INFO pInfo)
 {
-DPRINT("TestStartupEvent\n");
+DPRINT("SensPostShellEvent\n");
 DPRINT("Size: %lu\n", pInfo->Size);
 DPRINT("Flags: %lx\n", pInfo->Flags);
 DPRINT("UserName: %S\n", pInfo->UserName); @@ -99,10 +100,10 @@ 
TestStartupEvent(
 
 VOID
 WINAPI
-TestShutdownEvent(
+SensReconnectEvent(
 PWLX_NOTIFICATION_INFO pInfo)
 {
-DPRINT("TestShutdownEvent\n");
+DPRINT("SensReconnectEvent\n");
 DPRINT("Size: %lu\n", pInfo->Size);
 DPRINT("Flags: %lx\n", pInfo->Flags);
 DPRINT("UserName: %S\n", pInfo->UserName); @@ -116,10 +117,10 @@ 
TestShutdownEvent(
 
 VOID
 WINAPI
-TestStartScreenSaverEvent(
+SensShutdownEvent(
 PWLX_NOTIFICATION_INFO pInfo)
 {
-DPRINT("TestStartScreenSaverEvent\n");
+DPRINT("SensShutdownEvent\n");
 DPRINT("Size: %lu\n", pInfo->Size);
 DPRINT("Flags: %lx\n", pInfo->Flags);
 DPRINT("UserName: %S\n", pInfo->UserName); @@ -133,10 +134,10 @@ 
TestStartScreenSaverEvent(
 
 VOID
 WINAPI
-TestStopScreenSaverEvent(
+SensStartScreenSaverEvent(
 PWLX_NOTIFICATION_INFO pInfo)
 {
-DPRINT("TestStopScreenSaverEvent\n");
+DPRINT("SensStartScreenSaverEvent\n");
 DPRINT("Size: %lu\n", pInfo->Size);
 DPRINT("Flags: %lx\n", pInfo->Flags);
 DPRINT("UserName: %S\n", pInfo->UserName); @@ -150,10 +151,10 @@ 
TestStopScreenSaverEvent(
 
 VOID
 WINAPI
-TestStartShellEvent(
+SensStartShellEvent(
 PWLX_NOTIFICATION_INFO pInfo)
 {
-DPRINT("TestStartShellEvent\n");
+DPRINT("Sen

Re: [ros-dev] Postponing the July Meeting

[Ged Murphy]

We could keep components in the reactos git project and just create a new repo 
for them, however it might still get lost/overshadowed slightly by the main 
reactos codebase. Another option would be to create a new separate project with 
one\multiple repos. This would allow us to truly separate components from the 
reactos project and try to generate interest on their own merit.

We'd need to maximize their visibility by adding a good README.rd files with 
plenty of buzzwords for the google crawler bot to pick up.

If it was successful and we decide to do more, then we'd need to come up with a 
format as to how to best manage multiple components.
Do we have individual repos for each component, which allows dedicated 
README.rd files? This would give maximum flexibility and allow us to have a 
separate README.rd for each component.
Do we bundle everything into one repo similar to how the WDK samples are setup? 
This is easier to manage, but less convenient for end users, and won't be as 
visible for people to find in google searches.

Ged.


-Original Message-
From: Ros-dev  On Behalf Of Hermès BÉLUSCA-MAÏTO
Sent: Wednesday, 01 August 2018 20:20
To: 'ReactOS Development List' 
Subject: Re: [ros-dev] Postponing the July Meeting

Hi,

This sounds interesting, for potential developers wanting just to work on some 
module, but not wanting to deal with the whole OS thing.
Would this mean that we also have to think about git submodules? Because (in 
the case of the NTFS driver for example) it would be in a different git repo, 
and then it would have to be automatically downloaded and updated whenever one 
of the core ROS dev updates his own ROS git repo.

Cheers,
Hermes

> -Message d'origine-
> De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Ged 
> Murphy Envoyé : mercredi 1 août 2018 20:16 À : 'ReactOS Development 
> List'
> Objet : Re: [ros-dev] Postponing the July Meeting
> 
> I have an item for the agenda. I'd like to discuss the possibility of 
> moving some of our drivers out of the main repo and into something more 
> convenient.
> 
> In case I don't make the meeting, I'll put forward some of my reasons here:
> 
> This thought has come about due to the btrfs driver which we use from 
> Mark Harmstone. Mark's project receives quite a bit of interest on 
> github, and I'm assuming one of the reasons is that it's so easy to 
> find and build. Searching for 'btrfs windows' lists his project as the 
> top hit in google, and building is as simple as cloning, opening the 
> project in VS and clicking build (assuming you have the
> WDK)
> 
> I'm wondering if we did the same thing to some of our drivers, we 
> might generate more interest in them. A good example would be our NTFS driver.
> When searching for open source NTFS solutions you're only really given 
> Linux and Max options. The reactos driver is buried deep in the search 
> list, and you only see it if you know what you're looking for. Next if 
> you want to build it, you need to clone the main reactos repo, install 
> the build tools, setup and build the environment, build the tool 
> chain, build the linkers libs, etc, etc. There are so many barriers 
> for people who aren't part of the reactos development team that the chance of 
> getting anyone interested in it are practically zero.
> 
> This process would be much simpler if the code was available to clone 
> as a separate project, and could simply build with the WDK and VS. 
> There's then a chance that it might start to generate interest, and 
> people may start working on it instead of it just bit-rotting deep in our 
> main repo.
> 
> If we're going to do that, why not consider others too. Network cards, 
> sound stack, USB, boot loaders, printer drivers, directx, etc, There's 
> lots of things that people might be interested in working on and using 
> if they weren't tied to the reactos code base. We obviously benefit 
> from any external interest, and simply pull/import it back into the reactos 
> project.
> 
> Ged.
> 
> 
> 
> -Original Message-
> From: Ros-dev  On Behalf Of Colin Finck
> Sent: Thursday, 26 July 2018 17:58
> To: 'ReactOS Development List' 
> Subject: [ros-dev] Postponing the July Meeting
> 
> Hi all!
> 
> Looking at the calendar, it would be time for the July Meeting today.
> However, I didn't receive any agenda proposals and also forgot to 
> announce it in the course of releasing 0.4.9.
> So I suggest we postpone the meeting to next week's Thursday, August 2.
> 
> Please send agenda proposals by then.
> That meeting also allows us to handle last-minute planning regarding 
> the 

Re: [ros-dev] Postponing the July Meeting

[Ged Murphy]

I have an item for the agenda. I'd like to discuss the possibility of moving 
some of our drivers out of the main repo and into something more convenient.

In case I don't make the meeting, I'll put forward some of my reasons here:

This thought has come about due to the btrfs driver which we use from Mark 
Harmstone. Mark's project receives quite a bit of interest on github, and I'm 
assuming one of the reasons is that it's so easy to find and build. Searching 
for 'btrfs windows' lists his project as the top hit in google, and building is 
as simple as cloning, opening the project in VS and clicking build (assuming 
you have the WDK)

I'm wondering if we did the same thing to some of our drivers, we might 
generate more interest in them. A good example would be our NTFS driver. When 
searching for open source NTFS solutions you're only really given Linux and Max 
options. The reactos driver is buried deep in the search list, and you only see 
it if you know what you're looking for. Next if you want to build it, you need 
to clone the main reactos repo, install the build tools, setup and build the 
environment, build the tool chain, build the linkers libs, etc, etc. There are 
so many barriers for people who aren't part of the reactos development team 
that the chance of getting anyone interested in it are practically zero.

This process would be much simpler if the code was available to clone as a 
separate project, and could simply build with the WDK and VS. There's then a 
chance that it might start to generate interest, and people may start working 
on it instead of it just bit-rotting deep in our main repo.

If we're going to do that, why not consider others too. Network cards, sound 
stack, USB, boot loaders, printer drivers, directx, etc, There's lots of things 
that people might be interested in working on and using if they weren't tied to 
the reactos code base. We obviously benefit from any external interest, and 
simply pull/import it back into the reactos project.

Ged.



-Original Message-
From: Ros-dev  On Behalf Of Colin Finck
Sent: Thursday, 26 July 2018 17:58
To: 'ReactOS Development List' 
Subject: [ros-dev] Postponing the July Meeting

Hi all!

Looking at the calendar, it would be time for the July Meeting today.
However, I didn't receive any agenda proposals and also forgot to announce it 
in the course of releasing 0.4.9.
So I suggest we postpone the meeting to next week's Thursday, August 2.

Please send agenda proposals by then.
That meeting also allows us to handle last-minute planning regarding the 
Hackfest.

Best regards,

Colin



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

Re: [ros-dev] Phoronix

[Ged Murphy]

Me too, let them know; unless them are they, in which case, tell no one 

 

From: Ros-dev  On Behalf Of Can Tasan
Sent: Friday, 01 June 2018 23:58
To: ReactOS Development List 
Subject: Re: [ros-dev] Phoronix

 

I have finished for now. Please inform them. 

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

Re: [ros-dev] Status Meeting (May 2018)

[Ged Murphy]

I think in this particular case, Giannis' solution seems ideal. In addition, I 
think it'd be good to split our language resources into separate mui files and 
only install the language chosen on install.

However this obviously involves additional work, and doesn't solve the problem 
of what to do with the PR (leave it open, close, add to jira)

Ged.

-Original Message-
From: Ros-dev  On Behalf Of Colin Finck
Sent: Wednesday, 30 May 2018 17:19
To: ros-dev@reactos.org
Subject: Re: [ros-dev] Status Meeting (May 2018)

Am 30.05.2018 um 13:26 schrieb Ged Murphy:
> Potential problems are:
> 4) something else?

I've been struggling with e.g. https://github.com/reactos/reactos/pull/276

On the one hand, we definitely need official support for Chinese, Korean, and 
Japanese character sets.
On the other hand, this must not bloat up ReactOS by default, and just dropping 
a 12 MB font into the repository definitely does.
So what is the ideal solution? I don't even know myself.

- I could leave the PR open and hope that the submitter addresses my comments 
and comes up with a better solution. That hasn't happened in the last months.

- I could close the PR right away. That would give the submitter no chance to 
address my comments and may even look disrespectful. And the original problem 
tends to be forgotten.

- I could close the PR and open a JIRA issue describing the problem.
If we decide on that as a general rule, we would put another burden on every 
reviewer. Additionally, such general JIRA issues tend to rot in our database as 
well.

I think we often have this situation where the submitted PR is wrong, but we 
don't know the right solution either, and therefore keep the PR open. If we can 
better deal with these cases, the number of open PRs may decrease significantly.


- Colin



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

Re: [ros-dev] Status Meeting (May 2018)

[Ged Murphy]

I'd like to expand on point 2, which is something myself and DavidQ were 
discussing recently.
Our PRs are becoming out of control. I've been though a lot of the top project 
on github, and most seem to have just a small handful of open PRs at any one 
time. As of this writing, we're currently at 83 and we've consistently 
increased since we first moved to github. We're on track to surpass 100 next 
month.

Potential problems are:
1) we have too few people reviewing
2) some of the devs reviewing are far too picky/pedantic in their comments
3) people are too afraid of just merging them
4) anything not on the first page gets ignored
4) something else?

My personal thoughts are we have a mixture of 2 & 3, with a hint of 4.
Whatever the issues are, there are certainly things we can do to address it, 
but I'll leave that for the meeting discussion.

Ged.


-Original Message-
From: Ros-dev  On Behalf Of Colin Finck
Sent: Monday, 28 May 2018 08:16
To: 'ReactOS Development List' 
Subject: [ros-dev] Status Meeting (May 2018)

Hi all!

Let me invite you to the May 2018 meeting, taking place this Thursday, May 31, 
2018 at 19:00 UTC.
Invited members will again receive their credentials shortly before the meeting.

Based on requests and current topics, the agenda looks like this:


1. Status Reports
   ==
   Like last time, participants are requested to just post their
   prepared reports again to not waste any minute.

2. Improving our handling of PRs and JIRA reports
   ==
   The global JIRA permissions have been changed this month and there
   has been a lot of bad blood regarding issues marked as "trivial".
   On the one hand, trivial PRs waste a lot of time of our core
   developers as long as they are the only ones able to commit them.
   On the other hand, trivial PRs still add minor improvements to the
   code, so it would be wrong to just close them as invalid.
   Let's have an open discussion on this topic and try to establish
   rules we can all work with without taking this problem to a personal
   level.

3. Google Summer of Code
   =
   This will be the first meeting, which could be joined by our GSoC
   student Victor Perevertkin. If he or the mentors have questions that
   are better discussed with all developers in the monthly meeting,
   let's do this here.

4. Changes affecting base addresses
   
   Robert Naumann has requested adding this topic to the agenda.
   He couldn't merge several PRs translating .mc files, because that
   would blow up the kernel and require a regeneration of all base
   addresses. He requested a brainstorming session in this meeting
   to get to a conclusion how to deal with this problem.
   I know that Joachim Henze has also attempted to change base addresses
   lately to fix Photoshop CS2, so this is probably the right time to
   deal with this problem.


Further topics can be requested by replying to this mail.
See you all on Thursday!


Best regards,

Colin



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

Re: [ros-dev] Phoronix

[Ged Murphy]

I really don’t see it as a problem.

They clearly state it’s an RC, the wiki states it the changelog is incomplete 
…. and it’s just a single site.

 

Asking them to delete the article (which we have no actual authority to do) 
seems pretty ridiculous to me. We should be thanking them for writing articles, 
not shooting them down for writing too many.

 

 

 

From: Ros-dev  On Behalf Of Can Tasan
Sent: Tuesday, 29 May 2018 20:45
To: ReactOS Development List 
Subject: Re: [ros-dev] Phoronix

 

Well, the problem is that current CC is missing HALF of the improvements made. 

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

Re: [ros-dev] [ros-diffs] 01/01: [NULL] Additions for the Null driver.

[Ged Murphy]

They're pagable in NT6, I don't know whether that's the case in NT5.

Change looks good to me, I'm not really sure why Alex used NNP? 
Perhaps our kernel does/did things slightly differently back when he wrote the 
Null driver?

Ged.

-Original Message-
From: Ros-dev  On Behalf Of Thomas Faber
Sent: Monday, 23 April 2018 07:49
To: Hermès Bélusca-Maïto 
Cc: ros-dev@reactos.org
Subject: Re: [ros-dev] [ros-diffs] 01/01: [NULL] Additions for the Null driver.

On 2018-04-22 22:23, Hermès Bélusca-Maïto wrote:
> diff --git a/drivers/base/null/null.c b/drivers/base/null/null.c index 
> 610e886ddd..0d4ed541de 100644
> --- a/drivers/base/null/null.c
> +++ b/drivers/base/null/null.c
> @@ -181,26 +199,16 @@ DriverEntry(IN PDRIVER_OBJECT DriverObject,
>   DriverObject->MajorFunction[IRP_MJ_READ] = NullDispatch;
>   DriverObject->MajorFunction[IRP_MJ_LOCK_CONTROL] = NullDispatch;
>   DriverObject->MajorFunction[IRP_MJ_QUERY_INFORMATION] = 
> NullDispatch;
> +DriverObject->DriverUnload = NullUnload;
>   
> -/* Allocate the fast I/O dispatch table */
> -FastIoDispatch = ExAllocatePoolWithTag(NonPagedPool,
> -   sizeof(FAST_IO_DISPATCH),
> -   'llun');
> -if (!FastIoDispatch)
> -{
> -/* Failed, cleanup */
> -IoDeleteDevice(DeviceObject);
> -return STATUS_INSUFFICIENT_RESOURCES;
> -}
> -
> -/* Initialize it */
> -RtlZeroMemory(FastIoDispatch, sizeof(FAST_IO_DISPATCH));
> -FastIoDispatch->SizeOfFastIoDispatch = sizeof(FAST_IO_DISPATCH);
> +/* Initialize the fast I/O dispatch table */
> +RtlZeroMemory(&FastIoDispatch, sizeof(FastIoDispatch));
> +FastIoDispatch.SizeOfFastIoDispatch = sizeof(FastIoDispatch);
>   
>   /* Setup our pointers */
> -FastIoDispatch->FastIoRead = NullRead;
> -FastIoDispatch->FastIoWrite = NullWrite;
> -DriverObject->FastIoDispatch = FastIoDispatch;
> +FastIoDispatch.FastIoRead = NullRead;
> +FastIoDispatch.FastIoWrite = NullWrite;
> +DriverObject->FastIoDispatch = &FastIoDispatch;


Are you sure FAST_IO_DISPATCH is allowed to be pageable? It seems to only be 
used at low IRQLs, so it seems logical. However I see it allocated nonpaged 
everywhere else and can't seem to find definitive documentation on the subject.
(And yes, most filesystem drivers use a static structure, but those
  drivers don't use MmPageEntireDriver)

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] 01/01: [WTSAPI32] Sync with Wine 3.0. CORE-14225

[Ged Murphy]

Is this really a sync up?
It takes implemented functions are returns them to stubs

-Original Message-
From: Ros-diffs [mailto:ros-diffs-boun...@reactos.org] On Behalf Of Amine Khaldi
Sent: 21 January 2018 21:02
To: ros-di...@reactos.org
Subject: [ros-diffs] 01/01: [WTSAPI32] Sync with Wine 3.0. CORE-14225

https://git.reactos.org/?p=reactos.git;a=commitdiff;h=90f14ccef3d9d344b7021407b4c59a7234a19614

commit 90f14ccef3d9d344b7021407b4c59a7234a19614
Author: Amine Khaldi 
AuthorDate: Sun Jan 21 22:01:34 2018 +0100
Commit: Amine Khaldi 
CommitDate: Sun Jan 21 22:01:34 2018 +0100

[WTSAPI32] Sync with Wine 3.0. CORE-14225
---
 dll/win32/wtsapi32/wtsapi32.c | 95 ---
 media/doc/README.WINE |  2 +-
 2 files changed, 10 insertions(+), 87 deletions(-)

diff --git a/dll/win32/wtsapi32/wtsapi32.c b/dll/win32/wtsapi32/wtsapi32.c 
index a7f4c873d9..92a7396f54 100644
--- a/dll/win32/wtsapi32/wtsapi32.c
+++ b/dll/win32/wtsapi32/wtsapi32.c
@@ -28,9 +28,6 @@
 
 WINE_DEFAULT_DEBUG_CHANNEL(wtsapi);
 
-/* FIXME: Inspect */
-#define GetCurrentProcessToken() ((HANDLE)~(ULONG_PTR)3)
-
 
 /
  *WTSCloseServer  (WTSAPI32.@)
@@ -99,13 +96,8 @@ BOOL WINAPI WTSEnumerateProcessesA(HANDLE hServer, DWORD 
Reserved, DWORD Version  BOOL WINAPI WTSEnumerateProcessesW(HANDLE hServer, 
DWORD Reserved, DWORD Version,
 PWTS_PROCESS_INFOW* ppProcessInfo, DWORD* pCount)  {
-WTS_PROCESS_INFOW *processInfo;
-SYSTEM_PROCESS_INFORMATION *spi;
-ULONG size = 0x4000;
-void *buf = NULL;
-NTSTATUS status;
-DWORD count;
-WCHAR *name;
+FIXME("Stub %p 0x%08x 0x%08x %p %p\n", hServer, Reserved, Version,
+  ppProcessInfo, pCount);
 
 if (!ppProcessInfo || !pCount || Reserved != 0 || Version != 1)
 {
@@ -113,71 +105,9 @@ BOOL WINAPI WTSEnumerateProcessesW(HANDLE hServer, DWORD 
Reserved, DWORD Version
 return FALSE;
 }
 
-if (hServer != WTS_CURRENT_SERVER_HANDLE)
-{
-SetLastError(ERROR_CALL_NOT_IMPLEMENTED);
-return FALSE;
-}
-
-do
-{
-size *= 2;
-HeapFree(GetProcessHeap(), 0, buf);
-buf = HeapAlloc(GetProcessHeap(), 0, size);
-if (!buf)
-{
-SetLastError(ERROR_OUTOFMEMORY);
-return FALSE;
-}
-status = NtQuerySystemInformation(SystemProcessInformation, buf, size, 
NULL);
-}
-while (status == STATUS_INFO_LENGTH_MISMATCH);
-
-if (status != STATUS_SUCCESS)
-{
-HeapFree(GetProcessHeap(), 0, buf);
-SetLastError(RtlNtStatusToDosError(status));
-return FALSE;
-}
-
-spi = buf;
-count = size = 0;
-for (;;)
-{
-size += sizeof(WTS_PROCESS_INFOW) + spi->ProcessName.Length + 
sizeof(WCHAR);
-count++;
-if (spi->NextEntryOffset == 0) break;
-spi = (SYSTEM_PROCESS_INFORMATION *)(((PCHAR)spi) + 
spi->NextEntryOffset);
-}
-
-processInfo = HeapAlloc(GetProcessHeap(), 0, size);
-if (!processInfo)
-{
-HeapFree(GetProcessHeap(), 0, buf);
-SetLastError(ERROR_OUTOFMEMORY);
-return FALSE;
-}
-name = (WCHAR *)&processInfo[count];
-
-*ppProcessInfo = processInfo;
-*pCount = count;
-
-spi = buf;
-while (count--)
-{
-processInfo->SessionId = 0;
-processInfo->ProcessId = HandleToUlong(spi->UniqueProcessId);
-processInfo->pProcessName = name;
-processInfo->pUserSid = NULL;
-memcpy( name, spi->ProcessName.Buffer, spi->ProcessName.Length );
-name[ spi->ProcessName.Length/sizeof(WCHAR) ] = 0;
-
-processInfo++;
-name += (spi->ProcessName.Length + sizeof(WCHAR))/sizeof(WCHAR);
-spi = (SYSTEM_PROCESS_INFORMATION *)(((PCHAR)spi) + 
spi->NextEntryOffset);
-}
+*pCount = 0;
+*ppProcessInfo = NULL;
 
-HeapFree(GetProcessHeap(), 0, buf);
 return TRUE;
 }
 
@@ -241,7 +171,9 @@ BOOL WINAPI WTSEnumerateSessionsW(HANDLE hServer, DWORD 
Reserved, DWORD Version,
  */
 void WINAPI WTSFreeMemory(PVOID pMemory)  {
-HeapFree(GetProcessHeap(), 0, pMemory);
+static int once;
+
+if (!once++) FIXME("Stub %p\n", pMemory);
 }
 
 /
@@ -314,16 +246,7 @@ BOOL WINAPI WTSQuerySessionInformationW(  BOOL WINAPI 
WTSQueryUserToken(ULONG session_id, PHANDLE token)  {
 FIXME("%u %p\n", session_id, token);
-
-if (!token)
-{
-SetLastError(ERROR_INVALID_PARAMETER);
-return FALSE;
-}
-
-return DuplicateHandle(GetCurrentProcess(), GetCurrentProcessToken(),
-   GetCurrentProcess(), token,
-   0, FALSE, DUPLICATE_SAME_ACCESS);
+return FALSE;
 }
 
 /
@@ -357,7 +280,7 @@ BOOL WINAPI WTSRegisterSessionNotification(HWND hWnd, DWORD 
dwFlags)  }
 
 /***

Re: [ros-dev] Enabling themes in 3rd stage

[Ged Murphy]

They look great (especially the Basic Lite one :)) I'm guessing a smaller start 
icon would reduce the taskbar size?

An option to select a theme in second stage gets my vote.
Perhaps allow 4 default choices (3 and classic). The 2nd stage dialog could 
then be divided into 4 equal parts and each part contains a selectable image of 
the theme.


-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Giannis 
Adamopoulos
Sent: 31 July 2017 15:57
To: ReactOS Development List 
Subject: Re: [ros-dev] Enabling themes in 3rd stage

Lautus: http://i.imgur.com/lqrqvtu.png
Basic lite (without any font changes): http://i.imgur.com/BcTIF9m.png

To make basic lite look better needs to substitute its fonts with some we 
already have.


Ged Murphy  wrote on Mon, July 31st, 2017, 4:44 
PM:
> A link to the theme I mentioned would probably help...
> http://aportz19.deviantart.com/art/Basic-Lite-and-Basic-8-Visual-Style-for-Windows-XP-393826050
> 
> 
> -Original Message-
> From: Ged Murphy [mailto:gedmurphy.mailli...@gmail.com] 
> Sent: 31 July 2017 15:43
> To: 'ReactOS Development List' 
> Subject: RE: [ros-dev] Enabling themes in 3rd stage
> 
> Do you have some pics??
> 
> I've always been a big fan of seeing the Basic Lite theme being on by 
> default, which would give ros a much more modern look and feel.
> We're missing the start menu implementation for this though.
> 
> 
> 
> -Original Message-
> From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Giannis 
> Adamopoulos
> Sent: 31 July 2017 15:29
> To: ros-dev@reactos.org
> Subject: [ros-dev] Enabling themes in 3rd stage
> 
> Hello,
> After recent changes in explorer, comctl32 and uxtheme the state of themes in 
> reactos was improved a lot. I would like to ask your opinions about enabling 
> themes in 3rd stage. It is also possible to have an option in 2nd stage to 
> select if we want 3rd stage to have themes enabled. Do you think this should 
> be enabled by default or not? All ideas are welcome. My intention is to 
> complete it ASAP so that it can make in the release.
> 
> Thanks,
> Giannis Adamopoulos
> 
> ___
> 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] Enabling themes in 3rd stage

[Ged Murphy]

A link to the theme I mentioned would probably help...
http://aportz19.deviantart.com/art/Basic-Lite-and-Basic-8-Visual-Style-for-Windows-XP-393826050


-Original Message-
From: Ged Murphy [mailto:gedmurphy.mailli...@gmail.com] 
Sent: 31 July 2017 15:43
To: 'ReactOS Development List' 
Subject: RE: [ros-dev] Enabling themes in 3rd stage

Do you have some pics??

I've always been a big fan of seeing the Basic Lite theme being on by default, 
which would give ros a much more modern look and feel.
We're missing the start menu implementation for this though.



-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Giannis 
Adamopoulos
Sent: 31 July 2017 15:29
To: ros-dev@reactos.org
Subject: [ros-dev] Enabling themes in 3rd stage

Hello,
After recent changes in explorer, comctl32 and uxtheme the state of themes in 
reactos was improved a lot. I would like to ask your opinions about enabling 
themes in 3rd stage. It is also possible to have an option in 2nd stage to 
select if we want 3rd stage to have themes enabled. Do you think this should be 
enabled by default or not? All ideas are welcome. My intention is to complete 
it ASAP so that it can make in the release.

Thanks,
Giannis Adamopoulos

___
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] Enabling themes in 3rd stage

[Ged Murphy]

Do you have some pics??

I've always been a big fan of seeing the Basic Lite theme being on by default, 
which would give ros a much more modern look and feel.
We're missing the start menu implementation for this though.



-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Giannis 
Adamopoulos
Sent: 31 July 2017 15:29
To: ros-dev@reactos.org
Subject: [ros-dev] Enabling themes in 3rd stage

Hello,
After recent changes in explorer, comctl32 and uxtheme the state of themes in 
reactos was improved a lot. I would like to ask your opinions about enabling 
themes in 3rd stage. It is also possible to have an option in 2nd stage to 
select if we want 3rd stage to have themes enabled. Do you think this should be 
enabled by default or not? All ideas are welcome. My intention is to complete 
it ASAP so that it can make in the release.

Thanks,
Giannis Adamopoulos

___
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] About the bootcd and livecd, and the 1st-stage GUI setup

[Ged Murphy]

Run or install? 
I think I prefer David's version.

- Install
- Try without installing
- Cancel and boot from disk
- Advanced options ...


-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Giannis 
Adamopoulos
Sent: 05 July 2017 14:03
To: ReactOS Development List 
Subject: Re: [ros-dev] About the bootcd and livecd, and the 1st-stage GUI setup

I'd say that we should show:
- Run or install ReactOS
- Boot from hard disk
- Advanced options

Nothing more should be needed and the first option should be clear that can 
either lead to a live environment or a setup.


David Quintana (gigaherz)  wrote on Tue, July 4th, 2017, 
10:45 PM:
> I feel like the boot menu is going to be far too busy for the end 
> user. I'd go with something closer to
> 
> blah blah:
> 
>- Install Now
>- Try without installing
>- Show advanced options...
> 
> where:
> 
>- Install now -- boots into the graphical installer (no desktop unless
>you cancel or something)
>- Try without installing -- boots into livecd desktop (backed by RAM, I
>guess)
>- Show advanced options... -- opens a second-level menu with
>- Text-mode installer
>   - Live boot without Ramdisk
>   - etc.
> 
> 
> 
> On 4 July 2017 at 21:45, Hermès BÉLUSCA-MAÏTO  wrote:
> 
> > Hello everyone,
> >
> >
> >
> > One of the long-term plan for ReactOS was to have a graphical 
> > user-mode interface for the 1st-stage setup, similar to e.g. what 
> > may be found in newer versions of Windows (Vista+), as an 
> > alternative to our current 1st-stage setup in text-mode
> >
> > (note that I say “alternative”, not “replacement”, because both of 
> > them can live together without fundamental changes to either ReactOS 
> > or our ISO images, both of them can share core functionality, and 
> > finally because some people may prefer the text-mode either for 
> > unattended installations or for low-memory conditions).
> >
> >
> >
> > You can find some information about the 1st-stage GUI setup here:
> > https://reactos.org/wiki/First_Stage_GUI_Setup . In our source code, 
> > it can be found in base/setup/reactos/ . Currently only most of the 
> > screens have been implemented, while the core functionality is not 
> > present. However this functionality can somehow be taken by reusing 
> > the source code of USETUP (see my branch 
> > https://svn.reactos.org/svn/reactos/branches/setup_
> > improvements/base/setup/ ).
> >
> >
> >
> >
> >
> > Abstract (aka. TL;DR): I explain below the needed changes introduced 
> > experimentally in the “setup-improvements” branch, revision 75273, 
> > to generate an all-in-one ReactOS bootcd, that includes both the 
> > 1st-stage text-mode setup + 1st-stage GUI setup alternative + 
> > live-demo functionality. This is meant to replace our currently 
> > separated “bootcd” / “livecd” ISOs, where the latter currently do 
> > not offer the possibility to install ReactOS. Some currently known 
> > potential problems are evoked.
> >
> >
> >
> > Images: Proposed BootCD contents : http://i.imgur.com/EBA6JHd.png ; 
> > Proposed Boot Menu : http://i.imgur.com/14n5Ryi.png .
> >
> >
> >
> >
> >
> > Having a 1st-stage GUI setup also means that it’ll also use the 
> > already-existing functionality that we offer in our “Live-CD” ISOs.
> > Currently, the “Live-CD” ISOs we provide only allow for 
> > demonstration purposes, while the ReactOS installation proper is 
> > found in our so-called “Boot-CD” ISOs (which currently only contain 
> > text-mode setup). Thus, the 1 st-stage GUI setup, as an alternative 
> > to the 1st-stage setup in text-mode, means that both ISOs can be 
> > merged all in one, and we won’t have to make a distinction between 
> > both: they will be able to offer both the 1 st-stage in text mode 
> > AND a graphical mode (à la “Live-CD”) where it is possible to choose 
> > whether to test ReactOS in demo mode, or to install it via the GUI setup.
> >
> > Such an all-in-one ISO capability was already present in the trunk 
> > under the name “hybridcd”, but was used only when we built ISO 
> > images for the public events where ReactOS participated (FOSDEM, 
> > CLT, …). But now, having the setup process both in text mode and in 
> > graphics mode, in addition to the Live-CD demonstration capability, 
> > really suggests just using the all-in-one ISO and stop doing the “Boot-CD” 
> > (aka. only setup) vs. “Live-CD”
> > (aka. only demo) separation. We would just generate only one type of 
> > ISO that contains everything.
> >
> >
> >
> > With that in mind, I have committed in my branch 
> > “setup_improvements”, in revision 75273 : 
> > https://svn.reactos.org/svn/reactos?view=revision&;
> > revision=75273 such changes to be able to only build an ISO that 
> > contains everything. These changes are minimal, in the sense that I 
> > haven’t purposelessly changed the names of the build targets just to 
> > be fancy. Such changes may be done later, but not now.
> >
> >
> >
> >

Re: [ros-dev] "Note: LibreOffice 5.4 will be the last codeline tosupport Windows XP or Vista"

[Ged Murphy]

That’s what’s currently being worked on.

The kernel still closely follows the NT5.2 architecture, but user mode will 
have NT6+ compatibility shims to allow modern applications to run correctly.

 

From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of ajac...@yahoo.es
Sent: 30 June 2017 05:47
To: ReactOS Development List 
Subject: Re: [ros-dev] "Note: LibreOffice 5.4 will be the last codeline 
tosupport Windows XP or Vista"

 

I think it’s no neccesary to implement NT6, only to avoid the compatibility 
tests to NT6 and implement only the characteristics that the most of the 
programs uses.

 

Best regards

Antonio J. Arrieta Cuartero 

 

Enviado desde mi Lumia 635 con Windows 10 Mobile

 

De: Riccardo Paolo Bestetti  
Enviado: jueves, 29 de junio de 2017 22:11
Para: ReactOS Development List  
Asunto: Re: [ros-dev] "Note: LibreOffice 5.4 will be the last codeline 
tosupport Windows XP or Vista"

 

Hello Colin,

As this definitely wasn't the predominant thinking the last time this same 
discussion took place, Hermès' email scared me a bit. Thank you so much for 
clarifying.

 

Best regards,

Riccardo Paolo Bestetti

 

-Original Message-

From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Colin Finck

Sent: giovedì 29 giugno 2017 20:00

To: ros-dev@reactos.org  

Subject: Re: [ros-dev] "Note: LibreOffice 5.4 will be the last codeline to 
support Windows XP or Vista"

 

Rest assured, we know that ReactOS won't be of much use if we stay NT5-only. 
Work is underway to provide a seamless support of NT6 applications on top of 
the existing codebase.

Also the majority of developers should be using an NT6 platform themselves, so 
they certainly aim for support for NT6 applications.

Finally, applications compiled by modern versions of Visual Studio are NT6-only 
by default, so supporting this platform is unavoidable.

 

Just my two cents, as the previous replies could lead you to believe we're 
failing the reality check.

 

Cheers,

 

Colin

 

 

Am 29.06.2017 um 18:54 schrieb Riccardo Paolo Bestetti:

> I’m just gonna snap in for my yearly IT guy NT6 rant: this mindset is 

> going to kill the project by making it useless whenever it reaches a 

> usable state.

> 

> Windows XP/Server 2003 use is **already** marginal as of today, and 

> it’s only gonna get “worse” as more and more networks get infected by 

> ransomware and institutions all over the world wake up and update (and 

> as time passes of course). It’s not a matter of “fancy”, it is a 

> matter of what people use on their computers. With that argument you 

> may as well advocate for DOS.

> 

>  

> 

> Please don’t be offended, as always this is only intended as a reality 

> check.

> 

>  

> 

> Best regards,

> 

> Riccardo Paolo Bestetti

> 

>  

> 

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

> *Hermès BÉLUSCA-MAÏTO

> *Sent:* giovedì 29 giugno 2017 16:09

> *To:* 'ReactOS Development List'   >

> *Subject:* Re: [ros-dev] "Note: LibreOffice 5.4 will be the last 

> codeline to support Windows XP or Vista"

> 

>  

> 

> I’m wondering for which useless / fancy features they need Windows 7+ 

> support only….

> 

>  

> 

> H.

> 

>  

> 

>  

> 

> *De :*Ros-dev [mailto:ros-dev-boun...@reactos.org] *De la part de* 

> Javier Agustìn Fernàndez Arroyo *Envoyé :* jeudi 29 juin 2017 15:48 *À 

> :* ReactOS Development List *Objet :* [ros-dev] "Note: LibreOffice 5.4 

> will be the last codeline to support Windows XP or Vista"

> 

>  

> 

> https://wiki.documentfoundation.org/Releases/5.4.0/RC1

> 

>  

> 

>  

> 

> FYI

> 

> 

> 

> ___

> 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] ReactOS Hackfest 2017 - Are you in?

[Ged Murphy]

Hi Colin,

I was hoping to make it this year, but I'm at a family wedding and the wife 
seems to think it'd be rude if I didn't attend ☹

Next year is my year!
Ged.


-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Colin Finck
Sent: 21 June 2017 11:04
To: 'ReactOS Development List' 
Subject: [ros-dev] ReactOS Hackfest 2017 - Are you in?

Hi all!

I'm currently planning the ReactOS Hackfest 2017 in the Cologne/Bonn area in 
Germany. Currently, the plan is to book a meeting room from Monday, August 14 
to Friday, August 18. We can then use the weekend before to get to Cologne and 
explore the city a bit. After the Hackfest, everybody interested can join us at 
FrOSCon in Bonn the weekend after.

As booking a room there involves significant costs, I'd like to know who of you 
can definitely make it for the Hackfest and who of you is definitely out.

Please reply now to prevent me from bugging you on IRC all the time! ;)


Cheers,

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] [ros-diffs] [gedmurphy] 74590: [FLTMGR] - Add a rather messy header that I've been slowly building as I'm starting to understand the internals. - Mostly taken from the MS PDBs and info g

[Ged Murphy]

Hi Alex,

 

Oh I wasn’t aware of that, that’s great.

Thanks for the tip 😊

 

Ged.

 

 

From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Alex Ionescu
Sent: 19 May 2017 16:28
To: ReactOS Development List 
Subject: Re: [ros-dev] [ros-diffs] [gedmurphy] 74590: [FLTMGR] - Add a rather 
messy header that I've been slowly building as I'm starting to understand the 
internals. - Mostly taken from the MS PDBs and info gained from OSR and Alex...

 

Hey Ged,

 

The full internal internal filter manager header was published by microsoft in 
the "minwin" folder of the TH1 and TH2 WDK+SDK. Same place where Timo and 
Thomas have been using "ntosp.h" from.




Best regards,
Alex Ionescu

 

On Fri, May 19, 2017 at 2:42 AM, mailto:gedmur...@svn.reactos.org> > wrote:

Author: gedmurphy
Date: Fri May 19 09:42:00 2017
New Revision: 74590

URL: http://svn.reactos.org/svn/reactos?rev=74590 
 &view=rev
Log:
[FLTMGR]
- Add a rather messy header that I've been slowly building as I'm starting to 
understand the internals.
- Mostly taken from the MS PDBs and info gained from OSR and Alex Carp's blog. 
(https://fsfilters.blogspot.co.uk)

Added:
trunk/reactos/drivers/filters/fltmgr/fltmgrint.h   (with props)

Added: trunk/reactos/drivers/filters/fltmgr/fltmgrint.h
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filters/fltmgr/fltmgrint.h?rev=74590
==
--- trunk/reactos/drivers/filters/fltmgr/fltmgrint.h(added)
+++ trunk/reactos/drivers/filters/fltmgr/fltmgrint.h[iso-8859-1] Fri May 19 
09:42:00 2017
@@ -0,0 +1,284 @@
+#ifndef _FLTMGR_INTERNAL_H
+#define _FLTMGR_INTERNAL_H
+
+
+#define MAX_CONTEXT_TYPES   6
+
+
+typedef enum _FLT_OBJECT_FLAGS
+{
+FLT_OBFL_DRAINING = 1,
+FLT_OBFL_ZOMBIED = 2,
+FLT_OBFL_TYPE_INSTANCE = 0x100,
+FLT_OBFL_TYPE_FILTER = 0x200,
+FLT_OBFL_TYPE_VOLUME = 0x400
+
+} FLT_OBJECT_FLAGS, *PFLT_OBJECT_FLAGS;
+
+typedef enum _FLT_FILTER_FLAGS
+{
+FLTFL_MANDATORY_UNLOAD_IN_PROGRESS = 1,
+FLTFL_FILTERING_INITIATED = 2
+
+} FLT_FILTER_FLAGS, *PFLT_FILTER_FLAGS;
+
+typedef struct _FLT_OBJECT   // size = 0x14
+{
+volatile FLT_OBJECT_FLAGS Flags;
+ULONG PointerCount;
+EX_RUNDOWN_REF RundownRef;
+LIST_ENTRY PrimaryLink;
+
+} FLT_OBJECT, *PFLT_OBJECT;
+
+typedef struct _ALLOCATE_CONTEXT_HEADER
+{
+PFLT_FILTER Filter;
+PFLT_CONTEXT_CLEANUP_CALLBACK ContextCleanupCallback;
+struct _ALLOCATE_CONTEXT_HEADER *Next;
+FLT_CONTEXT_TYPE ContextType;
+char Flags;
+char AllocationType;
+
+} ALLOCATE_CONTEXT_HEADER, *PALLOCATE_CONTEXT_HEADER;
+
+typedef struct _FLT_RESOURCE_LIST_HEAD
+{
+ERESOURCE rLock;
+LIST_ENTRY rList;
+ULONG rCount;
+
+} FLT_RESOURCE_LIST_HEAD, *PFLT_RESOURCE_LIST_HEAD;
+
+typedef struct _FLT_MUTEX_LIST_HEAD
+{
+FAST_MUTEX mLock;
+LIST_ENTRY mList;
+ULONG mCount;
+
+} FLT_MUTEX_LIST_HEAD, *PFLT_MUTEX_LIST_HEAD;
+
+typedef struct _FLT_FILTER   // size = 0x120
+{
+FLT_OBJECT Base;
+PVOID Frame;  //FLTP_FRAME
+UNICODE_STRING Name;
+UNICODE_STRING DefaultAltitude;
+FLT_FILTER_FLAGS Flags;
+PDRIVER_OBJECT DriverObject;
+FLT_RESOURCE_LIST_HEAD InstanceList;
+PVOID VerifierExtension;
+PFLT_FILTER_UNLOAD_CALLBACK FilterUnload;
+PFLT_INSTANCE_SETUP_CALLBACK InstanceSetup;
+PFLT_INSTANCE_QUERY_TEARDOWN_CALLBACK InstanceQueryTeardown;
+PFLT_INSTANCE_TEARDOWN_CALLBACK InstanceTeardownStart;
+PFLT_INSTANCE_TEARDOWN_CALLBACK InstanceTeardownComplete;
+PALLOCATE_CONTEXT_HEADER SupportedContextsListHead;
+PALLOCATE_CONTEXT_HEADER SupportedContexts[MAX_CONTEXT_TYPES];
+PVOID PreVolumeMount;
+PVOID PostVolumeMount;
+PFLT_GENERATE_FILE_NAME GenerateFileName;
+PFLT_NORMALIZE_NAME_COMPONENT NormalizeNameComponent;
+PFLT_NORMALIZE_CONTEXT_CLEANUP NormalizeContextCleanup;
+PFLT_OPERATION_REGISTRATION Operations;
+PFLT_FILTER_UNLOAD_CALLBACK OldDriverUnload;
+FLT_MUTEX_LIST_HEAD ActiveOpens;
+FLT_MUTEX_LIST_HEAD ConnectionList;
+FLT_MUTEX_LIST_HEAD PortList;
+EX_PUSH_LOCK PortLock;
+
+}  FLT_FILTER, *PFLT_FILTER;
+
+typedef enum _FLT_yINSTANCE_FLAGS
+{
+INSFL_CAN_BE_DETACHED = 0x01,
+INSFL_DELETING = 0x02,
+INSFL_INITING = 0x04
+
+} FLT_INSTANCE_FLAGS, *PFLT_INSTANCE_FLAGS;
+
+typedef struct _FLT_TYPE
+{
+USHORT Signature;
+USHORT Size;
+
+} FLT_TYPE, *PFLT_TYPE;
+
+typedef struct _FLT_INSTANCE   // size = 0x144 (324)
+{
+FLT_OBJECT Base;
+ULONG OperationRundownRef;
+PVOID Volume; //PFLT_VOLUME
+PFLT_FILTER Filter;
+FLT_INSTANCE_FLAGS Flags;
+UNICODE_STRING Altitude;
+UNICODE_STRING Name;
+LIST_ENTRY FilterLink;
+ERESOURCE ContextLock;
+PVOID Context; //PCONTEXT_NODE
+PVOID TrackCompletionNodes; //PRACK_COMPLETION_NODES
+PVOID CallbackNodes[50]; //PCALLBACK_NODE
+
+} FLT_INSTANCE, *PFLT_INSTAN

Re: [ros-dev] [ros-diffs] [phater] 74577: [MSTSC] Fix BSOD when we can't acquire context from CryptoAPI. CORE-13263 #resolve

[Ged Murphy]

Fixing a bugcheck from usermode???
I'm guessing you mean avoid a bugcheck, and the real crash still needs 
investigating and fixing?

-Original Message-
From: Ros-diffs [mailto:ros-diffs-boun...@reactos.org] On Behalf Of 
pha...@svn.reactos.org
Sent: 18 May 2017 09:48
To: ros-di...@reactos.org
Subject: [ros-diffs] [phater] 74577: [MSTSC] Fix BSOD when we can't acquire 
context from CryptoAPI. CORE-13263 #resolve

Author: phater
Date: Thu May 18 08:47:30 2017
New Revision: 74577

URL: http://svn.reactos.org/svn/reactos?rev=74577&view=rev
Log:
[MSTSC] Fix BSOD when we can't acquire context from CryptoAPI. CORE-13263 
#resolve



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

Re: [ros-dev] Opening up #reactos-dev to the public

[Ged Murphy]

Hi,

 

Our audio developer is Johannes Anderwald, but unfortunately he’s been away 
from the project for a little while now. Unless anyone other devs feel they can 
step into this role, it’s unlikely we’d be able to find a mentor for this 
particular project.

 

Is audio the only area that you’re interested in, or are there other areas 
which you feel you’d like to work on? With an entire operating system at your 
disposal, there’s plenty of other options to explore.

 

Ged.

 

From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Pranay Pratyush
Sent: 28 March 2017 06:39
To: ReactOS Development List 
Subject: Re: [ros-dev] Opening up #reactos-dev to the public

 

Hi there, are any devs here with whom I can discuss the audio architecture of 
ReactOS in order to know its current state as compared to Windows?




 

--

Pranay Pratyush,

3rd year undergraduate ,

Computer Science and Engineering Department

Indian Institute Of Technology, Kharagpur

--

 

On Mon, Mar 27, 2017 at 5:26 PM, Aleksey Bragin mailto:alek...@reactos.org> > wrote:

Same for me. The idea for #reactos and #reactos-dev to exist was the fact that 
one is for public audience, and the second one is for internal communication 
between developers.

If #reactos-dev is opened to the public, then why not delete it at all and move 
to #reactos?

I rather support Alex's proposal of creating something like #reactos-gsoc or 
just autovoicing students, it's not a big deal.

Regards,
Aleksey Bragin



On 27.03.2017 11:31, Ged Murphy wrote:

Agreed.

If the restriction is removed, I would be much less inclined to join the 
channel.

I stopped joining #reactos for a reason…

Ged.

 

From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Hermès 
BÉLUSCA-MAÏTO
Sent: 24 March 2017 15:13
To: 'ReactOS Development List'  <mailto:ros-dev@reactos.org> 

Subject: Re: [ros-dev] Opening up #reactos-dev to the public

 

I don’t approve the idea. The fact is that if the devs quit originally 
#reactos, it’s because it was generally too noisy, etc… . If we remove the 
moderation irc bit in #reactos-dev, you may expect the same phenomenon to occur 
in #reactos-dev too.

 

De : Ros-dev [ <mailto:ros-dev-boun...@reactos.org> 
mailto:ros-dev-boun...@reactos.org] De la part de David Quintana (gigaherz)
Envoyé : vendredi 24 mars 2017 11:35
À : ReactOS Development List
Objet : Re: [ros-dev] Opening up #reactos-dev to the public

 

I approve the idea.

 

On 24 March 2017 at 11:21, Colin Finck < <mailto:co...@reactos.org> 
co...@reactos.org> wrote:

Hi all!

As you all know, our #reactos-dev IRC channel has been a moderated IRC
channel for decades, and only operators (devs) and voiced people can
talk. While we always tried to keep discussions dev-related there, no
topic has ever been enforced on #reactos. The result is that I see a
notable number of developers only on #reactos-dev these days.

This is a pretty bad situation! Emerging developers hardly have a way to
interact with all existing devs on IRC. Often enough, legitimate
questions from them remain unanswered on #reactos. Moreover, we don't
maintain the list of voiced people thoroughly, so even some contributors
have to ask for temporary voice on #reactos-dev.

Keep in mind that we're currently in the GSoC phase where students shall
submit their proposals and get in touch with the developers.
How are they going to do this on IRC if #reactos-dev continues to be an
exclusive club?

Because of these reasons, I'm proposing to remove the moderation bit on
#reactos-dev and let everybody talk there.
Its development topic should be enforced though! As soon as people get
too off-topic, they should be directed to #reactos and kicked if nothing
else helps. Given that all devs are already operators on #reactos-dev,
it's fully in their hands.


Cheers,

Colin

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

Re: [ros-dev] Opening up #reactos-dev to the public

[Ged Murphy]

Agreed.

If the restriction is removed, I would be much less inclined to join the 
channel.

I stopped joining #reactos for a reason…

Ged.

 

From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Hermès 
BÉLUSCA-MAÏTO
Sent: 24 March 2017 15:13
To: 'ReactOS Development List' 
Subject: Re: [ros-dev] Opening up #reactos-dev to the public

 

I don’t approve the idea. The fact is that if the devs quit originally 
#reactos, it’s because it was generally too noisy, etc… . If we remove the 
moderation irc bit in #reactos-dev, you may expect the same phenomenon to occur 
in #reactos-dev too.

 

De : Ros-dev [  
mailto:ros-dev-boun...@reactos.org] De la part de David Quintana (gigaherz)
Envoyé : vendredi 24 mars 2017 11:35
À : ReactOS Development List
Objet : Re: [ros-dev] Opening up #reactos-dev to the public

 

I approve the idea.

 

On 24 March 2017 at 11:21, Colin Finck <  
co...@reactos.org> wrote:

Hi all!

As you all know, our #reactos-dev IRC channel has been a moderated IRC
channel for decades, and only operators (devs) and voiced people can
talk. While we always tried to keep discussions dev-related there, no
topic has ever been enforced on #reactos. The result is that I see a
notable number of developers only on #reactos-dev these days.

This is a pretty bad situation! Emerging developers hardly have a way to
interact with all existing devs on IRC. Often enough, legitimate
questions from them remain unanswered on #reactos. Moreover, we don't
maintain the list of voiced people thoroughly, so even some contributors
have to ask for temporary voice on #reactos-dev.

Keep in mind that we're currently in the GSoC phase where students shall
submit their proposals and get in touch with the developers.
How are they going to do this on IRC if #reactos-dev continues to be an
exclusive club?

Because of these reasons, I'm proposing to remove the moderation bit on
#reactos-dev and let everybody talk there.
Its development topic should be enforced though! As soon as people get
too off-topic, they should be directed to #reactos and kicked if nothing
else helps. Given that all devs are already operators on #reactos-dev,
it's fully in their hands.


Cheers,

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] [ros-diffs] [akhaldi] 73929: [CABINET] Sync with Wine Staging 2.2. CORE-12823 a663fe94 cabinet:

[Ged Murphy]

These are so much more useful to read now we have a changelog to explain the 
patch.
Thanks Amine :)

-Original Message-
From: Ros-diffs [mailto:ros-diffs-boun...@reactos.org] On Behalf Of 
akha...@svn.reactos.org
Sent: 26 February 2017 16:01
To: ros-di...@reactos.org
Subject: [ros-diffs] [akhaldi] 73929: [CABINET] Sync with Wine Staging 2.2. 
CORE-12823 a663fe94 cabinet: Set index of folder in FDICopy callback. 1f7d144 
cabinet: Make Extract fail on read-only files. af86bdc cabinet: ...

Author: akhaldi
Date: Sun Feb 26 16:00:58 2017
New Revision: 73929

URL: http://svn.reactos.org/svn/reactos?rev=73929&view=rev
Log:
[CABINET] Sync with Wine Staging 2.2. CORE-12823

a663fe94 cabinet: Set index of folder in FDICopy callback.
1f7d144 cabinet: Make Extract fail on read-only files.
af86bdc cabinet: Make Extract overwrite existing files.
3273dff cabinet: Properly initialize internal fci structure (Valgrind).

Modified:
trunk/reactos/dll/win32/cabinet/cabinet_main.c
trunk/reactos/dll/win32/cabinet/fci.c
trunk/reactos/media/doc/README.WINE



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

Re: [ros-dev] Microsoft switched to Git

[Ged Murphy]

I think the easiest path is to switch to a centralized style model using git.
That is, we have a master copy (aka trunk) that gives the feel of our existing 
model. That would allow devs that prefer SVN to mostly continue working as 
before, and give the devs who want to use git in a more traditional way the 
ability to branch off and work in a git style manner, then sync their changes 
back into 'trunk'.


-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Colin Finck
Sent: 15 February 2017 10:53
To: ros-dev@reactos.org
Subject: Re: [ros-dev] Microsoft switched to Git

Am 15.02.2017 um 11:35 schrieb David Quintana (gigaherz):
> The number doesn't matter. The ReactOS project can't afford to lost 
> any long-time members. Git would be a benefit for all of us, but it 
> has to be a benefit for ALL of us.

Let's not forget:

- Part of the reasons developers had against Git may have been resolved by now.
- Part of the problem may be that "Git is so different" to some devs, but I 
think this can be resolved by a detailed Wiki article showing how to do the 
same thing in SVN and Git. We already wrote such articles for TortoiseSVN after 
all!
- And finally, we first need a plan for a Git move that doesn't suck. We tried 
SubGit and it failed for us. Then there is the "Merge workflow", which is 
supported very well by all tools, but creates a lot of parallel history. The 
"Rebase workflow" is more like what SVN does (keeping a linear history), but no 
idea how to enforce that with TortoiseGit.

I think if a team could look after these things and help moving each and every 
developer towards Git, it may even be doable for us.

Cheers,

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] Microsoft switched to Git

[Ged Murphy]

Yeah, I had a meeting about this last week at work. We’re slowly doing the 
same, pushing all new projects to use tfs git, and give existing projects using 
vsts the option to convert if they wish.

Git is far better at managing developers working in remote locations, and as 
most of the software industry has already moved towards devs working remotely, 
it makes sense. There are very few big companies no longer using a distributed 
system such as git or mercurial. 

 

That fact that open source projects, which are inherently built on devs being 
remote, are still reluctant to move from a centralized to a distributed system 
seems archaic and self-detrimental. It’s a shame to hold the project back 
because a few devs are unwilling to move forward.

 

A distributed system can do everything a centralized system can do if you 
decide to model it in that way, and so much more if you decide to model it in 
other ways.

 

Ged.

 

 

From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of David Quintana 
(gigaherz)
Sent: 15 February 2017 09:57
To: ReactOS Development List 
Subject: Re: [ros-dev] Microsoft switched to Git

 

Unlike us, Microsoft probably doesn't care if a few of the developers would 
rather quit than switch. ;P

 

On 15 February 2017 at 10:40, Colin Finck mailto:co...@reactos.org> > wrote:

https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-git-and-some-back-story/

I didn't expect Microsoft to switch to Git sooner than us..

___
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] 73433: [SERVICES] Create a new environment block when a service process is started. Patch by Hermès BÉLUSCA - MAÏTO. CORE-12414

[Ged Murphy]

This leaks if ImpersonateLoggedOnUser fails and the environment block is 
non-null

-Original Message-
From: Ros-diffs [mailto:ros-diffs-boun...@reactos.org] On Behalf Of 
ek...@svn.reactos.org
Sent: 06 December 2016 17:30
To: ros-di...@reactos.org
Subject: [ros-diffs] [ekohl] 73433: [SERVICES] Create a new environment block 
when a service process is started. Patch by Hermès BÉLUSCA - MAÏTO. CORE-12414


+if (Service->lpImage->hToken)
+{
+/* User token: Run the service under the user account */
+
+if (!CreateEnvironmentBlock(&lpEnvironment, Service->lpImage->hToken, 
FALSE))
+{
+/* We failed, run the service with the current environment */
+DPRINT1("CreateEnvironmentBlock() failed with error %d, service 
'%S' will run with the current environment.\n",
+Service->lpServiceName, GetLastError());
+lpEnvironment = NULL;
+}
+
+/* Impersonate the new user */
+if (!ImpersonateLoggedOnUser(Service->lpImage->hToken))
+{
+dwError = GetLastError();
+DPRINT1("ImpersonateLoggedOnUser() failed with error %d\n", 
GetLastError());
+return dwError;
+}



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

Re: [ros-dev] [ros-diffs] [gedmurphy] 72178: [FLTLIB] - Stub out fltlib.dll. - Add basic implementations for FilterLoad and FilterUnload - Remove the wine code, this lib talks directly to fltmgr.sys a

[Ged Murphy]

> You're leaking this allocation.
Oops Code is still very unfinished so would've picked it up later.

> +// Hack - our SDK reports NTDDI_VERSION as 0x05020100 (from 
> +_WIN32_WINNT 0x502) // which doesn't pass the FLT_MGR_BASELINE check 
> +in fltkernel.h #define NTDDI_VERSION NTDDI_WS03SP1

> We typically set this kind of thing in CMakeLists.txt.. however maybe we 
> should define it this way by default

It's a temporary hack, it definitely doesn't wanna be in cmakelists.txt
We need to come up with a better solution, bumping the version is one 
possibility.





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

Re: [ros-dev] [ros-diffs] [hbelusca] 71864: [FLTMGR]: Remove a MSVC warning: FltObjectDereference, whose prototype is publicly defined in fltkernel.h, doesn't return any value.

[Ged Murphy]

This change in incorrect, FltObectDereference does return a value. 
It's the public definition that's does match the function.

-Original Message-
From: Ros-diffs [mailto:ros-diffs-boun...@reactos.org] On Behalf Of 
hbelu...@svn.reactos.org
Sent: 08 July 2016 18:45
To: ros-di...@reactos.org
Subject: [ros-diffs] [hbelusca] 71864: [FLTMGR]: Remove a MSVC warning: 
FltObjectDereference, whose prototype is publicly defined in fltkernel.h, 
doesn't return any value.

Author: hbelusca
Date: Fri Jul  8 17:44:59 2016
New Revision: 71864

URL: http://svn.reactos.org/svn/reactos?rev=71864&view=rev
Log:
[FLTMGR]: Remove a MSVC warning: FltObjectDereference, whose prototype is 
publicly defined in fltkernel.h, doesn't return any value.



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

Re: [ros-dev] [ros-diffs] [hbelusca] 71695: [SUBST] - Update the resource program description. - Convert to full UNICODE. - Use Win32 functions where possible. - Factor-out the usage of QueryDosDevice

[Ged Murphy]

This should probably be moved to \base\applications\cmdutils

-Original Message-
From: Ros-diffs [mailto:ros-diffs-boun...@reactos.org] On Behalf Of 
hbelu...@svn.reactos.org
Sent: 29 June 2016 01:39
To: ros-di...@reactos.org
Subject: [ros-diffs] [hbelusca] 71695: [SUBST] - Update the resource program 
description. - Convert to full UNICODE. - Use Win32 functions where possible. - 
Factor-out the usage of QueryDosDevice into a QuerySubstedDri...

Author: hbelusca
Date: Wed Jun 29 00:38:51 2016
New Revision: 71695

URL: http://svn.reactos.org/svn/reactos?rev=71695&view=rev
Log:
[SUBST]
- Update the resource program description.
- Convert to full UNICODE.
- Use Win32 functions where possible.
- Factor-out the usage of QueryDosDevice into a QuerySubstedDrive function, 
that returns error codes according to whether the specified drive is a mapped 
(substed) drive, or is just an existing drive that is not a mapping, or if the 
drive does not exist. This allows us to detect attempts to use a drive letter 
that is not a mapped drive, to define a new mapping, and if so we reject such 
attempt.
This fixes CORE-10681 #resolve #comment Fixed with another patch according to 
my last remark.



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

Re: [ros-dev] [ros-diffs] [hbelusca] 71486: [WIN32K] Display a nice ReactOS version desktop watermark (with different fonts) when the corresponding registry values are set. See http://winaero.com/blog

[Ged Murphy]

There's another one of these when the OS is running in test mode.
"Bcdedit -set TESTSIGNING ON" will display the following:

Test Mode
Windows (n)
Build (n)

Maybe you can add that one when Alex finishes his UEFI/BCD stuff :)


-Original Message-
From: Ros-diffs [mailto:ros-diffs-boun...@reactos.org] On Behalf Of 
hbelu...@svn.reactos.org
Sent: 01 June 2016 16:25
To: ros-di...@reactos.org
Subject: [ros-diffs] [hbelusca] 71486: [WIN32K] Display a nice ReactOS version 
desktop watermark (with different fonts) when the corresponding registry values 
are set. See http://winaero.com/blog/a-new-way-to-display-t...

Author: hbelusca
Date: Wed Jun  1 15:24:38 2016
New Revision: 71486

URL: http://svn.reactos.org/svn/reactos?rev=71486&view=rev
Log:
[WIN32K]
Display a nice ReactOS version desktop watermark (with different fonts) when 
the corresponding registry values are set.
See 
http://winaero.com/blog/a-new-way-to-display-the-windows-version-on-your-desktop/
 for more details (which works on Windows 2003 too).
CORE-11349 #resolve



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

Re: [ros-dev] [ros-diffs] [mjansen] 71439: [APPHELP] Begin shimlib implementation. CORE-11329 Implement some macro's and functions that help when registering shims. These are all written in C, so that

[Ged Murphy]

Would it not be better to do all this in C++ and let wine write a C interface 
around it?
When we're trying to move to C++, it seems like a step backwards in order to 
support wine's insistence on using C


-Original Message-
From: Ros-diffs [mailto:ros-diffs-boun...@reactos.org] On Behalf Of 
mjan...@svn.reactos.org
Sent: 28 May 2016 17:43
To: ros-di...@reactos.org
Subject: [ros-diffs] [mjansen] 71439: [APPHELP] Begin shimlib implementation. 
CORE-11329 Implement some macro's and functions that help when registering 
shims. These are all written in C, so that wine can use the shim ...

Author: mjansen
Date: Sat May 28 16:42:57 2016
New Revision: 71439

URL: http://svn.reactos.org/svn/reactos?rev=71439&view=rev
Log:
[APPHELP] Begin shimlib implementation. CORE-11329 Implement some macro's and 
functions that help when registering shims.
These are all written in C, so that wine can use the shim libraries as well.



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

Re: [ros-dev] Pale Moon drops ReactOS support

[Ged Murphy]

I read the mail, and while it's definitely an elegant and well-engineered 
solution, I'm not convinced we need to go to that extent to support newer 
applications.

IMO applications checking for the existence of exports is not the massive 
problem it's always made out to be. We all know this happens, but do we have 
any use cases we can use to back it up? Can anyone point out any apps that 
would have a problem or is this all hypothetical?

Possible scenarios:
1) App checks for an export, finds it and uses it. Everyone is happy, and we're 
supporting a newer app. Yey! :)
2) App checks for an export and doesn't find it. It likely falls back onto an 
older (XP) solution which we'll likely support. Still happy, and we now have 
the option to implement support for this missing feature to make the app/user 
even happier.
3) App checks for an export, finds it and assumes a minimum OS. It therefore 
assumes a certain design/architecture and acts upon it (e.g. session 0 are 
system processes only). Okay so this is our pain point, and while it's clearly 
an issue in theory, does it actually exist in the real world? And if so, how 
often would we see it? Could we work around it using compatibility shims? This 
is what compatibility shims were designed for.

Most popular software is written by good engineers, and if good engineers are 
going to make design decisions based on the OS they're running on, they'll 
normally use the versioning APIs instead of trying to load an export that only 
exists on some boxes. So again I'm wondering how often scenario 3 actually 
exists in the real world.

Let's not forget that nobody uses reactos. No one is paying us for support, and 
we don't answer to anyone. Therefore if there's one misbehaving app out of 
1000, is it really such a big issue, especially if we're now providing support 
for more modern apps that previously didn't work due to a Win7 requirement. If 
it's a popular app that everyone needs, can we work around it using the 
compatibility shim engine? 

There has to be a trade-off somewhere as we have such low resources in terms of 
manpower, money and time. The solution I presented is a quick win, and once 
we've taken a reasonable step towards Win7 APIs, we could even report usermode 
as being win7 (with the kernel still reporting as 5.2).

You presented your solution to the list over a year ago and we're still having 
this discussion. Is anyone looking at it? Is it close to being finished? Will 
we still be having this discussion this time next year?

Our other option is to go with a simpler solution which we can move to almost 
immediately. We can deal with any problem apps if they actually materialize 
using compatibility shims, which are being worked on and may soon be ready so 
solve our problems when they appear.

We have to start adding new APIs at some point to move forward, otherwise we'll 
be in 2020, still reporting win2k3 and implementing everything via your 
compatibility layer.

Ged.

p.s. Apologies for the slightly long mail, hopefully you got this far without 
switching off ;)



-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Timo Kreuzer
Sent: 18 May 2016 20:28
To: ReactOS Development List 
Subject: Re: [ros-dev] Pale Moon drops ReactOS support

Looks like I have to chime in here.

We have been discussing this before and I wonder that Alex is not heavily 
opposing the idea of randomly adding new exports to our user mode DLLs. It is a 
well known fact that applications check for existance of exports to decide how 
to behave, so ... not going to go over this again.

To addess this issue I suggested to implement a compatibility layer. And there 
was a detailed discussion about that on this mailing list. 
https://www.reactos.org/pipermail/ros-dev/2015-March/017216.html

Please take your time to read the whole thread again so we can avoid wasting 
time, talking about the same things again.

Timo

...

Did you read it? Ok, then we can continue ;-)

Some remaining questions:
1. Does our SxS / ActiveCtx work properly, and does it work with 
registry/appcompat db? Otherwise what do we need to make it work? Aleksey?
2. How do we organize the DLLs? I would suggest to unite some core DLLs into 
"ros-kernelbase.dll" or something and gdi32/user32 into ros-win32.dll and 
export all functions from those, using forwarder DLLs through SxS. At the same 
time we should reorganize the code, organizing it the way that MS API sets do 
it. And also move the stuff out of the "dlls" folder into "win32core" or 
something.
3. How do we handle ntdll? Can we use SxS for ntdll as well? Obviously we 
cannot load the original ntdll with it, but we can probably load versioned 
wrapper ntdlls and resolve imports to those.

Timo

Am 18.05.2016 um 17:01 schrieb Ged Murphy:
> Okay, considering no other devs are chimi

Re: [ros-dev] Pale Moon drops ReactOS support

[Ged Murphy]

because 
>>> all the pieces of software they run dropped support for NT5, one 
>>> after another. They still have a single machine in the whole 
>>> building running Windows XP, for legacy software, and honestly they 
>>> don't use it very often. In my school, pretty much the same. And 
>>> even if someone, for whatever reason, intends to run NT5 for 10 more 
>>> years, why should (s)he re-setup all the systems again to run ReactOS 
>>> instead of keeping Windows XP?
>>>
>>> The point is, you can either implement the architecture that runs 
>>> all of the computer in building, or the architecture that runs that 
>>> one legacy machine. And even that would happen if and only if you 
>>> can achieve 100% compatibility with all of NT5 and Windows XP bugs 
>>> and quirks and give people a really good reason to reinstall the OS 
>>> on such machines, and sorry that's just not gonna happen.
>>>
>>> I get why some of you may want to stick to NT5, but you have to be 
>>> aware that if you do that ReactOS will never be used in the real 
>>> world. No reason to stick to NT5 is good enough, since no one out there 
>>> needs or wants NT5.
>>> Hell, it would probably be easier for a business to switch from NT6 
>>> to GNU/Linux than to go back to NT5.
>>>
>>> Again, these are just the two cents of a guy that works in the field.
>>>
>>> Best regards,
>>> --- Riccardo Paolo Bestetti
>>>
>>>
>>> Il 16/05/2016 16:42, Ged Murphy ha scritto:
>>>
>>> But you’re missing the point. The problem is that modern software is 
>>> leaving XP behind and focusing on Win7 as a minimum recommended requirement.
>>>
>>> What use is ReactOS if none of the modern browsers or applications 
>>> will run on it? It limits the OS to being a compatibility solution 
>>> for older software, or a POS device. No one really wants to see that.
>>>
>>>
>>>
>>> I think the best solution to start with is to keep reporting as 5.2 
>>> in the kernel, but allowing developers to start moving to the NT6 
>>> model. An mish-mash of NT5 and NT6 can co-exist as long things are done 
>>> sensibly. e.g.
>>> adding IO cancelation to our NT5 kernel isn’t going to make us 
>>> incompatible for XP’s drivers, but it allows us to implement an NT6 
>>> feature which hugely benefits the OS. Other obvious candidates are 
>>> unimplemented areas such as the fltmgr . Why implement the 2k3 
>>> fltmgr when we can implement a later fltmgr model which still loads older 
>>> filter drivers.
>>>
>>>
>>>
>>> Usermode should also still report as win2k3 (at least in the short 
>>> term), but start to add NT6 APIs directly into the codebase instead 
>>> of using a shim. We then maintain a whitelist of processes that 
>>> don’t run on ros due to a minimum requirement issue, and they get a 
>>> modified result from VerifyVersionInfo (and friends) to a later OS version.
>>>
>>>
>>>
>>> The above changes keep things pretty simple to start with, and allow 
>>> us to move forward almost immediately with very little infrastructure work.
>>>
>>>
>>>
>>> Ged.
>>>
>>>
>>>
>>>
>>>
>>> From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of 
>>> Javier Agustìn Fernàndez Arroyo
>>> Sent: 15 May 2016 22:55
>>> To: ReactOS Development List 
>>> Subject: Re: [ros-dev] Pale Moon drops ReactOS support
>>>
>>>
>>>
>>> "Being runnable only on old computers"
>>>
>>> I think this is a bad understanding of the problem
>>>
>>> By such statement, it seems that ReactOS will only work on old computers.
>>> And thats not true.
>>>
>>> ReactOS may work in any computer where there is hardware drivers for.
>>> And, as such, any software written for XP/2k3/ReactOS will work in 
>>> that computer.
>>>
>>> And afaik, manufacturers are still releasing drivers compatible with 
>>> XP
>>> :) (nVidia, for example)
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> 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


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

Re: [ros-dev] Pale Moon drops ReactOS support

[Ged Murphy]

But you’re missing the point. The problem is that modern software is leaving XP 
behind and focusing on Win7 as a minimum recommended requirement.

What use is ReactOS if none of the modern browsers or applications will run on 
it? It limits the OS to being a compatibility solution for older software, or a 
POS device. No one really wants to see that.

 

I think the best solution to start with is to keep reporting as 5.2 in the 
kernel, but allowing developers to start moving to the NT6 model. An mish-mash 
of NT5 and NT6 can co-exist as long things are done sensibly. e.g. adding IO 
cancelation to our NT5 kernel isn’t going to make us incompatible for XP’s 
drivers, but it allows us to implement an NT6 feature which hugely benefits the 
OS. Other obvious candidates are unimplemented areas such as the fltmgr . Why 
implement the 2k3 fltmgr when we can implement a later fltmgr model which still 
loads older filter drivers.

 

Usermode should also still report as win2k3 (at least in the short term), but 
start to add NT6 APIs directly into the codebase instead of using a shim. We 
then maintain a whitelist of processes that don’t run on ros due to a minimum 
requirement issue, and they get a modified result from VerifyVersionInfo (and 
friends) to a later OS version.

 

The above changes keep things pretty simple to start with, and allow us to move 
forward almost immediately with very little infrastructure work. 

 

Ged.

 

 

From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Javier Agustìn 
Fernàndez Arroyo
Sent: 15 May 2016 22:55
To: ReactOS Development List 
Subject: Re: [ros-dev] Pale Moon drops ReactOS support

 

"Being runnable only on old computers"

I think this is a bad understanding of the problem

By such statement, it seems that ReactOS will only work on old computers. And 
thats not true.

ReactOS may work in any computer where there is hardware drivers for. And, as 
such, any software written for XP/2k3/ReactOS will work in that computer.

And afaik, manufacturers are still releasing drivers compatible with XP :) 
(nVidia, for example)

 

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

Re: [ros-dev] Pale Moon drops ReactOS support

[Ged Murphy]

Yep, I agree with everything David says here. It’s the only sensible way 
forward, unless we’re aiming to be the next freedos.

 

A move to NT6 doesn’t mean we have to scrap everything we have that doesn’t fit 
that architecture, it’s just means the project is free to start to move towards 
a more NT6 way of doing things. It brings more freedom and fun to the project, 
keeps us relevant and hopefully makes us more attractive to would-be developers.

 

Ged.

 

From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of David Quintana 
(gigaherz)
Sent: 14 May 2016 10:27
To: ReactOS Development List 
Subject: Re: [ros-dev] Pale Moon drops ReactOS support

 

No, ros isn't a project to revive xp/2003, it has never been. The project 
decided to stick to 2003 many years ago, because it was unreasonable to try to 
keep up, and it was best to remain on a static target. When XP/2003 got close 
to EOL, we decided to use the fact that ReactOS is NT5 as a PR advantage, but I 
don't even know that this did much for us. 

The problem we have now, is this target is now so far back that many of us feel 
that staying on it may hurt the project more than help it.

Here is how I see it: There's two kinds of potentially large groups of users of 
ReactOS:

1.  The users of older hardware or software who require NT5 in order to run 
specific devices or applications that aren't compatible with newer systems, or
2.  The Windows users who like the Windows Platform, but want something 
more flexible, adaptable, and free of corporate control.

My guess is the number of people who would use ros simply because it implements 
and old architecture and they have an irrational dislike of anything newer, is 
a tiny minority.

If this is right, then we have two separate issues:

1.  We can't really "sell" (convince them to use) reactos to the first 
group, simply because it's too unstable an incomplete, so they'd rather stay on 
the real thing rather than use ros (with exceptions), and
2.  We can't really "sell" reactos to the second group, unless we can run 
the new applications designed for NT6+ that the second group is currently 
enjoying.

So the project has two possible goals:

1.  Continue doing as it does now, keep the NT5.2 target, stabilize the 
existing components, and develop the remaining components, all within the 
limitations of NT5, or
2.  Start an NT6 effort, maintaining NT5 compatibility through the 
compatibility systems (apphelp, sxs, and whatever else may be involved), that 
are already being developed regardless, but opening the doors to all the new 
software that has been developed for NT6+

And I have a strong feeling that the first group are less likely to contribute 
to the project, and less likely to adopt the project in the future, so yes, I 
would like the project to move in the other direction, not back to a dynamic 
target, just choose a new target to stick to, that isn't so far back, but isn't 
also being changed constantly anymore, and right now, that would be NT6.3 
(Windows 8.1 -- but we don't have to implement the Modern UI or remove the 
start menu, or any of that crap, this is about structure and APIs).


I may be biased, though: I'm most definitely on the second group. As a 
developer, I like ros because I like Windows over other platforms, but I'd love 
if it was opensource so I could tweak certain things beyond the options they 
provide. If ReactOS would start an effort to add NT6 features, I'd most 
definitely feel a renewed interest in the project, which you may have noticed 
has been already quite low these days.

P.S.: There's no NT7, Microsoft decided to change the NT version to match the 
client version, so windows 10 is now NT10, and like apple did with OSX, they 
plan on making future versions of windows just 10.x  ;P

 

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

Re: [ros-dev] Pale Moon drops ReactOS support

[Ged Murphy]

It might be worth putting a doc together listing the kernel parts we’re 
missing, the areas which need changes, and the areas which can be left as-is.

 

 

From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Mark Jansen
Sent: 12 May 2016 18:14
To: ReactOS Development List 
Subject: Re: [ros-dev] Pale Moon drops ReactOS support

 

 

For the features where this is possible without kernel support,

there is a mechanism in the pipeline that makes this possible: 'apphelp'

Currently I am still working on the base layer,

but when that is progressed a bit more we could integrate it more tightly in 
the Ldr,

so that it uses the target platform to apply automatic fixes (shims).

 

Having said that, it might be worth to upgrade parts of the kernel (only where 
it makes sense) to NT6 already,

without exposing that to applications.

Especially in new parts, as it would mean that something is written for NT5 
now, and first thing we do next is upgrade it to NT6.

 

 

On Thu, May 12, 2016 at 6:39 PM, Zachary Gorden mailto:drakekaizer...@gmail.com> > wrote:

Quite a few 'userland' features of NT6 requires kernel support to
function properly. If we go in, it would be, do NT6 kernel and slowly
bring the userland up to NT6. But we don't have a fully working NT5
kernel yet, so


On Thu, May 12, 2016 at 8:34 AM, David Quintana (gigaherz)
mailto:gigah...@gmail.com> > wrote:
> If we do NT6, we may want to have latest NT6 instead of trying to stick to
> an older one and having the same deprecation issue in a couple years?
>
> Also, what about the "idea" of keeping the majority of the kernel and large
> part of the usermode NT5, but having compatibility profiles that
> implement/emulate NT6 API functions using the existing NT5 feature set? Is
> that unrealistic?
>
> On 12 May 2016 at 14:39, Aleksey Bragin  <mailto:alek...@reactos.org> > wrote:
>>
>> Which again brings in the topic of updating the version we are targeting.
>> Windows 7 would be a minimum target these days, IMO.
>>
>> Regards,
>> Aleksey Bragin
>>
>> On 12.05.2016 14:04, Ged Murphy wrote:
>>>
>>> Yeah it's nonsense. No one drops support for ReactOS, they drop support
>>> for
>>> older versions of Windows which likely includes reactos too.
>>> If they were adding in ReactOS specific code, they were doing it wrong.
>>>
>>> The bigger issue here is that a lot of apps are starting to drop support
>>> for
>>> XP and recommend a minimum of Win7. If we don't do something about our
>>> insistence on sticking with 2k3, we'll soon be in a position where no
>>> browsers will run on ros, as well as a whole other list of apps.
>>>
>>> Ged.
>>>
>>
>>
>> ___
>> 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 <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

Re: [ros-dev] Pale Moon drops ReactOS support

[Ged Murphy]

Yeah it's nonsense. No one drops support for ReactOS, they drop support for
older versions of Windows which likely includes reactos too.
If they were adding in ReactOS specific code, they were doing it wrong.

The bigger issue here is that a lot of apps are starting to drop support for
XP and recommend a minimum of Win7. If we don't do something about our
insistence on sticking with 2k3, we'll soon be in a position where no
browsers will run on ros, as well as a whole other list of apps.

Ged.


-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Aleksey
Bragin
Sent: 12 May 2016 11:57
To: ReactOS Development List 
Subject: Re: [ros-dev] Pale Moon drops ReactOS support

On 10.05.2016 19:26, Alexander Rechitskiy wrote:
> https://forum.palemoon.org/viewtopic.php?t=12011#p84556
Maintaining ReactOS-specific version of anything is not a good idea anyway.
It's much more useful to fix bugs in ReactOS than to hide them in one
specific app or game.

Regards,
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] Status Meeting (March 2016)

[Ged Murphy]

But surely the meetings aren't sensitive for us to need our own server. What
do we think is going to happen, freenode are going to spy on us and release
the logs to government agencies?

All our clients can log, in fact mine has logging turned on globally at all
times. It's pretty simple to upload one of those logs to reactos.org.

It just seems kinda pointless to run our own server when we're all already
connected to freenode. Things were so much simpler last month.

-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Hermès
BÉLUSCA - MAÏTO
Sent: 31 March 2016 00:56
To: 'ReactOS Development List' 
Subject: Re: [ros-dev] Status Meeting (March 2016)

The point of using our own server is to be able to have our über-top-secret
(xDD) meetings there, and be able to automatically log the stuff so that you
can see it on some dedicated xxx.reactos.org server, the address of which I
don't remember now on top of my head. Plus other features, maybe, that I
don't know. Pierre and Colin, please shed light on that?

Cheers,
Hermès

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Ged Murphy
Envoyé : mercredi 30 mars 2016 21:38 À : 'ReactOS Development List'
Objet : Re: [ros-dev] Status Meeting (March 2016)

Can we not just use freenode again? It was so much easier last month

-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Aleksey
Bragin
Sent: 30 March 2016 19:15
To: ReactOS Development List 
Subject: [ros-dev] Status Meeting (March 2016)

Hello,
Let me invite you to the monthly status meeting taking place last Thursday
of a month, 31th of March, 19:00 UTC, as usual. That's tomorrow!

IRC service will only be started shortly before the meeting. Your
participation passwords and server address will be emailed to you shortly
before the meeting starts, and they are going to be different once again as
they are not stored in any database. Hopefully it's not much of
inconvenience.

Please send agenda proposals to me before the meeting. And yes, 0.4.1
release discussion is in the agenda list already, proposed by Alex Rex :-)

Regards,
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


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

Re: [ros-dev] Status Meeting (March 2016)

[Ged Murphy]

Can we not just use freenode again? It was so much easier last month

-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Aleksey
Bragin
Sent: 30 March 2016 19:15
To: ReactOS Development List 
Subject: [ros-dev] Status Meeting (March 2016)

Hello,
Let me invite you to the monthly status meeting taking place last Thursday
of a month, 31th of March, 19:00 UTC, as usual. That's tomorrow!

IRC service will only be started shortly before the meeting. Your
participation passwords and server address will be emailed to you shortly
before the meeting starts, and they are going to be different once again as
they are not stored in any database. Hopefully it's not much of
inconvenience.

Please send agenda proposals to me before the meeting. And yes, 0.4.1
release discussion is in the agenda list already, proposed by Alex Rex :-)

Regards,
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] [ros-diffs] [akhaldi] 71057: [REISERFS] Import ReiserFS file system driver for Windows. It will be enabled later on. Brought to you by Peter Hater. CORE-11005

[Ged Murphy]

And “Hide your wife” is surely the comment of the month

 

From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Javier Agustìn 
Fernàndez Arroyo
Sent: 27 March 2016 16:56
To: ReactOS Development List 
Cc: Linda Wang 
Subject: Re: [ros-dev] [ros-diffs] [akhaldi] 71057: [REISERFS] Import ReiserFS 
file system driver for Windows. It will be enabled later on. Brought to you by 
Peter Hater. CORE-11005

 

this is a candidate for "fix of the month"!

 

On Sat, Mar 26, 2016 at 11:42 PM, Alex Ionescu mailto:ion...@videotron.ca> > wrote:

Hide your wife.
Best regards,
Alex Ionescu


On Sat, Mar 26, 2016 at 1:40 PM,  mailto:akha...@svn.reactos.org> > wrote:
> Author: akhaldi
> Date: Sat Mar 26 20:40:42 2016
> New Revision: 71057
>
> URL: http://svn.reactos.org/svn/reactos?rev=71057 
>  &view=rev
> Log:
> [REISERFS] Import ReiserFS file system driver for Windows. It will be enabled 
> later on. Brought to you by Peter Hater. CORE-11005
>
> Added:
> trunk/reactos/drivers/filesystems/reiserfs/
> trunk/reactos/drivers/filesystems/reiserfs/CMakeLists.txt   (with props)
> trunk/reactos/drivers/filesystems/reiserfs/inc/
> trunk/reactos/drivers/filesystems/reiserfs/inc/gplntifs.h   (with props)
> trunk/reactos/drivers/filesystems/reiserfs/inc/linux/
> trunk/reactos/drivers/filesystems/reiserfs/inc/linux/bit_spinlock.h   
> (with props)
> trunk/reactos/drivers/filesystems/reiserfs/inc/linux/bitops.h   (with 
> props)
> trunk/reactos/drivers/filesystems/reiserfs/inc/linux/config.h   (with 
> props)
> trunk/reactos/drivers/filesystems/reiserfs/inc/linux/errno.h   (with 
> props)
> trunk/reactos/drivers/filesystems/reiserfs/inc/linux/fs.h   (with props)
> trunk/reactos/drivers/filesystems/reiserfs/inc/linux/jbd.h   (with props)
> trunk/reactos/drivers/filesystems/reiserfs/inc/linux/journal-head.h   
> (with props)
> trunk/reactos/drivers/filesystems/reiserfs/inc/linux/kernel.h   (with 
> props)
> trunk/reactos/drivers/filesystems/reiserfs/inc/linux/list.h   (with props)
> trunk/reactos/drivers/filesystems/reiserfs/inc/linux/log2.h   (with props)
> trunk/reactos/drivers/filesystems/reiserfs/inc/linux/module.h   (with 
> props)
> trunk/reactos/drivers/filesystems/reiserfs/inc/linux/nls.h   (with props)
> trunk/reactos/drivers/filesystems/reiserfs/inc/linux/reiserfs_acl.h   
> (with props)
> trunk/reactos/drivers/filesystems/reiserfs/inc/linux/reiserfs_fs.h   
> (with props)
> trunk/reactos/drivers/filesystems/reiserfs/inc/linux/reiserfs_fs_i.h   
> (with props)
> trunk/reactos/drivers/filesystems/reiserfs/inc/linux/reiserfs_fs_sb.h   
> (with props)
> trunk/reactos/drivers/filesystems/reiserfs/inc/linux/reiserfs_xattr.h   
> (with props)
> trunk/reactos/drivers/filesystems/reiserfs/inc/linux/slab.h   (with props)
> trunk/reactos/drivers/filesystems/reiserfs/inc/linux/spinlock.h   (with 
> props)
> trunk/reactos/drivers/filesystems/reiserfs/inc/linux/stddef.h   (with 
> props)
> trunk/reactos/drivers/filesystems/reiserfs/inc/linux/string.h   (with 
> props)
> trunk/reactos/drivers/filesystems/reiserfs/inc/linux/types.h   (with 
> props)
> trunk/reactos/drivers/filesystems/reiserfs/inc/linux/version.h   (with 
> props)
> trunk/reactos/drivers/filesystems/reiserfs/inc/reiserfs.h   (with props)
> trunk/reactos/drivers/filesystems/reiserfs/inc/rfsd.h   (with props)
> trunk/reactos/drivers/filesystems/reiserfs/src/
> trunk/reactos/drivers/filesystems/reiserfs/src/blockio.c   (with props)
> trunk/reactos/drivers/filesystems/reiserfs/src/cleanup.c   (with props)
> trunk/reactos/drivers/filesystems/reiserfs/src/close.c   (with props)
> trunk/reactos/drivers/filesystems/reiserfs/src/cmcb.c   (with props)
> trunk/reactos/drivers/filesystems/reiserfs/src/create.c   (with props)
> trunk/reactos/drivers/filesystems/reiserfs/src/debug.c   (with props)
> trunk/reactos/drivers/filesystems/reiserfs/src/devctl.c   (with props)
> trunk/reactos/drivers/filesystems/reiserfs/src/dirctl.c   (with props)
> trunk/reactos/drivers/filesystems/reiserfs/src/dispatch.c   (with props)
> trunk/reactos/drivers/filesystems/reiserfs/src/except.c   (with props)
> trunk/reactos/drivers/filesystems/reiserfs/src/fastio.c   (with props)
> trunk/reactos/drivers/filesystems/reiserfs/src/fileinfo.c   (with props)
> trunk/reactos/drivers/filesystems/reiserfs/src/flush.c   (with props)
> trunk/reactos/drivers/filesystems/reiserfs/src/fsctl.c   (with props)
> trunk/reactos/drivers/filesystems/reiserfs/src/init.c   (with props)
> trunk/reactos/drivers/filesystems/reiserfs/src/lockctl.c   (with props)
> trunk/reactos/drivers/filesystems/reiserfs/src/memory.c   (with props)
> trunk/reactos/drivers/filesystems/reiserfs/src/misc.c   (with props)
> trunk/reactos/drivers/filesystems/reiserfs/src/nls/
> trunk/reacto

Re: [ros-dev] Get STK running into ReactOS

[Ged Murphy]

I think he sent this to the STK mailing list and Cc’ed ros-dev in.

Yeah I know, it caught me out too….

 

 

From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Sylvain Deverre
Sent: 18 March 2016 07:10
To: ReactOS Development List 
Subject: Re: [ros-dev] Get STK running into ReactOS

 

Hello,

Applications that run on XP but not on ReactOS are considered as bugs, so the 
best thing you can do is to report them on our bugtracker I think (and provide 
debug logs to see what goes wrong)

Le 17 mars 2016 18:19, "Javier Agustìn Fernàndez Arroyo" mailto:elh...@gmail.com> > a écrit :

Hello, STK users and devs,

First of all, i´m new to this mailing list, so i hope not to disturb it...

I´m a fan of SuperTuxKart both in Linux (Ubuntu) and Windows. And i´m also a 
fan and user of the new operating system Reactos.

http://www.reactos.org

Yes, i do love open source.

I hae seen in your homepage that you bring binaries for Windows XP. You all 
know XP ended support long ago. And here is where ReactOS comes in place.

ReactOS aims to clone Windows 2003 behavior (and, as you know, 2k3 and XP are 
quite similar).

So my request is simple. I think it would be asesome if your game runs in this 
OS. And if not, its a bug that ReactOS devs have to fix. What would help 
development too.

What do u think? is it worth to give STK a try into ReactOS? what about putting 
this OS as a supported one, along with XP?

Thanks in advance for your attention.


___
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] GSOC 2016 - SSH Service Project

[Ged Murphy]

Why do we want an SSH server in the source?

If someone wants to run an SSH server, they can download and install one as 
they would do on Windows.

 

 

From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Zachary Gorden
Sent: 02 March 2016 16:58
To: ReactOS Development List 
Subject: Re: [ros-dev] GSOC 2016 - SSH Service Project

 

Any SSH server developed for ReactOS would need to be written in C/C++ and be 
compilable by both GCC and VC++. So while the expectation is that a developer 
would likely need to pull a SSH library from an existing source such as 
OpenSSH, the server itself will almost certainly need to be written from 
scratch if only because there does not exist as far as I am aware of a fully 
open source SSH server that runs natively on Windows without hauling around the 
likes of cygwin. Apache Mina is written in Java and therefore would be 
inappropriate as a starting base for the SSH server project.

 

On Wed, Mar 2, 2016 at 5:30 AM, Anchit Jain mailto:mailingl...@anchitja.in> > wrote:

Hello everyone,

I am Anchit Jain, Computer Science undergraduate from BITS PILANI, India. 
I am interested in pursuing SSH Service project.

 

I have some experience in Socket Programming and Network Protocol development 
in C. Some of my work could be seen at  

 https://github.com/anchitjain1234.

In past, I have implemented some basic network services like TFTP protocol and 
some minor part of FTP client. 

 

Regarding the project :- Would this project require a new SSH Server to be 
written from scratch or to be build upon some existing codebase like Apache 
Mina etc.?

 

I would request potential mentors to guide me for the same.

 

 

Thanks,

Anchit Jain





___
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 SVN version naming

[Ged Murphy]

Because that’s what is being worked towards now, and there will be an
unknown number of point releases until it’s reached.

It’s also a bit of nostalgia, it’s what we’ve always done :)

 

From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Hermès
BÉLUSCA - MAÏTO
Sent: 29 February 2016 16:00
To: ReactOS Development List 
Subject: [ros-dev] ReactOS SVN version naming

 

Hi guys,

 

I would like to understand what’s the rationale behind changing the ReactOS
trunk version from “0.4-SVN” to “0.5-SVN” (see revision 70818) whereas we
have just started to release ROS 0.4.0 only?

 

Thanks in advance for your explanations!

 

Cheers,

Hermès.

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

Re: [ros-dev] Consideration for migrating from Subversion to Git

[Ged Murphy]

Okay ignore me, we cleared it up in IRC. David means significant, I've just 
never heard  nevermind ..

If moving to git will increase the likelihood of patches from outside the team, 
then that in itself is a good enough reason to move IMO.


-Original Message-
From: Ged Murphy [mailto:gedmurphy.mailli...@gmail.com] 
Sent: 25 February 2016 11:26
To: 'ReactOS Development List' 
Subject: RE: [ros-dev] Consideration for migrating from Subversion to Git

> I think the real goal with moving to a platform such as github is 
> reducing the entry barriers for new contributors. As it has been 
> mentioned already, almost all projects who moved from SVN with "send 
> patches" contribution system, to Git/Hg with Pull Requests have got 
> non-negligible growth in contributions.

I'm confused, maybe it's your use of a double negative (non-negligible), but 
that sounds contradictory?
Are you saying that projects that have moved from SVN to git have had no growth 
or good growth in contributions?

Ged.



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

Re: [ros-dev] Consideration for migrating from Subversion to Git

[Ged Murphy]

> I think the real goal with moving to a platform such as github is reducing
> the entry barriers for new contributors. As it has been mentioned already,
> almost all projects who moved from SVN with "send patches" contribution
> system, to Git/Hg with Pull Requests have got non-negligible growth in
> contributions. 

I'm confused, maybe it's your use of a double negative (non-negligible), but 
that sounds contradictory?
Are you saying that projects that have moved from SVN to git have had no growth 
or good growth in contributions?

Ged.


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

Re: [ros-dev] Consideration for migrating from Subversion to Git

[Ged Murphy]

Are we not just looking for a solution to a problem that doesn't really
exist? Is SVN stopping us from doing anything, or from changing to a better
way of working for our project style? The move from CVS to SVN was worth
doing, but is a move to git worth doing?

If you think we have a use for git submodules, would svn externals not do
what you want instead?

I like git (from my limited experience with it), but as the majority of our
developers work in a Windows environment, I'm not convinced it's worth
moving everyone to, especially when we already have the git mirror.

Although one real win for us in moving to github would be in moving our
repository off of our servers and onto git's cloud backed service.

Ged.

-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Colin Finck
Sent: 25 February 2016 06:42
To: ros-dev@reactos.org
Subject: Re: [ros-dev] Consideration for migrating from Subversion to Git

Hi Mike,

So I was about to finish my ongoing server work in the next few days and
then push for a move to Git on the mailing lists. Thanks for spoiling those
plans! :)

I totally agree with all your raised points. I'm using Git every day at work
now, so do several of our developers. For some of us, ReactOS remains the
only project still using SVN.
While Git's usability under Windows has long been a problem (check ros-dev
from April 2009), TortoiseGit and GitHub have greatly simplified things
here.

I also got introduced into Git submodules recently. They're perfectly suited
for a large project like ReactOS that should be split up into multiple
smaller subprojects. Having several easily hackable subprojects, and then
having them on GitHub, gives us way more exposure and probably more
contributors.

So why hasn't this move happened earlier? Especially when some of our
developers are already actively using the git-svn mirror?
One reason is definitely trying to get a smooth transition done. You already
mentioned git-svn being buggy, and missing SVN branches are one part of the
problem. Reposurgeon looks interesting to do the right thing here.
Given that I'm used to Git by now, I also wouldn't mind if we fix a date,
make SVN read-only on that date and do all development in Git from then on.
AFAIK, the same has also worked for the CVS to SVN transition.

But I could imagine that there are still developers tied to the SVN way of
doing things. We would at least need a detailed Wiki page explaining some
common SVN tasks and how they're now done in Git/TortoiseGit.
There has also been the idea of employing a two-way mirror solution like
SubGit for 6 months to ease the transition. While I'm not fully opposed to
that idea, I fear that some people won't even give up SVN after that time.
But even more important, this would prevent us from making use of features
like Git submodules.


Answering one of your other questions inline.

Am 24.02.2016 um 12:59 schrieb Mike Swanson:
>  * Old versions of RosBE are under /tags. Is RosBE maintained 
> elsewhere?

We used to have everything in the one big "reactos" repository. First, the
website and media split off as the "web" and "press-media" repos, then some
tools followed as the "project-tools" repo. This one is also where RosBE is
now maintained.

When doing a proper transition to Git, all remnants of these repositories
should be removed from the history wherever possible.
Reposurgeon may be helpful here.



Cheers,

Colin



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

Re: [ros-dev] [ros-diffs] [gedmurphy] 70408: [NTOSKRNL] - Raise the IRQL when enumerating device lists so it doesn't get edited mid-listing - Don't hardcode the pointer size when checking the buffer s

[Ged Murphy]

Yeah good point about the SMP variant Thomas, I hadn't taken that into 
consideration.
When I get a free minute, I'll update the code (and various other sections that 
access attached devices) to use the spinlock

-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Hermès BÉLUSCA 
- MAÏTO
Sent: 30 December 2015 10:21
To: 'ReactOS Development List' 
Subject: Re: [ros-dev] [ros-diffs] [gedmurphy] 70408: [NTOSKRNL] - Raise the 
IRQL when enumerating device lists so it doesn't get edited mid-listing - Don't 
hardcode the pointer size when checking the buffer size

Also in NT6+, the kernel seems to always be multiprocessor. And yes, the 
KeAcquire(queued)SpinLock becomes KeRaiseIrql in a SP kernel. Finally, directly 
using the correct function (AcquireSpinLock) would be better to know have to 
hack again the kernel to add support for MP afterwards. Better do it correctly 
now.

-Message d'origine-
De : Hermès BÉLUSCA - MAÏTO [mailto:hermes.belu...@sfr.fr] Envoyé : mercredi 30 
décembre 2015 11:16 À : 'ReactOS Development List'
Objet : RE: [ros-dev] [ros-diffs] [gedmurphy] 70408: [NTOSKRNL] - Raise the 
IRQL when enumerating device lists so it doesn't get edited mid-listing - Don't 
hardcode the pointer size when checking the buffer size

To answer Ged's worry, I don't think here people would get angry, since that 
spinlock is also used there: 
https://git.reactos.org/?p=reactos.git&a=search&h=HEAD&st=grep&s=LockQueueIoDatabaseLock
 (see iomgr/file.c and volume.c) .

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Thomas Faber 
Envoyé : mardi 29 décembre 2015 22:07 À : ReactOS Development List Objet : Re: 
[ros-dev] [ros-diffs] [gedmurphy] 70408: [NTOSKRNL] - Raise the IRQL when 
enumerating device lists so it doesn't get edited mid-listing - Don't hardcode 
the pointer size when checking the buffer size

I think this might be an SP/MP difference?
Would make sense if KeAcquireSpinLock inside an SP kernel becomes KeRaiseIrql. 
But even for a 2003 MP kernel this would serve no purpose.


On 2015-12-29 21:48, Ged Murphy wrote:
> It depends on whether we want to emulate the 2k3 kernel or not.
> 
> I noticed in my 2k3 fltmgr testing that IoEnumerateDeviceObjectList 
> runs at DPC for the entirety of the function. This was changed in the
> NT6 kernel to use a lock, which is indeed the LockQueueIoDatabaseLock Hermes 
> mentioned.
> 
> I'm happy to use the spinlock (and would prefer to myself), but any 
> move towards NT6 normally results in an angry email, so I opted for 
> the 2k3 approach  ;)
> 
> Ged.
> 
> 
> -Original Message-
> From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Hermès 
> BÉLUSCA - MAÏTO
> Sent: 29 December 2015 16:08
> To: 'ReactOS Development List' 
> Subject: Re: [ros-dev] [ros-diffs] [gedmurphy] 70408: [NTOSKRNL] - 
> Raise the IRQL when enumerating device lists so it doesn't get edited 
> mid-listing - Don't hardcode the pointer size when checking the buffer 
> size
> 
> Yes this should be a spinlock involved instead, for example the 
> "LockQueueIoDatabaseLock" (queued) spinlock that we already use in 
> other places in the code.
> 
> -Message d'origine-
> De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Thomas 
> Faber Envoyé : mardi 29 décembre 2015 13:20 À : ros-dev@reactos.org Objet : 
> Re:
> [ros-dev] [ros-diffs] [gedmurphy] 70408: [NTOSKRNL] - Raise the IRQL 
> when enumerating device lists so it doesn't get edited mid-listing - 
> Don't hardcode the pointer size when checking the buffer size
> 
> Uhm... raising the IRQL is not a synchronization mechanism. Should 
> there be a spinlock involved?
> 
> 
> On 2015-12-23 12:26, gedmur...@svn.reactos.org wrote:
>> Author: gedmurphy
>> Date: Wed Dec 23 11:26:28 2015
>> New Revision: 70408
>>
>> URL: http://svn.reactos.org/svn/reactos?rev=70408&view=rev
>> Log:
>> [NTOSKRNL]
>> - Raise the IRQL when enumerating device lists so it doesn't get 
>> edited mid-listing
>> - Don't hardcode the pointer size when checking the buffer size
>>
>> Modified:
>> trunk/reactos/ntoskrnl/io/iomgr/device.c
>>
>> Modified: trunk/reactos/ntoskrnl/io/iomgr/device.c
>> URL: 
>> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/iomgr/de
>> v ice.c?rev=70408&r1=70407&r2=70408&view=diff
>>
> ==
> ==
> ==
>> --- trunk/reactos/ntoskrnl/io/iomgr/device.c [iso-8859-1] (original)
>> +++ trunk/reactos/ntoskrnl/io/iomgr/d

Re: [ros-dev] [ros-diffs] [gedmurphy] 70408: [NTOSKRNL] - Raise the IRQL when enumerating device lists so it doesn't get edited mid-listing - Don't hardcode the pointer size when checking the buffer s

[Ged Murphy]

It depends on whether we want to emulate the 2k3 kernel or not.

I noticed in my 2k3 fltmgr testing that IoEnumerateDeviceObjectList runs at
DPC for the entirety of the function. This was changed in the NT6 kernel to
use a lock, which is indeed the LockQueueIoDatabaseLock Hermes mentioned.

I'm happy to use the spinlock (and would prefer to myself), but any move
towards NT6 normally results in an angry email, so I opted for the 2k3
approach  ;)

Ged.


-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Hermès
BÉLUSCA - MAÏTO
Sent: 29 December 2015 16:08
To: 'ReactOS Development List' 
Subject: Re: [ros-dev] [ros-diffs] [gedmurphy] 70408: [NTOSKRNL] - Raise the
IRQL when enumerating device lists so it doesn't get edited mid-listing -
Don't hardcode the pointer size when checking the buffer size

Yes this should be a spinlock involved instead, for example the
"LockQueueIoDatabaseLock" (queued) spinlock that we already use in other
places in the code.

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Thomas Faber
Envoyé : mardi 29 décembre 2015 13:20 À : ros-dev@reactos.org Objet : Re:
[ros-dev] [ros-diffs] [gedmurphy] 70408: [NTOSKRNL] - Raise the IRQL when
enumerating device lists so it doesn't get edited mid-listing - Don't
hardcode the pointer size when checking the buffer size

Uhm... raising the IRQL is not a synchronization mechanism. Should there be
a spinlock involved?


On 2015-12-23 12:26, gedmur...@svn.reactos.org wrote:
> Author: gedmurphy
> Date: Wed Dec 23 11:26:28 2015
> New Revision: 70408
> 
> URL: http://svn.reactos.org/svn/reactos?rev=70408&view=rev
> Log:
> [NTOSKRNL]
> - Raise the IRQL when enumerating device lists so it doesn't get 
> edited mid-listing
> - Don't hardcode the pointer size when checking the buffer size
> 
> Modified:
> trunk/reactos/ntoskrnl/io/iomgr/device.c
> 
> Modified: trunk/reactos/ntoskrnl/io/iomgr/device.c
> URL: 
> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/iomgr/dev
> ice.c?rev=70408&r1=70407&r2=70408&view=diff
>

==
> --- trunk/reactos/ntoskrnl/io/iomgr/device.c  [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/io/iomgr/device.c  [iso-8859-1] Wed Dec 23
11:26:28 2015
> @@ -1088,6 +1088,10 @@
>  {
>  ULONG ActualDevices = 1;
>  PDEVICE_OBJECT CurrentDevice = DriverObject->DeviceObject;
> +KIRQL OldIrql;
> +
> +/* Raise to dispatch level */
> +KeRaiseIrql(DISPATCH_LEVEL, &OldIrql);
>  
>  /* Find out how many devices we'll enumerate */
>  while ((CurrentDevice = CurrentDevice->NextDevice))
> ActualDevices++; @@ -1099,13 +1103,14 @@
>  *ActualNumberDeviceObjects = ActualDevices;
>  
>  /* Check if we can support so many */
> -if ((ActualDevices * 4) > DeviceObjectListSize)
> +if ((ActualDevices * sizeof(PDEVICE_OBJECT)) >
> + DeviceObjectListSize)
>  {
>  /* Fail because the buffer was too small */
> +KeLowerIrql(OldIrql);
>  return STATUS_BUFFER_TOO_SMALL;
>  }
>  
> -/* Check if the caller only wanted the size */
> +/* Check if the caller wanted the device list */
>  if (DeviceObjectList)
>  {
>  /* Loop through all the devices */ @@ -1123,6 +1128,9 @@
>  DeviceObjectList++;
>  }
>  }
> +
> +/* Return back to previous IRQL */
> +KeLowerIrql(OldIrql);
>  
>  /* Return the status */
>  return STATUS_SUCCESS;
> 
> 


___
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] Status Meeting (November 2015)

[Ged Murphy]

It tells me no one outside of america either knows much or cares much about 
thanks giving :)


-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Zachary Gorden
Sent: 25 November 2015 19:16
To: ReactOS Development List 
Subject: Re: [ros-dev] Status Meeting (November 2015)

And what does that tell you about the team's awareness of a holiday that always 
falls on the last Thursday of November every year?

On Wed, Nov 25, 2015 at 1:07 PM, Hermès BÉLUSCA - MAÏTO  
wrote:
> I remember you gave the same "excuse" last year...
> H.
>
> -Message d'origine-
> De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de 
> Zachary Gorden Envoyé : mercredi 25 novembre 2015 17:28 À : ReactOS 
> Development List Objet : Re: [ros-dev] Status Meeting (November 2015)
>
> Uh, so that's Thanksgiving for Americans.
>
> On Wed, Nov 25, 2015 at 5:25 AM, Aleksey Bragin  wrote:
>> Hello,
>> Let me invite you to the monthly status meeting taking place last 
>> Thursday of a month, 26th of November, 19:00 UTC, as usual.
>>
>> IRC service will only be started shortly before the meeting. Your 
>> participation passwords and server address will be emailed to you 
>> shortly before the meeting starts, and they are going to be different 
>> once again as they are not stored in any database. Hopefully it's not 
>> much of inconvenience.
>>
>> Please send agenda proposals to me before the meeting.
>>
>> Regards,
>> 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

___
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] Patch situation

[Ged Murphy]

I'm glad you put this together, it brings light to a growing problem that we
seem to be receiving more patches but don't have the available man power to
manage them. There needs to be an arrangement put together to better manage
this in the future because it's arguably one of the most important aspects
of generating and maintaining external interest from developers.

With regards to the patches listed, how about looking to (quickly / almost
blindly) merging them after Amine has branched the 0.4 release, with a view
to push them back into the 0.4 branch if they seem stable and pass all the
testing that's hopefully coming?

Ged

-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Robert
Naumann
Sent: 21 November 2015 10:02
To: ros-dev@reactos.org
Subject: [ros-dev] Patch situation


Hey all. I have some thoughts about our current patch situation. After the
last big strike regarding patches, which was around the Hackfest, The count
of them increased amazingly.
We got some new contributers, this year, which do a great work. Some of our
old contributers are still hacking like fire and mostly this are small fixes
with big impact. Easy to review.
I summed up some of them, to show which could get some attention. There are
also bigger patches, which would need a coordinated review, but add very
nice features (Swyters vbox fix for example). I am sure that about 10 of
them could make it.

Patches that are currently under review or active development
=
The following patches are the ones, which actually got some attention. 
They all are slightly bigger ones.

CORE-10533  PATCH: Fix local network resolving
CORE-10440  PATCH: Fix issues of ws2_32_new
CORE-10367  Implement apphelp sdb layer


(More or less) simple patches, that would be nice2have for 0.4
==
These are all the patches from our actual most active contributers. Most of
them are very small and easy to understand.
Let's not forget them because contributers can become developers, which we
need so badly. It would be nice to have them in trunk before release, if
they are correct.

CORE-10550  clipbrd: Load the clipboard contents from a file
CORE-10476  Add a placeholder machine owner at second stage 
installer to improve UX
CORE-10438  [shell32] 'Empty Recycle Bin' should be disabled 
when no items are present
CORE-10437  [console] Add missing DS_MODALFRAME
CORE-10436  [shell32] OK button in run dialog should be disabled 
by default
CORE-10410  [fdebug] Manifest and application title
CORE-10393  [RAPPS] Small Database Update
CORE-10310  Automatically format file size & assorted fixes for apps
CORE-9721   [notepad] Let the user know when an opened file is 
modified
CORE-9959   shell32: patch for SHFileOperation (delete-operation)
CORE-6742   Can't dynamically change the resolution by resizing 
in VirtualBox

Hacks(?) that would improve the look and feel in 0.4

These patches contain hacks but it would be nice to have them in release. I
don't mean to apply them to trunk, but to the 0.4 branch.
Important is that, if this happens, enough regression testing is done.

CORE-9654   PATCH +Bugfix: UXTHEME draw text with shadows, fix 
GetThemeSysColor
CORE-9533   Title icons are 32pixel downsized to 16pixel
CORE-5644   mspaint: selection border isn't visible
CORE-9689   Drive's properties theming problem
CORE-8925   Start menu has classic border when themes are enabled

Drive Type related patches
==
The author of these patches did some effort to fix the bug, which shows the
correct icon for specific drives.
I feel like I saw more than this 2 patches but I am not sure and don't find
more. We should collaborate with him and take care of this annoying bug,

CORE-10221  Fix icons in My Computer
CORE-9622   Improvement to GetDriveType() Function


Victor's Patches

These patches are from Victor M. Calvo. He did a big effort to fix bugs,
which affect specifig apps and caused registry curruption.
He also proved his patches with apitests but almost nothing happened with
the patches.

CORE-9673   PATCH: BS_DIBPATTERN8x8 not supported
CORE-9672   PATCH: Rewrite RegQueryInfoKeyW
CORE-9666   PATCH: RegQueryValueExW fails to set properly the 
REG_NONE type
CORE-9665   PATCH: RegQueryValueExW and RegQueryValueExA calls 
accept bytes not chars.
CORE-9398   PATCH: Several fixes for 
SetupInstallServicesFromInfSectionExW
CORE-8164   Fix a interexchanging values in Vga driver
CORE-8157   Fix a memcpy in Dhcpclient using the length in bytes.
CORE-8156   Fix a sanity check of a returned ConstructBitBlob
CORE-8077   

Re: [ros-dev] Unify system icons into one central folder

[Ged Murphy]

I'm not sure it won't create as many problems as it solves. The bulk of the
icons are already grouped in setupapi and shell32, and with the exception of
cpls, the majority of the OS uses these icons. Unless there's a full icon
replacement, it's not particularly hard to maintain the existing stuff as
there's very little to change. 

 

What else do you propose to move? Control panel applet icons? Win32 dll
icons? Application icons? What about other resources such as animations or
sounds?

What's the naming convention going to be? Currently shell32 uses the
resource ids from 2k3 as their names as it makes them easy to compare
directly. 

 

I'm not saying it's a bad idea, I'm just saying that you can't propose
"let's move all the icons to one folder" without providing a plan

Can you or David (or anyone else) come up with a proposal that works?

 

I'm guessing you're thinking something like the following:

 

Root 

Shell

Icons

Bitmaps

Toolbars


Animations

Media

Sounds

Icons

System

 

Or do you prefer a layout more akin to how Tango does it just purely for
icons:

Root

Action

Animation

Apps

Devices

.

 

 

I'm also guessing you'd want all win32 dlls and cpls try to reference icons
from this folder structure. Anything in base\applications should manage its
own resources.

Anything which doesn't fit (what are the guidelines for "doesn't fit")
should be stored local to the project?

 

Ged.

 

 

From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Jared Smudde
Sent: 24 July 2015 15:22
To: ReactOS Development List 
Subject: Re: [ros-dev] Unify system icons into one central folder

 

Why not we leave the kernel and win32ss icons where they are and move the
rest. win32ss has around 7 icons that need to be changed when going to a
different icon theme. That's much better than having to go into each folder
to check if there's icons in there. Of course the bitmaps will have to stay
in each folder as most of the apps and dlls have unique bitmaps to them.

 

Jared

> Date: Fri, 24 Jul 2015 16:14:24 +0200
> From:  <mailto:gigah...@gmail.com> gigah...@gmail.com
> To:  <mailto:ros-dev@reactos.org> ros-dev@reactos.org
> Subject: Re: [ros-dev] Unify system icons into one central folder
> 
> Yes, it is indeed a ridiculous analogy. I believe there are too many
> advantages to have a unified place to have most of the common icons
> usable by any app that needs them.
> 
> Note that my idea was for common icons, thing such the usual "objects"
> (document icon, folder icon, the configuration cogs, warning triangle,
> ...) and "actions" (document-new, search, navigate-back/dorward,
> zoom-in/out, ...).
> 
> I believe this ADDS to modularization, since it removes duplicate
> copies of icons and unifies them in a more manageable way, while most
> people who work on code are going to download most of ReactOS AND
> RosTests either way, because it's not that useful with just the
> kernel. ;P
> 
> I do admit that it has one bigger side-effect: if someone wants to
> "move out" a single module/app away from the rest of the repository,
> they'd have to select the required icons manually, but this does not
> happen very often and it shouldn't really be bothering us. If a lot of
> people are taking pieces of ReactOS and moving them elsewhere, this is
> a sign of bad things.
> 
> On 24 July 2015 at 10:18, Ged Murphy <
<mailto:gedmurphy.mailli...@gmail.com> gedmurphy.mailli...@gmail.com> wrote:
> > I like the idea in general, but there must be a cleaner and more modular
way
> > of doing it instead of dumping everything in one location.
> >
> >
> >
> > In an area where many devs are pushing to modularize things (think
current
> > win32ss and future minwin), this moves the tree in the opposite
direction.
> > If you were a kernel and win32ss guy, you'd then need to have all the
icons
> > for the whole OS in your WC just to build the area you're interested in.
> >
> >
> >
> > This is a kinda ridiculous analogy, but imagine if you had to checkout
KDE
> > just to build the linux kernel.
> >
> >
> >
> > Ged.
> >
> >
> >
> > From: Ros-dev [ <mailto:ros-dev-boun...@reactos.org>
mailto:ros-dev-boun...@reactos.org] On Behalf Of Jared Smudde
> > Sent: 24 July 2015 02:39
> 

Re: [ros-dev] Unify system icons into one central folder

[Ged Murphy]

I like the idea in general, but there must be a cleaner and more modular way
of doing it instead of dumping everything in one location.

 

In an area where many devs are pushing to modularize things (think current
win32ss and future minwin), this moves the tree in the opposite direction.
If you were a kernel and win32ss guy, you'd then need to have all the icons
for the whole OS in your WC just to build the area you're interested in.

 

This is a kinda ridiculous analogy, but imagine if you had to checkout KDE
just to build the linux kernel.

 

Ged.

 

From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Jared Smudde
Sent: 24 July 2015 02:39
To: ros-dev@reactos.org
Subject: [ros-dev] Unify system icons into one central folder

 

Hello. I am Jared Smudde aka. Pi_User5. I propose that we move most of the
icons in trunk into a central folder in the media folder. Some icons will
need to stay because they might be application specific. The folder can be
called icons and it would be organized according to
http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.ht
ml. This way, we can eliminate duplicate icons thus making trunk slightly
smaller. It will also make changing ReactOS to a different icon theme much
easier. This idea was suggested by gigaherz and I would like to see it done.
Thanks!

 

Jared

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

Re: [ros-dev] [ros-diffs] [dquintana] 67976: [DEVMGMT_NEW] At the request of Christoph von Wittich, bring devmgmt_new into the build. * Created CMakeLists.txt and added to parent folder. * Removed som

[Ged Murphy]

Yeah I do know that, I've tried them a few times but they aren't very good.
It's quicker and easier to create an empty solution and add all the files
than to spend half an hour modifying the cmake vcxproj files so they build
and act the way I expect them to.

-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Hermès
BÉLUSCA - MAÏTO
Sent: 01 June 2015 13:06
To: 'ReactOS Development List'
Subject: Re: [ros-dev] [ros-diffs] [dquintana] 67976: [DEVMGMT_NEW] At the
request of Christoph von Wittich, bring devmgmt_new into the build. *
Created CMakeLists.txt and added to parent folder. * Removed some references
to CAtlStr...

Yo guys !

Ged, you may know also that now we support VS solutions generated with
CMake, so you may also consider adding a:
PROJECT(devmgmt_new)
at the beginning of the corresponding CMakeLists.txt file, and use this ;)

Cheers,
Hermès

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de David
Quintana (gigaherz) Envoyé : dimanche 31 mai 2015 13:28 À : ReactOS
Development List Objet : Re: [ros-dev] [ros-diffs] [dquintana] 67976:
[DEVMGMT_NEW] At the request of Christoph von Wittich, bring devmgmt_new
into the build. * Created CMakeLists.txt and added to parent folder. *
Removed some references to CAtlStr...

Oops, sorry about that. Christoph asked so I didn't think to consider if you
were still working on it.

On 31 May 2015 at 13:16, Ged Murphy  wrote:
> Eeek, I was working on this via VS and have quite a few changes in my 
> WC,
including CAtlString support for our ATL lib...
>
>
> -Original Message-
> From: Ros-diffs [mailto:ros-diffs-boun...@reactos.org] On Behalf Of 
> dquint...@svn.reactos.org
> Sent: 30 May 2015 20:54
> To: ros-di...@reactos.org
> Subject: [ros-diffs] [dquintana] 67976: [DEVMGMT_NEW] At the request 
> of
Christoph von Wittich, bring devmgmt_new into the build. * Created
CMakeLists.txt and added to parent folder. * Removed some references to
CAtlStr...
>
> Author: dquintana
> Date: Sat May 30 19:53:44 2015
> New Revision: 67976
>
> URL: http://svn.reactos.org/svn/reactos?rev=67976&view=rev
> Log:
> [DEVMGMT_NEW]
> At the request of Christoph von Wittich, bring devmgmt_new into the build.
> * Created CMakeLists.txt and added to parent folder.
> * Removed some references to CAtlString that were not needed and are 
> not
implemented in our headers.
> * Fixed build with gcc.
> * Spread all the changes done to the english resources to the other
languages. Many languages now contain untranslated strings that will need to
be fixed.
> Note that I made no effort to fix any bugs or improve any features. 
> The
app comes as-is, except it now builds with rosbe.
>
> Added:
> 
> trunk/reactos/base/applications/mscutils/devmgmt_new/CMakeLists.txt
(with props)
> trunk/reactos/base/applications/mscutils/devmgmt_new/precomp.h
>   - copied, changed from r67940,
trunk/reactos/base/applications/mscutils/devmgmt_new/stdafx.h
> trunk/reactos/base/applications/mscutils/devmgmt_new/resource.h
>   - copied unchanged from r67940, 
> trunk/reactos/base/applications/mscutils/devmgmt_new/Resource.h
> Removed:
> trunk/reactos/base/applications/mscutils/devmgmt_new/Resource.h
>
trunk/reactos/base/applications/mscutils/devmgmt_new/devmgmt.exe.manifest
> trunk/reactos/base/applications/mscutils/devmgmt_new/devmgmt.h
> 
> trunk/reactos/base/applications/mscutils/devmgmt_new/devmgmt_new.sln
>
trunk/reactos/base/applications/mscutils/devmgmt_new/devmgmt_new.vcxproj
>
trunk/reactos/base/applications/mscutils/devmgmt_new/devmgmt_new.vcxproj.fil
ters
> trunk/reactos/base/applications/mscutils/devmgmt_new/rsrc.rc
> trunk/reactos/base/applications/mscutils/devmgmt_new/stdafx.cpp
> trunk/reactos/base/applications/mscutils/devmgmt_new/stdafx.h
> trunk/reactos/base/applications/mscutils/devmgmt_new/targetver.h
> Modified:
> trunk/reactos/base/applications/mscutils/CMakeLists.txt
> trunk/reactos/base/applications/mscutils/devmgmt_new/DeviceView.cpp
> trunk/reactos/base/applications/mscutils/devmgmt_new/DeviceView.h
> trunk/reactos/base/applications/mscutils/devmgmt_new/Devices.cpp
> trunk/reactos/base/applications/mscutils/devmgmt_new/MainWindow.cpp
> trunk/reactos/base/applications/mscutils/devmgmt_new/MainWindow.h
> trunk/reactos/base/applications/mscutils/devmgmt_new/devmgmt.cpp
> trunk/reactos/base/applications/mscutils/devmgmt_new/devmgmt.rc
> trunk/reactos/base/applications/mscutils/devmgmt_new/lang/bg-BG.rc
> trunk/reactos/base/applications/mscutils/devmgmt_new/lang/de-DE.rc
> trunk/reactos/base/applications/mscutils/devmgmt_new/lang/el-GR.rc
> trunk/reactos/base/applications/mscutils/devmgmt_new/lang/en-US

Re: [ros-dev] [ros-diffs] [cwittich] 67981: [DEVMGMT_NEW] enable/disable context menu items on selection change

[Ged Murphy]

I also have all the code for this, but for choosing which icons to show in the 
toolbar. The context menu would have been able to use this code

-Original Message-
From: Ros-diffs [mailto:ros-diffs-boun...@reactos.org] On Behalf Of 
cwitt...@svn.reactos.org
Sent: 31 May 2015 10:15
To: ros-di...@reactos.org
Subject: [ros-diffs] [cwittich] 67981: [DEVMGMT_NEW] enable/disable context 
menu items on selection change

Author: cwittich
Date: Sun May 31 09:14:29 2015
New Revision: 67981

URL: http://svn.reactos.org/svn/reactos?rev=67981&view=rev
Log:
[DEVMGMT_NEW]
enable/disable context menu items on selection change

Modified:
trunk/reactos/base/applications/mscutils/devmgmt_new/DeviceView.cpp
trunk/reactos/base/applications/mscutils/devmgmt_new/DeviceView.h
trunk/reactos/base/applications/mscutils/devmgmt_new/MainWindow.cpp

Modified: trunk/reactos/base/applications/mscutils/devmgmt_new/DeviceView.cpp
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/mscutils/devmgmt_new/DeviceView.cpp?rev=67981&r1=67980&r2=67981&view=diff
==
--- trunk/reactos/base/applications/mscutils/devmgmt_new/DeviceView.cpp 
[iso-8859-1] (original)
+++ trunk/reactos/base/applications/mscutils/devmgmt_new/DeviceView.cpp 
[iso-8859-1] Sun May 31 09:14:29 2015
@@ -110,6 +110,30 @@
 (VOID)m_Devices->Uninitialize();
 
 return TRUE;
+}
+
+BOOL CDeviceView::HasChildItem(
+_In_ HTREEITEM Item)
+{
+return (TreeView_GetChild(m_hTreeView, Item) != NULL); }
+
+BOOL CDeviceView::IsRootItem(
+_In_ HTREEITEM Item)
+{
+return (TreeView_GetRoot(m_hTreeView) == Item); }
+
+BOOL CDeviceView::IsRootItemSelected()
+{
+return (TreeView_GetRoot(m_hTreeView) == 
+TreeView_GetSelection(m_hTreeView));
+}
+
+VOID CDeviceView::EnableContextMenuItem(
+_In_ UINT Id,
+_In_ UINT Enabled)
+{
+EnableMenuItem(m_hShortcutMenu, Id, Enabled);
 }
 
 VOID

Modified: trunk/reactos/base/applications/mscutils/devmgmt_new/DeviceView.h
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/mscutils/devmgmt_new/DeviceView.h?rev=67981&r1=67980&r2=67981&view=diff
==
--- trunk/reactos/base/applications/mscutils/devmgmt_new/DeviceView.h   
[iso-8859-1] (original)
+++ trunk/reactos/base/applications/mscutils/devmgmt_new/DeviceView.h   
[iso-8859-1] Sun May 31 09:14:29 2015
@@ -34,6 +34,11 @@
 BOOL Initialize();
 BOOL Uninitialize();
 
+VOID EnableContextMenuItem(
+_In_ UINT Id,
+_In_ UINT Enabled
+);
+
 VOID ShowContextMenu(
 _In_ INT xPos,
 _In_ INT yPos
@@ -49,12 +54,27 @@
 VOID Refresh();
 VOID DisplayPropertySheet();
 VOID SetFocus();
-
+
+BOOL IsRootItemSelected();
+
+BOOL IsRootItem(
+_In_ HTREEITEM Item
+);
+
+BOOL HasChildItem(
+_In_ HTREEITEM Item
+);
+
 VOID SetDeviceListType(ListDevices List)
 {
 m_ListDevices = List;
 }
 
+ListDevices GetDeviceListType()
+{
+return m_ListDevices;
+}
+
 VOID ShowHiddenDevices(_In_ BOOL ShowHidden)
 {
 m_ShowHidden = ShowHidden;

Modified: trunk/reactos/base/applications/mscutils/devmgmt_new/MainWindow.cpp
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/mscutils/devmgmt_new/MainWindow.cpp?rev=67981&r1=67980&r2=67981&view=diff
==
--- trunk/reactos/base/applications/mscutils/devmgmt_new/MainWindow.cpp 
[iso-8859-1] (original)
+++ trunk/reactos/base/applications/mscutils/devmgmt_new/MainWindow.cpp 
[iso-8859-1] Sun May 31 09:14:29 2015
@@ -429,7 +429,61 @@
 
 break;
 }
-
+
+case TVN_SELCHANGED:
+{
+LPNM_TREEVIEW pnmtv = (LPNM_TREEVIEW)lParam;
+ListDevices ListType = m_DeviceView->GetDeviceListType();
+
+if (ListType == DevicesByType)
+{
+if (!m_DeviceView->HasChildItem(pnmtv->itemNew.hItem))
+{
+SendMessage(m_hToolBar,
+TB_SETSTATE,
+IDC_PROP,
+(LPARAM)MAKELONG(TBSTATE_ENABLED, 0));
+
+EnableMenuItem(GetMenu(m_hMainWnd), IDC_PROP, MF_ENABLED);
+m_DeviceView->EnableContextMenuItem(IDC_PROP, MF_ENABLED);
+}
+else
+{
+SendMessage(m_hToolBar,
+TB_SETSTATE,
+IDC_PROP,
+(LPARAM)MAKELONG(TBSTATE_INDETERMINATE, 
+ 0));
+
+EnableMenuItem(GetMenu(m_hMainWnd), IDC_PROP, MF_GRAYED);
+m_DeviceView->EnableContextMenuItem(IDC_PROP, MF_GR

Re: [ros-dev] [ros-diffs] [dquintana] 67976: [DEVMGMT_NEW] At the request of Christoph von Wittich, bring devmgmt_new into the build. * Created CMakeLists.txt and added to parent folder. * Removed som

[Ged Murphy]

Eeek, I was working on this via VS and have quite a few changes in my WC, 
including CAtlString support for our ATL lib...


-Original Message-
From: Ros-diffs [mailto:ros-diffs-boun...@reactos.org] On Behalf Of 
dquint...@svn.reactos.org
Sent: 30 May 2015 20:54
To: ros-di...@reactos.org
Subject: [ros-diffs] [dquintana] 67976: [DEVMGMT_NEW] At the request of 
Christoph von Wittich, bring devmgmt_new into the build. * Created 
CMakeLists.txt and added to parent folder. * Removed some references to 
CAtlStr...

Author: dquintana
Date: Sat May 30 19:53:44 2015
New Revision: 67976

URL: http://svn.reactos.org/svn/reactos?rev=67976&view=rev
Log:
[DEVMGMT_NEW]
At the request of Christoph von Wittich, bring devmgmt_new into the build.
* Created CMakeLists.txt and added to parent folder.
* Removed some references to CAtlString that were not needed and are not 
implemented in our headers.
* Fixed build with gcc.
* Spread all the changes done to the english resources to the other languages. 
Many languages now contain untranslated strings that will need to be fixed.
Note that I made no effort to fix any bugs or improve any features. The app 
comes as-is, except it now builds with rosbe.

Added:
trunk/reactos/base/applications/mscutils/devmgmt_new/CMakeLists.txt   (with 
props)
trunk/reactos/base/applications/mscutils/devmgmt_new/precomp.h
  - copied, changed from r67940, 
trunk/reactos/base/applications/mscutils/devmgmt_new/stdafx.h
trunk/reactos/base/applications/mscutils/devmgmt_new/resource.h
  - copied unchanged from r67940, 
trunk/reactos/base/applications/mscutils/devmgmt_new/Resource.h
Removed:
trunk/reactos/base/applications/mscutils/devmgmt_new/Resource.h
trunk/reactos/base/applications/mscutils/devmgmt_new/devmgmt.exe.manifest
trunk/reactos/base/applications/mscutils/devmgmt_new/devmgmt.h
trunk/reactos/base/applications/mscutils/devmgmt_new/devmgmt_new.sln
trunk/reactos/base/applications/mscutils/devmgmt_new/devmgmt_new.vcxproj

trunk/reactos/base/applications/mscutils/devmgmt_new/devmgmt_new.vcxproj.filters
trunk/reactos/base/applications/mscutils/devmgmt_new/rsrc.rc
trunk/reactos/base/applications/mscutils/devmgmt_new/stdafx.cpp
trunk/reactos/base/applications/mscutils/devmgmt_new/stdafx.h
trunk/reactos/base/applications/mscutils/devmgmt_new/targetver.h
Modified:
trunk/reactos/base/applications/mscutils/CMakeLists.txt
trunk/reactos/base/applications/mscutils/devmgmt_new/DeviceView.cpp
trunk/reactos/base/applications/mscutils/devmgmt_new/DeviceView.h
trunk/reactos/base/applications/mscutils/devmgmt_new/Devices.cpp
trunk/reactos/base/applications/mscutils/devmgmt_new/MainWindow.cpp
trunk/reactos/base/applications/mscutils/devmgmt_new/MainWindow.h
trunk/reactos/base/applications/mscutils/devmgmt_new/devmgmt.cpp
trunk/reactos/base/applications/mscutils/devmgmt_new/devmgmt.rc
trunk/reactos/base/applications/mscutils/devmgmt_new/lang/bg-BG.rc
trunk/reactos/base/applications/mscutils/devmgmt_new/lang/de-DE.rc
trunk/reactos/base/applications/mscutils/devmgmt_new/lang/el-GR.rc
trunk/reactos/base/applications/mscutils/devmgmt_new/lang/en-US.rc
trunk/reactos/base/applications/mscutils/devmgmt_new/lang/es-ES.rc
trunk/reactos/base/applications/mscutils/devmgmt_new/lang/fr-FR.rc
trunk/reactos/base/applications/mscutils/devmgmt_new/lang/he-IL.rc
trunk/reactos/base/applications/mscutils/devmgmt_new/lang/id-ID.rc
trunk/reactos/base/applications/mscutils/devmgmt_new/lang/it-IT.rc
trunk/reactos/base/applications/mscutils/devmgmt_new/lang/ja-JP.rc
trunk/reactos/base/applications/mscutils/devmgmt_new/lang/ko-KR.rc
trunk/reactos/base/applications/mscutils/devmgmt_new/lang/no-NO.rc
trunk/reactos/base/applications/mscutils/devmgmt_new/lang/pl-PL.rc
trunk/reactos/base/applications/mscutils/devmgmt_new/lang/pt-BR.rc
trunk/reactos/base/applications/mscutils/devmgmt_new/lang/ro-RO.rc
trunk/reactos/base/applications/mscutils/devmgmt_new/lang/ru-RU.rc
trunk/reactos/base/applications/mscutils/devmgmt_new/lang/sk-SK.rc
trunk/reactos/base/applications/mscutils/devmgmt_new/lang/sq-AL.rc
trunk/reactos/base/applications/mscutils/devmgmt_new/lang/sv-SE.rc
trunk/reactos/base/applications/mscutils/devmgmt_new/lang/th-TH.rc
trunk/reactos/base/applications/mscutils/devmgmt_new/lang/tr-TR.rc
trunk/reactos/base/applications/mscutils/devmgmt_new/lang/uk-UA.rc
trunk/reactos/base/applications/mscutils/devmgmt_new/lang/zh-CN.rc

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

Modified: trunk/reactos/base/applications/mscutils/CMakeLists.txt
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/mscutils/CMakeLists.txt?rev=67976&r1=67975&r2=67976&view=diff

Added: trunk/reactos/base/applications/mscutils/devmgmt_new/CMakeLists.txt
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/mscutils/devmgmt

Re: [ros-dev] Fezile motherboard has finally failed

[Ged Murphy]

Great, thanks Pierre :)

-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Pierre
Schweitzer
Sent: 11 May 2015 07:31
To: ros-dev@reactos.org
Subject: Re: [ros-dev] Fezile motherboard has finally failed

It was from beginish of December 2014.

Proper update is ongoing at the moment.

On 11/05/2015 08:25, Ged Murphy wrote:
> Hi Colin,
> 
> Doxygen doesn't appear to be the latest code. Did you do a rebuild?
> The date of the last build is also missing so I can't tell when it's 
> from, although I believe it was from as far back as 2012 previously.
> 
> Ged.
> 
> 
> -Original Message-
> From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Colin 
> Finck
> Sent: 10 May 2015 19:14
> To: ros-dev@reactos.org
> Subject: Re: [ros-dev] Fezile motherboard has finally failed
> 
> Well, this definitely took longer than any of us expected..
> Nevertheless, the Fezile server is back now! Enjoy an updated Doxygen 
> as well as the Buildslaves and cppcheck.
> 
> Cheers,
> 
> Colin
> 
> 
> Am 11.12.2014 um 17:07 schrieb Colin Finck:
>> Hi all,
>>
>> Today, the motherboard in our Fezile server has finally failed after 
>> many hick-ups over the year. This causes an outage for the following
>> services:
>>
>> * doxygen.reactos.org
>> * cppcheck.reactos.org
>> * VMware Player Test slave
>> * VMware Player Patchbot
>>
>> As this is not the first time we struggle with such problems, 
>> iso.reactos.org is routed to a different server right now and not
> affected.
>>
>> We have already ordered replacement hardware for this system and hope 
>> to be able to get it back to a working state soon. Even if this 
>> machine is from 2007, we have decided to revive it with replacement 
>> parts instead of going for a brand-new one as this is much cheaper 
>> and quicker to realize. Also there is a huge pile of replacement 
>> hardware
> available.
>>
>> Sorry for the inconveniences!
>>
>> Cheers,
>>
>> 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
> 


--
Pierre Schweitzer  System & Network Administrator
Senior Kernel Developer ReactOS Deutschland e.V.



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

Re: [ros-dev] Fezile motherboard has finally failed

[Ged Murphy]

Hi Colin,

Doxygen doesn't appear to be the latest code. Did you do a rebuild?
The date of the last build is also missing so I can't tell when it's from,
although I believe it was from as far back as 2012 previously.

Ged.


-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Colin Finck
Sent: 10 May 2015 19:14
To: ros-dev@reactos.org
Subject: Re: [ros-dev] Fezile motherboard has finally failed

Well, this definitely took longer than any of us expected..
Nevertheless, the Fezile server is back now! Enjoy an updated Doxygen as
well as the Buildslaves and cppcheck.

Cheers,

Colin


Am 11.12.2014 um 17:07 schrieb Colin Finck:
> Hi all,
> 
> Today, the motherboard in our Fezile server has finally failed after 
> many hick-ups over the year. This causes an outage for the following
> services:
> 
> * doxygen.reactos.org
> * cppcheck.reactos.org
> * VMware Player Test slave
> * VMware Player Patchbot
> 
> As this is not the first time we struggle with such problems, 
> iso.reactos.org is routed to a different server right now and not
affected.
> 
> We have already ordered replacement hardware for this system and hope 
> to be able to get it back to a working state soon. Even if this 
> machine is from 2007, we have decided to revive it with replacement 
> parts instead of going for a brand-new one as this is much cheaper and 
> quicker to realize. Also there is a huge pile of replacement hardware
available.
> 
> Sorry for the inconveniences!
> 
> Cheers,
> 
> 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] [ros-diffs] [gedmurphy] 67563: [DDK] Fix the FS filter callback definitions

[Ged Murphy]

I'm not suggesting to remove the NTAPI from the headers, I'm just suggesting
switching /Gz on for our MS toolset.
Code that builds using the MS toolset and MS WDK doesn't build using the MS
toolset and the ReactOS DDK.


-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Hermès
BÉLUSCA - MAÏTO
Sent: 06 May 2015 13:35
To: 'ReactOS Development List'
Subject: Re: [ros-dev] [ros-diffs] [gedmurphy] 67563: [DDK] Fix the FS
filter callback definitions

And also, for correctness/exactness/documentation purposes/any other
reason... we should keep explicit the calling conventions, so that people
who have other compilers which cannot enforce on a module basis STDCALL, or
people who want to play with msvc by changing the default calling
convention, do not become screwed.
The easy way "solution" à la MS is NOT *the* solution (it looks more like a
hack as in: "heck we don't want to modify all of our headers to add the
needed STDCALL/NTAPI/WINAPI stuff so keep them as they are but then ask the
compiler to always use STDCALL").

H.

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Timo Kreuzer
Envoyé : mercredi 6 mai 2015 00:12 À : ReactOS Development List Objet : Re:
[ros-dev] [ros-diffs] [gedmurphy] 67563: [DDK] Fix the FS filter callback
definitions


GCC doesn't support that.


Am 05.05.2015 um 23:11 schrieb Ged Murphy:
> Ahh interesting.
> So why don't we force /Gz  in our build env?
>
> -Original Message-
> From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Timo 
> Kreuzer
> Sent: 05 May 2015 22:01
> To: ReactOS Development List
> Subject: Re: [ros-dev] [ros-diffs] [gedmurphy] 67563: [DDK] Fix the FS 
> filter callback definitions
>
> Am 05.05.2015 um 22:35 schrieb Ged Murphy:
>>I don't get is that if I were to write code which uses this API, I 
>> would write my callbacks without NTAPI  as per the headers. I'm 
>> guessing most other devs would too. So how are people building with 
>> cdecl and being called by Windows with stdcall  without stack issues?
> As I said: the compiler (you are supposed to use Visual Studio with a 
> driver project and nothing else, and that will have the option 
> "Calling
Convention"
> set to "__stdcall (/Gz)") will use stdcall by default. So unless you 
> see __cdecl, the function or function pointer is stdcall.
> Have  a look at WDK sample sources. Almost completely lacking NTAPI.
> If you mess with VS settings or use a different compiler ... well, you 
> are screwed.
>
> 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] [gedmurphy] 67563: [DDK] Fix the FS filter callback definitions

[Ged Murphy]

Ahh interesting.
So why don't we force /Gz  in our build env?

-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Timo Kreuzer
Sent: 05 May 2015 22:01
To: ReactOS Development List
Subject: Re: [ros-dev] [ros-diffs] [gedmurphy] 67563: [DDK] Fix the FS
filter callback definitions

Am 05.05.2015 um 22:35 schrieb Ged Murphy:
>   I don't get is that if I were to write code which uses this API, I 
> would write my callbacks without NTAPI  as per the headers. I'm 
> guessing most other devs would too. So how are people building with 
> cdecl and being called by Windows with stdcall  without stack issues?
As I said: the compiler (you are supposed to use Visual Studio with a driver
project and nothing else, and that will have the option "Calling Convention"
set to "__stdcall (/Gz)") will use stdcall by default. So unless you see
__cdecl, the function or function pointer is stdcall. 
Have  a look at WDK sample sources. Almost completely lacking NTAPI.
If you mess with VS settings or use a different compiler ... well, you are
screwed.

Timo




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

Re: [ros-dev] [ros-diffs] [gedmurphy] 67563: [DDK] Fix the FS filter callback definitions

[Ged Murphy]

Wait, I misread your previous post. The compiler uses cdecl by default, so
unless you specify NTAPI then you get cdecl

-Original Message-
From: Ged Murphy [mailto:gedmurphy.mailli...@gmail.com] 
Sent: 05 May 2015 21:35
To: 'ReactOS Development List'
Subject: RE: [ros-dev] [ros-diffs] [gedmurphy] 67563: [DDK] Fix the FS
filter callback definitions

Yeah I get that, and I realise the change is wrong. (I blindly followed the
headers). I just wanna understand it before I revert.

What I don't get is that if I were to write code which uses this API, I
would write my callbacks without NTAPI  as per the headers. I'm guessing
most other devs would too. So how are people building with cdecl and being
called by Windows with stdcall  without stack issues?

In fact, explicitly going against the DDK and adding NTAPI to your callbacks
would generate a compiler warning. 

Ged.

-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Timo Kreuzer
Sent: 05 May 2015 21:25
To: ReactOS Development List
Subject: Re: [ros-dev] [ros-diffs] [gedmurphy] 67563: [DDK] Fix the FS
filter callback definitions


MS DDK often misses NTAPI, since the compiler uses it by default.
So unless there is a __cdecl in the DDK definition, your change is most
likely wrong.

PS: I guess it's time to finally autogenerate headers at build time, so that
nobody even gets tempted to hack ntifs/ntddk/wdm/winnt directly instead of
adding stuff to XDK... :)

Timo


Am 05.05.2015 um 21:41 schrieb Ged Murphy:
> Well this is a weird one, the DDK says these callbacks are cdecl 
> (missing
NTAPI) and anyone building against the DDK will obviously declare their
callbacks to match this convention.  However internally, windows uses
stdcall for these callbacks.
>
> I can't find much by way of problems people have encountered with 
> this, so
why aren't people seeing problems with the way the stack is cleaned up?
Anyone have any ideas before I blindly revert this change?
>
> Ged.
>
>
> -Original Message-
> From: Ros-diffs [mailto:ros-diffs-boun...@reactos.org] On Behalf Of 
> gedmur...@svn.reactos.org
> Sent: 05 May 2015 19:54
> To: ros-di...@reactos.org
> Subject: [ros-diffs] [gedmurphy] 67563: [DDK] Fix the FS filter 
> callback definitions
>
> Author: gedmurphy
> Date: Tue May  5 18:54:28 2015
> New Revision: 67563
>
> URL: http://svn.reactos.org/svn/reactos?rev=67563&view=rev
> Log:
> [DDK]
> Fix the FS filter callback definitions
>
> Modified:
>  trunk/reactos/include/ddk/ntifs.h
>
> Modified: trunk/reactos/include/ddk/ntifs.h
> URL: 
> http://svn.reactos.org/svn/reactos/trunk/reactos/include/ddk/ntifs.h?r
> ev=67563&r1=67562&r2=67563&view=diff
>

==
> --- trunk/reactos/include/ddk/ntifs.h [iso-8859-1] (original)
> +++ trunk/reactos/include/ddk/ntifs.h [iso-8859-1] Tue May  5 18:54:28
2015
> @@ -4890,12 +4890,12 @@
>   } FS_FILTER_CALLBACK_DATA, *PFS_FILTER_CALLBACK_DATA;
>   
>   typedef NTSTATUS
> -(NTAPI *PFS_FILTER_CALLBACK) (
> +(*PFS_FILTER_CALLBACK) (
> _In_ PFS_FILTER_CALLBACK_DATA Data,
> _Out_ PVOID *CompletionContext);
>   
>   typedef VOID
> -(NTAPI *PFS_FILTER_COMPLETION_CALLBACK) (
> +(*PFS_FILTER_COMPLETION_CALLBACK) (
> _In_ PFS_FILTER_CALLBACK_DATA Data,
> _In_ NTSTATUS OperationStatus,
> _In_ PVOID CompletionContext);
>
>
>
>
> ___
> 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] [gedmurphy] 67563: [DDK] Fix the FS filter callback definitions

[Ged Murphy]

Yeah I get that, and I realise the change is wrong. (I blindly followed the
headers). I just wanna understand it before I revert.

What I don't get is that if I were to write code which uses this API, I
would write my callbacks without NTAPI  as per the headers. I'm guessing
most other devs would too. So how are people building with cdecl and being
called by Windows with stdcall  without stack issues?

In fact, explicitly going against the DDK and adding NTAPI to your callbacks
would generate a compiler warning. 

Ged.

-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Timo Kreuzer
Sent: 05 May 2015 21:25
To: ReactOS Development List
Subject: Re: [ros-dev] [ros-diffs] [gedmurphy] 67563: [DDK] Fix the FS
filter callback definitions


MS DDK often misses NTAPI, since the compiler uses it by default.
So unless there is a __cdecl in the DDK definition, your change is most
likely wrong.

PS: I guess it's time to finally autogenerate headers at build time, so that
nobody even gets tempted to hack ntifs/ntddk/wdm/winnt directly instead of
adding stuff to XDK... :)

Timo


Am 05.05.2015 um 21:41 schrieb Ged Murphy:
> Well this is a weird one, the DDK says these callbacks are cdecl (missing
NTAPI) and anyone building against the DDK will obviously declare their
callbacks to match this convention.  However internally, windows uses
stdcall for these callbacks.
>
> I can't find much by way of problems people have encountered with this, so
why aren't people seeing problems with the way the stack is cleaned up?
Anyone have any ideas before I blindly revert this change?
>
> Ged.
>
>
> -Original Message-
> From: Ros-diffs [mailto:ros-diffs-boun...@reactos.org] On Behalf Of 
> gedmur...@svn.reactos.org
> Sent: 05 May 2015 19:54
> To: ros-di...@reactos.org
> Subject: [ros-diffs] [gedmurphy] 67563: [DDK] Fix the FS filter 
> callback definitions
>
> Author: gedmurphy
> Date: Tue May  5 18:54:28 2015
> New Revision: 67563
>
> URL: http://svn.reactos.org/svn/reactos?rev=67563&view=rev
> Log:
> [DDK]
> Fix the FS filter callback definitions
>
> Modified:
>  trunk/reactos/include/ddk/ntifs.h
>
> Modified: trunk/reactos/include/ddk/ntifs.h
> URL: 
> http://svn.reactos.org/svn/reactos/trunk/reactos/include/ddk/ntifs.h?r
> ev=67563&r1=67562&r2=67563&view=diff
>

==
> --- trunk/reactos/include/ddk/ntifs.h [iso-8859-1] (original)
> +++ trunk/reactos/include/ddk/ntifs.h [iso-8859-1] Tue May  5 18:54:28
2015
> @@ -4890,12 +4890,12 @@
>   } FS_FILTER_CALLBACK_DATA, *PFS_FILTER_CALLBACK_DATA;
>   
>   typedef NTSTATUS
> -(NTAPI *PFS_FILTER_CALLBACK) (
> +(*PFS_FILTER_CALLBACK) (
> _In_ PFS_FILTER_CALLBACK_DATA Data,
> _Out_ PVOID *CompletionContext);
>   
>   typedef VOID
> -(NTAPI *PFS_FILTER_COMPLETION_CALLBACK) (
> +(*PFS_FILTER_COMPLETION_CALLBACK) (
> _In_ PFS_FILTER_CALLBACK_DATA Data,
> _In_ NTSTATUS OperationStatus,
> _In_ PVOID CompletionContext);
>
>
>
>
> ___
> 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] [gedmurphy] 67563: [DDK] Fix the FS filter callback definitions

[Ged Murphy]

Well this is a weird one, the DDK says these callbacks are cdecl (missing 
NTAPI) and anyone building against the DDK will obviously declare their 
callbacks to match this convention.  However internally, windows uses stdcall 
for these callbacks.

I can't find much by way of problems people have encountered with this, so why 
aren't people seeing problems with the way the stack is cleaned up? Anyone have 
any ideas before I blindly revert this change?

Ged.


-Original Message-
From: Ros-diffs [mailto:ros-diffs-boun...@reactos.org] On Behalf Of 
gedmur...@svn.reactos.org
Sent: 05 May 2015 19:54
To: ros-di...@reactos.org
Subject: [ros-diffs] [gedmurphy] 67563: [DDK] Fix the FS filter callback 
definitions

Author: gedmurphy
Date: Tue May  5 18:54:28 2015
New Revision: 67563

URL: http://svn.reactos.org/svn/reactos?rev=67563&view=rev
Log:
[DDK]
Fix the FS filter callback definitions

Modified:
trunk/reactos/include/ddk/ntifs.h

Modified: trunk/reactos/include/ddk/ntifs.h
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/include/ddk/ntifs.h?rev=67563&r1=67562&r2=67563&view=diff
==
--- trunk/reactos/include/ddk/ntifs.h   [iso-8859-1] (original)
+++ trunk/reactos/include/ddk/ntifs.h   [iso-8859-1] Tue May  5 18:54:28 2015
@@ -4890,12 +4890,12 @@
 } FS_FILTER_CALLBACK_DATA, *PFS_FILTER_CALLBACK_DATA;
 
 typedef NTSTATUS
-(NTAPI *PFS_FILTER_CALLBACK) (
+(*PFS_FILTER_CALLBACK) (
   _In_ PFS_FILTER_CALLBACK_DATA Data,
   _Out_ PVOID *CompletionContext);
 
 typedef VOID
-(NTAPI *PFS_FILTER_COMPLETION_CALLBACK) (
+(*PFS_FILTER_COMPLETION_CALLBACK) (
   _In_ PFS_FILTER_CALLBACK_DATA Data,
   _In_ NTSTATUS OperationStatus,
   _In_ PVOID CompletionContext);




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

Re: [ros-dev] [ros-diffs] [tkreuzer] 66893: [WIN32K] Rewrite brush code in C++

[Ged Murphy]

Timo and C++??
Hell must be a bit chilly today :)

-Original Message-
From: Ros-diffs [mailto:ros-diffs-boun...@reactos.org] On Behalf Of 
tkreu...@svn.reactos.org
Sent: 25 March 2015 22:38
To: ros-di...@reactos.org
Subject: [ros-diffs] [tkreuzer] 66893: [WIN32K] Rewrite brush code in C++

Author: tkreuzer
Date: Wed Mar 25 22:38:20 2015
New Revision: 66893

URL: http://svn.reactos.org/svn/reactos?rev=66893&view=rev
Log:
[WIN32K]
Rewrite brush code in C++



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

Re: [ros-dev] ReactOS versioning

[Ged Murphy]

It might also be useful to employ some form of heuristics as UAC does. Things 
like file name detection, string table detection, marked processes via user 
defined requests or a hash database, etc. Perhaps even scanning the imports 
(although this is harder to manage due to people using GetProcAddress to detect 
OS version)


-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Timo Kreuzer
Sent: 07 March 2015 12:44
To: ReactOS Development List
Subject: [ros-dev] ReactOS versioning


1. We need a method to specify which application should be run in which 
environment. We should probably use the same mechanism that is used on Windows. 
Compatibility information is stored in a registry key 
HKCU\Software\Microsodt\Windows NT\CurrentVersion\AppCompatFlags\... The trick 
is to make this easy / transparent for the user. A right-click -> properties -> 
compatibility approach should for now probably be the easiest thing, 



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

Re: [ros-dev] GSoC :: application rejected

[Ged Murphy]

I would imagine the reason has something to do with a conflict of interest


-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Hermès BÉLUSCA 
- MAÏTO
Sent: 03 March 2015 13:08
To: 'ReactOS Development List'
Subject: Re: [ros-dev] GSoC :: application rejected

We've been yet again rejected for the same "reasons" as before (i.e. no 
apparent reasons)?

Cheers,
Hermès.

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Pierre 
Schweitzer Envoyé : lundi 2 mars 2015 22:23 À : ReactOS Development List Objet 
: [ros-dev] GSoC :: application rejected

Dear all,

The ReactOS Foundation application to GSoC has been rejected this year again. 
Statistics are not reliable after all.

In any case, keep up the good work. We don't need Google to be the bests at 
what we do.

Cheers,
--
Pierre Schweitzer  System & Network Administrator Senior 
Kernel Developer ReactOS Deutschland e.V.


___
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] 66144: [FREELDR] - Fix date format in CHANGELOG (that uses that #$@! of US format) - Diverse code style changes (whitespace, extra braces, C++ to C-style comments,

[Ged Murphy]

1st May hasn't happened yet...

-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Aleksey
Bragin
Sent: 03 February 2015 15:09
To: ros-dev@reactos.org
Subject: Re: [ros-dev] [ros-diffs] [hbelusca] 66144: [FREELDR] - Fix date
format in CHANGELOG (that uses that #$@! of US format) - Diverse code style
changes (whitespace, extra braces, C++ to C-style comments, ...)

On 01.02.2015 23:22, hbelu...@svn.reactos.org wrote:
> Author: hbelusca
> Date: Sun Feb  1 20:22:13 2015
> New Revision: 66144
>
> URL: http://svn.reactos.org/svn/reactos?rev=66144&view=rev
> Log:
> [FREELDR]
> - Fix date format in CHANGELOG (that uses that #$@! of US format)
> - Diverse code style changes (whitespace, extra braces, C++ to C-style 
> comments, ...)

==
> --- trunk/reactos/boot/freeldr/freeldr/CHANGELOG  [iso-8859-1]
(original)
> +++ trunk/reactos/boot/freeldr/freeldr/CHANGELOG  [iso-8859-1] Sun Feb
1 20:22:13 2015
> @@ -1,4 +1,4 @@
> -Changes in v3.0+ (05/01/2015) (hbelusca)
> +Changes in v3.0+ (01/05/2015) (hbelusca)
Don't make our dear American contributors feel offended! :-) Also there is
ISO 8601 standard, you know, the big-endian style -MM-DD.


Regards,
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] [ros-diffs] [pschweitzer] 65352: [NTOSKRNL] So... Because actual ReactOS mood is to worship hacks instead of looking for proper fixes to have decent behavior: reenable the IopParseDevice

[Ged Murphy]

Barney?

On 10/11/2014 18:57, "Pierre Schweitzer"  wrote:

>Let me make a simple arrogant comment:
>
>Challenge accepted :P
>
>Best regards,
>Pierre Schweitzer
>
>On 10/11/2014 19:02, Alex Ionescu wrote:
>> Let me make a simple arrogant comment:
>> 
>> Don't try to fix hacks that I spent years trying to fix (and failed).
>>They
>> just can't be fixed :P
>> 
>> Best regards,
>> Alex Ionescu
>> 
>> On Mon, Nov 10, 2014 at 1:45 AM,  wrote:
>> 
>>> Author: pschweitzer
>>> Date: Mon Nov 10 09:45:43 2014
>>> New Revision: 65352
>>>
>>> URL: http://svn.reactos.org/svn/reactos?rev=65352&view=rev
>>> Log:
>>> [NTOSKRNL]
>>> So... Because actual ReactOS mood is to worship hacks instead of
>>>looking
>>> for proper fixes to have decent behavior: reenable the IopParseDevice
>>>hack.
>>>
>>> But, so far, only reenable it for the 1st stage: the most intensive
>>> storage stack stage (unless you start playing with partitions &
>>>formating
>>> in 3rd stage).
>>>
>>> CORE-8732 #resolve #comment Bug is now properly hidden with r65352
>>>
>>> Modified:
>>> trunk/reactos/ntoskrnl/io/iomgr/file.c
>>>
>>> Modified: trunk/reactos/ntoskrnl/io/iomgr/file.c
>>> URL:
>>> 
>>>http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/iomgr/file.
>>>c?rev=65352&r1=65351&r2=65352&view=diff
>>>
>>> 
>>>
>>>==
>>> --- trunk/reactos/ntoskrnl/io/iomgr/file.c  [iso-8859-1] (original)
>>> +++ trunk/reactos/ntoskrnl/io/iomgr/file.c  [iso-8859-1] Mon Nov 10
>>> 09:45:43 2014
>>> @@ -404,6 +404,27 @@
>>>  /* Check if we can simply use a dummy file */
>>>  UseDummyFile = ((OpenPacket->QueryOnly) ||
>>>(OpenPacket->DeleteOnly));
>>>
>>> +/* FIXME: Small hack still exists, have to check why...
>>> + * This is triggered multiple times by usetup and then once per
>>>boot.
>>> + */
>>> +if (ExpInTextModeSetup &&
>>> +!(DirectOpen) &&
>>> +!(RemainingName->Length) &&
>>> +!(OpenPacket->RelatedFileObject) &&
>>> +((wcsstr(CompleteName->Buffer, L"Harddisk")) ||
>>> +(wcsstr(CompleteName->Buffer, L"Floppy"))) &&
>>> +!(UseDummyFile))
>>> +{
>>> +DPRINT1("Using IopParseDevice() hack. Requested invalid
>>> attributes: %lx\n",
>>> +DesiredAccess & ~(SYNCHRONIZE |
>>> +  FILE_READ_ATTRIBUTES |
>>> +  READ_CONTROL |
>>> +  ACCESS_SYSTEM_SECURITY |
>>> +  WRITE_OWNER |
>>> +  WRITE_DAC));
>>> +DirectOpen = TRUE;
>>> +}
>>> +
>>>  /* Check if this is a direct open */
>>>  if (!(RemainingName->Length) &&
>>>  !(OpenPacket->RelatedFileObject) &&
>>>
>>>
>>>
>> 
>> 
>> 
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>> 
>
>
>-- 
>Pierre Schweitzer 
>System & Network Administrator
>Senior Kernel Developer
>ReactOS Deutschland e.V.
>
>___
>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] 64994: [ADVAPI32] * Update ImpersonateNamedPipeClient(). CORE-8540

[Ged Murphy]

Eeww, these are a bit ugly :(


On 25/10/2014 19:30, "akha...@svn.reactos.org" 
wrote:

>Author: akhaldi
>Date: Sat Oct 25 18:30:05 2014
>New Revision: 64994
>
>URL: http://svn.reactos.org/svn/reactos?rev=64994&view=rev
>Log:
>[ADVAPI32]
>* Update ImpersonateNamedPipeClient().
>CORE-8540
>
>Modified:
>trunk/reactos/dll/win32/advapi32/wine/security.c
>
>Modified: trunk/reactos/dll/win32/advapi32/wine/security.c
>URL: 
>http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/advapi32/wine/s
>ecurity.c?rev=64994&r1=64993&r2=64994&view=diff
>==
>
>--- trunk/reactos/dll/win32/advapi32/wine/security.c   [iso-8859-1]
>(original)
>+++ trunk/reactos/dll/win32/advapi32/wine/security.c   [iso-8859-1] Sat Oct
>25 18:30:05 2014
>@@ -954,37 +954,14 @@
> return TRUE;
> }
> 
>-/**
>- * ImpersonateNamedPipeClient EXPORTED
>- *
>- * @implemented
>- */
>-BOOL
>-WINAPI
>-ImpersonateNamedPipeClient(HANDLE hNamedPipe)
>-{
>-IO_STATUS_BLOCK StatusBlock;
>-NTSTATUS Status;
>-
>-TRACE("ImpersonateNamedPipeClient() called\n");
>-
>-Status = NtFsControlFile(hNamedPipe,
>- NULL,
>- NULL,
>- NULL,
>- &StatusBlock,
>- FSCTL_PIPE_IMPERSONATE,
>- NULL,
>- 0,
>- NULL,
>- 0);
>-if (!NT_SUCCESS(Status))
>-{
>-SetLastError(RtlNtStatusToDosError(Status));
>-return FALSE;
>-}
>-
>-return TRUE;
>+BOOL WINAPI ImpersonateNamedPipeClient( HANDLE hNamedPipe )
>+{
>+IO_STATUS_BLOCK io_block;
>+
>+TRACE("(%p)\n", hNamedPipe);
>+
>+return set_ntstatus( NtFsControlFile(hNamedPipe, NULL, NULL, NULL,
>+ &io_block, FSCTL_PIPE_IMPERSONATE, NULL, 0,
>NULL, 0) );
> }
> 
> /*
>
>



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

Re: [ros-dev] [ros-diffs] [tfaber] 64749: [PSDK] - Use macro version of RtlUlonglongByteSwap in winternl.h because using the fastcall version causes stack corruption CORE-8632 #resolve

[Ged Murphy]

There shouldn't really be anything using this header

-Original Message-
From: Ros-diffs [mailto:ros-diffs-boun...@reactos.org] On Behalf Of 
tfa...@svn.reactos.org
Sent: 15 October 2014 17:38
To: ros-di...@reactos.org
Subject: [ros-diffs] [tfaber] 64749: [PSDK] - Use macro version of 
RtlUlonglongByteSwap in winternl.h because using the fastcall version causes 
stack corruption CORE-8632 #resolve

Author: tfaber
Date: Wed Oct 15 16:38:13 2014
New Revision: 64749

URL: http://svn.reactos.org/svn/reactos?rev=64749&view=rev
Log:
[PSDK]
- Use macro version of RtlUlonglongByteSwap in winternl.h because using the 
fastcall version causes stack corruption
CORE-8632 #resolve

Modified:
trunk/reactos/include/psdk/winternl.h

Modified: trunk/reactos/include/psdk/winternl.h
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/include/psdk/winternl.h?rev=64749&r1=64748&r2=64749&view=diff
==
--- trunk/reactos/include/psdk/winternl.h   [iso-8859-1] (original)
+++ trunk/reactos/include/psdk/winternl.h   [iso-8859-1] Wed Oct 15 
16:38:13 2014
@@ -2310,7 +2310,12 @@
 BOOLEAN   WINAPI RtlTimeToSecondsSince1980(const LARGE_INTEGER *,LPDWORD);
 BOOL  WINAPI RtlTryEnterCriticalSection(RTL_CRITICAL_SECTION *);
 
+#ifdef __REACTOS__
 ULONGLONG __fastcall RtlUlonglongByteSwap(ULONGLONG);
+#define RtlUlonglongByteSwap(_x) _byteswap_uint64((_x)) #else ULONGLONG 
+__cdecl RtlUlonglongByteSwap(ULONGLONG); #endif
 DWORD WINAPI RtlUnicodeStringToAnsiSize(const UNICODE_STRING*);
 NTSTATUS  WINAPI 
RtlUnicodeStringToAnsiString(PANSI_STRING,PCUNICODE_STRING,BOOLEAN);
 NTSTATUS  WINAPI RtlUnicodeStringToInteger(const UNICODE_STRING *,ULONG,ULONG 
*);




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

[ros-dev] CRT changes

[Ged Murphy]

Some interesting changes are coming to the CRT which the VS builds will need
to prepare for. The obvious one is the %s/%S  format changes

 

http://blogs.msdn.com/b/vcblog/archive/2014/06/18/crt-features-fixes-and-bre
aking-changes-in-visual-studio-14-ctp1.aspx

 

Ged.

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

Re: [ros-dev] [ros-diffs] [hbelusca] 63599: [TASKMGR]: Use the EndTask API to kill tasks.

[Ged Murphy]

They produce the same asm.

 

From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of David Quintana 
(gigaherz)
Sent: 16 June 2014 11:10
To: ReactOS Development List
Subject: Re: [ros-dev] [ros-diffs] [hbelusca] 63599: [TASKMGR]: Use the EndTask 
API to kill tasks.

 

It's equivalent to writing " != 0", although less readable. I have 
no idea if compilers actually generate better code for it, or people just do it 
because it's shorter to type.

 

On 16 June 2014 11:09, Ged Murphy mailto:gedmurphy.mailli...@gmail.com> > wrote:

Yes, the double negate is a little trick to give you either a 1 or a 0 instead 
of the value of the operation.



-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org 
<mailto:ros-dev-boun...@reactos.org> ] On Behalf Of Pierre Schweitzer
Sent: 16 June 2014 07:31
To: ros-dev@reactos.org <mailto:ros-dev@reactos.org> 
Subject: Re: [ros-dev] [ros-diffs] [hbelusca] 63599: [TASKMGR]: Use the EndTask 
API to kill tasks.

On 15/06/2014 19:47, hbelu...@svn.reactos.org <mailto:hbelu...@svn.reactos.org> 
 wrote:
> +/* Trick: on Windows, pressing the CTRL key forces the task to be ended 
> */
> +BOOL ForceEndTask = !!(GetKeyState(VK_CONTROL) & 0x8000);
> +

Was it really meant to be '!!'?

--
Pierre Schweitzerhttp://reactos.org> > System 
Administrator ReactOS Foundation





___
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

Re: [ros-dev] [ros-diffs] [hbelusca] 63599: [TASKMGR]: Use the EndTask API to kill tasks.

[Ged Murphy]

Yes, the double negate is a little trick to give you either a 1 or a 0 instead 
of the value of the operation.


-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Pierre 
Schweitzer
Sent: 16 June 2014 07:31
To: ros-dev@reactos.org
Subject: Re: [ros-dev] [ros-diffs] [hbelusca] 63599: [TASKMGR]: Use the EndTask 
API to kill tasks.

On 15/06/2014 19:47, hbelu...@svn.reactos.org wrote:
> +/* Trick: on Windows, pressing the CTRL key forces the task to be ended 
> */
> +BOOL ForceEndTask = !!(GetKeyState(VK_CONTROL) & 0x8000);
> +

Was it really meant to be '!!'?

--
Pierre Schweitzer System Administrator ReactOS Foundation




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

Re: [ros-dev] About hotpatchable dlls on ReactOS

[Ged Murphy]

Ahh, the detours trampoline. Hand over £10k to Microsoft and you can have
their source ;)

 

 

From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On
Behalf Of Hermès BÉLUSCA - MAÏTO
Sent: 28 February 2014 14:29
To: 'ReactOS Development List'
Subject: Re: [ros-dev] About hotpatchable dlls on ReactOS

 

Not exactly. I’m referring to the fact that, starting with Windows XP sp1
(or 2), and in windows 2k3, usual dlls like kernel32, user32 and others (and
maybe some exes) have, in the prologue of their exported APIs, two bytes
that allows for detouring the API (that allows for in-memory hotpatch).
Maybe that it’s used when patching a core dll, when you cannot modify its
file directly without any reboot (otherwise you would need to reboot for the
effects to take change). Here it also appears that some games and some
applications try to patch in-memory some of those Apis, and if they cannot,
they fail.

 

Searching on wine commits / mailing lists for “hotpatch” and
“DECLSPEC_HOTPATCH” (altough that it’s something which doesn’t exist in the
PSDK) may give more precision on that subject.

 

Hermes

 

De : ros-dev-boun...@reactos.org <mailto:ros-dev-boun...@reactos.org>
[mailto:ros-dev-boun...@reactos.org] De la part de Ged Murphy
Envoyé : vendredi 28 février 2014 14:55
À : 'ReactOS Development List'
Objet : Re: [ros-dev] About hotpatchable dlls on ReactOS

 

Are you referring to .msp’s ?

 

From: ros-dev-boun...@reactos.org <mailto:ros-dev-boun...@reactos.org>
[mailto:ros-dev-boun...@reactos.org] On Behalf Of Hermès BÉLUSCA - MAÏTO
Sent: 28 February 2014 13:53
To: ReactOS Development List
Subject: [ros-dev] About hotpatchable dlls on ReactOS

 

Hi guys !

 

It seems to appear that some games need standard APIs hotpatchable, in the
sense of MS: few extra bytes present in the prologue of the functions that
allow somebody to detour the API. I knew that this feature was useful for
windows updates, but what I didn’t know is that there are other programs
that use it: see this answer from James on the “Epic Win!” forum thread:
http://www.reactos.org/forum/viewtopic.php?f=2
<http://www.reactos.org/forum/viewtopic.php?f=2&t=10972&p=106823#p106814>
&t=10972&p=106823#p106814 , and the following post is something that I’ve
found about this subject, and the fact that Wine already have done something
about that.

 

So my question: should we support/create hotpatchable images (of the
standard dlls and maybe ?? exes) in ReactOS ? Is it already done ? If not,
what needs to be added ? It seems that MSVC and GCC handle that a bit
differently.

 

Cheers,

Hermès BÉLUSCA - MAÏTO

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

Re: [ros-dev] About hotpatchable dlls on ReactOS

[Ged Murphy]

Are you referring to .msp’s ?

 

From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On
Behalf Of Hermès BÉLUSCA - MAÏTO
Sent: 28 February 2014 13:53
To: ReactOS Development List
Subject: [ros-dev] About hotpatchable dlls on ReactOS

 

Hi guys !

 

It seems to appear that some games need standard APIs hotpatchable, in the
sense of MS: few extra bytes present in the prologue of the functions that
allow somebody to detour the API. I knew that this feature was useful for
windows updates, but what I didn’t know is that there are other programs
that use it: see this answer from James on the “Epic Win!” forum thread:
http://www.reactos.org/forum/viewtopic.php?f=2

&t=10972&p=106823#p106814 , and the following post is something that I’ve
found about this subject, and the fact that Wine already have done something
about that.

 

So my question: should we support/create hotpatchable images (of the
standard dlls and maybe ?? exes) in ReactOS ? Is it already done ? If not,
what needs to be added ? It seems that MSVC and GCC handle that a bit
differently.

 

Cheers,

Hermès BÉLUSCA - MAÏTO

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

Re: [ros-dev] [ros-diffs] [ekohl] 61145: [FASTFAT] FsdGetFsVolumeInformation: Return volume creation time.

[Ged Murphy]

Hi Eric,

I know this has been discussed before, but should we not just bite the bullet 
and replace this driver with the Microsoft driver.
The MS_LPL license allows it to be used in reactos, and it would certainly get 
rid of any unknowns  and give us a reliable filesystem to work from.

http://code.msdn.microsoft.com/windowshardware/fastfat-File-System-Driver-135bdf34/view/SourceCode

Ged.


-Original Message-
From: ros-diffs-boun...@reactos.org [mailto:ros-diffs-boun...@reactos.org] On 
Behalf Of ek...@svn.reactos.org
Sent: 29 November 2013 14:06
To: ros-di...@reactos.org
Subject: [ros-diffs] [ekohl] 61145: [FASTFAT] FsdGetFsVolumeInformation: Return 
volume creation time.

Author: ekohl
Date: Fri Nov 29 14:05:43 2013
New Revision: 61145



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

Re: [ros-dev] Branches status & cleanup

[Ged Murphy]

Yes!  This is such an obvious improvement, I'm surprised it's still not
widely accepted.

An epic mail from Timo explaining the current tree layout
https://www.reactos.org/archives/public/ros-dev/2010-July/013278.html

For anyone still interested in reading our rants, here's the start of the
original mailing list convo
https://www.reactos.org/archives/public/ros-dev/2010-July/013257.html



-Original Message-
From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On
Behalf Of Hermès BÉLUSCA - MAÏTO
Sent: 08 October 2013 17:47
To: 'ReactOS Development List'
Subject: Re: [ros-dev] Branches status & cleanup


> Tree-restructure-test
> Playground for restructuring the tree. "Let's reshuflle the files and
directories and that makes our OS more stable and usable". Last commit was
almost exactly 3 years ago.

I'm personally very interested in this thing (cf.
http://www.reactos.org/forum/viewtopic.php?p=102258&sid=ef8d6c9a27f9e3800b7d
ff87afdc5919 and OF COURSE http://www.reactos.org/wiki/Techwiki:File_Layout
) which aims at bringing modularity.


Cheers,
Hermès.



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

Re: [ros-dev] Google Montreal Tech Talk

[Ged Murphy]

Will the session be available online?

 

From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On
Behalf Of Alex Ionescu
Sent: 04 September 2013 20:12
To: 'ReactOS Development List'
Subject: [ros-dev] Google Montreal Tech Talk

 

Hey Guys,

 

I'll be in Montreal on October 2nd (Wednesday) giving a tech talk about
ReactOS, for about 2 hours. I intend to go over everything from development
to infrastructure (translation, testing, etc).

 

Are there any materials and/or suggestions from previous talks available
anywhere? Any set of tools/games/apps you recommend I try out?

 

--

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] [hbelusca] 58770: [REACTOS] Merge of the ros-csrss branch created with a three-fold purpose: - Use the new Windows-compatible Client-Server Runtime Subsystem (csrss + csrsrv)

[Ged Murphy]

Fantastic work Hermes!
Congrats


On 15/04/2013 20:32, "hbelu...@svn.reactos.org" 
wrote:

>Author: hbelusca
>Date: Mon Apr 15 19:32:00 2013
>New Revision: 58770
>
>URL: http://svn.reactos.org/svn/reactos?rev=58770&view=rev
>Log:
>[REACTOS]
>
>Merge of the ros-csrss branch created with a three-fold purpose:
>
>- Use the new Windows-compatible Client-Server Runtime Subsystem (csrss +
>csrsrv)
>written by Alex Ionescu to replace the old hacked one. Also the CSR
>client part,
>residing in ntdll, is updated. Some work also done on the dlls side, which
>communicate with CSR, namely kernel32.
>
>- Replace our very old win32csr.dll CSR server by the collection
>basesrv.dll /
>winsrv.dll as it is done under Windows.
>
>- Since the console subsystem is (for historical purposes on Windows) the
>only subsystem which exploits all the possibilities of the CSR, I decided
>to
>put it in a new CSR dll called 'consrv.dll', even if on Windows it is
>included
>together with other APIs inside the winsrv dll (since Windows NT 3.1
>release)
>(I took the name 'consrv' from the dll where it was included in Windows
>NT 3.1
>beta from October 1991). Some work was also done on its internal
>architecture
>(the external interface is of course unchanged for compatibility reasons)
>and a
>two-layer approach was developed, using the existing idea of console
>functions +
>GUI or TUI we already had in win32csr:
>   * the "console server" which dialogs with the console applications,
>and which maintains a list of all the created consoles.
>   * different "front-ends" corresponding to where you want to output
>the information (~= console hardware) (Work-In-Progress).
>Another idea would be to make those front-ends dynamically-loadable
>(instead
>of being compiled inside consrv).
>- I also fixed some parts of the console properties dialog box.
>
>More information can be found in
>http://www.reactos.org/archives/public/ros-dev/2013-April/016121.html
>
>CORE-122 CORE-2510 CORE-7002 #resolve #comment Committed in revision
>r58xxx.



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

Re: [ros-dev] Future merge of the ros-csrss branch into the trunk

[Ged Murphy]

Very impressive, great work Hermés!

 

From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On
Behalf Of Hermès BÉLUSCA - MAÏTO
Sent: 09 April 2013 19:26
To: 'ReactOS Development List'
Subject: Re: [ros-dev] Future merge of the ros-csrss branch into the trunk

 

Yes of course ! Here they are :

 

-  When I was testing both setting an adequate console title when an
app was launched and the corresponding icon (colors are here for the eyes):
http://img594.imageshack.us/img594/3669/consoletest3.png

-  Color changes with the console properties dialog (test on Far
Manager 3): http://img203.imageshack.us/img203/742/consoletest4.png

-  The first run of a mouse-aware console (test on Far Manager 3).
Right-click on an item in Far Manager (left, the console is in
ENABLE_MOUSE_INPUT mode) and (right) right-click on the console (mode
ENABLE_MOUSE_INPUT off): it displays the edition popup menu:
http://img856.imageshack.us/img856/6660/consolefarmanagerros.png

-  The two modes of selection: (left background) “Mark” mode, i.e.
selection via the keyboard (new) and (right foreground) “Selection” mode,
i.e. selection via the mouse (tested on Far Manager; since usual right-click
won’t show the edition menu, you have to right-click on the console
title-bar and select “Modify” – “Selection”):
http://img832.imageshack.us/img832/7482/consoleselection.png

-  To finish, test of Irssi (IRC client in command-line) (this one
works ok in the trunk): http://img29.imageshack.us/img29/1102/irssiros.png

 

The current console font is Fixedsys Excelsior 3.01 from
http://www.fixedsysexcelsior.com/ (already added in trunk), which is capable
of displaying Unicode characters (but not implemented in the console).

 

Regards,

Hermès

 

De : ros-dev-boun...@reactos.org <mailto:ros-dev-boun...@reactos.org>
[mailto:ros-dev-boun...@reactos.org] De la part de Ged Murphy
Envoyé : mardi 9 avril 2013 19:12
À : 'ReactOS Development List'
Objet : Re: [ros-dev] Future merge of the ros-csrss branch into the trunk

 

Screenshots? Can you post a few of those on here please?

 

From: ros-dev-boun...@reactos.org <mailto:ros-dev-boun...@reactos.org>
[mailto:ros-dev-boun...@reactos.org] On Behalf Of victor martinez
Sent: 09 April 2013 15:50
To: ReactOS Development List
Subject: Re: [ros-dev] Future merge of the ros-csrss branch into the trunk

 

Congrats!
This is an awesome work!
I will miss all the beauty screenshots now that your work in Console is
almost over!
I'm willing to enjoy the ros-csrss asap!
:)

> From: hermes.belu...@sfr.fr <mailto:hermes.belu...@sfr.fr> 
> To: ros-dev@reactos.org <mailto:ros-dev@reactos.org> 
> Date: Tue, 9 Apr 2013 12:47:48 +0200
> Subject: [ros-dev] Future merge of the ros-csrss branch into the trunk
> 
> Hi all !
> 
> I'm writing this mail to announce to you that in one week (if everything
> works as expected till this time) I will be ready to merge my ros-csrss
> branch into our current codebase.
> 
> The ros-csrss branch
> (http://svn.reactos.org/svn/reactos/branches/ros-csrss/?view=log) was
> started 5 months ago (October 14, 2012 to be precise) with a three-fold
> purpose:
> 
> - Use the new Windows-compatible Client-Server Runtime Subsystem (csrss +
> csrsrv) written by Alex Ionescu, unused at the moment and which currently
> lives in trunk/reactos/subsystems/csr/, and as such was a replacement for
> the older one in trunk/reactos/subsystems/win32/csrss/. This last one was
> progressively hacked to include functionalities from the new csrss;
however
> most of the old code remained and as such it was a big hack. Also the CSR
> client part, residing in ntdll, was updated (thanks to comments put by
Alex
> inside it). To communicate between the server-part and the client-part,
some
> messaging protocol is used (thanks to LPC); the used structures were not
so
> up-to-date, but the new ones were in the code, not used. So I could use
them
> instead of the older ones. That meant that some work was needed in ntdll
(as
> previously stated). Disregarding the details (you can see them in the
commit
> log), I also had to rework a little bit on the dlls which communicate with
> CSR, namely kernel32.
> 
> - Replacing our very old win32csr.dll csr server by the collection basesrv
/
> winsrv as it is done under Windows. For that I tried to match accurately
our
> existing code with what should exist on Windows according to this list of
> CSR servers APIs : http://j00ru.vexillium.org/csrss_list/api_list.html .
> 
> - Since the console subsystem is (for historical purposes on Windows) the
> only subsystem which exploits all the possibilities of the CSR, much of
the
> work in the branch was done to make it working with the new csrss. Even if
> on Windows it is included together with other APIs insid

Re: [ros-dev] Future merge of the ros-csrss branch into the trunk

[Ged Murphy]

Screenshots? Can you post a few of those on here please?

 

From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On
Behalf Of victor martinez
Sent: 09 April 2013 15:50
To: ReactOS Development List
Subject: Re: [ros-dev] Future merge of the ros-csrss branch into the trunk

 

Congrats!
This is an awesome work!
I will miss all the beauty screenshots now that your work in Console is
almost over!
I'm willing to enjoy the ros-csrss asap!
:)



> From: hermes.belu...@sfr.fr  
> To: ros-dev@reactos.org  
> Date: Tue, 9 Apr 2013 12:47:48 +0200
> Subject: [ros-dev] Future merge of the ros-csrss branch into the trunk
> 
> Hi all !
> 
> I'm writing this mail to announce to you that in one week (if everything
> works as expected till this time) I will be ready to merge my ros-csrss
> branch into our current codebase.
> 
> The ros-csrss branch
> (http://svn.reactos.org/svn/reactos/branches/ros-csrss/?view=log) was
> started 5 months ago (October 14, 2012 to be precise) with a three-fold
> purpose:
> 
> - Use the new Windows-compatible Client-Server Runtime Subsystem (csrss +
> csrsrv) written by Alex Ionescu, unused at the moment and which currently
> lives in trunk/reactos/subsystems/csr/, and as such was a replacement for
> the older one in trunk/reactos/subsystems/win32/csrss/. This last one was
> progressively hacked to include functionalities from the new csrss;
however
> most of the old code remained and as such it was a big hack. Also the CSR
> client part, residing in ntdll, was updated (thanks to comments put by
Alex
> inside it). To communicate between the server-part and the client-part,
some
> messaging protocol is used (thanks to LPC); the used structures were not
so
> up-to-date, but the new ones were in the code, not used. So I could use
them
> instead of the older ones. That meant that some work was needed in ntdll
(as
> previously stated). Disregarding the details (you can see them in the
commit
> log), I also had to rework a little bit on the dlls which communicate with
> CSR, namely kernel32.
> 
> - Replacing our very old win32csr.dll csr server by the collection basesrv
/
> winsrv as it is done under Windows. For that I tried to match accurately
our
> existing code with what should exist on Windows according to this list of
> CSR servers APIs : http://j00ru.vexillium.org/csrss_list/api_list.html .
> 
> - Since the console subsystem is (for historical purposes on Windows) the
> only subsystem which exploits all the possibilities of the CSR, much of
the
> work in the branch was done to make it working with the new csrss. Even if
> on Windows it is included together with other APIs inside the winsrv dll
> (since Windows NT 3.1 release), I decided to put it in a separate dll,
> called consrv, on ReactOS (I took the name from the dll where it was
> included in Windows NT 3.1 beta from October 1991). Also, because I
believe
> that the console subsystem is something that, on Windows, was somewhat
> neglected (no ANSI control, (almost?)no TTY-like flavour...) I decided to
> work on its internal architecture (the exterior one being unchanged for
> compatibility reasons) such as to exacerbate the following things:
> * the "console server" which dialogs with the console applications,
> and which maintains a list of all the created consoles.
> * different "front-ends" corresponding to where you want to output
> the information (~= console hardware) (it is of course work-in-progress).
At
> the moment only one is working: the GUI console. I have to make the TUI
> interfacing correctly with the rest of the code (but since it's not used
for
> now, it's not extremely urgent). The idea would be to have also a
front-end
> for serial ports, so that we could interact with the serial port (with
Putty
> if running ROS on a virtual machine, or with a serial console, etc...).
And
> another idea would be to make those front-ends dynamically-loadable
(instead
> of being compiled inside consrv).
> - I also fixed some parts of the console properties dialog box.
> 
> 
> Here is the JIRA report for the merge:
> http://jira.reactos.org/browse/CORE-7002
> Here are the test results with revision 58723 (plus comparison with
> revisions 58722 and 58720):
> http://old.reactos.org/testman/compare.php?ids=16213,16218,16219,16221
> You will see that the ntdll:exception seems to run 24 more tests, but 4
> failed compared to non-patched r58723. The errors are "exception.c:821:
Test
> failed: Eip at 0x77f2b2a3 instead of 0079000B". It would be interesting to
> investigate further on these failings.
> Also, gdi32:font executes 33 more tests, and 10 more fail, due to the
> Fixedsys font.
> A problem, already existing in trunk, remains:
> http://jira.reactos.org/browse/CORE-6397 (see description inside).
> 
> You are encouraged to make comments, etc... etc...
> 
> Cheers,
> Hermès.
> 
> 
>
~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=
> ~

Re: [ros-dev] Notice Of Intent - Visual Studio Build of ReactOS

[Ged Murphy]

Having a solution for each project is like having a separate build system
for each project.
You could probably break it down to between 5-10 solutions, having one for
each major area of the build but anything more would be detrimental to the
advantages of using VS.


From:  Timo Kreuzer 
Reply-To:  ReactOS List 
Date:  Friday, 11 January 2013 21:16
To:  ReactOS List 
Subject:  Re: [ros-dev] Notice Of Intent - Visual Studio Build of ReactOS


 
Am 11.01.2013 06:48, schrieb BinSys:
 
 
>  
>  
> I suggest a sln file in each directory. Only a sln file is too big, very slow
> to load.
>  
>  
>  
>  
 I agree, but before changing this, we should measure a possible performance
impact on the configure operation. (We are talking about generating a few
hundred solution files)
 I don't know if it has any impact at all (especially for non-VS build), but
you never know...
 
 
___ 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] Notice Of Intent - Visual Studio Build of ReactOS

[Ged Murphy]

To speed up the process for you, I'd recommend you get a copy of RosBE and
run 'make msvc10'
This will generate all the project files and a solution for for you, in a
mostly buildable state. I think it may also generate some property sheets,
which you should definitely try to incorporate. I can help you with suitable
property sheets if you'd like some advise on this.

We've already put quite a bit of effort into generating dynamic visual
studio projects, (as this is definitely the only maintainable solution IMO),
so the outputted vcxproj files should lay down a good base for you to work
with. 

Ged.


From:  "J. C. Jones" 
Reply-To:  ReactOS List 
Date:  Friday, 4 January 2013 19:30
To:  ReactOS List 
Subject:  Re: [ros-dev] Notice Of Intent - Visual Studio Build of ReactOS

Ok. VS2010+ it will be. J
 
I will do a quick review to make sure that we can get all the multiple-CPU
development features, etc. and report back.
 
Cheers.
 

From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On
Behalf Of Aleksey Bragin
Sent: Friday, January 04, 2013 1:25 PM
To: ReactOS Development List
Subject: Re: [ros-dev] Notice Of Intent - Visual Studio Build of ReactOS
 

It's up to you of course, but VS2008 is too dated, and VS2012 is "too new"
indeed, so many devs will cry about incompatible project files.
So, VS2010 would be the ideal bet, as Ged said.

Regards,
Alex Bragin

On 04.01.2013 23:21, J. C. Jones wrote:
> Yes.
>  
> But initially, I wanted to make it so that anyone, especially a newbie, could
> go from discovering ReactOS, to an edit-compile-link-debug cycle of ³Hello,
> World!² within the IDE  in 30 minutes or less (not the OS, just a single app).
> That means accommodating whatever version of Visual Studio they are using.
> VS2008 is safe, because, no matter which version they are using: VS2008,
> VS2010, VS2011, or VS2012, the conversion would be done automatically, on
> their machine, and since the project files in SVN would be locked, there¹d be
> no harm done to SVN using this method. However, if I start out with VS2012,
> for example, then, sure, they could go and download VS2012 alongside say,
> VS2010Šbut my goal was to present a totally new user with the SVN URL for
> ReactOS, and say, ³Here is is. Give it a try!², and remove all excuses for
> them trying it out. [I figured that having to install a 1GB+ tool alongside a
> very similar tool was a bigger excuse for most newbie developers than having
> to wait < 5 minutes to watch the VS2012 do its conversion.]
>  
> That said, if Visual Studio users came back and said, ³We¹re not using VS2008
> anyway!² then I would change it, and I am definitely open to ideas on this.
> 
> Sent: Friday, January 04, 2013 3:43 AM
> To: 'ReactOS Development List'
> Subject: Re: [ros-dev] Notice Of Intent - Visual Studio Build of ReactOS
>  
> VS2008?
> Shouldn¹t you be doing this in 2012, especially considering the much improved
> support for kernel mode projects.
> At the very least you should be using 2010 as 2012 can open 2010 project
> without modification to project files.
>  
>  
>  
> 
> From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On
> Behalf Of J. C. Jones
> Sent: 04 January 2013 02:40
> To: 'ReactOS Development List'
> Subject: Re: [ros-dev] Notice Of Intent - Visual Studio Build of ReactOS
>  
> Yes, it is one thing to create a project file, which takes 15-30 seconds. It
> is another thing to get the configuration right.  Fortunately, there are
> copious notes and highly-readable scripts in the tree which practically say
> what needs to be done, so I do not anticipate any major hurdles.
>  
> I spent a little time in the source tree today. I integrated a few modules
> into Visual  Studio 2008, an tested calc, by buiding it from within Visual
> Studio for x86-32 and x86-64. It ran fine, thanks to the author(Mr. Carlo
> Bramini) who left good notes in his source code. Just for kicks, I also
> created an ARM-based project that would run on the Raspberry Pi, compiled it
> from within  VS2008, and ran it inside the emulator that comes with VS2008.
> That ran fine also. Tomorrow I will ask a colleague to try the following:
> 1.   Pull the repository to his local hard disk from inside Visual Studio.
> 
> 2.   Hit Build.
> 
> 3.   Run calc in an edit- compile-debug loop.
> 
>  
>  
> 
> From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On
> Behalf Of Timo Kreuzer
> Sent: Thursday, January 03, 2013 2:18 AM
> To: ReactOS Development List
> Subject: Re: [ros-dev] Notice Of Intent - Visual Studio Build of ReactOS
>  
> 
> Am 02.01.2013 19:04, schrieb J. C. Jones:
>> It would take 2-3 hours to create VS projects for all user-mode modules.
> No offence, but I think you are highly underestimating the magnitude of our
> codebase. We are talking about several hundred modules. And you probably also
> overestimate the pace at which you can create project files. I did that myself
> for a much smaller proje

Re: [ros-dev] [ros-diffs] [hbelusca] 58110: while (TRUE); (when something is unimplemented) ---> ASSERT(FALSE); // while (TRUE); (unless we deal with a 'noreturn' function), and in some cases, return

[Ged Murphy]

Well depending on which IRLQ the while loop is in means it could
occasionally loose CPU time only later to be rescheduled.

Also, if you do happen to want examine the running code path, you need to
break in to the running OS, find the runaway thread and attach to it. Having
an ASSERT(FALSE) is surely much simpler?

 

I’m sure Alex had his reasons for using while (TRUE), but I’m not sure what
they are.

 

Ged.

 

 

From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On
Behalf Of Aleksey Bragin
Sent: 04 January 2013 14:15
To: ReactOS Development List
Subject: Re: [ros-dev] [ros-diffs] [hbelusca] 58110: while (TRUE); (when
something is unimplemented) ---> ASSERT(FALSE); // while (TRUE); (unless we
deal with a 'noreturn' function), and in some cases, return an adequate
value. Part...

 

this while (TRUE); means that "OS can't function anymore if this codepath is
executed". It's a fatal, terminal way, so there is no power to save :)

On 04.01.2013 18:11, Javier Agustìn Fernàndez Arroyo wrote:

well, IMO, "while(true)" means CPU is permanently busy, while an ASSERT
stops CPU from running 
just a matter of power saving 

and i repeat, its just an opinion

On Fri, Jan 4, 2013 at 3:02 PM, Aleksey Bragin mailto:alek...@reactos.org> > wrote:

With all respect, I don't understand many of these changes. Answering
between the lines.

On 04.01.2013 15:47, hbelu...@svn.reactos.org
  wrote:

  NTSTATUS
@@ -643,7 +643,8 @@
  /* FIXME: TODO */
  DPRINT1("You have implemented the KD routines for searching PCI
debugger"
  "devices, but you have forgotten to implement this
routine\n");
-while (TRUE);
+UNIMPLEMENTED;
+ASSERT(FALSE); // while (TRUE);
  }

It already prints a mandatory log message that this part is unimplemented.
And execution is supposed to stop after printing this message, because it's
meaningless to continue (that's why while(TRUE); was put there in the first
place).

static ULONG NTAPI
@@ -678,7 +679,7 @@
  {
  /* /PCILOCK is not yet supported */
  UNIMPLEMENTED;
-while (TRUE);
+ASSERT(FALSE); // while (TRUE);
  }
  #endif
  /* Now create the correct resource list based on the supported bus
ranges */

It already has UNIMPLEMENTED; and now you added an ASSERT(FALSE); which
essentially is the same thing. And if continuation is possible, then just
UNIMPLEMENTED would be enough.

I'd like some general solution to this. Like, UNIMPLEMENTED_FATAL() or
something like that.

Any thoughts?

Regards,
Aleksey Bragin

 

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

Re: [ros-dev] Notice Of Intent - Visual Studio Build of ReactOS

[Ged Murphy]

VS2008?

Shouldn't you be doing this in 2012, especially considering the much
improved support for kernel mode projects.

At the very least you should be using 2010 as 2012 can open 2010 project
without modification to project files.

 

 

 

From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On
Behalf Of J. C. Jones
Sent: 04 January 2013 02:40
To: 'ReactOS Development List'
Subject: Re: [ros-dev] Notice Of Intent - Visual Studio Build of ReactOS

 

Yes, it is one thing to create a project file, which takes 15-30 seconds. It
is another thing to get the configuration right.  Fortunately, there are
copious notes and highly-readable scripts in the tree which practically say
what needs to be done, so I do not anticipate any major hurdles. 

 

I spent a little time in the source tree today. I integrated a few modules
into Visual  Studio 2008, an tested calc, by buiding it from within Visual
Studio for x86-32 and x86-64. It ran fine, thanks to the author(Mr. Carlo
Bramini) who left good notes in his source code. Just for kicks, I also
created an ARM-based project that would run on the Raspberry Pi, compiled it
from within  VS2008, and ran it inside the emulator that comes with VS2008.
That ran fine also. Tomorrow I will ask a colleague to try the following:

1.   Pull the repository to his local hard disk from inside Visual
Studio.

2.   Hit Build.

3.   Run calc in an edit- compile-debug loop.

 

 

From: ros-dev-boun...@reactos.org 
[mailto:ros-dev-boun...@reactos.org] On Behalf Of Timo Kreuzer
Sent: Thursday, January 03, 2013 2:18 AM
To: ReactOS Development List
Subject: Re: [ros-dev] Notice Of Intent - Visual Studio Build of ReactOS

 

Am 02.01.2013 19:04, schrieb J. C. Jones:

It would take 2-3 hours to create VS projects for all user-mode modules.

No offence, but I think you are highly underestimating the magnitude of our
codebase. We are talking about several hundred modules. And you probably
also overestimate the pace at which you can create project files. I did that
myself for a much smaller project, so I know what I'm talking about. 
But maybe I'm wrong and they call you "The Machine" :D

  _  

No virus found in this message.
Checked by AVG - www.avg.com  
Version: 2013.0.2805 / Virus Database: 2637/6005 - Release Date: 01/02/13

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

Re: [ros-dev] [ros-diffs] [tfaber] 57976: [EXPLORER_NEW] - Add a manifest file to support theming - Formatting fixes - Based on Andrew Green's GSoC branch

[Ged Murphy]

Are you planning on resurrecting this branch Thomas?


On 23/12/2012 10:25, "tfa...@svn.reactos.org" 
wrote:

>Author: tfaber
>Date: Sun Dec 23 10:25:19 2012
>New Revision: 57976
>
>URL: http://svn.reactos.org/svn/reactos?rev=57976&view=rev
>Log:
>[EXPLORER_NEW]
>- Add a manifest file to support theming
>- Formatting fixes
>- Based on Andrew Green's GSoC branch
>
>Added:
>trunk/reactos/base/shell/explorer-new/explorer.exe.manifest   (with
>props)
>Modified:
>trunk/reactos/base/shell/explorer-new/explorer.rc
>trunk/reactos/base/shell/explorer-new/taskswnd.c
>trunk/reactos/base/shell/explorer-new/trayntfy.c



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

Re: [ros-dev] [ros-diffs] [hbelusca] 57462: [REGEDIT] - WCHAR ==> TCHAR in (before a REALLY conversion of regedit into UNICODE) - Correct some mistakes in displayed strings - Improve informative / war

[Ged Murphy]

Windows 95 makes a comeback!

-Original Message-
From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On 
Behalf Of Timo Kreuzer
Sent: 03 October 2012 09:16
To: ros-dev@reactos.org
Subject: Re: [ros-dev] [ros-diffs] [hbelusca] 57462: [REGEDIT] - WCHAR ==> 
TCHAR in (before a REALLY conversion of regedit into UNICODE) - Correct some 
mistakes in displayed strings - Improve informative / warning / error messages 
w...


Please don't use TCHAR. Make everything WCHAR and use widechar functions 
explicitly.



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

Re: [ros-dev] [ros-diffs] [ion] 57284: [NTOSKRNL]: Use the token lock acquire/release macros that were already written instead of manually doing it. Also fix the macros since they didn't work in GCC.

[Ged Murphy]

I think the old ones were missing a brace before the 'while' statement

-Original Message-
From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On
Behalf Of Alex Ionescu
Sent: 12 September 2012 18:05
To: ReactOS Development List
Subject: Re: [ros-dev] [ros-diffs] [ion] 57284: [NTOSKRNL]: Use the token
lock acquire/release macros that were already written instead of manually
doing it. Also fix the macros since they didn't work in GCC. No functional
change, j...

The old ones gave compiler errors... if you guys can fix them, go ahead :)

--
Best regards,
Alex Ionescu

On 2012-09-12, at 9:56 AM, Timo Kreuzer  wrote:

> 
> What was the problem with the old macros? The new ones are error-prone.
> 
> if (NeedLock) SepAcquireTokenLockExclusive(Token); // <= fail!
> 
> WBR,
> Timo
> 
> 
> 
> 
> Am 12.09.2012 18:29, schrieb i...@svn.reactos.org:
>> Author: ion
>> Date: Wed Sep 12 16:29:28 2012
>> New Revision: 57284
>> 
>> URL: http://svn.reactos.org/svn/reactos?rev=57284&view=rev
>> Log:
>> [NTOSKRNL]: Use the token lock acquire/release macros that were already
written instead of manually doing it. Also fix the macros since they didn't
work in GCC.
>> No functional change, just code cleanup.
>> 
>> Modified:
>> trunk/reactos/ntoskrnl/include/internal/se.h
>> trunk/reactos/ntoskrnl/se/access.c
>> trunk/reactos/ntoskrnl/se/semgr.c
>> 
>> Modified: trunk/reactos/ntoskrnl/include/internal/se.h
>> URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/internal/s
e.h?rev=57284&r1=57283&r2=57284&view=diff
>>

==
>> --- trunk/reactos/ntoskrnl/include/internal/se.h [iso-8859-1] (original)
>> +++ trunk/reactos/ntoskrnl/include/internal/se.h [iso-8859-1] Wed Sep 12
16:29:28 2012
>> @@ -1,4 +1,28 @@
>>  #pragma once
>> +
>> +typedef struct _KNOWN_ACE
>> +{
>> +ACE_HEADER Header;
>> +ACCESS_MASK Mask;
>> +ULONG SidStart;
>> +} KNOWN_ACE, *PKNOWN_ACE;
>> +
>> +typedef struct _KNOWN_OBJECT_ACE
>> +{
>> +ACE_HEADER Header;
>> +ACCESS_MASK Mask;
>> +ULONG Flags;
>> +ULONG SidStart;
>> +} KNOWN_OBJECT_ACE, *PKNOWN_OBJECT_ACE;
>> +
>> +typedef struct _KNOWN_COMPOUND_ACE
>> +{
>> +ACE_HEADER Header;
>> +ACCESS_MASK Mask;
>> +USHORT CompoundAceType;
>> +USHORT Reserved;
>> +ULONG SidStart;
>> +} KNOWN_COMPOUND_ACE, *PKNOWN_COMPOUND_ACE;
>>PSID
>>  FORCEINLINE
>> @@ -75,6 +99,8 @@
>>  return Descriptor->Sacl;
>>  }
>>  }
>> +
>> +#ifndef RTL_H
>>/* SID Authorities */
>>  extern SID_IDENTIFIER_AUTHORITY SeNullSidAuthority;
>> @@ -156,6 +182,19 @@
>>  extern PSECURITY_DESCRIPTOR SeSystemDefaultSd;
>>  extern PSECURITY_DESCRIPTOR SeUnrestrictedSd;
>>  +
>> +#define SepAcquireTokenLockExclusive(Token)
\
>> +KeEnterCriticalRegion();
\
>> +ExAcquireResourceExclusive(((PTOKEN)Token)->TokenLock, TRUE);
\
>> +
>> +#define SepAcquireTokenLockShared(Token)
\
>> +KeEnterCriticalRegion();
\
>> +ExAcquireResourceShared(((PTOKEN)Token)->TokenLock, TRUE);
\
>> +
>> +#define SepReleaseTokenLock(Token)
\
>> +ExReleaseResource(((PTOKEN)Token)->TokenLock);
\
>> +KeLeaveCriticalRegion();
\
>> +
>>  //
>>  // Token Functions
>>  //
>> @@ -434,24 +473,6 @@
>>  OUT PACCESS_TOKEN* NewToken
>>  );
>>  -#define SepAcquireTokenLockExclusive(Token)
\
>> -  do {
\
>> -KeEnterCriticalRegion();
\
>> -ExAcquireResourceExclusive(((PTOKEN)Token)->TokenLock, TRUE);
\
>> -  while(0)
>> -
>> -#define SepAcquireTokenLockShared(Token)
\
>> -  do {
\
>> -KeEnterCriticalRegion();
\
>> -ExAcquireResourceShared(((PTOKEN)Token)->TokenLock, TRUE);
\
>> -  while(0)
>> -
>> -#define SepReleaseTokenLock(Token)
\
>> -  do {
\
>> -ExReleaseResource(((PTOKEN)Token)->TokenLock);
\
>> -KeLeaveCriticalRegion();
\
>> -  while(0)
>> -
>>  VOID NTAPI
>>  SeQuerySecurityAccessMask(IN SECURITY_INFORMATION SecurityInformation,
>>OUT PACCESS_MASK DesiredAccess);
>> @@ -460,4 +481,6 @@
>>  SeSetSecurityAccessMask(IN SECURITY_INFORMATION SecurityInformation,
>>  OUT PACCESS_MASK DesiredAccess);
>>  +#endif
>> +
>>  /* EOF */
>> 
>> Modified: trunk/reactos/ntoskrnl/se/access.c
>> URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/se/access.c?rev=57
284&r1=57283&r2=57284&view=diff
>>

==
>> --- trunk/reactos/ntoskrnl/se/access.c [iso-8859-1] (original)
>> +++ trunk/reactos/ntoskrnl/se/access.c [iso-8859-1] Wed Sep 12 16:29:28
2012
>> @@ -130,11 +130,7 @@
>>  ASSERT(Sid != NULL);
>>/* Lock the token if needed */
>> -if (!TokenLocked)
>> -{
>> -KeEnterCriticalRegion();
>> -ExAcquireResourceSharedLite(Token->TokenLock, TRUE);
>> -}
>> +if (!TokenLocked) SepAcquireTokenLockShared(Token);
>>/* Check if the owner SID is found, handling restricted case as
well */
>>  Re

Re: [ros-dev] [ros-diffs] [ion] 57284: [NTOSKRNL]: Use the token lock acquire/release macros that were already written instead of manually doing it. Also fix the macros since they didn't work in GCC.

[Ged Murphy]

Why the removal of the do/while loop?
This breaks the macro when used without braces :

+#define SepReleaseTokenLock(Token) 
\
+ExReleaseResource(((PTOKEN)Token)->TokenLock); 
\
+KeLeaveCriticalRegion();   
\
+



-#define SepReleaseTokenLock(Token) 
\
-  do { 
\
-ExReleaseResource(((PTOKEN)Token)->TokenLock); 
\
-KeLeaveCriticalRegion();   
\
-  while(0)



 /* Release the lock if we had acquired it */
+if (!TokenLocked) SepReleaseTokenLock(Token);
 



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

Re: [ros-dev] [ros-diffs] [ion] 56906: [NTOSKRNL]: Implement support for session pool (not yet enabled) and session space (implemented and enabled, but nobody is calling the APIs yet). [NTOSKRNL]: Imp

[Ged Murphy]

Fantastic!
Smss2 will be happy :)

-Original Message-
From: ros-diffs-boun...@reactos.org [mailto:ros-diffs-boun...@reactos.org] On 
Behalf Of i...@svn.reactos.org
Sent: 16 July 2012 00:42
To: ros-di...@reactos.org
Subject: [ros-diffs] [ion] 56906: [NTOSKRNL]: Implement support for session 
pool (not yet enabled) and session space (implemented and enabled, but nobody 
is calling the APIs yet). [NTOSKRNL]: Implement MmMapViewOInSess...

Author: ion
Date: Sun Jul 15 23:42:27 2012
New Revision: 56906

URL: http://svn.reactos.org/svn/reactos?rev=56906&view=rev
Log:
[NTOSKRNL]: Implement support for session pool (not yet enabled) and session 
space (implemented and enabled, but nobody is calling the APIs yet).
[NTOSKRNL]: Implement MmMapViewOInSessionSpace, MmUnmapViewInSessionSpace. 
Win32k needs to use these to we can test them.

Modified:
trunk/reactos/ntoskrnl/mm/ARM3/i386/init.c
trunk/reactos/ntoskrnl/mm/ARM3/miarm.h
trunk/reactos/ntoskrnl/mm/ARM3/pfnlist.c
trunk/reactos/ntoskrnl/mm/ARM3/pool.c
trunk/reactos/ntoskrnl/mm/ARM3/procsup.c
trunk/reactos/ntoskrnl/mm/ARM3/section.c



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

Re: [ros-dev] Monthly meeting - April 2012

[Ged Murphy]

It's just you, unless you can name a company that has their meetings in
public?

Meetings are for the members of organizations set goals, deal with issues
and discuss behind the scenes information. 
Why should non-members have the right to listen in on internal affairs?

Ged.



-Original Message-
From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On
Behalf Of Emanuel Rietveld
Sent: 27 April 2012 11:24
To: ros-dev@reactos.org
Subject: Re: [ros-dev] Monthly meeting - April 2012

On 04/26/2012 07:38 PM, Pierre Schweitzer wrote:
> Hi,
>
> This meeting will be private. If you do
> not have access, you will not be able to attend the meeting.
>
> Regards,
>

Is it just me, or this a little like spraying contributor repellant on 
your project?

Kind Regards,

Emanuel

___
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] 56356: [NTOSKRNL] Fix SepGet*FromDescriptor, returning NULL, when the relative offset is 0. Fixes VMware tools installer.

[Ged Murphy]

> Author: tkreuzer
>  [NTOSKRNL]
> Fix SepGet*FromDescriptor, returning NULL, when the relative offset is 0.
> Fixes VMware tools installer.

Someone buy that man a beer!


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

[ros-dev] Facebook fanpage

[Ged Murphy]

All Facebook fanpages will be to switch to the new timeline layout this
weekend. This means we need a cover picture for our reactos fan page.

If artistic guys out there wanna put something together, we'll upload it to
our fanpage.

 

Maybe someone could start a thread in the forum to gather some interest?

 

Cheers,

Ged.

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

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

[Ged Murphy]

> Well that's kinda the purpose of the testbot, to do the testing for you.
No, the purpose of the testbot is to run all tests in a controlled
environment and catch anything devs may miss.
Devs should be using the tests directly to develop reactos. Relying on
testbot to test your code and catch errors is very bad practice.

>  So for example you want to stuff everything that's in dibtests to the
gdi32 folder?
Trust you to pick that one, dibtests is one of the few tests which doesn't
fall into a child category.
However with the correct tree structure, dibtests would be under a parent
./tests folder in the 'win32core' directory
http://www.reactos.org/wiki/Techwiki:File_Layout 

> And have every module's ./test folder filled with unmaintained half
finished tests?
I didn't mention half finished tests. I wouldn't expect the folder to fill
up with bespoke tests, it's just a useful place if ever a neat test is
written.

> Also consider people with slower internet connection. Ever tried doing a
checkout on GPRS? :-)
This is 2012, you can't hold the project back in case someone might still be
using dialup. Technology moves forwards. 
Also, why would you checkout over GPRS? Are you trying to suggest people
thether to their mobile phones to checkout reactos?





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

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

[Ged Murphy]

> We don't need to have useless files in tree.

Useless files?
They're arguably the most important files in the tree.

Working on the codebase should be done directly with the tests for that area. 
The modules and tests are directly related and shouldn't be separated. It's 
like separating twins. Unfortunately, most people checkout trunk and not the 
tests, leaving testing to the build machines. 

I'm guessing that people also write lots of test apps to test certain 
functionality of a particular area. These never get committed because there's 
nowhere to commit them, or lost if they do (remember the lena app we used for 
alphablending?)
Having a ./tests folder will give people somewhere to drop this kind of thing 
and the chance to write bespoke tests outside of the winetest framework.

Obviously the tests shouldn't be compiled under the basic build, instead have a 
flag in the root makefile so they can be compiled as desired.
This would mean with the flag off everything would build as it does now.
With the flag on, 'make' would build reactos + tests. 'make module' would build 
the module + its specific tests.

The source for all tests comes to 24MB. It's not gonna flood your bandwidth or 
fill your hard disk.



-Original Message-
From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On 
Behalf Of Samuel Serapión
Sent: 08 March 2012 14:35
To: Sylvain Petreolle; ReactOS Development List
Subject: Re: [ros-dev] Re : [ros-diffs] [jgardou] 56082: [DAMN_IT] - addendum 
to r56081

+1 for keeping rostests separate
+1 for even more modularity

also i wish we would use/exploit the svn externals feature whenever
possible instead of importing 3rd party code into our repo

On Thu, Mar 8, 2012 at 10:21 AM, Sylvain Petreolle  wrote:
> I fully agree with Timo.
> We don't need to have useless files in tree.
> Remember we recently deleted stuff from the main tree for the same reasons :
> space used and download time.
>
> We do need tests, they are critical, but not in every reactos checkout.
> I am for making tests a complete separated project, which would lower build
> times even more.
>
> Kind regards,
> Sylvain Petreolle
>
> 
> De : Timo Kreuzer 
> À : ReactOS Development List 
> Envoyé le : Jeudi 8 mars 2012 1h27
> Objet : Re: [ros-dev] [ros-diffs] [jgardou] 56082: [DAMN_IT] - addendum to
> r56081
>
> Am I the only one against that?
> Tests are tests, not reactos.
> Why do I need to have another bazillion files in my source tree that I don't
> need or want?
> I have ONE checkout of rostests, but a dozen checkouts of reactos. For amd64
> work I even disabled build of a lot of stuff that was pointless. Now even
> more stuff spread thoughout the whole tree? Possibly even built by default?
> Deleting a full reactos checkout is already slow enough. Also every commit
> to rostetsts is a possible build breaker and can cause massive rebuilds.
> Configure time will also increase.
> I would rather prefer to make it even more modular, instead of mixing stuff
> even more.
>
> -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

___
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] 56082: [DAMN_IT] - addendum to r56081

[Ged Murphy]

I totally agree, every module should have a ./test folder containing all 
related tests. This was something I wanted to do with the proposed tree 
restructure (which I still think should be pushed)
The need to save bandwidth and disk space is a thing of the past.


-Original Message-
From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On 
Behalf Of Jérôme Gardou
Sent: 07 March 2012 21:51
To: ros-dev@reactos.org
Subject: Re: [ros-dev] [ros-diffs] [jgardou] 56082: [DAMN_IT] - addendum to 
r56081

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@re

Re: [ros-dev] Ram/hdd

[Ged Murphy]

Hahahaha
Insulting the project leader is a great way to start your reactos
experience.
:)


-Original Message-
From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On
Behalf Of Magnus Johnsson
Sent: 18 February 2012 09:36
To: ReactOS Development List
Subject: Re: [ros-dev] Ram/hdd

Dude. Your mailserver claims that the time you sent the email was
2008-05-24, which flags your mail as spam.
Go check your settings, Aleksey was merely joking :).

2008/5/24 Mikey :
> 1. Time machines have not been invented so that's impossible.
>
> 2. I don't live in the past so that was stupid
>
> 3. I have my date/time done perfectly fine.
>
> So next time don't say that to someone  knows what they are talking about
>
> ___
> 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] Proposal for FF support drop

[Ged Murphy]

Is the download link provided by Microsoft's browser choice web page static?
You could always link to that for the latest release.

http://www.browserchoice.eu 
http://go.microsoft.com/fwlink/?LinkID=166932 



-Original Message-
From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On 
Behalf Of Pierre Schweitzer
Sent: 15 January 2012 21:58
To: ros-dev@reactos.org
Subject: Re: [ros-dev] Proposal for FF support drop

Le dimanche 15 janvier 2012 à 20:05 +0100, Sven Barth a écrit :
> Btw: Mozilla wants to publish "long term support" releases in the next 
> time (based either on FF 8 or FF 9) which shall be supported around ~45 
> weeks. Maybe this will be a solution?

The main problem is not that they easily jump version number. The
problem is that they release too often.
Even if we get stuck at some LTS, if they release X.0.[1..100] every
month, that won't do the job.


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