Re: [ros-dev] The situation with version 0.4.14

[Hermès BÉLUSCA-MAÏTO]

I would like to just release the 0.4.14, as we already have a ton of release 
candidates of it on Sourceforge, so that we are done with it now, and then 
branch 0.4.15 and do the usual regression testing from there.

Regards,
Hermes

-Original Message-
From: Ros-dev  On Behalf Of Victor Perevertkin
Sent: 9. veljače 2021. 16:47
To: ReactOS Development List 
Subject: [ros-dev] The situation with version 0.4.14

Hello!

It seems for me that it's time to bring up the topic about our RC version - 
0.4.14.

Our current "stable", 0.4.13 was branched on 30 September, 2019 (remember those 
peacefull pre-COVID times :D) That's quite some time, but not the main issue 
I'd like to discuss.

0.4.14 was branched on 24 April, 2020. That's almost a year already.
And we're in a difficult situation here - there are regressions, but nobody 
fixed them within this long time.
According to https://reactos.org/wiki/Tests_for_0.4.14, there are 29 unfixed 
regressions found for this release. I'd like to point out: most of them are 
among usermode and non-kernel/driver functionality, and as our development is 
mostly focused in the kernel right now, it's unexpected for them to be fixed 
unless a volunteer comes up.

A quick reminder. Our "releases" mechanism is useful for finding regressions in 
the first place, there is no that much benefit for users here, because we're 
still a "deep" alpha. Correct me if I'm wrong.
Joakim made a great job finding all regressions, and this work won't be lost in 
any case.

We can't wait forever and I think it's time to resolve this situation somehow. 
I see two options:
1. Release 0.4.14 as-is. There were a lot more buggy releases, nobody dies from 
this.
2. Skip 0.4.14. This already happened once in the history of the project - 
0.3.2 was skipped. I wasn't around at the time, but I may guess that reasons 
were similar to what we have today.
(3.) Fix the bugs quickly. I don't expect this to happen, but who knows, maybe 
a volunteer appears :)

Let's vote. This seem to be the only way for us to decide on things.
Votes from the team members will be collected until 1 March.

===

I personally vote for skipping the release. The work on finding regressions is 
already done, so the most important part of a release cycle for us is there 
(thanks Joakim!) If we do a release now, all the stuff we were writing in news 
reports for the last 6 month would be missing from it. That would cause (as I
think) a lot of confusion to people. Moreover 0.4.14 is not that featureful 
release itself (compared to 0.4.13, which brought the new USB stack) So I 
suggest to move on and start checking 0.4.15 for regressions. I expect quite 
some of them to appear and we need time for fixing.


Cheers,
Victor


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

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

[Hermès BÉLUSCA-MAÏTO]

And it's not possible to use these tools and libraries as plug-in and -out?
I mean, for example, for people interested in these, and some of our
buildbots, to do "configure+build using libc++ and LLVM" in order to get
more info about the code they write in ROS,
and in such a way that it is also possible for other people who want to
build ROS with e.g. MSVC 2010, to instead "configure+build using MSVC 2010 +
older lib" ? 

Regards,
Hermes

-Original Message-
From: Ros-dev  On Behalf Of Victor Perevertkin
Sent: 18. prosinca 2020. 05:13
To: ReactOS Development List 
Subject: Re: [ros-dev] Status Meeting (November 2020)

Many words were said already about dropping the support for old compilers. I
agree with all of them and want to put one more argument on top of it from
myself.

There are a lot of innovations happen in compilers and tooling. Big
companies put thousands of man-hours to improve compiler toolchains and
standard libraries (LLVM and libc++ are the headliners here - everything
goes there first).
It's silly not to use all of those, it makes finding bugs easier by orders
of magnitude (modern C++ makes you write code with less bugs too, but that
has been said already).
For example, AddressSanitizer will show you out of bounds access right where
it happened, with stack trace and memory contents.

But there is one thing here, it doesn't work without the standard library
support. Of course, we can write that into our own lib (stlport?),
reinventing the wheel. But isn't it better to spend time on something
ReactOS-related, where there is no open source code available at all? (note:
I'm asking about who is going to do that)

And if we choose to incorporate libc++ into our project, which supports all
of that tooling out of the box for Windows, we have another problem
- it can't be compiled with ancient compilers.

So basically, the choice is simple - either we support building ReactOS with
old compilers (this is not only about MSVC2010, but for everything which
doesn't support modern-enough C++), or we benefit from modern tech for
dynamic and static code analysis. I prefer the latter.


Regards,
Victor






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

[Hermès BÉLUSCA-MAÏTO]

A detailed investigation would be needed for sure, but I am currently thinking 
about two things:

- some Vista+ functions being used (for example: GetTickCount64, some functions 
using the SRW locks …)

- the possible usage of apisets dlls.

In any case in order to cope with that in ROS, we would need the 
forwards-compatibility layer (almost) fully implemented, that can “activate” 
the support for these Vista+ features at runtime, for any program that requires 
it.

 

From: Ros-dev  On Behalf Of Magnus Johnsson
Sent: 2. prosinca 2020. 17:22
To: ReactOS Development List 
Subject: Re: [ros-dev] Status Meeting (November 2020)

 

Just a question from the outside here. If we look forward instead of backwards, 
what work would it take to make *just the command line build tools* work on 
reactos for newer versions?

Is that something to strive for? Is there a missing API, is it fundamentally 
incompatible in some way, is reactos 'target windows version' wrong..?

 

Den ons 2 dec. 2020 kl 11:14 skrev mailto:gedmurphy.mailli...@gmail.com> >:

I unfortunately don't get to contribute much anymore due to other commitments, 
so my view has little weight here, however I just wanted to throw my support 
behind Colin here in his effort to move the project forward.

Personally, I'd love to see reactos move to more modern standards, allowing 
more emphasis to be placed onto modern C++ and the benefits it brings:
- Support for scoped resources and RAII
- Better type checking
- Stronger use of const correctness
- Range based loops
- Use of bool and nullptr instead of BOOLEAN/BOOL and NULL
- Even use of the thing I hate the most ... auto 
- STL in user mode
- vectors, lists, etc
- NATVIS support to make the above easy to debug
- etc, etc, etc

I'm not advocating that these should be requirements, or to ever try to push 
devs to make use of them, but it would be incredibly useful to give developers 
the option if they prefer, as so many developers no do.

If it were me, I'd be tempted to drop VS2015 support too, only ever supporting 
the last two major toolchains from any compiler.

Ged.


-Original Message-
From: Ros-dev mailto:ros-dev-boun...@reactos.org> 
> On Behalf Of Colin Finck
Sent: 02 December 2020 08:07
To: ros-dev@reactos.org  
Subject: Re: [ros-dev] Status Meeting (November 2020)

> 1. Visual Studio 2010 is the last version that works (or almost works) 
> on ReactOS [...]
> 2. Dropping useful features is not really a good idea at all.

Oleg, nobody wants to take away any features here. VS2010 will continue 
to run on ReactOS now and in the future. This discussion is merely about 
*compiling ReactOS* with VS2010.

Everyone, please put personal preferences aside and think about the big 
picture:
We don't have the workforce Microsoft had when creating Windows XP.
The only way we can ever create a compatible OS is by leveraging modern 
technologies not yet available back then and building on the open-source 
work third parties have already done for us.
If we however decide to limit us to 10-year-old technologies now, we can 
do neither. Don't expect us to ever get this project into a usable state 
in a lifetime then.
The future of the project is at stake here!

I don't want to repeat myself, so let me just link to the reasoning I 
already gave:
* https://reactos.org/archives/public/ros-dev/2020-December/019158.html
* https://github.com/reactos/reactos/pull/2658#issuecomment-619540076
* https://github.com/reactos/reactos/pull/2658#issuecomment-629498043
* https://github.com/reactos/reactos/pull/2658#discussion_r427615924
* https://github.com/reactos/reactos/pull/2658#issuecomment-631113317


Best regards,

Colin Finck



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

[Hermès BÉLUSCA-MAÏTO]

What about that discussion about why we have ditched out MSVC 2010 support
(starting to depend on that fact, and thus, breaking any possibility of
self-hosting ROS building on ROS using MSVC compiler (without the IDE),
since later versions of MSVC only work on Vista+, and as an indirect
consequence, too, opening the can of worms, that is, being able to
"pollute", involuntarily or not, the ReactOS core code (kernel + drivers)
with C99+ non-standard portable code -- ),
and without having first warned heavily through all the mailing lists etc. ,
thus allowing the developers to voice their concerns publicly in the MLs ?
This was done around in mattermost only, after we decided for some reason
that we wouldn't need the VC2010 buildbots anymore.

Hermes.

-Original Message-
From: Ros-dev  On Behalf Of Colin Finck
Sent: Sun Nov 15 17:24:22 UTC 2020
To: ReactOS Development List 
Subject: [ros-dev] Status Meeting (November 2020)

Hi all,

With several people asking for a status meeting, let's have another one 
before the year is over.
Let me invite you to the meeting on

   Thursday, 26th November 2020
   19:00 UTC
   Mattermost private channel "Meeting"

So far, there is only one point on the agenda:

* Achievements and Future Outlook (everyone)
What have you been working on and what are your plans?

Please submit further agenda proposals by answering to this mail.


Looking forward to see you!

Colin


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

[ros-dev] MS Console/Terminal stuff (was: "RE: Ros-dev Digest, Vol 177, Issue 2")

[Hermès BÉLUSCA-MAÏTO]

Hi,

I’m trying to answer point by point.

 

1.   Their license is MIT. At least it allows us to borrow ideas from their 
code for how to implement stuff in ReactOS’ console/terminal. (I suppose that 
if one wants to copy entire chunks of code, that I wouldn’t do it, I’m not sure 
how the licensing of the original ReactOS console GPL code would have to 
change. But “I’m not a lawyer”. Anyway, copy-pasting stuff is never a good 
idea.)

2.   Yes but again you don’t need to care. It allows us to remain 
“original” in our way of implementing the things. What’s now “documented” 
however, is the interface between condrv and conhost (and to kernel32 if my 
quick reading of the shared headers is correct). This is sufficient. Then the 
internal implementation one can write for ReactOS is left free, this allows one 
to have original code and note a dull copy-paste.

3.   ReactOS doesn’t use C++ in the console, and won’t use ”WinRT” any time 
soon in its entire code-base. So forget about any direct import of the MS 
console code into ROS.

 

Regards,

Hermès

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Biswapriyo Nath
Envoyé : mardi 7 mai 2019 20:42
À : ros-dev@reactos.org
Objet : Re: [ros-dev] Ros-dev Digest, Vol 177, Issue 2

 

Some queries though:

1. There are many restrictions on how the code can be used. Are developers 
allowed to import the idea to ReactOS? Also with a different license.

2. The half of the codebase of console subsystem implemented in KernelBase and 
Kernel32. Those are not open source. Also the main magic happens in ConDrv 
driver.

3. The project has C++/WinRT code. Does ReactOS have that section?

Thank you <3 

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

[ros-dev] Microsoft open-sources its console / terminal code! (MIT-licensed)

[Hermès BÉLUSCA-MAÏTO]

Dear All,

 

Yes you've read correctly! Microsoft released the code of its terminal + the
Windows console host (conhost.exe) under MIT license at:

https://github.com/microsoft/Terminal

I think this is a really great move!! This can definitively help us for: 

*   first, allowing us to improve our existing console code,
*   and in the future, getting our console architecture Win10-compatible
(...)

 

This also means that anybody can contribute back to their code via
pull-requests, or at least creating issues.

 

For those using Windows 10, they plan releasing „official“ builds starting
June 2019 according to their posts:

https://devblogs.microsoft.com/commandline/introducing-windows-terminal/

https://www.hanselman.com/blog/ANewConsoleForWindowsItsTheOpenSourceWindowsT
erminal.aspx

 

Best,

Hermès

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

Re: [ros-dev] "[shell32] Shell dialog issues" .- CORE-10481

[Hermès BÉLUSCA-MAÏTO]

At least some people at MS / windows testers didn’t think it was a good idea, 
because on Windows 7 at least (I suppose it’s the same on Vista and on Windows 
10) these kind of property dialogs get again an entry in the taskbar.

H.

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Javier Agustìn 
Fernàndez Arroyo
Envoyé : dimanche 2 décembre 2018 20:34
À : ReactOS Development List
Objet : [ros-dev] "[shell32] Shell dialog issues" .- CORE-10481

 

Are you sure its better to follow Win behavior on this?

 

I think its a enhancement, specially if there are many open windows at a given 
time

 

it saves time!

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

Re: [ros-dev] Win8 theme for ReactOS?

[Hermès BÉLUSCA-MAÏTO]

Please don't include any "GreenteaOS" stuff in ReactOS!!

Hermès.

> -Message d'origine-
> De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de theUser BL
> Envoyé : samedi 8 septembre 2018 16:54
> À : ros-dev@reactos.org
> Objet : [ros-dev] Win8 theme for ReactOS?
> 
> A while ago I have asked in the forum, if the modified Lautus-theme of
> GreenteaOS could beintegrated in ReactOS
> https://www.reactos.org/forum/viewtopic.php?f=2=16788
> Sadly the theme is called in GreenteaOS Lautus, too. Here the source of it
> https://github.com/GreenteaOS/Deprecated/tree/master/third-
> party/reactos/media/themes/lautus.msstyles
> But it looks like Windows 8.
> 
> Here a screenshot of the Greentea Windows 8 like theme on ReactOS. Choose
> one link. I have uploaded it multiple times on multiple places, because some
> picture-uploading-sides delete its files from time to time
> 
> https://image.ibb.co/gTsPkU/Virtual_Box_React_OS_0_4_9_08_09_2018_16_2
> 2_18.png
> http://img4host.net/upload/081642005b93dfb8c233a.png
> https://img3.picload.org/image/dlpgdlow/virtualbox_reactos0.4.9_08_09_.png
> https://cdn3.imggmi.com/uploads/2018/9/8/e016c5a6842640ac5f7436ee2e9b
> 04e7-full.png
> https://i.imgur.com/mCUvsLy.png
> 
> EmuandCo is against the integration of the Win8-theme in ReactOS. But he is
> the only ReactOS-developer in the ReactOS-forum. So I now also ask here, what
> the other developers thinking about it.
> 
> Greetings
> theuserbl
> ___
> 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] Virtual consoles using ntvdm

[Hermès BÉLUSCA-MAÏTO]

Hi,

 

That’s on my plan, and this is certainly not to be done in ntvdm, as it’s 
indeed just another console app, so you would better implement your multiple 
consoles in winsrv.dll / win32k / whatever (actually the best way would be 
using a similar architecture as Win10).

 

Best,

Hermes

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Javier Agustìn 
Fernàndez Arroyo
Envoyé : mardi 4 septembre 2018 12:44
À : ReactOS Development List
Objet : [ros-dev] Virtual consoles using ntvdm

 

A crazy idea ..

 

 

What about implementing some kind of virtual consoles, just like Linux? The 
point is, using ntvdm subsystem, we could allow only console (DOS) apps to run 
in there. And some kind of "you are running a console. Switch to desktop to run 
this app!" Message is anyone tried to run another stuff

 

What do you think?

 

A side effect could be, allow remote connections, etc ... :)

 

 

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

Re: [ros-dev] [ros-diffs] 01/04: [REACTOS] RtlAssert(): use "%lu" as LineNumber format.

[Hermès BÉLUSCA-MAÏTO]

Yes ! Because for host-tools, on linux, %lu means unsigned long which may NOT 
be always == 32 bits.

> -Message d'origine-
> De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Michael
> Fritscher
> Envoyé : jeudi 9 août 2018 05:14
> À : ros-dev@reactos.org; Serge Gautherie; ros-di...@reactos.org
> Objet : Re: [ros-dev] [ros-diffs] 01/04: [REACTOS] RtlAssert(): use "%lu" as
> LineNumber format.
> 
> Moin,
> 
> On 08.08.2018 22:05, Serge Gautherie wrote:
> >
> https://git.reactos.org/?p=reactos.git;a=commitdiff;h=97d3b3ce3349fa87d01ee
> 29d0d08ff2ca8618a7d
> >
> > commit 97d3b3ce3349fa87d01ee29d0d08ff2ca8618a7d
> > Author: Serge Gautherie 
> > AuthorDate: Thu Jun 21 05:05:50 2018 +0200
> > Commit: Hermès Bélusca-Maïto 
> > CommitDate: Wed Aug 8 21:24:07 2018 +0200
> >
> > [REACTOS] RtlAssert(): use "%lu" as LineNumber format.
> > ---
> ...
> > -   if (NULL != Message)
> > -   {
> > -  DbgPrint("Assertion \'%s\' failed at %s line %d: %s\n",
> > -   (PCHAR)FailedAssertion,
> > -   (PCHAR)FileName,
> > -   LineNumber,
> > -   Message);
> > -   }
> > -   else
> > -   {
> > -  DbgPrint("Assertion \'%s\' failed at %s line %d\n",
> > -   (PCHAR)FailedAssertion,
> > -   (PCHAR)FileName,
> > -   LineNumber);
> > -   }
> > -
> > -   //DbgBreakPoint();
> > +if (Message != NULL)
> > +{
> > +DbgPrint("Assertion \'%s\' failed at %s line %u: %s\n",
> > + (PCHAR)FailedAssertion,
> > + (PCHAR)FileName,
> > + LineNumber,
> > + Message);
> > +}
> > +else
> > +{
> > +DbgPrint("Assertion \'%s\' failed at %s line %u\n",
> > + (PCHAR)FailedAssertion,
> > + (PCHAR)FileName,
> > + LineNumber);
> > +}
> > +
> > +//DbgBreakPoint();
> >  }
> >
> >  // DECLSPEC_NORETURN
> >
> 
> here no %lu, but only %u?
> 
> Best regards,
> Michael Fritscher
> 
> ___
> 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] Postponing the July Meeting

[Hermès BÉLUSCA-MAÏTO]

And MVDM etc... 

> -Message d'origine-
> De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Giannis
> Adamopoulos
> Envoyé : jeudi 2 août 2018 09:11
> À : Ged Murphy; ReactOS Development List
> Objet : Re: [ros-dev] Postponing the July Meeting
> 
> Hi,
> I really like this idea. Actually i was thinking something similar about user 
> mode
> apps like paint or even the file browser of the shell which can be used from
> windows xp to windows 10. (You need just these three files from us:
> filebrowser.exe, rshell.dll and browseui.dll).
> 
> 
> Ged Murphy  wrote on Wed, August 1st,
> 2018, 11:30 PM:
> > 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 

Re: [ros-dev] Postponing the July Meeting

[Hermès BÉLUSCA-MAÏTO]

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


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

[ros-dev] Repetitive "shell submit results failed" errors when running testbot manually

[Hermès BÉLUSCA - MAÏTO]

Hello!

I repeatedly get an error "shell submit results failed" while trying to run 
testbot on a PR patch, see for example 
https://build.reactos.org/builders/Test%20KVM/builds/20818
and as a result I cannot obtain the results under reactos.org/testman .

Can someone investigate what is going on?

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

Re: [ros-dev] [ros-diffs] 01/01: [WIN32SS] Fix NtUserGetClipboardData for text paste (#645)

[Hermès BÉLUSCA-MAÏTO]

Hello,

This commit, as well as the following one: 
0a8cd95cad36e7518ddb7256b3af9169789285f7 - "[USERINIT][EXPLORER] Fix auto 
startup of Start Menu (#594)"
that caused the apparition of a strange timeout during the "kernel32 : 
ConsoleCP" test (has been investigated by Mark, see 
https://jira.reactos.org/browse/CORE-14763 )
seems to expose an already-existing bug in win32k related to window painting.

Indeed, the problems appear to be fixed by this PR: 
https://github.com/reactos/reactos/pull/674
and fixes the testbots as you can see:
https://build.reactos.org/builders/Test%20KVM/builds/20737
https://build.reactos.org/builders/Test%20KVM/builds/20738

If everything goes well, I will commit the PR during the weekend.

Best regards,
Hermès

> -Message d'origine-
> De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Pierre
> Schweitzer
> Envoyé : mercredi 4 juillet 2018 07:41
> À : ros-dev@reactos.org; Katayama Hirofumi MZ
> Objet : Re: [ros-dev] [ros-diffs] 01/01: [WIN32SS] Fix NtUserGetClipboardData
> for text paste (#645)
> 
> For the record, that commit seems to have broken ReactOS testing (see
> testman, which records last successful test run for 2170901, ie, previous
> commit).
> 
> Starting with that commit, any regression test run never ends.
> It seems bug reports have been creating regarding regressions (timeouts) in
> the tests but got ignored so far.
> 
> It would be great to fix these before pushing any other commits.
> 
> Cheers,
> Pierre
> 
> Le 30/06/2018 à 17:12, Katayama Hirofumi MZ a écrit :
> > https://git.reactos.org/?p=reactos.git;a=commitdiff;h=6abc9f5b5af6cc7b
> > 7c57ff9c6bcc4a919cf85d1e
> >
> > commit 6abc9f5b5af6cc7b7c57ff9c6bcc4a919cf85d1e
> > Author: Katayama Hirofumi MZ 
> > AuthorDate: Sun Jul 1 00:12:23 2018 +0900
> > Commit: Hermès BÉLUSCA - MAÏTO 
> > CommitDate: Sat Jun 30 17:12:23 2018 +0200
> >
> > [WIN32SS] Fix NtUserGetClipboardData for text paste (#645)
> >
> > Fix the NtUserGetClipboardData function for the synthesized text formats
> (CF_TEXT, CF_OEMTEXT and CF_UNICODETEXT).
> > CORE-11471
> > --- 
> 
> --
> 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] [ros-diffs] 01/01: [USERSRV] HardError: Fix compilation warning; fix few comments; fix the default empty window title string.

[Hermès BÉLUSCA-MAÏTO]

This change (on my own code snippet btw, see commit 5a1a35ca5a6) was necessary 
because otherwise, the StringPrintf call that is done below (which would then 
use a WindowTitleU.Buffer == NULL) would generate the harderror dialog title: 
"(null)" (in addition to other strings being appended), instead of just an 
empty string.
And so the bug is that I forgot to adjust the condition that needs to be 
checked before freeing the window title string (if it has been allocated).

Hermès

> -Message d'origine-
> De : Thomas Faber [mailto:thomas.fa...@reactos.org]
> Envoyé : samedi 9 juin 2018 09:21
> À : ros-dev@reactos.org; Hermès Bélusca-Maïto
> Objet : Re: [ros-diffs] 01/01: [USERSRV] HardError: Fix compilation warning;
> fix few comments; fix the default empty window title string.
> 
> On 2018-04-08 16:17, Hermès Bélusca-Maïto wrote:
> >   /* Retrieve the window title of the client, if it has one */
> > -RtlInitEmptyUnicodeString(, NULL, 0);
> > +RtlInitEmptyUnicodeString(, L"", 0);
> 
> This looks like a bug. Can you explain why you think it's necessary please?
> 
> In particular, it will break this:
> 
> if (WindowTitleU.Buffer) RtlFreeUnicodeString();
> 
> 
> Thanks,
> Thomas


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

Re: [ros-dev] [ros-diffs] 02/08: [NTOSKRNL] Forbid processes without the Tcb prvilege to perform a user-mode hard-error BSOD.

[Hermès BÉLUSCA-MAÏTO]

Yes, to only allow programs that REALLY REALLY REALLY REALLY ….. need to do so 
to trigger the hard-error “shutdown” BSOD from user-mode to do so, and these 
programs would better be only those that run only in SYSTEM rights, and more 
exactly these include CSRSS, WINLOGON and SMSS when something very bad happen 
to them.

I would not appreciate, for example, that when I run a program under a not-so 
privileged account (like, some random user account) that has just the shutdown 
privilege to shut the computer down properly, that this program suddently 
“BSODS” my machine.

To these programs, I say “f$ck these!”

 

Regards,

Hermès

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Alex Ionescu
Envoyé : lundi 2 avril 2018 04:20
À : ReactOS Development List; Hermès Bélusca-Maïto
Cc : Linda Wang
Objet : Re: [ros-dev] [ros-diffs] 02/08: [NTOSKRNL] Forbid processes without 
the Tcb prvilege to perform a user-mode hard-error BSOD.

 

Is there a point to this blatant behavior change?




Best regards,
Alex Ionescu

 

On Sun, Apr 1, 2018 at 3:04 PM, Hermès Bélusca-Maïto 
<hermes.belusca-ma...@reactos.org> wrote:

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

commit f0729b30bb79d6f538cf2b9578ff8ebe7989f8d3
Author: Hermès Bélusca-Maïto <hermes.belusca-ma...@reactos.org>
AuthorDate: Sun Apr 1 14:46:19 2018 +0200
Commit: Hermès Bélusca-Maïto <hermes.belusca-ma...@reactos.org>
CommitDate: Sun Apr 1 22:39:31 2018 +0200

[NTOSKRNL] Forbid processes without the Tcb prvilege to perform a user-mode 
hard-error BSOD.
---
 ntoskrnl/ex/harderr.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/ntoskrnl/ex/harderr.c b/ntoskrnl/ex/harderr.c
index 84f409a1bb..a5200e3e74 100644
--- a/ntoskrnl/ex/harderr.c
+++ b/ntoskrnl/ex/harderr.c
@@ -132,8 +132,18 @@ ExpRaiseHardError(IN NTSTATUS ErrorStatus,
 /* Check if this error will shutdown the system */
 if (ValidResponseOptions == OptionShutdownSystem)
 {
-/* Check for privilege */
-if (!SeSinglePrivilegeCheck(SeShutdownPrivilege, PreviousMode))
+/*
+ * Check if we have the privileges.
+ *
+ * NOTE: In addition to the Shutdown privilege we also check whether
+ * the caller has the Tcb privilege. The purpose is to allow only
+ * SYSTEM processes to "shutdown" the system on hard errors (BSOD)
+ * while forbidding regular processes to do so. This behaviour differs
+ * from Windows, where any user-mode process, as soon as it has the
+ * Shutdown privilege, can trigger a hard-error BSOD.
+ */
+if (!SeSinglePrivilegeCheck(SeTcbPrivilege, PreviousMode) ||
+!SeSinglePrivilegeCheck(SeShutdownPrivilege, PreviousMode))
 {
 /* No rights */
 *Response = ResponseNotHandled;

 

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

Re: [ros-dev] [ros-diffs] 01/01: [WINLOGON] Clean up part 2 - Replace the UNICODE_STRING usMessage by a PWSTR pszMessage. - Use the "%02d:%02d:%02d" time format and get rid of the safe string printf b

[Hermès BÉLUSCA-MAÏTO]

If I remember correctly you can make shutdowns delayed of many days on Windows 
(using the InitiateSystemShutdown(Ex) function), in which case the 2-digit hour 
won't work at all.

Best,
Hermès

> -Message d'origine-
> De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Thomas
> Faber
> Envoyé : lundi 2 avril 2018 14:13
> À : Eric Kohl
> Cc : ros-dev@reactos.org
> Objet : Re: [ros-dev] [ros-diffs] 01/01: [WINLOGON] Clean up part 2 - Replace
> the UNICODE_STRING usMessage by a PWSTR pszMessage. - Use the
> "%02d:%02d:%02d" time format and get rid of the safe string printf because
> the string will NEVER be longer than 8 character
> 
> Hey Eric,
> 
> On 2018-04-02 12:58, Eric Kohl wrote:
> > -RtlStringCbPrintfW(strbuf, sizeof(strbuf), L"%d:%d:%d", hours, minutes,
> seconds);
> > +swprintf(szBuffer, L"%02d:%02d:%02d", iHours, iMinutes,
> > + iSeconds);
> 
> Unfortunately I must disagree with this change.
> 
> Buffer overflows are a big enough threat that code review and static analysis
> are not generally considered sufficient to protect against them.
> So it's best practice for new code to always verify sizes at run-time, and
> never to use s(w)print.
> 
> Best regards,
> Thomas
> 
> PS: from what I see, iHours can be as large as 1193046, which won't
>  fit in 2 digits
> 
> ___
> 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] RFC: Change Rapps 'Size' field

[Hermès BÉLUSCA-MAÏTO]

Two possibilities :

-  Either have : « Size = 1.345.123 » with no units, it’s in bytes, 
otherwise it is a string to be displayed. I wonder if that already breaks 
backwards compatibility with old versions of rapps… But then these old versions 
of rapps may or may not be able to connect to the new web service we are 
preparing for the databases? (in which case we don’t have to care too much 
about them)

-  Or just use some “ SizeInBytes = 1.345.123 ” field. It’s clear, and 
you just read that value and use the shell function you pointed in your 
previous mail to format it in MB or whatever.

 

Hermès

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de David Quintana 
(gigaherz)
Envoyé : jeudi 8 février 2018 21:03
À : ReactOS Development List
Objet : Re: [ros-dev] RFC: Change Rapps 'Size' field

 

https://github.com/reactos/rapps-db/blob/master/7zip.txt#L6

 

On 8 February 2018 at 21:00, Hermès BÉLUSCA-MAÏTO <hermes.belu...@sfr.fr> wrote:

What 'size' field are you exactly talking about?

> -Message d'origine-
> De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Mark Jansen
> Envoyé : jeudi 8 février 2018 20:43
> À : ros-dev@reactos.org
> Objet : [ros-dev] RFC: Change Rapps 'Size' field

>
> Hello,
>
> I'd like to propose a change for the 'Size' field:
> Currently this is a localized, pre-formatted field.
> By changing this to the actual size in bytes:
> - We can use StrFormatByteSizeW to format it locale dependent (without the
> need to manually translate it)
> - We can use this value to display the progress bar, in case the download 
> itself
> does not provide this value (for example, web.archive does not provide this).
>
> For backwards compatibility we should probably add this as another field, so
> that the 'old' rapps can still read the 'Size' field.
>
> Regards,
>
> Mark
>
>
> ___
> 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] RFC: Change Rapps 'Size' field

[Hermès BÉLUSCA-MAÏTO]

What 'size' field are you exactly talking about?

> -Message d'origine-
> De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Mark Jansen
> Envoyé : jeudi 8 février 2018 20:43
> À : ros-dev@reactos.org
> Objet : [ros-dev] RFC: Change Rapps 'Size' field
> 
> Hello,
> 
> I'd like to propose a change for the 'Size' field:
> Currently this is a localized, pre-formatted field.
> By changing this to the actual size in bytes:
> - We can use StrFormatByteSizeW to format it locale dependent (without the
> need to manually translate it)
> - We can use this value to display the progress bar, in case the download 
> itself
> does not provide this value (for example, web.archive does not provide this).
> 
> For backwards compatibility we should probably add this as another field, so
> that the 'old' rapps can still read the 'Size' field.
> 
> Regards,
> 
> Mark
> 
> 
> ___
> 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] Making bluescreens more useful

[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] Making bluescreens more useful

[Hermès BÉLUSCA-MAÏTO]

Let’s bring the NT-4-type BSODs back!! \o/

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de David Quintana 
(gigaherz)
Envoyé : jeudi 11 janvier 2018 00:53
À : ReactOS Development List
Objet : Re: [ros-dev] Making bluescreens more useful

 

Looks nice!

 

On 11 January 2018 at 00:48, Thomas Faber  wrote:

We often get bug reports with just a screenshot of a bluescreen; we then
go ahead and tell people that bluescreens are basically useless, they
should get a debug log and a backtrace, and also remember to tell us
what version they're using.

Since there's actually no reason why bluescreens need to be useless, I
thought I'd try to change that.
I've attached an example. The source for this quick PoC can be found at
https://github.com/ThFabba/reactos/commit/6a9f172b76bd11f763598c16e5d47299eec1971c

Thoughts?

___
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] *PREVIEW* : ReactOS 1st-stage GUI installer testing on Windows

[Hermès BÉLUSCA-MAÏTO]

Hello everyone,

 

Lately I was continuing working on my “setup_improvements” branch:
https://github.com/HBelusca/reactos/commits/setup_improvements

(whose main purpose, I recall, is to share a maximum of installation code
between our working 1st-stage text-mode usetup and our 1st-stage GUI-mode
“reactos.exe” setup that needs to be implemented).

The last results of this is that I am now able to install ReactOS files to a
user-provided directory using the GUI-mode setup!

As I’m developing under Windows I tested the file-copying part of the
installer (which is, at the time of writing, the latest part of installation
code I has been able to share between the two installers) on Windows.

 

You can see the demo here: https://i.imgur.com/xF97hv1.gifv

 

The animated gif also demonstrates the capability of the installer to halt
file copying if the user pops the “installation-cancel” confirmation dialog
out; file-copying is resumed when the user does not want to cancel the
installation, but it is stopped when the user really cancels the
installation.

And of course, the file-copying status is displayed with an animated
progress-bar.

I have worked out a bit the wizard transitions, but some work remains to be
done, especially for the partitioning step (currently I’m hardcoding in the
GUI installer the disk & partition where I want the copy to take place).

 

One can note in the animation that the preparation of the list of files to
be copied seems to take a while: indeed, the shared installation code works
exclusively with NT paths. However, when this shared code is used in the
win32 GUI-mode installer, this code calls inside setupapi.dll functions to
manage the installation file queue (in usetup on the contrary, it uses
instead a file queue implementation that works directly with NT paths). As a
consequence, I need to convert the NT paths back to Win32 ones before
feeding them into the setupapi functions, and this is not trivial. I want to
improve this conversion by caching some of the computed results.

 

Enjoy!

 

Best regards,

Hermès

 

P.S.: Please don’t put that on Twitter since this is under heavy
work-in-progress and this demo hasn’t been done under ReactOS at all.

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

Re: [ros-dev] Merging our x86 HALs

[Hermès BÉLUSCA-MAÏTO]

That's why I'm extremely in favour of keeping the HAL x86 Standard PC 
mono-processor separate from the other hals (I mean, as a separate dll).
But if you find inside some code that can be shared with the ACPI/APIC/whatever 
other hal, then just share it! (maybe use some #ifdefs inside as long as it 
doesn't imply recopying twice the file contents into the ifdef blocks).

Regards

> -Message d'origine-
> De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Michael
> Fritscher
> Envoyé : mercredi 13 décembre 2017 23:06
> À : ros-dev@reactos.org
> Objet : Re: [ros-dev] Merging our x86 HALs
> 
> Hi,
> 
> I think that at least merging most of the versions shouldn't be a big problem.
> We could go Win8's way. Is there a rough estimation, how much is the
> distribution of common code, code for new HW only and code für old HW only?
> 
> To be honest, I don't think that much space will be wasted in the 
> installation or
> during runtime if we merge all (generic) hals to one.
> 
> If I understand it correctly, even on modern HW we need most of the "old"
> ways for initialization. The biggest waste should be the ACPI infrastructure 
> on
> very(!) old HW. And this is how many KB on RAM? 200KB?
> 
> Btw, ACPI went into the mass market ca. 1998. On these days, 32 MB RAM
> were normal. ReactOS wouldn't even boot on these machines.
> 
> Best regards,
> Michael Fritscher
> 
> 
> ___
> 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] PineappleFund

[Hermès BÉLUSCA-MAÏTO]

… Because OpenBSD is ?

 

 
https://www.reddit.com/r/Bitcoin/comments/7jj0oa/im_donating_5057_btc_to_charitable_causes/dr6pabe/

 

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de David Quintana 
(gigaherz)
Envoyé : mercredi 13 décembre 2017 20:55
À : ReactOS Development List
Objet : Re: [ros-dev] PineappleFund

 

We are not a charity, though...

 

On 13 December 2017 at 20:52, Alexander Shaposhnikov  
wrote:

Hi all!
Recenly a new Reddit post came up on #reactos IRC:
https://redd.it/7jj0oa. Interesting stuff.

A person is giving away ~5000 BTC for charitable causes. We can apply
via the website but it must be done by someone from ReactOS e.V.

--
Cheers,
Alexander Shaposhnikov



___
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] Merging our x86 HALs

[Hermès BÉLUSCA-MAÏTO]

To remember what the ReactOS project is about : it’s about recreating Windows 
in open-source and trying not to do the same mistakes as the non-open-source 
counterpart, i.e. having it work only on the newest of the newest computers.

 

And also, it’s not like if the HAL PIC x86 UP would suddently not work anymore: 
its “maintenance” is very minimal (bug fixes).

 

Otherwise, Alex’ idea of two HALs sounds nice.

 

Regards,

Hermès

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Riccardo Paolo 
Bestetti
Envoyé : mardi 12 décembre 2017 22:01
À : ReactOS Development List
Objet : Re: [ros-dev] Merging our x86 HALs

 

My bi-annual IT guy peak:

 

Is there a real need to?

I think not.

 

B.R.

Riccardo P. Bestetti

 

From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Javier Agustìn 
Fernàndez Arroyo
Sent: martedì 12 dicembre 2017 18:13
To: ReactOS Development List <ros-dev@reactos.org>
Subject: Re: [ros-dev] Merging our x86 HALs

 

Win8 does not support old hardware as ReactOS do!

 

El 12 dic. 2017 17:52, "Alex Ionescu" <ion...@videotron.ca> escribió:

I would move to the Win8+ HAL Model -- a single HAL for APIC, ACPI with runtime 
support for UEFI (if present) and MP (if present).

 

If people still want to run on a PIC VM (why???) or old computer, then we can 
also maintain the HAL PIC x86 for UP.

 

Hence there would only be 2 HALs.




Best regards,
Alex Ionescu

 

On Mon, Dec 11, 2017 at 1:07 AM, Colin Finck <co...@reactos.org> wrote:

Am 11.12.2017 um 01:18 schrieb Hermès BÉLUSCA-MAÏTO:> If you basically
put all the HALs into one, then you obtain bloated stuff (which remains
in memory for the whole life of the OS). Example: standard HAL is 1MB
vs. ACPI HAL which is few kBHave you actually checked what makes up this
difference?
Hint: hal/halx86/legacy/bus/pci_vendors.ids


> Note that if Windows nowadays has only one hal, it's because they now support 
> basically only one "architecture"/platform, namely, ACPI multiprocessor (to 
> put it simple). It has its pros, but also a lot of cons.

That doesn't mean we need to do the same. We can have one HAL for all
(Pentium and newer) x86 platforms. The overhead of additional checks at
boot-up is negligible. That should be a solution for 99% of the people
out there. The rest may still go and trim down our HAL to their needs.

But let's not pretend we can maintain multiple x86 HALs for all x86
computers out there. Do you really want to test X HALs with Y different
systems? Ensure that a legacy HAL runs on a modern ACPI system? What
would be the point?


> Besides this, I've a question about your observation that in the APIC hal 
> (not ACPI) there's different implementation of HalpCalibrateStallExecution 
> and HalpInitializePICs / HalpInitializeLegacyPIC . Isn't it precisely because 
> these stuff are completely different from the standard PICs used in platforms 
> for which the standard HAL (and possibly the ACPI HAL) are used?

Absolutely not! You need to reprogram the standard PICs also on an APIC
system, and this is precisely what both functions do. Put them into a
diff tool to see for yourself.

The same goes for timers. Even with the introduction of ACPI Timers,
Local APIC Timers, and Time-Stamp Counters, you still need a traditional
one (like RTC or PIT) for calibration at system startup. Simply because
the newer ones don't run at a known fixed frequency.
The Legacy HAL successfully employs an algorithm based on the RTC while
the APIC HAL unsuccessfully tries to use the PIT.


> Actually we should, because the detection might not work (of course in our 
> simple case "ACPI UP/MP" vs. "Standard", it's simple, but think about other 
> platforms where there can be subtle differences)

Tell me about a single one we cannot detect and which is worth to
support. I don't recall that we ever recommended our testers to choose a
different HAL at setup.


> And normally it's not the setup that decides about the HAL, but the 
> bootloader.

That defies your previous point about the setup initializing the
registry depending on the HAL.
If we can let the user select a Legacy HAL in the boot loader after
installing with an ACPI HAL, it is also technically possible to have one
HAL that encompasses both.



- Colin

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

 


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

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

Re: [ros-dev] Merging our x86 HALs

[Hermès BÉLUSCA-MAÏTO]

Actually, this is parts of the HKLM\SYSTEM\ControlSet00x\Enum tree that are 
subject to the remark I made about HKLM\HARDWARE in my previous mail, while the 
HARDWARE hive is actually volatile (thus regenerated each time at boot).

H.

> -Message d'origine-
> De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Hermès
> BÉLUSCA-MAÏTO
> Envoyé : lundi 11 décembre 2017 02:03
> À : 'ReactOS Development List'
> Objet : Re: [ros-dev] Merging our x86 HALs
> 
> Also, there is (at least parts of) HKLM\HARDWARE tree that is built at
> installation time from info obtained from the HAL that is suitable for your
> platform, and that will be used for the rest of the life of your
> Windows/ReactOS/... installation. So if you then think that you'll be able to 
> use
> "the same ReactOS installation [...] on several different x86 computers" (to
> quote you), it'll be a bit more complicated than that
> 
> Besides this, I've a question about your observation that in the APIC hal (not
> ACPI) there's different implementation of HalpCalibrateStallExecution and
> HalpInitializePICs / HalpInitializeLegacyPIC . Isn't it precisely because 
> these
> stuff are completely different from the standard PICs used in platforms for
> which the standard HAL (and possibly the ACPI HAL) are used?
> 
> For your x2APIC question, if this shares a good stuff wrt. APIC, then either 
> it
> would be inside the same APIC HAL, otherwise there could be two HALs, APIC
> and the other one, but made from common "generic" code + different code
> that depend on the APIC vs. x2APIC.
> 
> > The user is also able to select a custom HAL during setup, even if it 
> > wouldn't
> work on the machine. We should give neither the user nor the setup the ability
> to decide. The HAL itself knows best at boot-up what features to enable and
> what not.
> 
> Actually we should, because the detection might not work (of course in our
> simple case "ACPI UP/MP" vs. "Standard", it's simple, but think about other
> platforms where there can be subtle differences), AND the fact that an
> advanced user may want to specify one's HAL. And normally it's not the setup
> that decides about the HAL, but the bootloader. The bootloader (ntldr / 
> winldr)
> also has the capability of detecting the HAL to use and load, unless being
> specified otherwise by a switch in the command-lines in boot.ini (ntldr) or
> somewhere in the BCD (bootmgr/winldr).
> 
> H.
> 
> > -Message d'origine-
> > De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Hermès
> > BÉLUSCA-MAÏTO Envoyé : lundi 11 décembre 2017 01:18 À : 'ReactOS
> > Development List'
> > Objet : Re: [ros-dev] Merging our x86 HALs
> >
> > I personally think it's a bit "against" the philosophy of HALs, namely
> > having a lightweight hardware abstraction layer code for different 
> > platforms.
> > If you basically put all the HALs into one, then you obtain bloated
> > stuff (which remains in memory for the whole life of the OS). Example:
> > standard HAL is 1MB vs. ACPI HAL which is few kB.
> > A bit more work and you could even get a monolithic kernel! Nah joking xD 
> > ...
> > but not completely.
> >
> > Note that if Windows nowadays has only one hal, it's because they now
> > support basically only one "architecture"/platform, namely, ACPI
> > multiprocessor (to put it simple). It has its pros, but also a lot of cons.
> >
> > To solve the original problem you have encountered in our code, just
> > introduce common/generic .c files containing the code that is similar
> > everywhere, even at the level of all the hals, or at the level of
> > (let's say) a given CPU "type" (x86, x64...), then there are the other
> > .c that implement the different flavours of the procedures that depend on 
> > the
> specific arch/platform.
> >
> > Like this:
> >
> > HALs
> > + Generic code
> > + HAL for a given arch #1 (e.g. x86)
> > | + Generic code for this arch
> > | + Code for standard (non-ACPI) HAL
> > | + Code for ACPI HAL
> > | + Code for a different HAL flavour (platform)?
> > | + ...
> > |
> > + HAL for arch #2
> > | + Generic code
> > | + Code for platform
> > | + Code for second platform
> > | + ...
> > |
> > + etc...
> >
> > This is very clear and maintainable.
> >
> > H.
> >
> > > -Message d'origine-
> > > De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part

Re: [ros-dev] Merging our x86 HALs

[Hermès BÉLUSCA-MAÏTO]

Also, there is (at least parts of) HKLM\HARDWARE tree that is built at 
installation time from info obtained from the HAL that is suitable for your 
platform, and that will be used for the rest of the life of your 
Windows/ReactOS/... installation. So if you then think that you'll be able to 
use "the same ReactOS installation [...] on several different x86 computers" 
(to quote you), it'll be a bit more complicated than that

Besides this, I've a question about your observation that in the APIC hal (not 
ACPI) there's different implementation of HalpCalibrateStallExecution and 
HalpInitializePICs / HalpInitializeLegacyPIC . Isn't it precisely because these 
stuff are completely different from the standard PICs used in platforms for 
which the standard HAL (and possibly the ACPI HAL) are used?

For your x2APIC question, if this shares a good stuff wrt. APIC, then either it 
would be inside the same APIC HAL, otherwise there could be two HALs, APIC and 
the other one, but made from common "generic" code + different code that depend 
on the APIC vs. x2APIC.

> The user is also able to select a custom HAL during setup, even if it 
> wouldn't work on the machine. We should give neither the user nor the setup 
> the ability to decide. The HAL itself knows best at boot-up what features to 
> enable and what not.

Actually we should, because the detection might not work (of course in our 
simple case "ACPI UP/MP" vs. "Standard", it's simple, but think about other 
platforms where there can be subtle differences), AND the fact that an advanced 
user may want to specify one's HAL. And normally it's not the setup that 
decides about the HAL, but the bootloader. The bootloader (ntldr / winldr) also 
has the capability of detecting the HAL to use and load, unless being specified 
otherwise by a switch in the command-lines in boot.ini (ntldr) or somewhere in 
the BCD (bootmgr/winldr).

H.

> -Message d'origine-
> De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Hermès
> BÉLUSCA-MAÏTO
> Envoyé : lundi 11 décembre 2017 01:18
> À : 'ReactOS Development List'
> Objet : Re: [ros-dev] Merging our x86 HALs
> 
> I personally think it's a bit "against" the philosophy of HALs, namely having 
> a
> lightweight hardware abstraction layer code for different platforms.
> If you basically put all the HALs into one, then you obtain bloated stuff 
> (which
> remains in memory for the whole life of the OS). Example: standard HAL is
> 1MB vs. ACPI HAL which is few kB.
> A bit more work and you could even get a monolithic kernel! Nah joking xD ...
> but not completely.
> 
> Note that if Windows nowadays has only one hal, it's because they now support
> basically only one "architecture"/platform, namely, ACPI multiprocessor (to 
> put
> it simple). It has its pros, but also a lot of cons.
> 
> To solve the original problem you have encountered in our code, just introduce
> common/generic .c files containing the code that is similar everywhere, even
> at the level of all the hals, or at the level of (let's say) a given CPU 
> "type" (x86,
> x64...), then there are the other .c that implement the different flavours of 
> the
> procedures that depend on the specific arch/platform.
> 
> Like this:
> 
> HALs
> + Generic code
> + HAL for a given arch #1 (e.g. x86)
> | + Generic code for this arch
> | + Code for standard (non-ACPI) HAL
> | + Code for ACPI HAL
> | + Code for a different HAL flavour (platform)?
> | + ...
> |
> + HAL for arch #2
> | + Generic code
> | + Code for platform
> | + Code for second platform
> | + ...
> |
> + etc...
> 
> This is very clear and maintainable.
> 
> H.
> 
> > -Message d'origine-
> > De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Colin
> > Finck Envoyé : dimanche 10 décembre 2017 19:55 À : ros-dev@reactos.org
> > Objet : Re: [ros-dev] Merging our x86 HALs
> >
> > Am 10.12.2017 um 19:38 schrieb David Quintana (gigaherz):
> > > Colin: Are we talking merge and decide which method to use at
> > > runtime
> >
> > Exactly! We don't even need boot flags: Just like the setup currently
> > detects an ACPI-compliant computer, the HAL could do this at boot-up.
> > It's also not too hard to detect the presence of an APIC.
> >
> > I think a universal HAL for every x86 machine wouldn't be noticeably
> > larger than an ACPI+SMP HAL.
> >
> >
> > - Colin
> >
> > ___
> > Ros-dev mailing list
> > Ros-dev@reactos.org
> > http://www.reactos.org/mailman/listinfo/ros-dev
> 
> 
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev


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

Re: [ros-dev] Merging our x86 HALs

[Hermès BÉLUSCA-MAÏTO]

I personally think it's a bit "against" the philosophy of HALs, namely having a 
lightweight hardware abstraction layer code for different platforms.
If you basically put all the HALs into one, then you obtain bloated stuff 
(which remains in memory for the whole life of the OS). Example: standard HAL 
is 1MB vs. ACPI HAL which is few kB.
A bit more work and you could even get a monolithic kernel! Nah joking xD ... 
but not completely.

Note that if Windows nowadays has only one hal, it's because they now support 
basically only one "architecture"/platform, namely, ACPI multiprocessor (to put 
it simple). It has its pros, but also a lot of cons.

To solve the original problem you have encountered in our code, just introduce 
common/generic .c files containing the code that is similar everywhere, even at 
the level of all the hals, or at the level of (let's say) a given CPU "type" 
(x86, x64...), then there are the other .c that implement the different 
flavours of the procedures that depend on the specific arch/platform.

Like this:

HALs
+ Generic code
+ HAL for a given arch #1 (e.g. x86)
| + Generic code for this arch
| + Code for standard (non-ACPI) HAL
| + Code for ACPI HAL
| + Code for a different HAL flavour (platform)?
| + ...
|
+ HAL for arch #2
| + Generic code
| + Code for platform
| + Code for second platform
| + ...
|
+ etc...

This is very clear and maintainable.

H.

> -Message d'origine-
> De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Colin Finck
> Envoyé : dimanche 10 décembre 2017 19:55
> À : ros-dev@reactos.org
> Objet : Re: [ros-dev] Merging our x86 HALs
> 
> Am 10.12.2017 um 19:38 schrieb David Quintana (gigaherz):
> > Colin: Are we talking merge and decide which method to use at runtime
> 
> Exactly! We don't even need boot flags: Just like the setup currently detects 
> an
> ACPI-compliant computer, the HAL could do this at boot-up.
> It's also not too hard to detect the presence of an APIC.
> 
> I think a universal HAL for every x86 machine wouldn't be noticeably larger
> than an ACPI+SMP HAL.
> 
> 
> - Colin
> 
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev


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

[ros-dev] Question about commits with no commit log, or commits with no files but just the log, on Git.

[Hermès BÉLUSCA - MAÏTO]

‌Hello all,

After having noticed 
https://github.com/reactos/reactos/commit/50ae5e7c5268222718174221366169e2b115b06a
I am wondering whether it is possible to add mechanisms (like git pre-commit 
hooks) that check for, and
prevent potential problematic commits like, commits without commit log, or 
commits with no files (but with a log).

Any ideas?

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

Re: [ros-dev] Git Migration: The documentation, rossubsys and wallpapers directories

[Hermès BÉLUSCA-MAÏTO]

Hi!

> * Commits to "documentation" never had a relation to "reactos" commits, so
> nothing is lost if we put that directory into a separate repo
> "documentation.git" and remove all traces to it from the history of
> "reactos.git". I'd go this way if there are no objections.
> 
Yeah, I see that as a separate "project" (documentation), separated from the 
ROS source.

> * I don't get the idea of that "rossubsys" directory created in 2014..
> These subsystems are all stubs, never built with modern ReactOS, and no
> work has happened since "reviving" them. I would just go and remove them
> again. You can always find them in our repository history.
> 
As long as they can be found easily in the history, then ok. Alternatively, as 
a separate "project" they can be found... (the "reactos" github account can 
have other repos I suppose?)

> * The "wallpapers" directory is a harder candidate.
> On the one hand, we don't want to bloat our ReactOS builds by including
> wallpapers in every build. Also the number of wallpapers may increase in the
> future, which could bloat the "reactos.git" repo even more.
> On the other hand, the wallpapers have always accompanied our release
> branches, so there is a value of having them tracked next to our code.
> 
Again, same, it's some heavy multimedia thingie.

> But then again, how are they picked
> up by the build process in the future if we can't check them out into a
> subdirectory of "modules"?
>
The builder(s) can have a "working" directory, in which they check-out the 
different "projects" they need for the build: reactos source can be DL'ed into 
"working/reactos.git" ; the wallpapers, rostests etc... can be DL'ed into 
"working/rostests" and "working/wallpapers", then symlinks (OK on *nix & 
windows) into the "working/reactos.git/modules" can be created that point to 
"working/wallpapers" and "working/rostests" , and then we build as usual ?

Cheers,
Hermès


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

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

[Hermès BÉLUSCA-MAÏTO]

What about the « Whistler » - like theme ? ^^

 

H.

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Mark Jansen
Envoyé : lundi 31 juillet 2017 17:18
À : ReactOS Development List
Objet : Re: [ros-dev] Enabling themes in 3rd stage

 

I like this theme!

 

Op 31 jul. 2017 16:44 schreef "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

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

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

[Hermès BÉLUSCA-MAÏTO]

Hi all, that’s good !

I would also prefer a page in 2nd-stage setup where we can choose whether we 
want to use “classic theme” (aka no theming), or any other theme we may have.

 

Hermès.

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de encoded
Envoyé : lundi 31 juillet 2017 16:36
À : ReactOS Development List
Objet : Re: [ros-dev] Enabling themes in 3rd stage

 

Add page in 2nd stage setup to select themes

 

On Mon, Jul 31, 2017 at 10:29 AM, Giannis Adamopoulos 
 wrote:

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

[Hermès BÉLUSCA-MAÏTO]

Thank you guys for your brainstorming about the boot menu.
This will require few adjustments to freeldr before being able to have the 
submenus, since we currently don't support them "dynamically" (aka. specified 
from within freeldr.ini), but only in hardcoded manner (like the F8 advanced 
options) up to now.

Hermès;.

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Ged Murphy
Envoyé : mercredi 5 juillet 2017 15:20
À : 'ReactOS Development List'
Objet : Re: [ros-dev] About the bootcd and livecd, and the 1st-stage GUI setup

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 <ros-dev@reactos.org>
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) <gigah...@gmail.com> 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 <hermes.belu...@sfr.fr> 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 Re

[ros-dev] About the bootcd and livecd, and the 1st-stage GUI setup

[Hermès BÉLUSCA-MAÏTO]

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
1st-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 1st-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

=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.

 

The needed changes are the following: First, the build target that will
generate the all-in-one CD is called “bootcd”, because this also was the
main build target for ISOs before the change. Second, I completely remove
the “hybridcd” build target, because its functionality are now absorbed by
“bootcd”. Third, the build target “livecd” is reduced to its strict minimum.
For the sake of building a RAMDISK boot drive (see comments after), I
continue to generate an ISO for “livecd”. But I’ve changed the generated
name to “liveimage.iso”, to emphasize the point that it has to be understood
as a (virtual) disk image for RAMDISK purposes, not just as a ISO image.
Note that I haven’t renamed the build target “livecd” to, say, “liveimage”
to reduce my commit changes (such a renaming may be done later). The
“livecd” target builds a list of files that need to be present in the image.
The generated liveimage.iso is no-more a bootable ISO, I’ve removed
inclusion of freeloader + El-Torito boot-sector + the USB-ISO-Hybrid
functionality for it.

The “bootcd” target has been slightly changed in order to include the
liveimage.iso as a file (for RAMDISK), and to also add the contents of this
image in a flattened tree within the bootcd iso: the two directories
“Profiles” and “reactos”.

The 1st-stage text-mode setup is kept, as said before, but its corresponding
files + the installation CAB source + the 1st-stage GUI setup application
proper goes into a (renamed) directory called “i386”, corresponding to
installation files for an i386 installation (technically, 1 per architecture
when we’ll 

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

[Hermès BÉLUSCA-MAÏTO]

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

Re: [ros-dev] SVN url change?

[Hermès BÉLUSCA-MAÏTO]

Thanks for the info! And lol, I didn't know about the svn urls: I'm actually 
wondering how I reached that one while I always used the first one so far and 
didn't know at all the existence of the "viewcvs" one ^^

Hermès

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Colin Finck
Envoyé : mercredi 28 juin 2017 11:23
À : 'ReactOS Development List'
Objet : Re: [ros-dev] SVN url change?

Am 28.06.2017 um 04:01 schrieb Hermès BÉLUSCA-MAÏTO:
> Today I noticed that our buildbots couldn’t connect to SVN to upload 
> the commit changes, and therefore failed to build.

It was just the buildserver's network that didn't come up again after a short 
power outage. Fixed now, thanks for reporting!


> Also I noticed that the
> usual SVN ViewVC address (which was previously 
> https://svn.reactos.org/svn/reactos , for example) changed to 
> https://svn.reactos.org/viewcvs/reactos/

No, both are equally valid for years. None of them redirects to the other and 
nothing has changed in this regard.


- Colin

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


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

[ros-dev] SVN url change?

[Hermès BÉLUSCA-MAÏTO]

Hello all,

 

Today I noticed that our buildbots couldn’t connect to SVN to upload the
commit changes, and therefore failed to build. Also I noticed that the usual
SVN ViewVC address (which was previously https://svn.reactos.org/svn/reactos
, for example) changed to https://svn.reactos.org/viewcvs/reactos/ (granted,
there appear to be an automatic redirection to this new address).

Is it an intentional change, or an unintentional one? We didn’t seem to be
warned prior to this on the mailing list!

 

Cheers,

Hermès

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

Re: [ros-dev] [ros-diffs] [hbelusca] 75008: [USETUP]: Introduce SetupDeleteFile() and SetupMoveFile() (in addition to the already-existing SetupCopyFile()) in order to implement moving / renaming exis

[Hermès BÉLUSCA-MAÏTO]

Yes, only the SetupMoveFile would need SEH2 (I took it from the kernel32 code, 
MoveFile(Ex) and associated Basep** function(s), which used SEH2). I agree, as 
it is, the SEH2 usage here is hackish (as I've redefined the SEH macros in 
filesup.h, because I didn't want to include SEH library in usetup yet, while 
keeping the SetupMoveFile code close to the original one) .

"> This variable fulfills the requirements for _SEH2_VOLATILE"
You should then check the corresponding kernel32 code that may need such a fix.

Thanks for the review,
Hermès

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Thomas Faber
Envoyé : lundi 12 juin 2017 21:16
À : ros-dev@reactos.org
Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 75008: [USETUP]: Introduce 
SetupDeleteFile() and SetupMoveFile() (in addition to the already-existing 
SetupCopyFile()) in order to implement moving / renaming existing files. Will 
be use...

On 2017-06-12 01:58, hbelu...@svn.reactos.org wrote:
> +NTSTATUS
> +SetupMoveFile(
> +IN PCWSTR ExistingFileName,
> +IN PCWSTR NewFileName,
> +IN ULONG Flags)
> +{
> +NTSTATUS Status;
> +IO_STATUS_BLOCK IoStatusBlock;
> +OBJECT_ATTRIBUTES ObjectAttributes;
> +PFILE_RENAME_INFORMATION RenameInfo;
> +UNICODE_STRING NewPathU, ExistingPathU;
> +HANDLE SourceHandle = NULL;

This variable fulfills the requirements for _SEH2_VOLATILE

> +BOOLEAN ReplaceIfExists;
> +
> +RtlInitUnicodeString(, ExistingFileName);
> +RtlInitUnicodeString(, NewFileName);
> +
> +_SEH2_TRY
> +{

Which part of this code needs SEH? That looks like it's purely hiding bugs.

___
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] 74698: [USETUP]: Minor fixes & simplifications: - Remove a redundant NtClose call; - Return failure if NtQuerySymbolicLinkObject fails; - Use RTL_CONSTANT_STRING a

[Hermès BÉLUSCA-MAÏTO]

Hi Colin,
But then, why do we have these ">   * COPYRIGHT:   See COPYING in the top 
level directory" lines in all our code headers then?
Is it because COPYING is actually just the GPLv2 (which seems to be the case)? 
Would it then be preferable to add this in the main (or another) COPYING file 
so that we can reuse these conditions elsewhere instead of cluttering the ROS 
code with these headers (that are put everywhere)? Your propositions that 
you're mentioning at the end of your mail sound interesting.

I'm ofc ready to put the notice back in the file.

Thanks for the info,
Hermès

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Colin Finck
Envoyé : mercredi 31 mai 2017 10:23
À : 'ReactOS Development List'
Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 74698: [USETUP]: Minor fixes & 
simplifications: - Remove a redundant NtClose call; - Return failure if 
NtQuerySymbolicLinkObject fails; - Use RTL_CONSTANT_STRING and 
RtlInitEmptyUnicodeS...

hbelu...@svn.reactos.org wrote:
> -/*
> - *  ReactOS kernel
> - *  Copyright (C) 2002 ReactOS Team
> - *
> - *  This program is free software; you can redistribute it and/or 
> modify
> - *  it under the terms of the GNU General Public License as published 
> by
> - *  the Free Software Foundation; either version 2 of the License, or
> - *  (at your option) any later version.
> - *
> - *  This program is distributed in the hope that it will be useful,
> - *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> - *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - *  GNU General Public License for more details.
> - *
> - *  You should have received a copy of the GNU General Public License
along
> - *  with this program; if not, write to the Free Software Foundation,
Inc.,
> - *  51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> - */
>  /*
>   * COPYRIGHT:   See COPYING in the top level directory
>   * PROJECT: ReactOS text-mode setup

You're taking away the information that this file is licensed under
GPLv2 or any later version (as opposed to GPLv2-only, what some developers 
prefer).
Also the entire license information is lost when this file is used as part of a 
different source tree.

I have visited a seminar by our friend Nuno Brito last week, who has founded a 
company that deals with such topics (www.triplecheck.tech).
There are some simple best practices we can apply here to get consistent and 
useful headers once and for all.
The first would be using the established SPDX license identifiers from 
https://spdx.org/licenses (here: "GPL-2.0+"). This would also make our source 
files easily scannable by tools to get an overview of all licenses involved in 
our code and imported third-party components.

If you or someone else is interested in working on this, let's draft a 
universal header for our files that is compatible with SPDX.
Otherwise, I will have a look when there's more 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] [hbelusca] 74621: [USETUP]: SetupLib: Add an ARC path to (and from) NT path resolver. It allows mapping between an ARC path as specified in freeldr.ini / boot.ini , to its co

[Hermès BÉLUSCA-MAÏTO]

Hi again,

> isspace(0) is false so you don't need the *p check.

Thanks, I was hesitating about this when I wrote this code.

>> +KeyValue = wcstoul(p, (PWSTR*), 10);
>> +ASSERT(p);

> This assert seems superfluous, you just dereferenced the pointer. Also, you 
> incremented it just above and also (rightly) assumed it was larger than 
> ArcPath.

If I'm 200% sure wcstoul can never ever ever return a NULL pointer via its 
second argument, then yes I can remove the assert.

>> +/*
>> + * We can directly cast the HRESULTs into NTSTATUS since the error 
>> codes
>> + * returned by StringCbPrintfW:
>> + *STRSAFE_E_INVALID_PARAMETER   == 0x80070057,
>> + *STRSAFE_E_INSUFFICIENT_BUFFER == 0x8007007a,
>> + * do not have assigned values in the NTSTATUS space.
>> + */
>> +return (NTSTATUS)hr;

>To me that sounds like an argument of why you _can't_ do that.
> (You know the Rtl versions of these functions give you an NTSTATUS btw,  
> right?)

Oh great! We do have the RtlStringC(b/ch)* functions! But the header: 
"ddk/ntstrsafe.h" : in the ddk : lol ...
OK I know that for the purposes of giving a DDK to the users, Microsoft put 
this header in "ddk", but it doesn't really make sense for us to have them 
there, when you know it can be used also for user-mode applications that just 
want to rely on NT Rtl* functions...


> Wine's test framework works okay for unit tests. You can make this an apitest 
> by just #include'ing the C source file, then it can run on Testbot.

Noted :)



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

Re: [ros-dev] [ros-diffs] [hbelusca] 74619: [USETUP]: filesup module: - Add a NtPathToDiskPartComponents helper, that takes in input a fully qualified NT path to a file on hard disk, e.g.: \Device\Har

[Hermès BÉLUSCA-MAÏTO]

Hi,

>> +if (_wcsnicmp(Path, L"\\Device\\Harddisk", 16) != 0)
>> +{
>> +/* The NT path doesn't start with the prefix string, thus it cannot 
>> be a hard disk device path */
>> +DPRINT1("'%S' : Not a possible hard disk device.\n", NtPath);
>> +return FALSE;
>> +}
>> +
>> +Path += 16;

> Avoiding these magic numbers would be nice.
> Options include:
> * static string à la
>   static const WCHAR DeviceHarddiskPath[] = L"\\Device\\Harddisk";
>   _wcsnicmp(Path, DeviceHarddiskPath, ARRAYSIZE(DeviceHarddiskPath) - 1)
> * simply using wcslen(L"\\Device\\Harddisk") (which should get optimized)
> * making a "starts with" function
> * using RtlPrefixUnicodeString

Yes, I may choose the RtlPrefix one but these options are better.


>> +
>> +if (FileInfo.EndOfFile.HighPart != 0)
>> +DPRINT1("WARNING!! The file %wZ is too large!\n", Name);

>Did you mean ?

Correct



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

[ros-dev] A surprising epic win: Wolfram Mathematica on ReactOS

[Hermès BÉLUSCA-MAÏTO]

Hi all,

 

I was pleasantly surprised to notice that the symbolic computation program «
Wolfram Mathematica », in its version 8.0.4 (later versions are for Vista+
only), actually works quite pretty well on ReactOS (as of r74550): see the
screen-capture at http://i.imgur.com/KegyW79.png .

This software is broadly used in many scientific, engineering, mathematical,
and computing fields. This is for example used intensively in theoretical
physics (in high-energy physics, statistical physics etc.) due to the
existence of numerous packages that have been developed for it. The only
problem of this software resides in its price…

On the screen-capture I demonstrate an infinitesimal portion of what
Mathematica can do: for the non-connoisseurs :) the picture shows the
computation of the integral (area under the curve) of the 1-dimensional
Gaussian function over the whole real axis (the result is square-root of
pi), and then I plot in 3 dimensions the map of a 2-D Gaussian function,
where on the horizontal plane there are the x and y axes, and the vertical
axis is the z axis. The 3-D graph can be rotated, zoomed-in and out with the
mouse, it can be edited, etc… The software also proposes an extensive and
interactive help documentation. Finally I show the “fancy” text-mode only
interface of Mathematica, that nobody actually uses (it is only used when
computing stuff in batch-mode).

There are almost no graphical glitches. Few font problems can be seen (see
the about-box, and the minus signs on the graph replaced by boxes). There
are few keyboard shortcut problems such as pressing (on French keyboards)
AltGr-5 to enter ‘[‘ doesn’t work, but anyways…

 

Enjoy!

 

Best,

Hermès

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

[ros-dev] About the recent USETUP improvements in the branch

[Hermès BÉLUSCA-MAÏTO]

Hi all,

 

I’m writing a short mail to explain the recent USETUP improvements I’m doing
in the
https://svn.reactos.org/svn/reactos/branches/setup_improvements/base/setup/
branch.

 

The aim is three-fold:

-  To improve multi-OSes / bootloaders detection and solve
https://jira.reactos.org/browse/CORE-4870 ,
https://jira.reactos.org/browse/CORE-12672 ,
https://jira.reactos.org/browse/CORE-13188 ,
https://jira.reactos.org/browse/CORE-13226 in a consistent & reliable way,
and possibly having a look at https://jira.reactos.org/browse/CORE-13205 and
https://jira.reactos.org/browse/CORE-10898 (low priority for me at the
moment).

-  A bit related to the previous point, have the possibility to
automatically detect existing installations of ReactOS (and of Windows) to
allow simple upgrade. For this latter part I have code that almost works: it
browses all the available partitions on all the disks, and for each,
attempts to see whether either freeldr or ntldr is installed, and if so,
open their respective configuration files, browse the latter, and from that,
deduce the candidate NT installations. On the following screenshot :
http://i.imgur.com/Nq67J1o.png , a Windows installation actually exists on
“partition(1)” but is not listed because it happens to be on an NTFS
partition. Then there is a ReactOS installation on a FAT “partition(2)”, and
finally a Windows installation on another FAT “partition(4)” (all on the
same disk). The installation detector has respectively parsed freeldr.ini,
and boot.ini, to deduce the installations, and have removed installations
having the same disk and partition numbers and SystemRoot (otherwise you
would have seen many “ReactOS (xxx)” entries).

-  To facilitate the future implementation of the 1st-stage GUI
setup by someone, all the code that can be made common between USETUP and
this future GUI setup, is placed into a library. At the time of writing,
this concerns the so-called “generic lists” functionality as well as the
partition lists & some file-system-related routines. It will certainly grow
up later.

 

Cheers,

Hermès

 

P.S.: Using a 8x8 font for the installer quickly hurts the eyes (and it has
been like that since ages). It would be great to use a more readable
resolution / font size…

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

Re: [ros-dev] [ros-diffs] [hbelusca] 74550: [USETUP]: Continue implementing the NT OS installation detector. What remains to be done here, besides cleaning up the code from temporary comments and DPRI

[Hermès BÉLUSCA-MAÏTO]

Thanks for your quick review, Thomas.

>> +/***
>> +*wchar_t *wcsstr(string1, string2) - search for string2 in string1
>> +*   (wide strings)
>
>Copypasta?

Yes, from the CRT, where I then put in msconfig_new/stringutils.c and then 
copied it again there, as an implementation of search substring with case 
insensitivity.
I'll have to clean this comment block.

>> +/* Finally, unmap and close the file */
>> +UnMapFile(SectionHandle, ViewBase);
>> +NtClose(FileHandle);
>
>This seems clumsy. If there's a single function to open and map the file, why 
>isn't there one function to unmap and close?

Possible. I was keeping (for OpenAndMapFile) the possibility to also make it 
take (from the "out phandle" parameter) an already-opened file (via handle) so 
that it could just map it in memory, and I wasn't decided whether I would merge 
or not the unmapfile + ntclose ... I'll think about it.

> You know there's DPRINT for exactly this purpose, right?

Correct; actually I didn't place them under comments just to shut them up, but 
actually because they wouldn't really compile as they are: FileName isn't a 
UNICODE_STRING anymore (it was, in a previous code iteration, where these 
dprints were enabled, but I then moved the code into this function, before 
committing, and preferred to keep the dprints in place, but I didn't fix them, 
because I don't know if I want to have FileName back to UNICODE_STRING, or keep 
it as it's now, i.e. PCWSTR).

> Casts from PVOID to other pointer types are unnecessary.

I agree.


Cheers,
Hermès


-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Thomas Faber
Envoyé : mardi 16 mai 2017 10:05
À : ros-dev@reactos.org
Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 74550: [USETUP]: Continue 
implementing the NT OS installation detector. What remains to be done here, 
besides cleaning up the code from temporary comments and DPRINTs (and fixing 
potenti...

Hi again,

some comments inline.


On 2017-05-15 03:59, hbelu...@svn.reactos.org wrote:
> --- branches/setup_improvements/base/setup/usetup/osdetect.c  [iso-8859-1] 
> (original)
> +++ branches/setup_improvements/base/setup/usetup/osdetect.c  [iso-8859-1] 
> Mon May 15 01:59:28 2017
> @@ -19,6 +19,9 @@
>  /* GLOBALS 
> **/
>
>  extern PPARTLIST PartitionList;
> +
> +/* Language-independent Vendor strings */ static const PCWSTR 
> +KnownVendors[] = { L"ReactOS", L"Microsoft" };
>
>
>  /* VERSION RESOURCE API 
> **/
> @@ -361,36 +364,331 @@
>
>  #endif
>
> +
> +/***
> +*wchar_t *wcsstr(string1, string2) - search for string2 in string1
> +*   (wide strings)

Copypasta?

> +*
> +*Purpose:
> +*   finds the first occurrence of string2 in string1 (wide strings)
> +*
> +*Entry:
> +*   wchar_t *string1 - string to search in
> +*   wchar_t *string2 - string to search for
> +*
> +*Exit:
> +*   returns a pointer to the first occurrence of string2 in
> +*   string1, or NULL if string2 does not occur in string1
> +*
> +*Uses:
> +*
> +*Exceptions:
> +*
> +*
> +**/ PWSTR FindSubStrI(PCWSTR str, PCWSTR strSearch) {
> +PWSTR cp = (PWSTR)str;
> +PWSTR s1, s2;
> +
> +if (!*strSearch)
> +return (PWSTR)str;
> +
> +while (*cp)
> +{
> +s1 = cp;
> +s2 = (PWSTR)strSearch;
> +
> +while (*s1 && *s2 && (towupper(*s1) == towupper(*s2)))
> +++s1, ++s2;
> +
> +if (!*s2)
> +return cp;
> +
> +++cp;
> +}
> +
> +return NULL;
> +}
> +
>  static BOOLEAN
> -IsRecognizedOS(
> +CheckForValidPEAndVendor(
> +IN HANDLE RootDirectory OPTIONAL,
> +IN PCWSTR PathName OPTIONAL,
> +IN PCWSTR FileName, // OPTIONAL
> +IN PCWSTR VendorName// Better would be OUT PCWSTR*, and the function 
> returning NTSTATUS ?
> +)
> +{
> +BOOLEAN Success = FALSE;
> +NTSTATUS Status;
> +HANDLE FileHandle, SectionHandle;
> +// SIZE_T ViewSize;
> +PVOID ViewBase;
> +PVOID VersionBuffer = NULL; // Read-only
> +PVOID pvData = NULL;
> +UINT BufLen = 0;
> +
> +Status = OpenAndMapFile(RootDirectory, PathName, FileName,
> +, , );
> +if (!NT_SUCCESS(Status))
> +{
> +DPRINT1("Failed to open and map file %wZ, Status 0x%08lx\n", 
> , Status);
> +return FALSE; // Status;
> +}
> +
> +/* Make sure it's a valid PE file */
> +if (!RtlImageNtHeader(ViewBase))
> +{
> +DPRINT1("File %wZ does not seem to be a valid PE, bail out\n", 
> );
> +Status = STATUS_INVALID_IMAGE_FORMAT;
> +goto UnmapFile;
> +}
> +
> +/*
> + * Search for a valid executable version and vendor.
> + * NOTE: The module is loaded as a data file, it should be marked as 
> such.
> + */
> +Status = 

Re: [ros-dev] [ros-diffs] [hbelusca] 74550: [USETUP]: Continue implementing the NT OS installation detector. What remains to be done here, besides cleaning up the code from temporary comments and DPRI

[Hermès BÉLUSCA-MAÏTO]

Hehe yeah :D Just that since some people might complain we either break their 
installs / do not play "fair" with other companies products / etc... I prefer 
to play safe here :)

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Thomas Faber
Envoyé : mardi 16 mai 2017 09:48
À : ros-dev@reactos.org
Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 74550: [USETUP]: Continue 
implementing the NT OS installation detector. What remains to be done here, 
besides cleaning up the code from temporary comments and DPRINTs (and fixing 
potenti...

On 2017-05-15 03:59, hbelu...@svn.reactos.org wrote:
> Author: hbelusca
> Date: Mon May 15 01:59:28 2017
> New Revision: 74550
>
> URL: http://svn.reactos.org/svn/reactos?rev=74550=rev
> Log:
> [USETUP]: Continue implementing the NT OS installation detector.
> What remains to be done here, besides cleaning up the code from temporary 
> comments and DPRINTs (and fixing potential bugs), is to actually parse the 
> NTOS loader configuration files (freeldr.ini in ROS' case, or boot.ini in 
> Win2k3's case, etc...) to retrieve the actual installation paths. So far 
> these are currently hardcoded for testing purposes only.
> Note that I try to distinguish between ROS and Windows installations by 
> checking at the company name vendor of the ntoskrnl.exe & ntdll.dll files, in 
> order to allow the upgrade of ROS installations only.
> Suggestions are always welcome.

We should totally allow "upgrading" Windows installations with ROS.
We're obviously better ;)


___
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] [ion] 74546: BL Library now works 100% in paging, protected mode. A picture is worth a thousand commits: http://i.imgur.com/Zx2nQ6x.jpg [BOOTLIB]: Add support for protocol op

[Hermès BÉLUSCA-MAÏTO]

What about using standard PE resources? Is it doable even in the EFI 
applications?
Hermès

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Thomas Faber
Envoyé : lundi 15 mai 2017 12:04
À : Alex Ionescu
Cc : ros-dev@reactos.org
Objet : Re: [ros-dev] [ros-diffs] [ion] 74546: BL Library now works 100% in 
paging, protected mode. A picture is worth a thousand commits: 
http://i.imgur.com/Zx2nQ6x.jpg [BOOTLIB]: Add support for protocol 
open/close/lookup while p...

We have a bin2c tool that would make including the boot logo much nicer. You'll 
want to use something like the attached patch, and add the bmp file as 
app/rosload/logo.bmp. Then just include "logo.h"
instead of the g_Logo array in rosload.c.


On 2017-05-15 03:38, i...@svn.reactos.org wrote:
> Author: ion
> Date: Mon May 15 01:38:49 2017
> New Revision: 74546
>
> URL: http://svn.reactos.org/svn/reactos?rev=74546=rev
> Log:
> BL Library now works 100% in paging, protected mode. A picture is 
> worth a thousand commits: http://i.imgur.com/Zx2nQ6x.jpg
> [BOOTLIB]: Add support for protocol open/close/lookup while paging and 
> protected mode is enabled.
> [BOOTLIB]: Implement support for dozens of UEFI functions while under 
> protected mode.
> [BOOTLIB]: Fix bugs in existing UEFI functions which were switching to 
> _protected_ mode instead of _real mode_ before making the UEFI call.
> [BOOTLIB]: Free dynamic descriptor in MmMdFreeDescriptor.
> [BOOTLIB]: Implement BlHtDelete.
> [BOOTLIB]: Implement re-initialize-all path in DsppInitialize.
> [BOOTLIB]: Fix small bug in BlDisplayInvalidateOemBitmap
> [BOOTLIB]: Fix bigger bug in BlDisplayGetOemBitmap :)
>
> Modified:
> trunk/reactos/boot/environ/app/rosload/rosload.c
> trunk/reactos/boot/environ/include/bl.h
> trunk/reactos/boot/environ/lib/firmware/efi/firmware.c
> trunk/reactos/boot/environ/lib/io/device.c
> trunk/reactos/boot/environ/lib/io/display/display.c
> trunk/reactos/boot/environ/lib/io/display/efi/gop.c
> trunk/reactos/boot/environ/lib/misc/util.c
> trunk/reactos/boot/environ/lib/mm/descriptor.c
> trunk/reactos/boot/environ/lib/platform/time.c
>
> [This mail would be too long, it was shortened to contain the URLs 
> only.]
>
> Modified: trunk/reactos/boot/environ/app/rosload/rosload.c
> URL: 
> http://svn.reactos.org/svn/reactos/trunk/reactos/boot/environ/app/rosl
> oad/rosload.c?rev=74546=74545=74546=diff
>
> Modified: trunk/reactos/boot/environ/include/bl.h
> URL: 
> http://svn.reactos.org/svn/reactos/trunk/reactos/boot/environ/include/
> bl.h?rev=74546=74545=74546=diff
>
> Modified: trunk/reactos/boot/environ/lib/firmware/efi/firmware.c
> URL: 
> http://svn.reactos.org/svn/reactos/trunk/reactos/boot/environ/lib/firm
> ware/efi/firmware.c?rev=74546=74545=74546=diff
>
> Modified: trunk/reactos/boot/environ/lib/io/device.c
> URL: 
> http://svn.reactos.org/svn/reactos/trunk/reactos/boot/environ/lib/io/d
> evice.c?rev=74546=74545=74546=diff
>
> Modified: trunk/reactos/boot/environ/lib/io/display/display.c
> URL: 
> http://svn.reactos.org/svn/reactos/trunk/reactos/boot/environ/lib/io/d
> isplay/display.c?rev=74546=74545=74546=diff
>
> Modified: trunk/reactos/boot/environ/lib/io/display/efi/gop.c
> URL: 
> http://svn.reactos.org/svn/reactos/trunk/reactos/boot/environ/lib/io/d
> isplay/efi/gop.c?rev=74546=74545=74546=diff
>
> Modified: trunk/reactos/boot/environ/lib/misc/util.c
> URL: 
> http://svn.reactos.org/svn/reactos/trunk/reactos/boot/environ/lib/misc
> /util.c?rev=74546=74545=74546=diff
>
> Modified: trunk/reactos/boot/environ/lib/mm/descriptor.c
> URL: 
> http://svn.reactos.org/svn/reactos/trunk/reactos/boot/environ/lib/mm/d
> escriptor.c?rev=74546=74545=74546=diff
>
> Modified: trunk/reactos/boot/environ/lib/platform/time.c
> URL: 
> http://svn.reactos.org/svn/reactos/trunk/reactos/boot/environ/lib/plat
> form/time.c?rev=74546=74545=74546=diff
>
>



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

Re: [ros-dev] [ros-diffs] [hbelusca] 69160: [EFISYS]: Add 'bcd_hive' as a dependency. [FATTEN]: Fix help message. Functions with no parameters are void. Remove an hardcoded array size.

[Hermès BÉLUSCA-MAÏTO]

Hi (I'm answering back here for the ML history).
I added this dependency back in r69160 because at that time, efisys depended on 
${CMAKE_BINARY_DIR}/boot/bootdata/BCD . But it was realized later (in r70626) 
that it was actually not needed; however the committer forgot to remote the 
bcd_hive dependency.

Best,
Hermès

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Thomas Faber
Envoyé : samedi 13 mai 2017 19:20
À : Hermès BÉLUSCA-MAÏTO
Cc : ros-dev@reactos.org
Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 69160: [EFISYS]: Add 'bcd_hive' as 
a dependency. [FATTEN]: Fix help message. Functions with no parameters are 
void. Remove an hardcoded array size.

Hey Hermès,
I'm fixing how the BCD hive is generated and this just showed up in an svn 
blame for me.
Can you explain why this bcd_hive dependency is needed? I don't see the command 
depending on the hive file.

Thanks,
Thomas


On 2015-09-09 21:48, hbelu...@svn.reactos.org wrote:
> Author: hbelusca
> Date: Wed Sep  9 19:48:15 2015
> New Revision: 69160
> 
> URL: http://svn.reactos.org/svn/reactos?rev=69160=rev
> Log:
> [EFISYS]: Add 'bcd_hive' as a dependency.
> [FATTEN]: Fix help message. Functions with no parameters are void. Remove an 
> hardcoded array size.
> 
> Modified:
> trunk/reactos/boot/CMakeLists.txt
> trunk/reactos/tools/fatten/fatten.c
> 
> Modified: trunk/reactos/boot/CMakeLists.txt
> URL: 
> http://svn.reactos.org/svn/reactos/trunk/reactos/boot/CMakeLists.txt?r
> ev=69160=69159=69160=diff
> ==
> --- trunk/reactos/boot/CMakeLists.txt [iso-8859-1] (original)
> +++ trunk/reactos/boot/CMakeLists.txt [iso-8859-1] Wed Sep  9 19:48:15 2015
> @@ -17,7 +17,7 @@
>  
>  add_custom_target(efisys
>  COMMAND native-fatten ${CMAKE_CURRENT_BINARY_DIR}/efisys.bin -format 
> 2880 EFIBOOT -boot ${CMAKE_CURRENT_BINARY_DIR}/freeldr/bootsect/fat.bin 
> -mkdir EFI -mkdir EFI/BOOT -add $ 
> EFI/BOOT/boot${EFI_PLATFORM_ID}.efi -add 
> ${CMAKE_BINARY_DIR}/boot/bootdata/BCD EFI/BOOT/BCD
> -DEPENDS native-fatten bootmgfw fat
> +DEPENDS native-fatten fat bootmgfw bcd_hive
>  VERBATIM)
>  
>  ##bootcd
> 

___
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] 74528: Code simplifications.

[Hermès BÉLUSCA-MAÏTO]

Fixed in r74538.

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Thomas Faber
Envoyé : samedi 13 mai 2017 18:26
À : ros-dev@reactos.org
Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 74528: Code simplifications.

On 2017-05-13 18:13, hbelu...@svn.reactos.org wrote:
> --- branches/setup_improvements/base/setup/usetup/filesup.c   [iso-8859-1] 
> (original)
> +++ branches/setup_improvements/base/setup/usetup/filesup.c   [iso-8859-1] 
> Sat May 13 16:13:49 2017

> @@ -524,14 +523,10 @@
>  ,
>  0,
>  FILE_SYNCHRONOUS_IO_NONALERT);
> -if (!NT_SUCCESS(Status))
> -{
> -  return FALSE;
> -}
>
>  NtClose(FileHandle);
>
> -return TRUE;
> +return NT_SUCCESS(Status);
>  }

Not an improvement. You're now closing an uninitialized handle on failure.


___
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] 74493: [NTOS]: Capture the counted BaseDllName unicode string into a local NULL-terminated buffer before calling wcsrchr on it (actually I think it would be better

[Hermès BÉLUSCA-MAÏTO]

Hi!
The assert is fixed (r74495). For ExAllocatePool, it would be better to change 
them all at once in this file.

Hermès

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Thomas Faber
Envoyé : dimanche 7 mai 2017 20:49
À : ros-dev@reactos.org
Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 74493: [NTOS]: Capture the counted 
BaseDllName unicode string into a local NULL-terminated buffer before calling 
wcsrchr on it (actually I think it would be better to create & use a simi...

On 2017-05-07 20:15, hbelu...@svn.reactos.org wrote:
> --- trunk/reactos/ntoskrnl/io/iomgr/driver.c  [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/io/iomgr/driver.c  [iso-8859-1] Sun May  7 
> 18:15:12 2017
> @@ -884,7 +884,7 @@
>  PDEVICE_NODE DeviceNode;
>  PDRIVER_OBJECT DriverObject;
>  NTSTATUS Status;
> -PWCHAR FileNameWithoutPath;
> +PWCHAR Buffer, FileNameWithoutPath;
>  PWSTR FileExtension;
>  PUNICODE_STRING ModuleName = >BaseDllName;
>  PLDR_DATA_TABLE_ENTRY LdrEntry;
> @@ -898,13 +898,19 @@
>  IopDisplayLoadingMessage(ModuleName);
>  InbvIndicateProgress();
>
> +Buffer = ExAllocatePool(PagedPool, ModuleName->Length + 
> sizeof(UNICODE_NULL));
> +ASSERT(Buffer);

Please don't call ExAllocatePool.
And please check for allocation failure. An assert is not acceptable.

___
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] Vgal USB patches

[Hermès BÉLUSCA-MAÏTO]

Hi Javier,

 

Actually I don’t think you’ve found where these code reviews are taking place. 
They are here:

https://code.reactos.org/cru/CR-109

https://code.reactos.org/cru/CR-110

https://code.reactos.org/cru/CR-111

and you can find there who’s currently reviewing them.

 

By what Alexander seems to say, the code changes seem to work quite well.

 

Hermès

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Javier Agustìn 
Fernàndez Arroyo
Envoyé : dimanche 16 avril 2017 10:59
À : ReactOS Development List
Objet : Re: [ros-dev] Vgal USB patches

 

please forgive me, as this may sound so rude...

Is this code reliable? is anyone reviewing it?

 

On Sat, Apr 15, 2017 at 2:09 PM, Alexander Rechitskiy  
wrote:

Hello everyone!

 

Vgal sais that his code from СR-110 CR-111 is ready for trunk merging.

 

Vgal's changes were tested a lot by the Russian community. Huge regressions are 
impossible. We have enough time before release (1 month and two days). I can't 
imagine a better time for the merge.

 

 

We need the upcoming release to be great again!

 

 

 

06.04.2017, 08:14, "Peter Hater" <7elem...@mail.bg>:

Code review is open for everyone.

Go ahead at search for ((not so) obvious) bugs :)

CR-110/CR-111 maybe more.

BR,

Peter


On Apr 6, 2017, at 08:09, Javier Agustìn Fernàndez Arroyo  
wrote:
 

Wo is reviewing that Code?

 

El 06/04/2017 06:46, "Peter Hater" <7elem...@mail.bg> escribió:

No.
This means that we won't have (much) BSODs and weird crashes when 
(dis)connecting usb devices.
Booting from usb is (at least) blocked by CORE-10456.

BR,
Peter

> On Apr 6, 2017, at 04:01, Thomas Mueller  wrote:
>
> from Robert Naumann:
>
>> Codereview is already ongoing. If everything goes well, USB will become
>> great again soon.
>
> Does this mean it will be possible to build ReactOS and install to a USB 
> stick so as to be bootable?
>
> Tom
>
>
>
> ___
> 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

 

 

-- 
Best regards,

 


___
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] Vgal USB patches

[Hermès BÉLUSCA-MAÏTO]

The cheap route for isohybrid is ok (and it's not the only tool where we would 
do this modification :) )
For my local msvc-problem I don't know what it does...

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Colin Finck
Envoyé : mardi 4 avril 2017 18:16
À : ros-dev@reactos.org
Objet : Re: [ros-dev] Vgal USB patches

Am 04.04.2017 um 14:05 schrieb Hermès BÉLUSCA-MAÏTO:
> Also, I confirm that, for whatever reason in VS2010, which doesn't have 
> inttypes.h, in its CRT headers, compilation might fail: here for me, for 
> example, it succeeds when being done from the command-line, but fails when 
> being done from within the VS IDE...

Huh?? That sounds like MSVC-provided headers are mixed with our target headers 
in sdk/include/crt for host tools, which mustn't happen!


> It would be nice if compilation could use the inttypes.h provided in the 
> mkisofs/shillytools, as this file is provided there indeed for a reason (and 
> not to be not used).

Actually, I put the schilytools headers into sdk/tools/mkisofs/schilytools and 
not into e.g. sdk/tools/schilytools for a reason:
I only imported the very subset that is required for mkisofs. Their usability 
for any other purpose is not guaranteed.

If you just want a cheap fix for isohybrid, you should uncomment the inttypes.h 
include and add the required <10 lines to reactos_support_code.h.

There may be merit in using schilytools headers for this if more than just 
isohybrid and mkisofs would do so. Currently, every host tool we have uses 
their own host-abstracting headers.
But unless you plan to work on this, I don't expect this to change any time 
soon, and this is why I would go the cheap route myself :)


- 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] Vgal USB patches

[Hermès BÉLUSCA-MAÏTO]

And also use ninja with the option "-k 0" (dash k zero, without the quotes), so 
that he doesn't stop at the first compilation error it encounters & allows to 
continue compiling what's compilable.
At the next ninja -k 0 invocation, you can then better see which module(s) was 
failing compilation.
Also, I confirm that, for whatever reason in VS2010, which doesn't have 
inttypes.h, in its CRT headers, compilation might fail: here for me, for 
example, it succeeds when being done from the command-line, but fails when 
being done from within the VS IDE... It would be nice if compilation could use 
the inttypes.h provided in the mkisofs/shillytools, as this file is provided 
there indeed for a reason (and not to be not used).

Regards,
Hermès

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Mark Jansen
Envoyé : mardi 4 avril 2017 13:57
À : ReactOS Development List
Objet : Re: [ros-dev] Vgal USB patches

What kind of problems with github?
For his build problem: try completely deleting everything from that build dir, 
and re-generating build files.

Regards,

Mark

On 4 April 2017 at 12:17, Alexander Rechitskiy <art1st...@yandex.ru> wrote:
> Vgal told me that he still has major problems with github. So code  
> review at code.reactos.org is the only option. Also he is a bit tired 
> with his local test builds and thinks that inclusion into trunk will 
> speed up his developments
>
> And one more problem that he faced. He could not build proper VC bulds 
> after new ISO format was adopted.
> https://pastebin.com/AtUqfGf9
>
> 04.04.2017, 02:41, "Hermès BÉLUSCA-MAÏTO" <hermes.belu...@sfr.fr>:
>
> Hi !
>
> A proper code review may be in order, where/how can we do that?
>
>
>
> Regards,
>
> Hermès BÉLUSCA - MAÏTO
>
>
>
> De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de 
> Alexander Rechitskiy Envoyé : mardi 4 avril 2017 01:18 À : ReactOS 
> Development List Objet : [ros-dev] Vgal USB patches
>
>
>
> Hello all!
>
>
>
> Vgal showed significant progress in his USB patches. With his test images
> almost every sungle  usb keyboard and mouse works. We (russian community)
> have reached the top corner of our testing capabilities and we could not
> find any new bugs in his work anymore. So Vgal usb patches are now in very
> mature state.
>
>
>
> Now we probably need to make the next step and put all his work or parts of
> it into trunk. But before  this Vgal said that it is important to test his
> drivers against Windows 2003 server to be sure in compatibilty. And this
> where russian community can not provide enough help with . I know that many
> developers are familiar with this procedure. So probably it is your turn
> now.
>
>
>
> We need this patches in trunk in order to make our next release great again!
> And we have not so many but still enough time to finish this effort.
>
>
>
>
>
> P.S. Here is the link to legal VHD-image of Microsoft Windows Server 2003 R2
> Enterprise Edition for test purposes
>
> https://www.microsoft.com/en-us/download/details.aspx?id=19727
>
> --
> Best regards,
>
> Alexander Rechitskiy
>
> ,
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>
> --
> Best regards,
>
>
> ___
> 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] Vgal USB patches

[Hermès BÉLUSCA-MAÏTO]

Hi !

A proper code review may be in order, where/how can we do that?

 

Regards,

Hermès BÉLUSCA - MAÏTO

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Alexander 
Rechitskiy
Envoyé : mardi 4 avril 2017 01:18
À : ReactOS Development List
Objet : [ros-dev] Vgal USB patches

 

Hello all!

 

Vgal showed significant progress in his USB patches. With his test images 
almost every sungle  usb keyboard and mouse works. We (russian community) have 
reached the top corner of our testing capabilities and we could not find any 
new bugs in his work anymore. So Vgal usb patches are now in very mature state.

 

Now we probably need to make the next step and put all his work or parts of it 
into trunk. But before  this Vgal said that it is important to test his drivers 
against Windows 2003 server to be sure in compatibilty. And this where russian 
community can not provide enough help with . I know that many developers are 
familiar with this procedure. So probably it is your turn now.

 

We need this patches in trunk in order to make our next release great again! 
And we have not so many but still enough time to finish this effort.

 

 

P.S. Here is the link to legal VHD-image of Microsoft Windows Server 2003 R2 
Enterprise Edition for test purposes

https://www.microsoft.com/en-us/download/details.aspx?id=19727

-- 
Best regards,

Alexander Rechitskiy

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

Re: [ros-dev] Gsoc audio project mentor status

[Hermès BÉLUSCA-MAÏTO]

Hi Pranay,

 

The code you would be working on (for the registry) is mainly the registry 
library :  <https://svn.reactos.org/svn/reactos/trunk/reactos/sdk/lib/cmlib/> 
https://svn.reactos.org/svn/reactos/trunk/reactos/sdk/lib/cmlib/ , which 
implements the core of the functionality. The missing functionality there are 
the hives mapped into memory (currently, only hives fully loaded in memory are 
supported; the mapped functionality would imply adding some lookup tables, as 
far as I’ve understood at first sight from some pieces of the code and from the 
documentation links I mentioned in the previous mail) . This is also in cmlib 
that the code regarding implementing registry corruption recovery would be 
implemented (implementing the registry hive transaction log feature, and the 
function responsible for checking the sanity of a registry hive being loaded, 
called “CmCheckRegistry”).

Then, the ReactOS kernel wraps all this into some extra code, which implements 
caching, etc… :  
<https://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/config/> 
https://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/config/ . Adding 
support for security (access control lists, etc…) for registry hives, which is 
currently stub-plemented, would be nice, so that our registry hives could be 
loaded by Windows’ NTLDR (loader bootstrap) & its kernel.

 

So the main two points cited in the wiki:

“

1. When ReactOS crashes, Registry Hives easily get corrupted and render the 
whole system unbootable. The reliability of the Registry Hive implementation 
shall be improved to make the effect of crashes less severe and also recover 
from partly corrupted Hives. 

2. Hives created by our mkhive tool are roughly compatible with the Windows 
format. The only part that is currently missing are the implementation of 
Security Descriptors. Implementing these could make the tool more usable and 
improve interoperability between Windows and ReactOS.

“

would concern respectively: 1) adding code into cmlib + implementing 
CmCheckRegistry, and 2) Implementing support for registry keys security 
(somewhere in ntoskrnl/config).

 

Also, you might be interested (optional, depending on your motivation/status/…) 
in implementing (actually the corresponding code is half-plemented & broken) 
code for correctly unloading hives (this needs, cleaning the appropriate 
caches, etc…). This should be looked more carefully. Properly unloading 
registry hives is needed to implement e.g. user log-off (the corresponding user 
registry hive, so-called “user profile”, has to be unloaded at logoff; we 
currently have a “hack”, so to say, to make it work). 

 

Regards,

Hermès BÉLUSCA - MAÏTO

 

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Pranay Pratyush
Envoyé : jeudi 30 mars 2017 11:26
À : ReactOS Development List
Objet : Re: [ros-dev] Gsoc audio project mentor status

 

Could you tell me what files would I be working on and what code would I be 
adding to fix the bugs mentioned on the wiki.
Thank You




 

--

Pranay Pratyush,

3rd year undergraduate ,

Computer Science and Engineering Department

Indian Institute Of Technology, Kharagpur

--

 

On Thu, Mar 30, 2017 at 5:04 AM, Hermès BÉLUSCA-MAÏTO <hermes.belu...@sfr.fr> 
wrote:

Hi Pranay !

 

Yes, the potential mentor for audio-related matters, Johannes Anderwald, is 
currently away from ReactOS since a long time now, so unless someone else wants 
to mentor on the audio project.

I can however mentor you for the “registry hive implementation” proposal, 
because I’ve touched this area of code recently, and there’s actually some 
documentation available out there (see the provided links on the wiki).

Other potential mentors for the registry stuff (besides me) could be Alex 
Ionescu or Aleksey Bragin (or others), as they have also implemented some parts 
of it.

 

Best,

Hermès BÉLUSCA - MAÏTO

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Pranay Pratyush
Envoyé : mercredi 29 mars 2017 22:23
À : ReactOS Development List
Objet : [ros-dev] Gsoc audio project mentor status

 

Hi there, 
I am under the impression that no mentor can be assigned to my audio mixer 
proposal. Can someone confirm this or the opposite? If so I would like to 
create a proposal on "Improving the quality of our Registry Hive 
implementation", but since I don't have much time left and I haven't gone 
through the relevant code, I would really appreciate it if you point me to the 
mentor for this project.
Thank You

--

Pranay Pratyush,

3rd year undergraduate ,

Computer Science and Engineering Department

Indian Institute Of Technology, Kharagpur

--


___
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] Opening up #reactos-dev to the public

[Hermès BÉLUSCA-MAÏTO]

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  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] [khornicek] 74209: [RAPPS] - Add a custom build of the Mesa 3D Graphics Library. This build contains mesa, gallium and llvmpipe. It provides an enormous performance boost ove

[Hermès BÉLUSCA-MAÏTO]

And another reason to make our SVN source tree structure modularized.

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Colin Finck
Envoyé : lundi 20 mars 2017 23:05
À : ros-dev@reactos.org
Objet : Re: [ros-dev] [ros-diffs] [khornicek] 74209: [RAPPS] - Add a custom 
build of the Mesa 3D Graphics Library. This build contains mesa, gallium and 
llvmpipe. It provides an enormous performance boost over the software 
implemen...

Am 20.03.2017 um 09:44 schrieb Kamil Hornicek:
> few other people asked me, but Jerome did it right. Mesa code base is 
> rather big and llvm is not small either. Integrating it in our 
> building process and keeping it in sync would require huge amount of 
> effort. It would also increase both the ISOs and the build time.

I'm seeing more and more people afraid of adding anything "big" to our tree. 
But this is just natural for a project that aims to become a fully fledged 
operating system!

The worst thing would be an OS that can be quickly compiled from scratch and 
then needs lots of binary blobs to be useful. Even worse, those binary blobs 
could hardly be verified and patched.
Don't forget we already had that with our schannel.dll implementation that 
depended on an external GnuTLS binary. Fortunately, this is fixed by now and 
ReactOS supports TLS out of the box.
I would like to see the same for a Mesa/Gallium/llvmpipe stack.
Having one somewhere hidden in RAPPS, but not in an out of the box ReactOS 
installation from the ReactOS giveaway CDs would be very disappointing...

I also understand the group though who wants the default ReactOS build to be 
lightweight. So maybe Mesa/Gallium/llvmpipe could become part of another module 
which is added through our "modules" subdirectory.
Our current SVN setup with just one ReactOS repository does not really 
encourage adding new modules. Another reason for a move to Git where everybody 
could easily put his big module into an own repository :)


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] New ideas added to GSoC Ideas list

[Hermès BÉLUSCA-MAÏTO]

To be the most accurate, WoW16 is an addition to NTVDM. NTVDM alone provides 
16-bit emulation plus DOS support. WoW16 adds on top of that, Win 3.1 support 
(which is also 16-bit). WoW16 is implemented using wow32.dll (the 32-bit part 
that interfaces directly with NTVDM), wowexec.exe (the corresponding 16-bit 
part), krnl386.exe (the “kernel” of Win 3.1) and the thunk dlls/exes user, gdi …

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de David Quintana 
(gigaherz)
Envoyé : jeudi 16 mars 2017 23:50
À : ReactOS Development List
Objet : Re: [ros-dev] New ideas added to GSoC Ideas list

 

That's not true. NTVDM is not WoW16. NTVDM is just DOS support. In order to 
support 16bit (windows 3.1) applications, a whole other system is needed.

 

On 16 March 2017 at 23:37, Javier Agustìn Fernàndez Arroyo  
wrote:

"-Implementing WoW16 support. I suppose that'll draw attention." --> NTVDM, 
already done :)

"Working on DirectX support: bringing new features, fixing bugs, optimising, if 
possible fixing some driver issues..." ---> ReactX, would be great!

 

On Thu, Mar 16, 2017 at 2:28 PM, Thomas Faber  wrote:

I can tell you some possible next steps:
- x64: implement PAE support in the 32 bit kernel
- SMP: Implement resource translators and arbiters (I have some initial work 
for this somewhere)
- Also SMP: build a CONFIG_SMP kernel (with some hack to use the regular HAL) 
and debug any issues coming from broken spinlock usage

On March 16, 2017 5:50:39 AM EDT, Colin Finck  wrote:

Am 16.03.2017 um 00:03 schrieb Huw Campbell:
 SMP or 64 bit processor support would be great. Too hard?

I think that's too much for a single GSoC student. But we also keep
saying this for a long time... The result is that everybody is afraid of
those "big topics".

What we need is some kernel dev looking into these topics and giving a
rough overview what needs to be done and in what places. Then we can
have a roadmap and split the work up into smaller tasks that are even
doable by GSoC students.

If nobody makes this first step, we will never have SMP or x64 CPU
support. People also kept saying that full printer support is too much
for a 6-month bachelor thesis, and they were right, but nevertheless I
was able to build the foundations and documentation in that
time.
And now I could guide everyone interested how to continue on achieving
full printing support.


- Colin


  _  


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


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

 

___
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] New ideas added to GSoC Ideas list

[Hermès BÉLUSCA-MAÏTO]

I’m sorry but I should remind you that we *already* have *MANY* apps & dlls 
(not from Wine) where dialog layouts are already different for different 
locales, examples being for French and German languages (amongst others) where 
having adapted sizes for buttons, static text controls, … are mandatory, 
because these languages use frequently long words, etc… . So it’s clear we will 
never go back to a single layout that is shared between different locales.

 

I should reassure you however, that we don’t care at all about “pixel-perfect 
layout compatibility with windows”.

 

A suggestion then, would be to have a resource editor, that can display nicely, 
for a given dialog ID, all the (possibly only the selected ones) different 
dialogs of the different languages, in e.g. mosaic positioning, which should 
help the translator to easily see whether he needs to adapt a layout for a 
given language, or whether he can just copy/paste an existing layout.

 

Hermès.

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Rafal Harabien
Envoyé : mardi 14 mars 2017 23:44
À : ReactOS Development List
Objet : Re: [ros-dev] New ideas added to GSoC Ideas list

 

PO files supports "context" markers to make it possible to differentiate usage 
of the same string in different contexts.
About different layout - yes, we would have only one layout but IMO for project 
like this with human resource problems its more important to make development 
less boring and easier to maintain than to customize dialogs for every locale 
without significant profit. If project treats pixel-perfect layout 
compatibility with windows as requirement it would be a problem but I don't 
think ROS needs it.  We already import multiple dialogs from Wine...


W dniu 14.03.2017 o 23:29, David Quintana (gigaherz) pisze:

Gettext-style translations are really really bad, because they use the original 
text (usually in english) as a translation key, which means they simply can not 
handle situations where the same english text needs different translations 
depending on where the text is used. And yes, I have come across that issue 
once upon a time.

You are right that editing a dialog is annoying, but due to the way win32 
resource dialogs work, it's unavoidable. Even if we could have a serpate file 
for reaching the translations, there's often the situation where certain 
languages need different layouts, or at least different control sizes, to 
accomodate for longer / taller text, or RTL. So even if we switched to a 
different system, that annoyance wouldn't go away.

I do agree that it would be nice to have some nicer tool for translators, but 
IMO, .po files are not it.

 

 

On 14 March 2017 at 23:14, Rafał Harabień  wrote:

In my opinion it's very sensible proposal. I remember changing  dialog
layout in resources was a big pain because of amount of repeated work
for all languages (and error prone). It was demotivating.
On the other hand there are free translation platforms making project
translation more organized and easier than editing raw resources. WINE
is using PO for years and ReactOS IMO should do it as well.
Just my two cents...

W dniu 14.03.2017 o 14:31, Ștefan Fulea pisze:

> Marți, 14 martie 2017 12:00:02 +, Mark Jansen
>  > a scris:
>> How about a better way to translate ros?
>> For example integrating .po files with our rc files (possibly needs a
>> preprocess step or something tho),
>> Or creating a resource editor that allows multiple files to be edited
>> at once?
>>
> Please don't push for .po resources, for these are not better. As for
> improving the process, I doubt it'd repay the investment. After the
> initial translation effort, the further maintenance requires very
> little.
>
> ___
> 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] New ideas added to GSoC Ideas list

[Hermès BÉLUSCA-MAÏTO]

Victor thought also about adding registry hive healing.
Hermès.

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Colin Finck
Envoyé : dimanche 12 mars 2017 17:27
À : 'ReactOS Development List'
Objet : [ros-dev] New ideas added to GSoC Ideas list

Hi all!

Daniel and me collected some additional ideas for GSoC today, which I've added 
to our Wiki Ideas list:
https://reactos.org/wiki/Google_Summer_of_Code_2017_Ideas

In particular:
* Fundamental WiFi components
* USBXHCI driver for supporting USB 3.x controllers
* Bluetooth Stack
* WebKit-based MSHTML implementation

I'm open for comments and suggestions!
We can still add ideas until March 20, so let's give students a large pool to 
draw from.

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] [hbelusca] 74068: [WS2_32] - Fix pointers verification in WSALookupServiceNextW and WSALookupServiceNextA; - In WSALookupServiceNextA: Perform extra checks to see whether we

[Hermès BÉLUSCA-MAÏTO]

Hi, thanks for your comments.
The rest of the ws2_32 code continues to use Set/GetLastError even for dealing 
with the WSA* error codes, and the WSASet/GetLastError just call back the 
normal functions, so I would just keep using GetLastError here.

Hermès

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Thomas Faber
Envoyé : dimanche 5 mars 2017 12:06
À : ros-dev@reactos.org
Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 74068: [WS2_32] - Fix pointers 
verification in WSALookupServiceNextW and WSALookupServiceNextA; - In 
WSALookupServiceNextA: Perform extra checks to see whether we failed the first 
local ...

On 2017-03-05 01:40, hbelu...@svn.reactos.org wrote:
> +
> +/*
> + * Check whether we actually just retrieved the needed buffer size
> + * because our previous local allocation did fail. If so, allocate
> + * a new buffer and retry again.
> + */
> +if ( (!UnicodeQuerySet) && (*lpdwBufferLength >= sizeof(WSAQUERYSETW)) &&
> + (ErrorCode == SOCKET_ERROR) && (GetLastError() == WSAEFAULT) 
> + )

Seems like you'd want to check WSAGetLastError when looking for WSA* error 
codes.

> +{
> +/* Allocate the buffer we'll use */
> +UnicodeQuerySet = HeapAlloc(WsSockHeap, 0, UnicodeQuerySetSize);
> +if (UnicodeQuerySet)
> +{
> +/* Call the Unicode Function */
> +ErrorCode = WSALookupServiceNextW(hLookup,
> +  dwControlFlags,
> +  ,
> +  UnicodeQuerySet);
> +}
> +/*
> + * Otherwise the allocation failed and we
> + * fall back into the error checks below.
> + */
> +}
> +
>  if (ErrorCode == ERROR_SUCCESS)
>  {
> -/* Not convert to ANSI */
> +/* Now convert back to ANSI */
>  ErrorCode = MapUnicodeQuerySetToAnsi(UnicodeQuerySet,
>   lpdwBufferLength,
>   lpqsResults);
> -if (ErrorCode != ERROR_SUCCESS) SetLastError(ErrorCode);
> +if (ErrorCode != ERROR_SUCCESS)
> +SetLastError(ErrorCode);
>  }
>  else
>  {
> @@ -499,10 +542,11 @@
>  }
>
>  /* If we had a local buffer, free it */
> -if (UnicodeQuerySet) HeapFree(WsSockHeap, 0, UnicodeQuerySet);
> +if (UnicodeQuerySet)
> +HeapFree(WsSockHeap, 0, UnicodeQuerySet);

HeapFree(NULL) is fine by the way.

>
>  /* Return to caller */
> -return ErrorCode == ERROR_SUCCESS ? ErrorCode : SOCKET_ERROR;
> +return (ErrorCode == ERROR_SUCCESS) ? ErrorCode : SOCKET_ERROR;
>  }


___
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] 73895: [NTGDI]: Few fixes & hacks for NtGdiGetGlyphIndicesW, see CORE-12825: - (Fix) Check for integer count overflow (per Thomas suggestion), - (Hack#1) Signal th

[Hermès BÉLUSCA-MAÏTO]

Hi,
I completely agree, and that's why I put in comment that INT_MIN stuff.

Hermès

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Neo Love
Envoyé : vendredi 3 mars 2017 01:26
À : ReactOS Development List
Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 73895: [NTGDI]: Few fixes & hacks 
for NtGdiGetGlyphIndicesW, see CORE-12825: - (Fix) Check for integer count 
overflow (per Thomas suggestion), - (Hack#1) Signal the particular calling ca...

If 'cwc' is a pointer or anything that would ever become 64 bits in x64 this 
type of coding needs rewriting using symbolic sizes.
(Such as ULONG_PTR(-1) and similar constructs..)


On 2017-02-24 20.42, Thomas Faber wrote:
> +/* Check for integer overflow */
> +if (cwc & 0x8000) // (INT_MAX + 1) == INT_MIN

L.
___
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] Office (Excel, Word...) 2010 on ReactOS

[Hermès BÉLUSCA-MAÏTO]

Hi !

Thanks for the notification James.

To answer Giannis’ question, I was asking the status because I did a ~= 2 hour 
long testing in “real-life” conditions of Word yesterday to see how many bugs 
(visual or not) were existing. I’ve mainly played with different tools in the 
ribbon bar, modified display of the document, inserted a screenshot taken with 
the word’s tool (which I was surprised to see that it did work great) etc etc… 
,  and *many* spammy win32k fixme / err / etc… appeared, most of them that 
already appear with other software as well. I give here few examples:

 

-  
(C:\Buildslave\Build_MSVC_x86\build\reactos\win32ss\user\ntuser\scrollbar.c:1216)
 err: FIXME: EnableScrollBar wSBflags 1 wArrows 0 Chg 0

This fixme spams a lot when word starts. I’ve checked the corresponding ntuser 
code, and the fixme seems to be there because the drawing code of the 
scrollbars (in user32/win32k) was not completely moved into win32k during the 
class rewrite. I’ve also noted code redundancies between the scroll.c file in 
user32 and the file of same name in ntuser. So this is one place where I can 
touch the code.

 

-  We also have many of these errors:

(C:\Buildslave\Build_MSVC_x86\build\reactos\win32ss\user\ntuser\message.c:1258) 
err: UserPostMessage: Invalid handle 0xBC65036C Msg 0x2a3!

(C:\Buildslave\Build_MSVC_x86\build\reactos\win32ss\user\ntuser\winpos.c:3309) 
err: NtUserSetWindowPos bad window handle!

(C:\Buildslave\Build_MSVC_x86\build\reactos\win32ss\user\ntuser\cursoricon.c:815)
 err: Trying to delete global cursor!

That may indicate someone (word, or us, within win32k calls) giving incorrect 
parameters to the functions (because e.g. some win32k object died in the 
meantime, or I don’t know). With Word, the appearance of these messages is 
accompanied by either slowdowns or the cursor that remain of the same shape 
when hovering on regions of word app window where it should change its shape, 
etc..

 

-  And other errors that we are used to see in our debug logs…

 

Plus there is the problem of mouse capture that appear when you try to resize 
word (or any other office app) window.

 

Therefore that’s why I was wondering in advance whether there were other people 
touching these similar win32k areas, before I’m potentially doing anything 
there.

 

Best,

Hermès

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de James Tabor
Envoyé : mercredi 22 février 2017 03:42
À : ReactOS Development List
Objet : Re: [ros-dev] Office (Excel, Word...) 2010 on ReactOS

 

Class rewrite is now done!  Giannis plugged in the remainder with Versioning so 
it's done.

I noticed this on the mail list, having email problem.

James

 

On Tue, Feb 21, 2017 at 8:22 PM, Javier Agustìn Fernàndez Arroyo 
 wrote:

that´s amazing!

congratulations! it´s wonderful to read such big news! :)

ReactOS (and you, devs, of course) is going to conquer desktop world! :)

 

On Wed, Feb 22, 2017 at 12:46 AM, Giannis Adamopoulos 
 wrote:

Jim completed the class rewrite years ago (with a great success) and afaik 
there is no other major rewrite/undertaking right now in win32k. Why do I have 
a feeling you plan some major undertaking?

ReactOS Development List  wrote on Wed, February 22nd, 
2017, 12:01 AM:
> Hi all,
>
>
>
> Before touching parts of win32ss (user32/gdi32/win32k) I would like to know
> what the status of different components are:
>
> -  James, have you finished with your win32 class rewrite? What’s
> the status of it? Is there a bug report concerning this rewrite?
>
> -  Does anybody else currently work on cursors / GDI bitmap matters?
>
>
>
> Best,
>
> Hermès
>
>
>
>
>
> De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de victor
> martinez
> Envoyé : mardi 21 février 2017 23:35
> À : ReactOS Development List
> Objet : Re: [ros-dev] Office (Excel, Word...) 2010 on ReactOS
>
>
>
> Somehow it reminds me to the release/capture issues GIMP is showing with the
> mouse:
>  
> https://jira.reactos.org/browse/CORE-11775
>
>   _
>
> De: Ros-dev  en nombre de Giannis Adamopoulos
> 
> Enviado: martes, 21 de febrero de 2017 11:50:04
> Para: ReactOS Development List
> Asunto: Re: [ros-dev] Office (Excel, Word...) 2010 on ReactOS
>
>
>
> Hi! This is excellent news! It's good to know that Samuel started working
> again on ntlm. I guess the most productive way to help him complete it would
> be to write several tests for it (and also convert Samuel's test to formal
> tests). Not only will it help Samuel but will help you understand ntlm
> yourself and then help Samuel. (It is not like I knew anything about
> activation contexts before. It was the tests I wrote that helped me come up
> with clever way to let our comctl32 really do what both versions of
> comctl32).
>
> Keep 

Re: [ros-dev] Office (Excel, Word...) 2010 on ReactOS

[Hermès BÉLUSCA-MAÏTO]

Hi all,

 

Before touching parts of win32ss (user32/gdi32/win32k) I would like to know
what the status of different components are:

-  James, have you finished with your win32 class rewrite? What’s
the status of it? Is there a bug report concerning this rewrite?

-  Does anybody else currently work on cursors / GDI bitmap matters?

 

Best,

Hermès

 

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de victor
martinez
Envoyé : mardi 21 février 2017 23:35
À : ReactOS Development List
Objet : Re: [ros-dev] Office (Excel, Word...) 2010 on ReactOS

 

Somehow it reminds me to the release/capture issues GIMP is showing with the
mouse:
 
https://jira.reactos.org/browse/CORE-11775 

  _  

De: Ros-dev  en nombre de Giannis Adamopoulos

Enviado: martes, 21 de febrero de 2017 11:50:04
Para: ReactOS Development List
Asunto: Re: [ros-dev] Office (Excel, Word...) 2010 on ReactOS 

 

Hi! This is excellent news! It's good to know that Samuel started working
again on ntlm. I guess the most productive way to help him complete it would
be to write several tests for it (and also convert Samuel's test to formal
tests). Not only will it help Samuel but will help you understand ntlm
yourself and then help Samuel. (It is not like I knew anything about
activation contexts before. It was the tests I wrote that helped me come up
with clever way to let our comctl32 really do what both versions of
comctl32).

Keep up the good work!

PS: regarding the capture problems I would suggest writing more tests!
(Win32k is so hard to come right that you are searching in the dark unless
you test it thoroughly). My instinct says that this is the same bug with the
spider solitaire where the last card isn't released when you win a game.
There is a bug report for that but I don't remember the number. I think that
if the mouse button is released we should also release capture (and this
needs testing, perhaps even interactive testing).

Giannis

ReactOS Development List <  ros-dev@reactos.org>
wrote on Tue, February 21st, 2017, 2:59 AM:
> Hello everyone,
> 
> Today I was finally able to finish the installation of Office 2010 in
> ReactOS, using as a temporary measure the Wine’s NTLM layer that calls
into
> the ntlm_auth utility of Samba. This was done while Samuel is completing
his
> NTLM implementation.
> As this wine layer is here running on ReactOS, few modifications were
> needed, and I also needed to find a Windows build of Samba. I’ve found
one,
> by chance, at http://smithii.com/samba . Then, using ReactOS revision
73868
> (or later), and using this version of Samba, the Office installation
> finishes (reminder: the problem was due to the fact the installer needed
> NTLM to communicate with the “Office Software Platform Service”,
> OSPPSVC.EXE). We are now able to use Excel, Word, … on ReactOS, as shown
in
> this picture:
> http://i.imgur.com/fLEwoVI.png
> 
> There are now 2 main problems:
> - NTLM should be correctly implemented;
> - There are an awful lot of drawing problems with Office 2010 applications
> (similar to those of Office 2007 apps): for example, dragging the graph
> downwards shows his frame going upwards; there are many black regions that
> show up, etc...: It seems we have problems in coordinate frames. And other
> problems too. Also, we have some mouse capture problems: if you try to
> redimension the windows the normal way (bring mouse cursor on top of the
> border, left-click-maintained, move mouse, release left button), and then
> move the mouse inside the window, it continues to be redimensioned...
> As a result, I took ~=15 minutes to make this simple trivial picture
above,
> almost all the time taken to fight against window dimensioning & the
drawing
> problems.
> 
> But anyways, enjoy !
> 
> This will be part of my next blog report.
> 
> Cheers,
> Hermès
> 
> 
> ___
> 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] Office (Excel, Word...) 2010 on ReactOS

[Hermès BÉLUSCA-MAÏTO]

Yes I was thinking about that… Let’s know what other people think before doing 
this however.

 

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Alexander 
Rechitskiy
Envoyé : mardi 21 février 2017 06:17
À : ReactOS Development List
Objet : Re: [ros-dev] Office (Excel, Word...) 2010 on ReactOS

 

May be it is better to temporarily add Samba itself to ReactOS? It is not that 
simple to install it for average user.

 

I suggest add it at least as downloadable module, the same way we do with gecko

 

21.02.2017, 05:11, "Hermès BÉLUSCA-MAÏTO" <hermes.belu...@sfr.fr>:

He recently (since January) restarted to play with it. 

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Zachary Gorden
Envoyé : mardi 21 février 2017 03:04
À : ReactOS Development List
Objet : Re: [ros-dev] Office (Excel, Word...) 2010 on ReactOS

 

Is Samuel actually still actively working on NTLM? I thought that branch of his 
was pretty old. Might be something to consider a dev contract for.

 

On Mon, Feb 20, 2017 at 7:59 PM, Hermès BÉLUSCA-MAÏTO <hermes.belu...@sfr.fr> 
wrote:

Hello everyone,

Today I was finally able to finish the installation of Office 2010 in
ReactOS, using as a temporary measure the Wine’s NTLM layer that calls into
the ntlm_auth utility of Samba. This was done while Samuel is completing his
NTLM implementation.
As this wine layer is here running on ReactOS, few modifications were
needed, and I also needed to find a Windows build of Samba. I’ve found one,
by chance, at http://smithii.com/samba . Then, using ReactOS revision 73868
(or later), and using this version of Samba, the Office installation
finishes (reminder: the problem was due to the fact the installer needed
NTLM to communicate with the “Office Software Platform Service”,
OSPPSVC.EXE). We are now able to use Excel, Word, … on ReactOS, as shown in
this picture:
http://i.imgur.com/fLEwoVI.png

There are now 2 main problems:
- NTLM should be correctly implemented;
- There are an awful lot of drawing problems with Office 2010 applications
(similar to those of Office 2007 apps): for example, dragging the graph
downwards shows his frame going upwards; there are many black regions that
show up, etc...: It seems we have problems in coordinate frames. And other
problems too. Also, we have some mouse capture problems: if you try to
redimension the windows the normal way (bring mouse cursor on top of the
border, left-click-maintained, move mouse, release left button), and then
move the mouse inside the window, it continues to be redimensioned...
As a result, I took ~=15 minutes to make this simple trivial picture above,
almost all the time taken to fight against window dimensioning & the drawing
problems.

But anyways, enjoy !

This will be part of my next blog report.

Cheers,
Hermès


___
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

 

 

-- 
Best regards,

 

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

Re: [ros-dev] Office (Excel, Word...) 2010 on ReactOS

[Hermès BÉLUSCA-MAÏTO]

He recently (since January) restarted to play with it. 

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Zachary Gorden
Envoyé : mardi 21 février 2017 03:04
À : ReactOS Development List
Objet : Re: [ros-dev] Office (Excel, Word...) 2010 on ReactOS

 

Is Samuel actually still actively working on NTLM? I thought that branch of his 
was pretty old. Might be something to consider a dev contract for.

 

On Mon, Feb 20, 2017 at 7:59 PM, Hermès BÉLUSCA-MAÏTO <hermes.belu...@sfr.fr> 
wrote:

Hello everyone,

Today I was finally able to finish the installation of Office 2010 in
ReactOS, using as a temporary measure the Wine’s NTLM layer that calls into
the ntlm_auth utility of Samba. This was done while Samuel is completing his
NTLM implementation.
As this wine layer is here running on ReactOS, few modifications were
needed, and I also needed to find a Windows build of Samba. I’ve found one,
by chance, at http://smithii.com/samba . Then, using ReactOS revision 73868
(or later), and using this version of Samba, the Office installation
finishes (reminder: the problem was due to the fact the installer needed
NTLM to communicate with the “Office Software Platform Service”,
OSPPSVC.EXE). We are now able to use Excel, Word, … on ReactOS, as shown in
this picture:
http://i.imgur.com/fLEwoVI.png

There are now 2 main problems:
- NTLM should be correctly implemented;
- There are an awful lot of drawing problems with Office 2010 applications
(similar to those of Office 2007 apps): for example, dragging the graph
downwards shows his frame going upwards; there are many black regions that
show up, etc...: It seems we have problems in coordinate frames. And other
problems too. Also, we have some mouse capture problems: if you try to
redimension the windows the normal way (bring mouse cursor on top of the
border, left-click-maintained, move mouse, release left button), and then
move the mouse inside the window, it continues to be redimensioned...
As a result, I took ~=15 minutes to make this simple trivial picture above,
almost all the time taken to fight against window dimensioning & the drawing
problems.

But anyways, enjoy !

This will be part of my next blog report.

Cheers,
Hermès


___
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] Office (Excel, Word...) 2010 on ReactOS

[Hermès BÉLUSCA-MAÏTO]

Hello everyone,

Today I was finally able to finish the installation of Office 2010 in
ReactOS, using as a temporary measure the Wine’s NTLM layer that calls into
the ntlm_auth utility of Samba. This was done while Samuel is completing his
NTLM implementation.
As this wine layer is here running on ReactOS, few modifications were
needed, and I also needed to find a Windows build of Samba. I’ve found one,
by chance, at http://smithii.com/samba . Then, using ReactOS revision 73868
(or later), and using this version of Samba, the Office installation
finishes (reminder: the problem was due to the fact the installer needed
NTLM to communicate with the “Office Software Platform Service”,
OSPPSVC.EXE). We are now able to use Excel, Word, … on ReactOS, as shown in
this picture:
http://i.imgur.com/fLEwoVI.png

There are now 2 main problems:
- NTLM should be correctly implemented;
- There are an awful lot of drawing problems with Office 2010 applications
(similar to those of Office 2007 apps): for example, dragging the graph
downwards shows his frame going upwards; there are many black regions that
show up, etc...: It seems we have problems in coordinate frames. And other
problems too. Also, we have some mouse capture problems: if you try to
redimension the windows the normal way (bring mouse cursor on top of the
border, left-click-maintained, move mouse, release left button), and then
move the mouse inside the window, it continues to be redimensioned...
As a result, I took ~=15 minutes to make this simple trivial picture above,
almost all the time taken to fight against window dimensioning & the drawing
problems.

But anyways, enjoy !

This will be part of my next blog report.

Cheers,
Hermès


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

Re: [ros-dev] JIRA/FishEye upgrade this weekend

[Hermès BÉLUSCA-MAÏTO]

Hi Colin, thank you for your feedback!
Does this imply also rebuilding (and perhaps re-indexing again?) the FishEye 
cache?

Best,
Hermès.

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Colin Finck
Envoyé : jeudi 16 février 2017 17:49
À : 'ReactOS Development List'
Objet : [ros-dev] JIRA/FishEye upgrade this weekend

Hi all!

Due to the current unstable situation with FishEye, which also badly affects 
JIRA, I will attempt an upgrade of both applications on a new server this 
weekend.
As always I will do my best to keep the downtime low. But keep in mind that 
this involves migrating databases from one machine to another, so downtime may 
be longer than for a usual upgrade.

In the end, you can expect/hope for a much better performing setup with all the 
new features that got added to JIRA and FishEye over 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] Microsoft switched to Git

[Hermès BÉLUSCA-MAÏTO]

Because a « working solution » does not mean it is still optimal / efficient…

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Javier Agustìn 
Fernàndez Arroyo
Envoyé : mercredi 15 février 2017 16:04
À : ReactOS Development List
Objet : Re: [ros-dev] Microsoft switched to Git

 

why change a working solution?

its a questin i have done myself many times :P

 

On Wed, Feb 15, 2017 at 3:18 PM, Brandin L Claar  wrote:

Just move everything to GitHub:

 

https://github.com/blog/966-improved-subversion-client-support

-brandin


On Feb 15, 2017, at 06:32, ros-dev-requ...@reactos.org wrote:

Send Ros-dev mailing list submissions to
   ros-dev@reactos.org

To subscribe or unsubscribe via the World Wide Web, visit
   http://www.reactos.org/mailman/listinfo/ros-dev
or, via email, send a message with subject or body 'help' to
   ros-dev-requ...@reactos.org

You can reach the person managing the list at
   ros-dev-ow...@reactos.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ros-dev digest..."


Today's Topics:

  1. Re: Microsoft switched to Git (Ged Murphy)
  2. Re: Microsoft switched to Git (David Quintana (gigaherz))
  3. Re: Microsoft switched to Git (Colin Finck)
  4. Re: Microsoft switched to Git (David Quintana (gigaherz))
  5. Re: Microsoft switched to Git (Colin Finck)


--

Message: 1
Date: Wed, 15 Feb 2017 11:04:52 -
From: "Ged Murphy" 
To: "'ReactOS Development List'" 
Subject: Re: [ros-dev] Microsoft switched to Git
Message-ID: <004701d2877b$55983010$00c89030$@gmail.com>
Content-Type: text/plain;charset="utf-8"

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




--

Message: 2
Date: Wed, 15 Feb 2017 12:18:40 +0100
From: "David Quintana (gigaherz)" 
To: ReactOS Development List 
Subject: Re: [ros-dev] Microsoft switched to Git
Message-ID:
   
Content-Type: text/plain; charset="utf-8"

My belief is that the best path would be:

Phase 0: This is how we are now. We have SVN master (trunk), and a
read-only git mirror, and a semi-updated github mirror for when a
contributor really wants to submit git PRs.

Phase 1: Switch to using Git with PRs for submitting patches (Github's PR
system is really really nice these days, but other solutions exist). Setup
a SVN mirror "bot" that creates one svn commit for each push/merge detected
in the master branch, and allows the buildbots to continue working as they
do now.

This would allow the existing svn-patch workflow to continue working, but
commits on svn wouldn't be allowed anymore. Developers are expected to at
least TRY to learn to use git (it's not that hard! I promise!).

Phase 2: We switch the buildbots and testbots to pull from git, enable
testbot access for git PRs (such as with a github bot that responds to
"@rosbot runtest" or similar). The SVN mirror remains, for archival
purposes, but git commits aren't merged so regularly. Release tags/branches

Re: [ros-dev] Bootlogos for FOSDEM (was: "RE: FOSDEM 2017 - It's happening!")

[Hermès BÉLUSCA-MAÏTO]

Hi !

 

After this successful poll, the winner bootlogo is without doubt the (d) 
version :-)

I have committed it here : https://svn.reactos.org/svn/reactos?view=revision 
 
=73639

This is the file “1.bmp”.

As the bootlogo and the other boot images are 16-colour (palette) bitmaps, I 
had to adjust the palette of the other ones too (because they are occasionally 
rendered together).

 

Cheers,

Hermès

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Daniel Franzini
Envoyé : lundi 30 janvier 2017 17:20
À : ReactOS Development List
Objet : Re: [ros-dev] Bootlogos for FOSDEM (was: "RE: FOSDEM 2017 - It's 
happening!")

 

I'd go with (h) first then (d) second. I agree with David but I prefer the (h) 
version of the logo.

P.S.: I don't think that my opinion matters that much.

 

On Mon, Jan 30, 2017 at 2:08 PM, David Quintana (gigaherz)  
wrote:

Ah I just realised I never wrote which version I prefer: d.



Reason: it's more symmetric -- fills in the empty space to the right, 
corresponding to the copyright notice on the left.

 

On 30 January 2017 at 16:40, Yaroslav Veremenko  wrote:

I like c/d (preferably more d).

Yaroslav


-Original Message-
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Hermes 
BELUSCA-MAITO
Sent: Saturday, January 28, 2017 8:29 AM
To: 'ReactOS Development List' 
Subject: [ros-dev] Bootlogos for FOSDEM (was: "RE: FOSDEM 2017 - It's 
happening!")

Hello everyone,

Upon an idea by Jared Smudde I modified a bit the ReactOS bootlogo to 
incorporate in addition the FOSDEM logo in it. See 
http://polariton.ad-l.ink/6WhjqNRrM/image.png or the attached file.
I have done several versions and I would like to hear what you think from them 
(if possible, make a choice).

Regards,
Hermès


-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Colin Finck 
Envoyé : jeudi 26 janvier 2017 00:16 À : 'ReactOS Development List'
Objet : [ros-dev] FOSDEM 2017 - It's happening!

Hi all!

Hermès and me have just decided to go to FOSDEM this year. Which is a really 
good idea considering that we have a booth to staff there ;)

Planning is currently happening at
https://docs.google.com/document/d/1ofYUc7j0XwDH9SmNlGzNZlO8jOGhoPUn7KTRcFmanIc
Just request access if you're a ReactOS member and like to add or comment stuff 
there.

Hermès will be preparing an ISO in the upcoming days. Please test current trunk 
to see if any last minute fixes need to go there. If you have ideas what cool 
apps we shall show at FOSDEM, please also share them here.
We will go with burning and giving away CDs again (hopefully the last time 
before USBs do it).

I hope that this definite plan will also motivate others to join us or visit 
our booth! :)


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

 


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




-- 

Daniel

"Let us change our traditional attitude to the construction of programs. 
Instead of imagining that our main task is to instruct a computer what to do, 
let us concentrate rather on explaining to human beings what we want a computer 
to do." (Donald Knuth)

"Yes, technogeeks can be funny, even if only to each other." 
(http://www.boogieonline.com/revolution/science/humor/)"

"Man is driven to create; I know I really love to create things. And while I'm 
not good at painting, drawing, or music, I can write software." (Yukihiro 
Matsumoto, a.k.a. ``Matz'')

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

Re: [ros-dev] FOSDEM 2017 - It's happening!

[Hermès BÉLUSCA-MAÏTO]

Hello all!

Since this message is sent to the public mailing list, let me mention which 
programs I have in top of my head, that would be nice to have for the show 
(most of them are already in rapps, but it would be nice to retest them just to 
be sure ...) :
- Foxit PDF Reader,
- Notepad++ (6.9, or latest version 7+),
- Word/Excel/PPT viewers (the PPT viewer wants a printer available, and iirc it 
is also calling a stubbed print API function, Cc Colin ;) )
- LibreOffice, if possible. I know that the latest versions somewhat make 
ReactOS hang (--> win32k?), so possibly using an older version.
- Photoshop? Does this even run on ROS?
- Far Manager 3+
- Some DOS games (Daniel/Victor/someone else please send suggestions!)
- ...

Best,
Hermès

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Colin Finck
Envoyé : jeudi 26 janvier 2017 00:16
À : 'ReactOS Development List'
Objet : [ros-dev] FOSDEM 2017 - It's happening!

Hi all!

Hermès and me have just decided to go to FOSDEM this year. Which is a really 
good idea considering that we have a booth to staff there ;)

Planning is currently happening at
https://docs.google.com/document/d/1ofYUc7j0XwDH9SmNlGzNZlO8jOGhoPUn7KTRcFmanIc
Just request access if you're a ReactOS member and like to add or comment stuff 
there.

Hermès will be preparing an ISO in the upcoming days. Please test current trunk 
to see if any last minute fixes need to go there. If you have ideas what cool 
apps we shall show at FOSDEM, please also share them here.
We will go with burning and giving away CDs again (hopefully the last time 
before USBs do it).

I hope that this definite plan will also motivate others to join us or visit 
our booth! :)


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

[ros-dev] Tr: Re: Ros-diffs Digest, Vol 150, Issue 29

[Hermès BÉLUSCA - MAÏTO]

Hi Eric, are you sure this will not break compatibility with WIn2k3 
applications? For example by quickly googling I've noticed some people rely on 
this Index value for their Time Zone stuff.


Example: 
https://www.experts-exchange.com/questions/24948382/How-to-get-Time-Zone-index-from-registry-in-windows-Vista-onwards.html


Also, since 
http://microsoft.public.win32.programmer.ui.narkive.com/SOU9r3ef/time-zones-in-registry
 clearly says that the "IndexMapping" reg_multi_sz is for doing the mapping 
with the "Index" values of each time zone, you could have also deleted it! 
(note that this mapping value is indeed absent on Windows 7 for example).



Cheers,


Hermès




Message du : 03/07/2016 20:42
De : ros-diffs-requ...@reactos.org
A : ros-di...@reactos.org
Copie à : 
Sujet : Ros-diffs Digest, Vol 150, Issue 29



[...]



Today's Topics:

[...]



3. [ekohl] 71801: [BOOTDATA] Remove the Index value from the
time zone entries. We do not need it any more and it has been
removed from Windows Vista. (ek...@svn.reactos.org)


--

Message: 3
Date: Sun, 03 Jul 2016 18:40:27 -
From: ek...@svn.reactos.org
To: ros-di...@reactos.org
Subject: [ros-diffs] [ekohl] 71801: [BOOTDATA] Remove the Index value
from the time zone entries. We do not need it any more and it has been
removed from Windows Vista.
Message-ID: 
Content-Type: text/plain; charset="utf-8"

Author: ekohl
Date: Sun Jul 3 18:40:27 2016
New Revision: 71801

URL: http://svn.reactos.org/svn/reactos?rev=71801=rev
Log:
[BOOTDATA]
Remove the Index value from the time zone entries. We do not need it any more 
and it has been removed from Windows Vista.

Modified:
trunk/reactos/boot/bootdata/hivesft.inf

Modified: trunk/reactos/boot/bootdata/hivesft.inf
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/hivesft.inf?rev=71801=71800=71801=diff
==
--- trunk/reactos/boot/bootdata/hivesft.inf [iso-8859-1] (original)
+++ trunk/reactos/boot/bootdata/hivesft.inf [iso-8859-1] Sun Jul 3 18:40:27 2016
@@ -406,7 +406,6 @@
HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Dateline Standard 
Time","Display",0x,"(GMT-12:00) International Date Line West"
HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Dateline Standard 
Time","Dlt",0x,"Dateline Daylight Time"
HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Dateline Standard 
Time","Std",0x,"Dateline Standard Time"
-HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Dateline 
Standard Time","Index",0x00010001,0
HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Dateline Standard 
Time","TZI",0x0001,\
0xd0,0x02,0x00,0x00,0x00,0x00,0x00,0x00,0xc4,0xff,0xff,0xff,\
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,\


(skipping)



@@ -1125,7 +1046,6 @@
HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Tonga Standard 
Time","Display",0x,"(GMT+13:00) Nuku'alofa"
HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Tonga Standard 
Time","Dlt",0x,"Tonga Daylight Time"
HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Tonga Standard 
Time","Std",0x,"Tonga Standard Time"
-HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Tonga Standard 
Time","Index",0x00010001,300
HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Tonga Standard 
Time","TZI",0x0001,\
0xf4,0xfc,0xff,0xff,0x00,0x00,0x00,0x00,0xc4,0xff,0xff,0xff,\
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,\




--

Subject: Digest Footer

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

--

End of Ros-diffs Digest, Vol 150, Issue 29
**___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[ros-dev] Spam attack, continuing... (episode 12345/infinity)

[Hermès BÉLUSCA - MAÏTO]

So, guys, ...

We are yet again subject to a spam attack on the forums AND in the wiki (since 
yesterday for the latter), but nothing was done yet  !!

https://reactos.org/forum/
https://reactos.org/wiki/Special:RecentChanges

For the wiki, the abuse filter hasn't blocked everything !!

Regards,
Hermès
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

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

[Hermès BÉLUSCA - MAÏTO]

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] Spam, the irony

[Hermès BÉLUSCA - MAÏTO]

Hi all, I guess this post is spam :
http://www.reactos.org/forum/viewtopic.php?f=2

=9752#p120604

Ironically placed inside the thread titled “Spam Bot Detection Guidelines”
^^

 

Cheers,

Hermès.

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

Re: [ros-dev] Ros-diffs Digest, Vol 146, Issue 58

[Hermès BÉLUSCA - MAÏTO]

This is indeed an amazing feature, until you notice that you've tested
already local build compilation (just before committing) and neither GCC nor
MSVC detected any error, and only after commit you see that it breaks the
build bots...

Hermès.

-Message d'origine-
Date: Thu, 17 Mar 2016 07:55:00 -
From: pschweit...@svn.reactos.org
To: ros-di...@reactos.org
Subject: [ros-diffs] [pschweitzer] 71017: [VFATLIB] Hint for future
and current developers: there's a hidden feature in ReactOS, you can
build it locally before committing, so that you can check whether
your
commit bre...
Message-ID: 
Content-Type: text/plain; charset="utf-8"

Author: pschweitzer
Date: Thu Mar 17 07:55:00 2016
New Revision: 71017

URL: http://svn.reactos.org/svn/reactos?rev=71017=rev
Log:
[VFATLIB]
Hint for future and current developers: there's a hidden feature in ReactOS,
you can build it locally before committing, so that you can check whether
your commit breaks build...
Amazing, isn't it?

Modified:
trunk/reactos/lib/fslib/vfatlib/check/common.h

Modified: trunk/reactos/lib/fslib/vfatlib/check/common.h
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/lib/fslib/vfatlib/check/com
mon.h?rev=71017=71016=71017=diff

==
--- trunk/reactos/lib/fslib/vfatlib/check/common.h  [iso-8859-1]
(original)
+++ trunk/reactos/lib/fslib/vfatlib/check/common.h  [iso-8859-1] Thu Mar
17 07:55:00 2016
@@ -32,7 +32,7 @@
 void die_func(const char *msg, ...);
 #define die(msg, ...)   \
 do {\
-die_func("DIE! (%s:%d) " msg "\n", __RELFILE__, __LINE__,
##__VA_ARGS__)  \
+die_func("DIE! (%s:%d) " msg "\n", __RELFILE__, __LINE__, 
+ ##__VA_ARGS__);  \
 } while (0)
 
 /* Displays a prinf-style message and terminates the program. */ @@ -42,7
+42,7 @@  void pdie_func(const char *msg, ...);
 #define pdie(msg, ...)   \
 do {\
-pdie_func("P-DIE! (%s:%d) " msg "\n", __RELFILE__, __LINE__,
##__VA_ARGS__)  \
+pdie_func("P-DIE! (%s:%d) " msg "\n", __RELFILE__, __LINE__, 
+ ##__VA_ARGS__);  \
 } while (0)
 
 /* Like die, but appends an error message according to the state of errno.
*/




--

Subject: Digest Footer

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

--

End of Ros-diffs Digest, Vol 146, Issue 58
**

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

[ros-dev] TR: ReactOs newbie. Help to get started with bug fixes.

[Hermès BÉLUSCA - MAÏTO]

Hi Rama, I’m retransmitting your mail to the reactos developers mailing-list so 
that other people can also guide you.

 

There are some ideas already proposed for the GSoC that you can see on this 
page:

https://www.reactos.org/wiki/Google_Summer_of_Code_2016_Ideas

and on which you can choose, depending on your familiarity with one or any 
other proposals, or bring your own proposal (read also 
https://www.reactos.org/wiki/Google_Summer_of_Code_2016 for more details).

 

Regards,

Hermès BÉLUSCA - MAÏTO

 

 

De : Rama Teja G [mailto:ramatej...@gmail.com] 
Envoyé : mardi 15 mars 2016 15:10
À : hermes.belu...@sfr.fr
Objet : ReactOs newbie. Help to get started with bug fixes.

 

Hi,

   This is Rama Teja.G a student applying to reactOs for GSoc. I want to get 
started with the community(may be some patches?). I am not sure how to get 
started. Can you please help me. Any advice will be appreciated.

Thanks in advance,

Rama Teja.G

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

Re: [ros-dev] Build Crash Revision 70918

[Hermès BÉLUSCA - MAÏTO]

If I remember correctly, in pure VS C/C++ projects using precompiled headers
(ie. with stdafx.h/stdafx.c (or cpp) ), when using #pragma once in stdafx.h,
the compiler doesn’t fail. That’s why I’m surprised of seeing that problem
with ROS. 

 

Hermès

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Amine Khaldi
Envoyé : samedi 5 mars 2016 16:10
À : ros-dev@reactos.org
Objet : Re: [ros-dev] Build Crash Revision 70918

 

Hi Amine, why haven't the build bots complained about the #pragma once? (and
the more fundamental question: why does the #pragma once make compilation
fail for *some* people?)

Hi,

The pragma issue makes compilation break for *all* people except those who
have PCH set to 0. As to build bots, I assume they are using ccache builds
with PCH turned off.

Cheers,
Amine.

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

Re: [ros-dev] [ros-diffs] [hbelusca] 70869: [AUTOCHK][CHKDSK]: Minor fixes / formatting. Really add chkdsk to build. [FMIFS]: Quickly implement the chkdsk function, the same way as it is done for the

[Hermès BÉLUSCA - MAÏTO]

I wanted to add a proper '?' switch, but I've seen that if I do that, chkdsk
in its current implementation runs afterwards a check (I noticed that after
the commit that added the '?'). So I temporarily disabled it in this commit
for further investigation (aka. modifying the ProcessCommandLine procedure
so that it doesn't run the checkdisk if you use '?', *and* such that it
doesn't say that '?' is an unrecognized cmdline option).

Hermès.

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Thomas Faber
Envoyé : jeudi 3 mars 2016 11:27
À : ros-dev@reactos.org
Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 70869: [AUTOCHK][CHKDSK]: Minor
fixes / formatting. Really add chkdsk to build. [FMIFS]: Quickly implement
the chkdsk function, the same way as it is done for the formatting function.

On 2016-03-03 01:36, hbelu...@svn.reactos.org wrote:
> @@ -160,9 +163,9 @@
>  
>  switch (argv[i][1])
>  {
> -case L'?':
> -Usage(argv[0]);
> -break;
> +// case L'?':
> +// Usage(argv[0]);
> +// return i;
>  
>  case L'F': case L'f':
>  {

What is the purpose of this?


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

[ros-dev] TR: [ros-diffs] [hbelusca] 70857: [USETUP]: In case chkdsk detects some disk errors, just display a warning message but allow the user to continue the installation.

[Hermès BÉLUSCA - MAÏTO]

(Message resent because the other one was automatically rejected because it was 
too large).

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Hermès BÉLUSCA 
- MAÏTO
Envoyé : mercredi 2 mars 2016 10:14
À : 'ReactOS Development List'
Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 70857: [USETUP]: In case chkdsk 
detects some disk errors, just display a warning message but allow the user to 
continue the installation.

Thanks Pierre for your ideas. I will modify the message box to try to integrate 
those options.
At the moment we are (in usetup) limited, so repairing the errors will be done 
later. The rest can be implemented easily.
The fact is that the only error that happens as soon as you write files using 
ReactOS' fastfat driver is that fastfat doesn't update the "free cluster 
number" field in the FSInfo sector of FAT32 disk.
Because of that, each time you try to reinstall ReactOS without formatting on 
such a partition, you get the checkdisk complaining that this number is wrong & 
needs to be corrected, but then the VfatChkdsk returns a non-success error that 
is interpreted by Usetup as a failure (and the error message appears, 
forbidding the user to continue nevertheless to install ROS).

Cheers,
Hermès

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Pierre 
Schweitzer Envoyé : mercredi 2 mars 2016 08:47 À : ros-dev@reactos.org Objet : 
Re: [ros-dev] [ros-diffs] [hbelusca] 70857: [USETUP]: In case chkdsk detects 
some disk errors, just display a warning message but allow the user to continue 
the installation.

No?!
This is totally broken and is to be reverted.

If you detect errors, there are only 3 issues:
- Offer the user to attempt to repair errors
- Offer the user to format
- Exit (as it was done previously)

(If repairing fails, you fall into the two next cases).
You cannot ignore errors and let the use write on a borked file system.


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

Re: [ros-dev] [ros-diffs] [hbelusca] 70857: [USETUP]: In case chkdsk detects some disk errors, just display a warning message but allow the user to continue the installation.

[Hermès BÉLUSCA - MAÏTO]

Thanks Pierre for your ideas. I will modify the message box to try to integrate 
those options.
At the moment we are (in usetup) limited, so repairing the errors will be done 
later. The rest can be implemented easily.
The fact is that the only error that happens as soon as you write files using 
ReactOS' fastfat driver is that fastfat doesn't update the "free cluster 
number" field in the FSInfo sector of FAT32 disk.
Because of that, each time you try to reinstall ReactOS without formatting on 
such a partition, you get the checkdisk complaining that this number is wrong & 
needs to be corrected, but then the VfatChkdsk returns a non-success error that 
is interpreted by Usetup as a failure (and the error message appears, 
forbidding the user to continue nevertheless to install ROS).

Cheers,
Hermès

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Pierre 
Schweitzer
Envoyé : mercredi 2 mars 2016 08:47
À : ros-dev@reactos.org
Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 70857: [USETUP]: In case chkdsk 
detects some disk errors, just display a warning message but allow the user to 
continue the installation.

No?!
This is totally broken and is to be reverted.

If you detect errors, there are only 3 issues:
- Offer the user to attempt to repair errors
- Offer the user to format
- Exit (as it was done previously)

(If repairing fails, you fall into the two next cases).
You cannot ignore errors and let the use write on a borked file system.

Le 02/03/2016 01:51, hbelu...@svn.reactos.org a écrit :
> Author: hbelusca
> Date: Wed Mar  2 00:51:48 2016
> New Revision: 70857
> 
> URL: http://svn.reactos.org/svn/reactos?rev=70857=rev
> Log:
> [USETUP]: In case chkdsk detects some disk errors, just display a warning 
> message but allow the user to continue the installation.
> 
> Modified:
> trunk/reactos/base/setup/usetup/interface/usetup.c
> trunk/reactos/base/setup/usetup/lang/bg-BG.h
> trunk/reactos/base/setup/usetup/lang/bn-BD.h
> trunk/reactos/base/setup/usetup/lang/cs-CZ.h
> trunk/reactos/base/setup/usetup/lang/da-DK.h
> trunk/reactos/base/setup/usetup/lang/de-DE.h
> trunk/reactos/base/setup/usetup/lang/el-GR.h
> trunk/reactos/base/setup/usetup/lang/en-US.h
> trunk/reactos/base/setup/usetup/lang/es-ES.h
> trunk/reactos/base/setup/usetup/lang/et-EE.h
> trunk/reactos/base/setup/usetup/lang/fr-FR.h
> trunk/reactos/base/setup/usetup/lang/he-IL.h
> trunk/reactos/base/setup/usetup/lang/it-IT.h
> trunk/reactos/base/setup/usetup/lang/ja-JP.h
> trunk/reactos/base/setup/usetup/lang/lt-LT.h
> trunk/reactos/base/setup/usetup/lang/ms-MY.h
> trunk/reactos/base/setup/usetup/lang/nl-NL.h
> trunk/reactos/base/setup/usetup/lang/pl-PL.h
> trunk/reactos/base/setup/usetup/lang/pt-BR.h
> trunk/reactos/base/setup/usetup/lang/ro-RO.h
> trunk/reactos/base/setup/usetup/lang/ru-RU.h
> trunk/reactos/base/setup/usetup/lang/sk-SK.h
> trunk/reactos/base/setup/usetup/lang/sq-AL.h
> trunk/reactos/base/setup/usetup/lang/sv-SE.h
> trunk/reactos/base/setup/usetup/lang/tr-TR.h
> trunk/reactos/base/setup/usetup/lang/uk-UA.h
> trunk/reactos/base/setup/usetup/mui.h
> 
> Modified: trunk/reactos/base/setup/usetup/interface/usetup.c
> URL: 
> http://svn.reactos.org/svn/reactos/trunk/reactos/base/setup/usetup/int
> erface/usetup.c?rev=70857=70856=70857=diff
> ==
> --- trunk/reactos/base/setup/usetup/interface/usetup.c[iso-8859-1] 
> (original)
> +++ trunk/reactos/base/setup/usetup/interface/usetup.c[iso-8859-1] 
> Wed Mar  2 00:51:48 2016
> @@ -3154,13 +3154,15 @@
>  if (!NT_SUCCESS(Status))
>  {
>  DPRINT("ChkdskPartition() failed with status 0x%08lx\n", Status);
> -sprintf(Buffer, "Setup failed to verify the selected 
> partition.\n"
> +// sprintf(Buffer, "Setup failed to verify the selected 
> partition.\n"
> +sprintf(Buffer, "ChkDsk detected some disk errors.\n"
>  "(Status 0x%08lx).\n", Status);
>  PopupError(Buffer,
> -   MUIGetString(STRING_REBOOTCOMPUTER),
> +   // MUIGetString(STRING_REBOOTCOMPUTER),
> +   MUIGetString(STRING_CONTINUE),
> Ir, POPUP_WAIT_ENTER);
>  
> -return QUIT_PAGE;
> +// return QUIT_PAGE;
>  }
>  
>  PartEntry->NeedsCheck = FALSE;
> 
> Modified: trunk/reactos/base/setup/usetup/lang/bg-BG.h
> URL: 
> http://svn.reactos.org/svn/reactos/trunk/reactos/base/setup/usetup/lan
> g/bg-BG.h?rev=70857=70856=70857=diff
> ==
> --- trunk/reactos/base/setup/usetup/lang/bg-BG.h  [iso-8859-1] (original)
> +++ trunk/reactos/base/setup/usetup/lang/bg-BG.h  [iso-8859-1] Wed Mar  2 
> 00:51:48 2016
> @@ 

[ros-dev] ReactOS SVN version naming

[Hermès BÉLUSCA - MAÏTO]

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] [ros-diffs] [hbelusca] 70707: [CMLIB]: Implement CmpFreeSecurityDescriptor. See r70609. CORE-10793 CORE-10796

[Hermès BÉLUSCA - MAÏTO]

Yes: When the key is initialized and a security block is added ,the refcount
is set to 1 (see e.g.
https://git.reactos.org/?p=reactos.git;a=blob;f=reactos/tools/mkhive/cmi.c;h
b=HEAD#l173 ), and then, it is increased when other keys use this security
block and decreased when other keys are deleted (and hence, release this
security block). When you delete the key and the security refcount was == 1,
then it means this was the last reference to the security block that is
going to disappear, hence you can remove now the security block.

Also, http://www.sentinelchicken.com/data/TheWindowsNTRegistryFileFormat.pdf
end of section 11, page 5, seems to back up what I say.

Regards,
Hermès

P.S.: http://amnesia.gtisc.gatech.edu/~moyix/suzibandit.ltd.uk/MSc/ is a
nice source of information about the NT registry (in case you didn't know it
already).


-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Alex Ionescu
Envoyé : jeudi 11 février 2016 00:58
À : ReactOS Development List
Cc : Linda Wang
Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 70707: [CMLIB]: Implement
CmpFreeSecurityDescriptor. See r70609. CORE-10793 CORE-10796

On Wed, Feb 10, 2016 at 5:28 PM,   wrote:
> else // if (SecurityData->ReferenceCount <= 1)

Is the intent to free the data while SecurityData->RefCount will remain at
1?!

Best regards,
Alex Ionescu

___
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] 70674: [CMLIB]: Demote the DPRINT1 saying that we leak the security block descriptor to a DPRINT. People (Alex & me) working on cmlib already know this. "Fixes" ti

[Hermès BÉLUSCA - MAÏTO]

I will have a look at this function when I'll have time.

Regards,
Hermès

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Alex Ionescu
Envoyé : mardi 2 février 2016 06:38
À : ReactOS Development List
Cc : Linda Wang
Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 70674: [CMLIB]: Demote the
DPRINT1 saying that we leak the security block descriptor to a DPRINT.
People (Alex & me) working on cmlib already know this. "Fixes" timeout
problems of the t...

I think you guys took more time to debug and mess with the DPRINT then it
would've taken to implement the function. Come on guys.
Best regards,
Alex Ionescu


On Mon, Feb 1, 2016 at 3:10 PM,   wrote:
> Author: hbelusca
> Date: Mon Feb  1 23:10:38 2016
> New Revision: 70674
>
> URL: http://svn.reactos.org/svn/reactos?rev=70674=rev
> Log:
> [CMLIB]: Demote the DPRINT1 saying that we leak the security block
descriptor to a DPRINT. People (Alex & me) working on cmlib already know
this. "Fixes" timeout problems of the testbots due to spamming this dprint.
>
> Modified:
> trunk/reactos/lib/cmlib/cmkeydel.c
>
> Modified: trunk/reactos/lib/cmlib/cmkeydel.c
> URL: 
> http://svn.reactos.org/svn/reactos/trunk/reactos/lib/cmlib/cmkeydel.c?
> rev=70674=70673=70674=diff
> ==
> 
> --- trunk/reactos/lib/cmlib/cmkeydel.c  [iso-8859-1] (original)
> +++ trunk/reactos/lib/cmlib/cmkeydel.c  [iso-8859-1] Mon Feb  1 
> +++ 23:10:38 2016
> @@ -215,7 +215,7 @@
>  }
>
>  /* FIXME: This leaks the security desriptor! */
> -DPRINT1("Potentially leaking key security descriptor. Please call
CmpFreeSecurityDescriptor\n");
> +DPRINT("Potentially leaking key security descriptor. Please call 
> + CmpFreeSecurityDescriptor\n");
>
>  /* Free the key body itself, and then return our status */
>  if (!CmpFreeKeyBody(Hive, Cell)) return 
> STATUS_INSUFFICIENT_RESOURCES;
>
>

___
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] [cfinck] 70507: [BOOTVID] Change the Blue Screen Font hardcoded into bootvid.dll to the Open Source "Anonymous Pro" font, which makes a nice 8x13 font. Blue Screens now look

[Hermès BÉLUSCA - MAÏTO]

Hi ! It seems that your web-browser (as well as the Windows image preview,
usually), likes to smooth the images, and this is what happens, indeed, and
I agree this is quite problematic if e.g. you want to zoom on small portions
of the images.

Also, we also use now the Plan-9 font in the latest trunk, so you can also
compare it with the Anonymous pro font J

 

Cheers,

Hermès

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Timo Kreuzer
Envoyé : jeudi 7 janvier 2016 01:37
À : ReactOS Development List
Objet : Re: [ros-dev] [ros-diffs] [cfinck] 70507: [BOOTVID] Change the Blue
Screen Font hardcoded into bootvid.dll to the Open Source "Anonymous Pro"
font, which makes a nice 8x13 font. Blue Screens now look like this:
http://fs5.d...

 

In my browser (both FF as well as IE) it looks blurred. It even looks
blurred, when i paste it into Thunderbird, so there is no way to show a
difference :)

Anyway, I'll attach the results, download them and compare.


Am 07.01.2016 um 01:21 schrieb Javier Agustìn Fernàndez Arroyo:

hm?

i see it right on Firefox 43.0.2

 

On Wed, Jan 6, 2016 at 11:41 PM, Timo Kreuzer  wrote:


For everyone who thinks this looks terrible: don't view it in your browser.
Instead download it and open it with a proper image viewer. Then your eyes
stop bleeding and it actually looks good :)

Timo

Am 06.01.2016 um 10:31 schrieb cfi...@svn.reactos.org:

Author: cfinck
Date: Wed Jan  6 09:31:53 2016
New Revision: 70507

URL: http://svn.reactos.org/svn/reactos?rev=70507
 =rev
Log:
[BOOTVID]
Change the Blue Screen Font hardcoded into bootvid.dll to the Open Source
"Anonymous Pro" font, which makes a nice 8x13 font.
Blue Screens now look like this:
http://fs5.directupload.net/images/160106/ehv6245t.png

[BOOTVID_FONT_GENERATOR]
In case you find an even better font, you now have a nice little tool to
test that font and generate the corresponding FontData array for bootvid.

Added:
 trunk/rosapps/applications/devutils/bootvid_font_generator/
 
trunk/rosapps/applications/devutils/bootvid_font_generator/CMakeLists.txt
(with props)
 
trunk/rosapps/applications/devutils/bootvid_font_generator/bootvid_font_gene
rator.c   (with props)
Modified:
 trunk/reactos/drivers/base/bootvid/arm/bootdata.c
 trunk/reactos/drivers/base/bootvid/i386/bootdata.c
 trunk/rosapps/applications/devutils/CMakeLists.txt

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

Modified: trunk/reactos/drivers/base/bootvid/arm/bootdata.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/base/bootvid/arm/bo
otdata.c?rev=70507

=70506=70507=diff

Modified: trunk/reactos/drivers/base/bootvid/i386/bootdata.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/base/bootvid/i386/b
ootdata.c?rev=70507

=70506=70507=diff

Modified: trunk/rosapps/applications/devutils/CMakeLists.txt
URL:
http://svn.reactos.org/svn/reactos/trunk/rosapps/applications/devutils/CMake
Lists.txt?rev=70507

=70506=70507=diff

Added:
trunk/rosapps/applications/devutils/bootvid_font_generator/CMakeLists.txt
URL:
http://svn.reactos.org/svn/reactos/trunk/rosapps/applications/devutils/bootv
id_font_generator/CMakeLists.txt?rev=70507

Added:
trunk/rosapps/applications/devutils/bootvid_font_generator/bootvid_font_gene
rator.c
URL:
http://svn.reactos.org/svn/reactos/trunk/rosapps/applications/devutils/bootv
id_font_generator/bootvid_font_generator.c?rev=70507







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

[Hermès BÉLUSCA - MAÏTO]

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=search=HEAD=grep=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' <ros-dev@reactos.org>
> 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=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=70407=70408=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, );
>>  
>>  /* 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

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

[Hermès BÉLUSCA - MAÏTO]

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=search=HEAD=grep=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' <ros-dev@reactos.org>
> 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=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=70407=70408=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, );
>>  
>>  /* 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_OBJE

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

[Hermès BÉLUSCA - MAÏTO]

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=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=70407=70408=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, );
>  
>  /* 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

Re: [ros-dev] Something is wron again with getbuilds

[Hermès BÉLUSCA - MAÏTO]

Nothing seems wrong so far...

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Alexander 
Rechitskiy
Envoyé : mercredi 16 décembre 2015 19:54
À : ReactOS Development List
Objet : [ros-dev] Something is wron again with getbuilds

 

Hi!

 

  https://www.reactos.org/getbuilds

 

What is wrong with this page again?

 

-- 

С уважением,
Alexander Rechitskiy

+79286331900

 

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

Re: [ros-dev] kbswitch update

[Hermès BÉLUSCA - MAÏTO]

Hi, my question is inline the previous mail.

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Colin Finck
Envoyé : lundi 7 décembre 2015 04:48
À : ros-dev@reactos.org
Objet : Re: [ros-dev] kbswitch update

> A proper per-application keyboard layout switcher as part of the Language
Bar should also be implemented as a shell extension instead of a tray icon
to be as flexible as the Windows original.
> To get notified of focus changes, an application should probably hook the
EVENT_SYSTEM_FOREGROUND event using the SetWinEventHook API. The rest can be
done using calls to GetForegroundWindow, GetWindowThreadProcessId and
GetKeyboardLayout as you already suggested.

Shell extension?! Are you completely sure? On windows 2000 and 2003 this is
usually done by an external application, called internat.exe on windows
2000, and ctfmon.exe on windows 2003.
- on windows 2000, internat.exe uses imm32.dll and shell32.dll (the latter
is used to create the language icon in the traybar);
- on windows 2003, ctfmon.exe loads msctf.dll and msutb.dll, having the
effect of creating the toolbar (when it is in floating mode, if you kill
ctfmon.exe you'll see it disappear; however, if it is anchored in the
explorer taskbar, then it'll remain alive until you kill and restart
explorer.exe . Note to myself: it appears explorer.exe loads on demand those
dlls also so that the language bar can be redisplayed if you force-click on
the "Language bar" menu item in the taskbar property menu). On Windows
Vista+, I don't know how it works (but we don't copy vista+ up to now). They
have a language service stuff...

In any case, our current architecture regarding the language bar/icon is
more similar to the one of windows 2000 (but our language app is called
kbswitch.exe instead of internat.exe). But on windows 2000 (contrary to
reactos, and similarly to win2k3), if you select e.g. a german keyboard for
taskmgr while your default keyboard was English, then when you focus on
taskmgr you get the german keyboard and when you focus elsewhere (or open a
new app), you get English (or the other language for that other app), i.e.
as Hans-Peter wants. That's IME stuff, it looks working together with GUI
threads; this needs also some cooperation with user32.dll / win32k.sys;
however the IMM/IME code in win32k is partly broken.

Cheers,
Hermès.

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

Re: [ros-dev] wtf iso.reactos.org is down for ages?

[Hermès BÉLUSCA - MAÏTO]

Hi,

 

Thank you for all of your information J It’s nice that the power systems were 
able to handle gracefully the power outages; and I can only understand it’s not 
the cause of the infra now that the problem comes from, since it appears as you 
say that parts of Sweden is out of electricity ^^.

 

Cheers,

Hermès.

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Magnus Olsen
Envoyé : lundi 7 décembre 2015 10:49
À : ReactOS Development List
Objet : Re: [ros-dev] wtf iso.reactos.org is down for ages?

 

I can only guess what happen at the datacenter 

at moment in sweden we got big power shoutdown thanks to two diffnent storms. 
and the stroms are still active most part of sweden. 

 

The lower part of sweden and the land close to norwage allot datacenter and 
house in thuse area does not have any power at all. the power company are 
already in progress to repiar the damges power grids and power start coming 
back slowy in thuse area.

 

I do not known where the reactos datacenter are locatated in sweden.

 

 

 

On Mon, Dec 7, 2015 at 4:27 AM, Colin Finck <co...@reactos.org> wrote:

Am 06.12.2015 um 10:29 schrieb Hermès BÉLUSCA - MAÏTO:
> Anybody really knows what happened there ? (since it’s not the first
> time this part of the infra fails like that).

This time, we really had a major power failure at Jan's site that lasted
for two days. The UPS systems were able to keep up most of the systems
for 10 more minutes till these were gracefully shut down.

Actually, this has been the only time we had such a major power outage.
Nevertheless, there is a single server "Fezile" from 2007 (responsible
for iso.reactos.org, Doxygen, VMware Testbot) that has been troubling
over the year:

* In December 2014, its motherboard failed. As a replacement one was
cheaply available, we didn't need more performance for its tasks and the
system was fully set up, it was decided to just order that one and
continue using the system. Unfortunately, replacing it took longer than
expected. It's now fully up and running again, but next time we will
definitely order a new server.

* Recently, we also had Fezile crashing several times due to a faulty
UPS it was connected to. This has been fixed in the meantime.

* The latest total power outage is of course not Fezile's fault, but
affected each and every server there. Nevertheless, those other servers
(e.g. additional Testbots) have basically been up every day of the year,
which I find quite reliable.


I'm open for every affordable idea to make this infrastructure more
reliable. I just personally don't think we can make better than Jan's
site, since it offers us total flexibility on what servers to install,
how to interconnect them, and the help of a definite ReactOS supporter
in case something fails.

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] wtf iso.reactos.org is down for ages?

[Hermès BÉLUSCA - MAÏTO]

Anybody really knows what happened there ? (since it’s not the first time
this part of the infra fails like that). By the way I noticed that the
VMWare testbots (regular and hybrid) are still off.

 

Cheers,

Hermès.

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Christoph
von Wittich
Envoyé : dimanche 6 décembre 2015 18:52
À : Sylvain Petreolle; ReactOS Development List
Objet : Re: [ros-dev] wtf iso.reactos.org is down for ages?

 

Should work again.

Am 06.12.2015 um 16:54 schrieb Sylvain Petreolle:

Are there any updates ?

This blocks me from fixing network bugs, testman lacks the last 20 commits
results.

 

Kind regards, Sylvain Petreolle

 


  _  


De : Colin Finck   
À : ros-dev@reactos.org 
Envoyé le : Samedi 5 décembre 2015 6h40
Objet : Re: [ros-dev] wtf iso.reactos.org is down for ages?


Am 04.12.2015 um 21:22 schrieb Alexander Rechitskiy: 

 


> wtf iso.reactos.org is down for ages?



All I can say is that we currently have no access to the entire network
in our Sweden data center. It may be caused by a power or ISP outage,
but I'm just guessing here.
I expect our administrator to look at it after the weekend.

Sorry for the inconveniences, but this is all I can do for now.

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

 

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

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

[Hermès BÉLUSCA - MAÏTO]

I don’t understand what’s your matter, James.

 

Regards,

Hermès.

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Huw Campbell
Envoyé : lundi 30 novembre 2015 02:23
À : ReactOS Development List
Objet : Re: [ros-dev] Status Meeting (November 2015)

 

Oh, well, at least they're not at 5am (which is the case if you're Australian).

 

On Mon, Nov 30, 2015 at 12:00 PM, James Tabor  wrote:

Hello All!

I guess for now on NO HOLIDAYS will be observed, no exceptions!!! If you have a 
problem with this you have two choices!

Leave or continue working with the project!


December 31 is the next one so!

Think this is funny now?

James

 

On Thu, Nov 26, 2015 at 12:39 PM, Colin Finck  wrote:

The meeting credentials have just been sent. The meeting starts in about
half an hour.
If you didn't receive your credentials, please contact me before the
meeting starts.

The meeting will take place on fezile.reactos.org (SSL Port 6697) in the
#meeting channel.

For the first time, we will also have live meeting logs available at
https://fezile.reactos.org:16697
Use your ReactOS development account credentials (aka SVN Account) to
log in there.

Cheers,

Colin



Am 25.11.2015 um 03:25 schrieb Aleksey Bragin:
> 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

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

[Hermès BÉLUSCA - MAÏTO]

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

Re: [ros-dev] Infrastructure problems today

[Hermès BÉLUSCA - MAÏTO]

We are still using Hetzner? ^^

Hermès.

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Colin Finck
Envoyé : mercredi 4 novembre 2015 20:05
À : 'ReactOS Development List'
Objet : [ros-dev] Infrastructure problems today

Hi all,

We suffered from several Infrastructure problems in one of our datacenters 
today, with the cause that multiple servers were temporarily unreachable.
All problems should be finally fixed now though. If you still encounter related 
problems, please reply to my mail.


Cheers,

Colin


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

Re: [ros-dev] [ros-diffs] [akhaldi] 69435: [NTVDM] Improve the PCH situation.

[Hermès BÉLUSCA - MAÏTO]

Hi !

I don't think this commit constitutes a nice improvement for NTVDM at its
present status:

- having the precise list of the used headers in each .c file helped me in
knowing at a glance which functionalities a given .c needed,
- therefore enabling me to find better places where to put the functions and
possibly reduce the number of headers in the future (refactoring).
- This broke my numerous local changes regarding e.g. a modularization of
the CPU layer in NTVDM, video layer, ...
- Finally, stuffing indistinctively *all* the headers (including the private
ones like bios32p.h which purpose was to be used in the sources of one
module only) inside the PCH ntvdm.h, makes for example BIOS or DOS functions
visible inside hardware modules like ps2.h, which is completely illogical
when you try to modularize NTVDM at source level, by completely separating
hardware emulation from bios code and DOS emulation, etc... .

Therefore I will revert your commit tomorrow, while keeping a diff and put
it in a JIRA report.

Cheers,
Hermès.



[ros-diffs] [akhaldi] 69435: [NTVDM] Improve the PCH situation.
akhaldi at svn.reactos.org akhaldi at svn.reactos.org 
Sat Oct 3 21:47:46 UTC 2015
• Previous message: [ros-diffs] [spetreolle] 69434: [user32_apitest] 0x%lu
does not mean anything correct.
• Next message: [ros-diffs] [spetreolle] 69436: [ROSTESTS] Fix 0x%lu
specifier. Add cmake file for notificationtest.
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Author: akhaldi
Date: Sat Oct  3 21:47:46 2015
New Revision: 69435

URL: http://svn.reactos.org/svn/reactos?rev=69435=rev
Log:
[NTVDM] Improve the PCH situation.


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

Re: [ros-dev] [ros-diffs] [spetreolle] 69186: [TRANSLATIONS] Translate remaining French strings in msgina.dll

[Hermès BÉLUSCA - MAÏTO]

"Veuillez contacter votre administrateur système."

H.

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Pierre
Schweitzer
Envoyé : lundi 14 septembre 2015 13:03
À : ros-dev@reactos.org
Objet : Re: [ros-dev] [ros-diffs] [spetreolle] 69186: [TRANSLATIONS]
Translate remaining French strings in msgina.dll

"Voyez (avec) votre administrateur système" sounds too "spoken" French.

I'd really be in favour of something more... "written". Consultez,
contactez, whatever.

On 09/14/2015 12:43 PM, Hermès BÉLUSCA - MAÏTO wrote:
> Hi all !
> 
>  
> 
> De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de 
> Sylvain Petreolle Envoyé : lundi 14 septembre 2015 11:36 À : ReactOS 
> Development List Objet : Re: [ros-dev] [ros-diffs] [spetreolle] 69186: 
> [TRANSLATIONS] Translate remaining French strings in msgina.dll
> 
>  
> 
>> +IDS_LOGONUSERDISABLED "Votre compte est désactivé. Voyez votre
administrateur système."
> 
>> Consultez votre ?
> 
> In this case we should change the english line too, unless this is a false
friend :
> 
>> -IDS_LOGONUSERDISABLED "Your account has been disabled. Please see
your system administrator."
> 
> Voyez avec votre administrateur système ?
> 
>  
> 
> I confirm what Pierre says, in proper french we say « Consultez votre
administrateur système » ; in english “please see” can be said. I would not
say it is a false friend, but better proper translation; indeed when you
translate from language X to language Y you are not obliged to do
word-by-word translation if you know that in language Y there is another way
to say the same thing (eg. If you see “when pigs will fly” you won’t
translate by “quand les cochons voleront” in French, but instead you’ll say
“quand les poules auront des dents”).
> 
>  
> 
> [...]
> 
>  
> 
> Kind regards,
> 
>  
> 
> Sylvain Petreolle
> 
>  
> 
> Cheers,
> 
> Hermès
> 
>  
> 
> (and the obligatory :
> 
> “Sent by my spying MS Outlook” :P)
> 
>  
> 
>   _
> 
> De : Pierre Schweitzer <pie...@reactos.org> À : ros-dev@reactos.org 
> Envoyé le : Vendredi 11 septembre 2015 22h05 Objet : Re: [ros-dev] 
> [ros-diffs] [spetreolle] 69186: [TRANSLATIONS] Translate remaining 
> French strings in msgina.dll
> 
>  
> 
>  
> 
> 
> Comments inline.
> 
> On 11/09/2015 21:30, spetreo...@svn.reactos.org wrote:
>> URL: 
>> http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msgina/lan
>> g/fr-FR.rc?rev=69186 
>> <http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msgina/la
>> ng/fr-FR.rc?rev=69186=69185=69186=diff> 
>> =69185=69186=diff 
>> =
>> =
>>
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev


--
Pierre Schweitzer <pie...@reactos.org>
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] [ros-diffs] [spetreolle] 69186: [TRANSLATIONS] Translate remaining French strings in msgina.dll

[Hermès BÉLUSCA - MAÏTO]

Hi all !

 

De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Sylvain 
Petreolle
Envoyé : lundi 14 septembre 2015 11:36
À : ReactOS Development List
Objet : Re: [ros-dev] [ros-diffs] [spetreolle] 69186: [TRANSLATIONS] Translate 
remaining French strings in msgina.dll

 

> +IDS_LOGONUSERDISABLED "Votre compte est désactivé. Voyez votre 
> administrateur système."

>Consultez votre ?

In this case we should change the english line too, unless this is a false 
friend :

> -IDS_LOGONUSERDISABLED "Your account has been disabled. Please see your 
> system administrator."

Voyez avec votre administrateur système ?

 

I confirm what Pierre says, in proper french we say « Consultez votre 
administrateur système » ; in english “please see” can be said. I would not say 
it is a false friend, but better proper translation; indeed when you translate 
from language X to language Y you are not obliged to do word-by-word 
translation if you know that in language Y there is another way to say the same 
thing (eg. If you see “when pigs will fly” you won’t translate by “quand les 
cochons voleront” in French, but instead you’ll say “quand les poules auront 
des dents”).

 

[...]

 

Kind regards, 

 

Sylvain Petreolle

 

Cheers,

Hermès

 

(and the obligatory :

“Sent by my spying MS Outlook” :P)

 

  _  

De : Pierre Schweitzer 
À : ros-dev@reactos.org 
Envoyé le : Vendredi 11 septembre 2015 22h05
Objet : Re: [ros-dev] [ros-diffs] [spetreolle] 69186: [TRANSLATIONS] Translate 
remaining French strings in msgina.dll

 

 


Comments inline.

On 11/09/2015 21:30, spetreo...@svn.reactos.org wrote:
> URL: 
> http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msgina/lang/fr-FR.rc?rev=69186
>  
> 
>  =69185=69186=diff
> ==
-- 
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] 69139: OMGWTFBBQ!!!! We can now boot our ISOs on UEFI systems!! Thanks gigaherz for the "fatten" utility!, and others for testing. [CDMAKE] - Add multi-boot CD sup

[Hermès BÉLUSCA - MAÏTO]

Thanks Colin for the information! Yes, 2 days ago I talked a bit about that 
with David when he also wanted to fix this problem in his fatten utility.
Hermès.

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Colin Finck
Envoyé : mercredi 9 septembre 2015 09:49
À : 'ReactOS Development List'
Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 69139: OMGWTFBBQ We can now 
boot our ISOs on UEFI systems!! Thanks gigaherz for the "fatten" utility!, and 
others for testing. [CDMAKE] - Add multi-boot CD support, following El-Tori...

hbelu...@svn.reactos.org wrote:
> +// FIXME! FIXME! Do it in a portable way!!
>  typedef unsigned char BYTE;
>  typedef unsigned short WORD;
>  typedef unsigned long DWORD;

Try using our include/host/typedefs.h, which provides the most popular Windows 
type definitions in a portable way.


- Colin


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

Re: [ros-dev] [ros-diffs] [cwittich] 69079: [MODE] use ARRAYSIZE, don't include windows.h, fix two possible out-of-bounds reads CID 1206872 CID 1206873

[Hermès BÉLUSCA - MAÏTO]

As for the other following .com's: chcp, diskcomp, diskcopy, format,
graftabl, mode, more, tree, win . They are named ".com" for backwards
compatibility purposes (for .bat files that would run the tool with also its
extension in the name). However the following ones are real 16-bit programs:
command.com, edit.com (: ) ) and graphics.com

Hermès.

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Colin Finck
Envoyé : lundi 7 septembre 2015 09:56
À : ros-dev@reactos.org
Objet : Re: [ros-dev] [ros-diffs] [cwittich] 69079: [MODE] use ARRAYSIZE,
don't include windows.h, fix two possible out-of-bounds reads CID 1206872
CID 1206873

Am 07.09.2015 um 09:53 schrieb Colin Finck:
> cwitt...@svn.reactos.org wrote:
>> Modified: trunk/reactos/base/applications/cmdutils/mode/mode.c
> 
> What is that tool for anyway?
> Windows has a 16-bit "mode.com" for compatibility and I believe the 
> actual "mode" command is built-in into cmd.exe these days.

Nevermind! Just saw that "mode.com" is actually a 32-bit PE executable under
Windows and ReactOS :)


- Colin


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

Re: [ros-dev] [ros-diffs] [hbelusca] 68975: [VSSAPI] Compile the THISCALL calling convention support only for x86. On x64, we are automatically in THISCALL. Also I suggest we turn this file (and maybe

[Hermès BÉLUSCA - MAÏTO]

OK I didn't know that! I proposed this stuff because I noticed that the
msvc-thiscall.c files otherwise had the same (inlined-asm) macro than the
.s.

Hermès.

-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Thomas Faber
Envoyé : vendredi 4 septembre 2015 07:12
À : ros-dev@reactos.org
Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 68975: [VSSAPI] Compile the
THISCALL calling convention support only for x86. On x64, we are
automatically in THISCALL. Also I suggest we turn this file (and maybe also
/lib/sdk/crt/exce...

On 2015-09-04 03:14, hbelu...@svn.reactos.org wrote:
> Also I suggest we turn this file (and maybe also
/lib/sdk/crt/except/i386/cpp.s) into a "msvc-thiscall.c" as it is already
done in some other DLLs (like in ole32, riched20).

ole32 and riched20 don't export mangled names.
MSVC ignores redirects for them in the def file so it needs to be assembly
(or C++ code).

___
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