Re: [ros-dev] [QubesOS] Debug first boot

[Sylvain Petreolle]

Hello,
100% CPU is the sign that the system has entered the kernel debugger. (BSOD / 
assert)


Kind regards, Sylvain Petreolle 

Le dimanche 10 mai 2020 à 21:10:14 UTC+2, Frédéric Pierret 
 a écrit :  
 
 Hi,

I'm Frédéric from QubesOS project. I wanted to try your latest release ReactOS 
0.4.13 today and I've managed to install it on our latest QubesOS R4.1 in 
development within a HVM domain. First text installer for partitioning is fine 
and the graphical setup for languages and parameters too. At first OS boot 
while seeing the desktop for the first time, it popups a window pci device 
detection but then, just few seconds after the VM is freezing. Looking at Xen 
status, the stubdomain is not frozen at all, but the VM itself yes with 100% 
CPU usage. I've tried IDE driver for disk too but the same behavior appeared.

Any idea on how I can catch errors or having logs? Should I try your debug ISO?

Thank you in advance for your help.

Frédéric

PS: https://jira.reactos.org/browse/CORE-13358
___
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] BuildBot Upgrade on Tuesday

[Sylvain Petreolle]

Hello all,
Connecting to the new buildbot now shows an avatar picture from 
www.gravatar.com.
What are the legal implications ? What personal data are sent here ?

Is it still possible to see online logs as plain text ?
https://build.reactos.org/#/builders/9/builds/24976/steps/5/logs/stdio/text 
comes back to the index now.
Looking at a 1 billion lines hung log as HTML won't do anything good,
for the client and the server.
  
|   |

  Kind regards, Sylvain Petreolle 

   

 Le Dimanche 23 juin 2019 23h13, Colin Finck  a écrit :
 

 Hi all!

Our BuildBot at https://build.reactos.org is finally going to be
upgraded from the ancient version 0.8.14 to the latest 2.3.1 release
this Tuesday evening (CEST).

We have postponed this for a very long time due to the fundamental UI
changes in newer versions. The UI has been rewritten from scratch and
its Waterfall View has been simplified. I used to be a strong opponent
of this change. However, in one of the last meetings, it turned out that
the current Waterfall View isn't that popular among our developers anyway.
You can expect the new BuildBot to look like this:
https://lidell.nu/xemacs-buildbot/

BuildBot also doesn't provide a direct migration path from the old to
the new version. This means that previous build and log information will
be gone after the upgrade.
I used to consider this a blocker as well, but current BuildBot already
purges old build/log information after some time and apparently it
hasn't been missed. We still have all important information in Testman.
I will make sure however that build numbers in the new version continue
where they ended in the old version.

On the plus side, this upgrade brings integrations with GitHub and
Mattermost as well as proper Unicode support. Using an up-to-date
BuildBot version also allows us to actually enhance it. In fact, this
upgrade is a prerequisite for the Developer Web Interface our GSoC
student Ayush Sinha is currently working on.

Regarding Buildslaves (now called "workers"), the new BuildBot is still
compatible with 0.8.x clients, so these don't need an upgrade right
away. We just need a small change on workers submitting test results.

Kudos go to Victor Perevertkin, who has already begun evaluating the new
BuildBot version a long time ago and provided me with an updated
master.cfg file, along with other help!
I'm glad that the number of people maintaining our BuildBot setup is
growing! :)


Cheers,

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

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

[ros-dev] Test_KVM_AHK is offline

[Sylvain Petreolle]

Hi all,
The Test_KVM_AHK machine has encountered a power shortage in my area and is 
currently shut off.
I will bring it back on today evening. Kind regards, Sylvain Petreolle___
Ros-dev mailing list
Ros-dev@reactos.org
http://reactos.org/mailman/listinfo/ros-dev

[ros-dev] Test_KVM_AHK is temporarily offline

[Sylvain Petreolle]

Hello all.
My family is at home and I need to shut down the AHK bot until the end of the 
week.

See you later on Ros ;-) Kind regards, Sylvain Petreolle___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[ros-dev] Tr : ReactOS, AHK: offline!

[Sylvain Petreolle]

Due to my family presence, I need to stop the Test KVM AHK bot during this week 
end.I have good news regarding CORE-14536 and sound in general.
"I'll be back."  Kind regards, Sylvain Petreolle

 Le Vendredi 27 avril 2018 14h46, Serge Gautherie 
<reactos_serge_161...@gautherie.fr> a écrit :
 

 Hello Sylvain,

Test KVM AHK is offline since
"about 1 day ago (2018-Apr-25 18:27:36)".

Thanks.

-- 


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

Re: [ros-dev] AHK Bot maintenance in progress

[Sylvain Petreolle]

 Test KVM AHK is back on its feet.
After a fight with the package update manager (bug in dnf) and a problem with 
the primary monitor setting,its building and testing the last push from 
AmineKhaldi 

Kind regards, Sylvain Petreolle 

Le Mardi 28 novembre 2017 23h06, Sylvain Petreolle <spetreo...@yahoo.fr> a 
écrit :
 

 The AHK bot crashes often these days.

I uploaded a crash dump to Fedora and discovered that these crashes are due to 
the network emulation (SLIRP) used in KVM.
For reference, here is the opened issue : 
https://bugzilla.redhat.com/show_bug.cgi?id=1509589
Since bugs with previous versions of Fedora take time to be resolved, I'm 
upgrading the bot to Fedora 27.
Ideas to overcome the SLIRP problems are welcome.

After all, if it crashes the virtual machine, it could also be at the source of 
other problems.
The AHK tests show randomness in the tests that require network,related to 
nonblocking mode not working, but it could involve KVM too. Kind regards, 
Sylvain Petreolle

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

[ros-dev] AHK Bot maintenance in progress

[Sylvain Petreolle]

The AHK bot crashes often these days.

I uploaded a crash dump to Fedora and discovered that these crashes are due to 
the network emulation (SLIRP) used in KVM.
For reference, here is the opened issue : 
https://bugzilla.redhat.com/show_bug.cgi?id=1509589
Since bugs with previous versions of Fedora take time to be resolved, I'm 
upgrading the bot to Fedora 27.
Ideas to overcome the SLIRP problems are welcome.

After all, if it crashes the virtual machine, it could also be at the source of 
other problems.
The AHK tests show randomness in the tests that require network,related to 
nonblocking mode not working, but it could involve KVM too. Kind regards, 
Sylvain Petreolle___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[ros-dev] AHK Bot down for the week end

[Sylvain Petreolle]

Due to my family presence, I need to stop the Test KVM AHK bot during this week 
end."I'll be back." Kind regards, Sylvain Petreolle___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[ros-dev] Test KVM AHK Bot Upgrade

[Sylvain Petreolle]

Hello all,
I'm currently upgrading my AHK Testbot to Fedora 25, 24 only receives backports 
and Fedora 26 is already on the way.
I never upgraded it before, so I don't know if it will take one or several 
hours to be back online. Kind regards, Sylvain Petreolle___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Work on dxg.sys

[Sylvain Petreolle]

Hello Sebastian.If you haven't already, you can look at Magnus GreatLord reactx 
branch, available until revision 
60647.svn://svn.reactos.org/reactos/branches/reactx
 Kind regards, Sylvain Petreolle 

Le Mardi 7 mars 2017 22h41, Sebastian Gąsiorek 
<sebastian.gasio...@gmail.com> a écrit :
 

 Hi,
Couple of days ago I have started dxg.sys functions implementation. There is 
some progress but it would be good to write tests for this api.Dxg mostly is 
just wrapper between driver and win32k, so win32k api tests should be enough.
I saw some tests in rostests\dxtest\win32kdxtest but can't figure out how to 
enable them in build.
Could some help me with this and add proper cmake files? :)
Best regards,Sebastian
___
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] The Terminator^W AHK bot needs a vacation

[Sylvain Petreolle]

During Christmas, I have to leave the AHK bot room free of machine noise at my 
place.
The bot is officially on vacation until Dec 27-28th :-)
Happy Christmas,
Sylvain Petreolle___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [spetreolle] 72905: [NtUser] Turn an ERR into a TRACE.

[Sylvain Petreolle]

This paint lockup happens for Java applications.Where can I look for source of 
problems ?The AHK bot has logs for this :Result Details
  
|  
|   |  
Result Details
   |  |

  |

 
 Kind regards, Sylvain Petreolle 

Le Vendredi 7 octobre 2016 7h41, James Tabor <jimtabor.ros...@gmail.com> a 
écrit :
 

 Thank you!

This is the cheapest way to know if an application is locked up in paint. 
Breaking into debug sometimes helps, but it might break into some other place 
except the message loop.

On Wed, Oct 5, 2016 at 3:50 AM, Sylvain Petreolle <spetreo...@yahoo.fr> wrote:

Hello Jim.
I did not read it as a failure path in your code.I reverted my change. Kind 
regards, Sylvain Petreolle 

Le Mercredi 5 octobre 2016 0h32, James Tabor <jimtabor.ros...@gmail.com> a 
écrit :
 

 Now we will never know what happen to the lost application!


__ _
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] [spetreolle] 72905: [NtUser] Turn an ERR into a TRACE.

[Sylvain Petreolle]

Hello Jim.
I did not read it as a failure path in your code.I reverted my change. Kind 
regards, Sylvain Petreolle 

Le Mercredi 5 octobre 2016 0h32, James Tabor <jimtabor.ros...@gmail.com> a 
écrit :
 

 Now we will never know what happen to the lost application!


___
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] Re :[ros-bugs] [jira] (CORE-12020) We're not able to perform DPH test runs anymore

[Sylvain Petreolle]

Don't change code when runtime conditions evolve.Just give more RAM to the bot 
and it's over.

Envoyé depuis Yahoo Mail pour Android 
 
  Le jeu. j sept. PM à 18:01, Thomas Faber (JIRA) a écrit 
:   
    [ 
https://jira.reactos.org/browse/CORE-12020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=82914#comment-82914
 ] 

Thomas Faber commented on CORE-12020:
-

First stage is extremely heavy on memory due to inf parsing. One thing that 
helped in a similar situation was to separate caroots.inf from registry.inf and 
have it parsed separately. We should probably do that in trunk...
                
> We're not able to perform DPH test runs anymore
> ---
>
>                Key: CORE-12020
>                URL: https://jira.reactos.org/browse/CORE-12020
>            Project: Core ReactOS
>          Issue Type: Bug
>            Reporter: Amine Khaldi
>            Assignee: Bug Zilla
>              Labels: REGRESSION
>
> https://build.reactos.org/builders/Test%20KVM/builds/15147/steps/test/logs/stdio/text
> https://jira.reactos.org/secure/attachment/37125/ was used with patchbot.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Re: [ros-dev] [ros-diffs] [cwittich] 72792: [CRYPTNET] disable broken code

[Sylvain Petreolle]

Did you check the existing tests ? Many of them are run during test runs. Kind 
regards, Sylvain Petreolle 

Le Samedi 24 septembre 2016 17h28, Christoph von Wittich 
<christ...@apiviewer.de> a écrit :
 

  I guess CreateFile in wine doesn't return the correct LastError when you pass 
an invalid path like "C:C:\Windows"
 Our CreateFile returns ERROR_INVALID_NAME, wines PATH_NOT_FOUND or 
FILE_NOT_FOUND
 
 Guess we need a test for CreateFile...
 
 Am 24.09.2016 um 17:10 schrieb Thomas Faber:
  
 What's the symptom you're trying to fix?
Is it a problem for Wine also, or just for us? And why?

Trying to understand why we need to break Wine sync here.


On 2016-09-24 17:01, Christoph von Wittich wrote:
 
 It won't work for absolute paths as it will result in C:C:\folder\. I 
committed a better fix.


Am 24.09.2016 um 13:56 schrieb Thomas Faber:
 
 Could you elaborate on what makes it broken? Link to a bug perhaps?

On 2016-09-24 13:39, cwitt...@svn.reactos.org wrote:
 
 Author: cwittich
Date: Sat Sep 24 11:39:17 2016
New Revision: 72792

URL: http://svn.reactos.org/svn/reactos?rev=72792=rev
Log:
[CRYPTNET] disable broken code

Modified:
 trunk/reactos/dll/win32/cryptnet/cryptnet_main.c

Modified: trunk/reactos/dll/win32/cryptnet/cryptnet_main.c
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/cryptnet/cryptnet_main.c?rev=72792=72791=72792=diff
==
--- trunk/reactos/dll/win32/cryptnet/cryptnet_main.c[iso-8859-1] (original)
+++ trunk/reactos/dll/win32/cryptnet/cryptnet_main.c[iso-8859-1] Sat Sep 24 
11:39:17 2016
@@ -1025,6 +1025,7 @@
   components.dwUrlPathLength + 1);
  hFile = CreateFileW(path, GENERIC_READ, FILE_SHARE_READ,
   NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
+#ifndef __REACTOS__
  if (hFile == INVALID_HANDLE_VALUE)
  {
  /* Try again on the current drive */
@@ -1049,6 +1050,7 @@
  }
  }
  }
+#endif
  if (hFile != INVALID_HANDLE_VALUE)
  {
  if ((ret = CRYPT_GetObjectFromFile(hFile, pObject)))


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

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

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

[Sylvain Petreolle]

You can unsubscribe atRos-dev Info Page

|   |
|   |  |   |   |   |   |   |
| Ros-dev Info PageSubscribe to Ros-dev by filling out the following form. You 
will be sent email requesting confirmation, to prevent others from gratuitously 
subsc... |
|  |
| Afficher sur www.reactos.org | Aperçu par Yahoo |
|  |
|   |

Too bad to see you go. Kind regards, Sylvain Petreolle

  De : Arthur Janturin <jewta9...@gmail.com>
 À : ReactOS Development List <ros-dev@reactos.org> 
 Envoyé le : Jeudi 31 mars 2016 21h26
 Objet : Re: [ros-dev] Status Meeting (March 2016)
   
как мне отписаться от ваших писем?
2016-03-31 20:41 GMT+04:00 Aleksey Bragin <alek...@reactos.org>:

Thank you, Matthias!

On 31.03.2016 12:50, Matthias Kupfer wrote:

Hello,

unfortunately I can't attend this meeting because of another official
appointment. Nevertheless I would like to offer support the GSoC student as
contact or mentor of necessary. Rama already contacted me and I reviewed his
proposal last week. As long as it is on the optional list of projects I deem
necessary to mention this.

Regards,

Matthias

Am Wednesday 30 March 2016 20:15:08 schrieb Aleksey Bragin:

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

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

[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 <co...@reactos.org>
 À : 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

Re: [ros-dev] kbswitch update

[Sylvain Petreolle]

I didn't get this message at all. Kind regards, Sylvain Petreolle
  De : Richard Campbell <beta...@gmail.com>
 À : ReactOS Development List <ros-dev@reactos.org> 
 Envoyé le : Vendredi 4 décembre 2015 8h57
 Objet : Re: [ros-dev] kbswitch update
   
Hello!
Haven't been paying too much these days to ROS (wife, kids, job), but fyi i 
know your email ended up in spam.  Gmail says this:
Why is this message in Spam? It has a from address in aol.com but has failed 
aol.com's required tests for authentication.



On Fri, Dec 4, 2015 at 1:03 AM, Hans-Peter Diettrich <drdiettri...@aol.com> 
wrote:

Hi all,
I'm just digging into kbswitch and have several questions (later).

The major issue: kbswitch affects all windows at once, while it should change 
the input language only for the current (focused) window.

I assume that kbswitch must preserve the active window, so that it can know 
where to apply changes, and to re-activate that window when done. As I don't 
know what's already implemented, I wrote a simple test program, using
GetForegroundWindow() to determine the active window (hwnd),
GetWindowThreadProcessId() to get the related process handle, and
GetKeyboardLayout() to get the keyboard/language handle (hkl).

Tested on WinXP and ReactOS, the output looks correct. The hkl seems to be 
composed of two words (hi: language and low: layout), which are always the same 
on ReactOS. On XP a different keyboard layout can be used for a language, but I 
cannot decipher the resulting encoding of the layout. As soon as I try to 
change the layout for a language on ReactOS, kbswitch shows the *layout* name, 
not the *language* name.

Q: Can somebody try to find out how to convert a HKL into language and layout 
id's and/or names? (see GetLayoutIDByHkl)

Q: Is kbswitch notified of focus changes, and if so: how?
Then above sequence can be used to identify the related thread's setting, and 
update the tray icon and menu accordingly.

Q: Is every process/thread already assigned a *private* hkl?
If not, this feature must be implemented before further updates.

So much for now
DoDi


___
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] [spetreolle] 69186: [TRANSLATIONS] Translate remaining French strings in msgina.dll

[Sylvain Petreolle]

Agreed with your comments.
Can we change the mail adress or disable the automatic email ?I just got this 
notification failure:
Sorry, we were unable to deliver your message to the following address.

<spetreo...@svn.reactos.org>:
Mail server for "svn.reactos.org" unreachable for too long :

--- Below this line is a copy of the message. Kind regards, Sylvain Petreolle
  De : Hermès BÉLUSCA - MAÏTO <hermes.belu...@sfr.fr>
 À : 'ReactOS Development List' <ros-dev@reactos.org> 
 Envoyé le : Lundi 14 septembre 2015 13h46
 Objet : Re: [ros-dev] [ros-diffs] [spetreolle] 69186: [TRANSLATIONS] Translate 
remaining French strings in msgina.dll
   
"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

  ___
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

[Sylvain Petreolle]

> French typography requires a space before and after ':'Agreed, but one 
> comment for all the broken space changes would have been enough. :)
> +    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 ?

>On 11/09/2015 21:30, spetreo...@svn.reactos.org wrote: 
These email address don't exist.


Kind regards, 

Sylvain Petreolle
  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/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] [spetreolle] 67053: [FREELDR] In a quest to better registry, don't break VSSolution builds. freeldr_pe is not in the same directory and copy doesn't care if you ask to concat

[Sylvain Petreolle]

freeldr.sys and freeldr16.bin are generated into 
{output-VS-i386}\reactos\boot\freeldr\freeldr.
freeldr_pe is generated into 
{output-VS-i386}\reactos\boot\freeldr\freeldr\${Configuration} (Debug/Release)
 Kind regards,


Sylvain Petreolle
  De : Timo Kreuzer timo.kreu...@web.de
 À : ros-dev@reactos.org 
 Envoyé le : Dimanche 5 avril 2015 10h00
 Objet : Re: [ros-dev] [ros-diffs] [spetreolle] 67053: [FREELDR] In a quest to 
better registry, don't break VSSolution builds. freeldr_pe is not in the same 
directory and copy doesn't care if you ask to concatenate C:\tomatoes, it a...
   

The comment # Retrieve the full path to the generated file of the 
'freeldr_pe' target Doesn't explain why it is done.
It rather looks like someone is doing something pointless and 
documenting in a comment that he's doing the pointless.

${CMAKE_CURRENT_BINARY_DIR} should be the full path to the generated file. So 
it seems completely pointless to add extra magic to get that file path. Your 
commit message implies that this change fixes VSSolution builds, but it also 
doesn't explain it. In fact I don't even understand that sentence.

If you don't add a proper comment to that thing, why it is needed, I 
promise I will have forgotten about this in a year and remove it again. :)

Thanks,
Timo

Am 04.04.2015 um 22:33 schrieb spetreo...@svn.reactos.org:
 Author: spetreolle
 Date: Sat Apr  4 20:33:18 2015
 New Revision: 67053

 URL: http://svn.reactos.org/svn/reactos?rev=67053view=rev
 Log:
 [FREELDR]
 In a quest to better registry,
 don't break VSSolution builds.
 freeldr_pe is not in the same directory and copy doesn't care if you ask to 
 concatenate C:\tomatoes, it already has the first file.

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

 Modified: trunk/reactos/boot/freeldr/freeldr/CMakeLists.txt
 URL: 
 http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/CMakeLists.txt?rev=67053r1=67052r2=67053view=diff
 ==
 --- trunk/reactos/boot/freeldr/freeldr/CMakeLists.txt    [iso-8859-1] 
 (original)
 +++ trunk/reactos/boot/freeldr/freeldr/CMakeLists.txt    [iso-8859-1] Sat Apr 
  4 20:33:18 2015
 @@ -226,10 +226,13 @@
  add_dependencies(freeldr_pe asm)
  add_dependencies(freeldr_pe_dbg asm)
  
 +# Retrieve the full path to the generated file of the 'freeldr_pe' target
 +get_target_property(_freeldr_pe_output_file freeldr_pe LOCATION)
 +
  concatenate_files(
      ${CMAKE_CURRENT_BINARY_DIR}/freeldr.sys
      ${CMAKE_CURRENT_BINARY_DIR}/frldr16.bin
 -    ${CMAKE_CURRENT_BINARY_DIR}/freeldr_pe.dll)
 +    ${_freeldr_pe_output_file})
  
  add_custom_target(freeldr ALL DEPENDS 
${CMAKE_CURRENT_BINARY_DIR}/freeldr.sys)
  
 @@ -240,7 +243,8 @@
  concatenate_files(
      ${CMAKE_CURRENT_BINARY_DIR}/setupldr.sys
      ${CMAKE_CURRENT_BINARY_DIR}/frldr16.bin
 -    ${CMAKE_CURRENT_BINARY_DIR}/freeldr_pe.dll)
 +    ${_freeldr_pe_output_file})
  
  add_custom_target(setupldr ALL DEPENDS 
${CMAKE_CURRENT_BINARY_DIR}/setupldr.sys)
  add_cd_file(TARGET setupldr FILE ${CMAKE_CURRENT_BINARY_DIR}/setupldr.sys 
DESTINATION loader NO_CAB FOR bootcd regtest)
 +





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

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

Re: [ros-dev] [ros-diffs] [dreimer] 66690: [RAPPS] lack of a proxy configuration by Peter Hater. German translation updated by me. CORE-4852 #resolve #comment Committed, thx for help.

[Sylvain Petreolle]

I vote for an improvement instead of a revert.
We can use the system configured one as a fallback if there are no settings 
into RAPPS.
Kind regards,

Sylvain Petreolle
  De : Colin Finck co...@reactos.org
 À : 'ReactOS Development List' ros-dev@reactos.org 
 Envoyé le : Samedi 14 mars 2015 13h53
 Objet : Re: [ros-dev] [ros-diffs] [dreimer] 66690: [RAPPS] lack of a proxy 
configuration by Peter Hater. German translation updated by me. CORE-4852 
#resolve #comment Committed, thx for help.
   
drei...@svn.reactos.org wrote:
 [RAPPS] lack of a proxy configuration by Peter Hater.

I don't think we need a separate proxy configuration per application.
We should rather keep things consistent and always use the system
proxy set in the Internet Options control panel applet.

Unless someone has any objections, I suggest reverting this.


- 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] 66575: Start source tree (final, I hope!) restructuration. Part 1/X Win32, Shell, Services, MVDM

[Sylvain Petreolle]

Backup ALL your local changes.Svn doesn't do existed-deleted-but-is-back 
changes :as the history goes, it deletes, adds and changes files. With local 
changes, you get tree conflicts : modified but deleted.
Again, back up with svn diff and/or plain copy the working copy before any 
update. Kind regards,
Sylvain Petreolle
  De : Pierre Schweitzer pie...@reactos.org
 À : ReactOS Development List ros-dev@reactos.org 
 Envoyé le : Vendredi 6 mars 2015 13h46
 Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 66575: Start source tree (final, 
I hope!) restructuration. Part 1/X Win32, Shell, Services, MVDM
   
On 03/06/2015 01:30 PM, Hermès BÉLUSCA - MAÏTO wrote:
 First I would prefer to revert everything I done so far for that (failed) 
 attempt of tree restructure, because otherwise nobody will be happy. As far 
 as I can see in a local SVN repo I did here, if I revert to the tree shape 
 pre-66575 nothing should break (I mean, if you update your local copy that 
 was at, let’s say, revision 66574 and you update to revision 
 after-my-would-be-revert, it should be ok, your local changes should survive.

Given these last information, I'm all for a revert.



 
  
 
 Then it would be nice to have a discussion with everybody and seriously to 
 how move the main parts of the things.
 
  
 
 Cheers,
 
 Hermès.
 
  
 
 De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de daniel.reimer
 Envoyé : vendredi 6 mars 2015 13:12
 À : ReactOS Development List
 Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 66575: Start source tree (final, 
 I hope!) restructuration. Part 1/X Win32, Shell, Services, MVDM
 
  
 
 Hii,
 
  
 
 Well... In theory the restructuring might be logical and maybe even a good 
 idea to separate some of the DLL/win32 folder etc, but this can't be done as 
 one man show. It breaks the patches in jira, breaks the stuff our devs might 
 have locally and maybe someone has something to say to your plans.
 
 How to resolve this? Tbh, no clue. But a open discussion BEFORE commiting 
 would be a start IMO. So guys, what now? Can we keep it or not?
 
  
 
 Greetings
 
  
 
 Daniel
 
  
 
  
 
  
 
 Von meinem Samsung Gerät gesendet.
 
 
 
  Ursprüngliche Nachricht 
 Von: Hermès BÉLUSCA - MAÏTO hermes.belu...@sfr.fr 
 Datum: 06.03.2015 12:03 (GMT+01:00) 
 An: 'ReactOS Development List' ros-dev@reactos.org 
 Betreff: Re: [ros-dev] [ros-diffs] [hbelusca] 66575: Start source tree 
 (final, I hope!) restructuration. Part 1/X Win32, Shell, Services, MVDM 
 
 So...
 
 ... must I revert trunk pre-66575 ?
 
 Hermès.
 
 -Message d'origine-
 De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Aleksey
 Bragin
 Envoyé : vendredi 6 mars 2015 10:48
 À : ReactOS Development List
 Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 66575: Start source tree
 (final, I hope!) restructuration. Part 1/X Win32, Shell, Services, MVDM
 
 On 06.03.2015 2:58, Hermès BÉLUSCA - MAÏTO wrote:
 Hi,

 So first, please receive my apologies for not having warned in ros-dev 
 about this (continuation of) tree restructure I did starting with 
 r66575. Indeed this was the first thing to do before doing anything, 
 even if I talked about that on IRC and JIRA!
 Wrong.
 You did not need to warn, you need to get majority of devs to support this
 change, to get comments from them, to make sure they continue to feel at
 home in ReactOS source code.
 
 Right now, for the sake of subjective beautification you just forced
 everyone but you to adapt their patches (myself included, I have many
 working copies) just because you feel the tree structure was wrong.
 
 This is just ridiculous. As Pierre said, we are a team here. And teamwork
 without big issues is what is making our project a good place to work in, to
 get pleasure and satisfaction from the work done.
 
 
 In fact, the tree restructure discussion started 5 years ago, along 
 with the cmake bringup: see the big thread here:
 http://www.reactos.org/pipermail/ros-dev/2010-July/013257.html .
 Imagine what, I was part of it.
 
  At that
 time the main argument was that we were also in the middle of changing 
 the old build system (rbuild) to a new one (cmake) so it was 
 problematic to do those two big changes at once. Also at that time, 
 seeing the argumentation of Ged, Timo, Jérôme and the few others 
 (active developers) who dared to participate to this discussion, it 
 was clear that a tree restructure was necessary anyway, sooner or later.
 This is called
 https://en.wikipedia.org/wiki/Post-purchase_rationalization . After you made
 the change you start explaining that everyone was supporting it, it was so
 much needed, and let's just forget about any side-effects it may have
 caused.
 
 In 2012 some tree restructure happened (r56305) by moving around and 
 in a more logical manner some core components of win32.
 Yep.
 
 What happens now in 2015, i.e. 5 years after ? We have CMake well 
 established, everything works, but only win32 core was reorganized.
 Sure

Re: [ros-dev] [ros-diffs] [hbelusca] 65678: [MSGINA]: Update the function names of stubs, with (in comments) the number of parameters they take. See CORE-8459 for more information. CORE-8459 #resolve

[Sylvain Petreolle]

Can this be used everywhere ?We have other stubs like this into user32 and 
userenv. Kind regards,
Sylvain Petreolle
  De : Thomas Faber thomas.fa...@reactos.org
 À : ros-dev@reactos.org 
 Envoyé le : Dimanche 25 janvier 2015 18h45
 Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 65678: [MSGINA]: Update the 
function names of stubs, with (in comments) the number of parameters they take. 
See CORE-8459 for more information. CORE-8459 #resolve #comment Fixed in r65678.
   
On 2014-12-15 22:07, hbelu...@svn.reactos.org wrote:
 +1 stub -noname ShellGetUserList  ; (long long long)

For future reference, you might as well write this kind of thing as
1 stdcall -stub -noname ShellGetUserList(long long long)

Then spec2def will create a stub that uses the correct calling
convention and also prints out the arguments. Plus it's easier to
change to the real thing when someone implements it ;)

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


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

Re: [ros-dev] ReactOS/Wine patches.

[Sylvain Petreolle]

We already submit fixes to Wine.Since Wine is upstream, patches are sent to 
Wine first.I didn't 'reject' your patch blindly. There is also a change into 
shlwapi and freetype, which is 3rd party.
Changes to 3rd party code give silent reverts or conflicts at update time, 
better be safe than sorry.See [reactos] Revision 57747 and [#CORE-6495] 
unicode: some CLI Programs compiled and using unicode outputs characters 
incorrectly. - ReactOS JIRA for an example of these.


|   |
|   |  |   |   |   |   |   |
| [reactos] Revision 57747 |
|  |
| Afficher sur svn.reactos.org | Aperçu par Yahoo |
|  |
|   |



|   |
|   |  |   |   |   |   |   |
| [#CORE-6495] unicode: some CLI Programs compiled and usi...I have noticed on 
CLI (Command Line Interface) programs that have been compiled using UNICODE 
displays junk characters between each intended character.  |
|  |
| Afficher sur jira.reactos.org | Aperçu par Yahoo |
|  |
|   |

  Kind regards,Sylvain Petreolle
  De : Love Nystrom love.nyst...@gmail.com
 À : ReactOS Development List ros-dev@reactos.org 
 Envoyé le : Vendredi 14 novembre 2014 12h56
 Objet : [ros-dev] ReactOS/Wine patches.
   
@Sylvain,

It occurred to me that since we have a lot of Wine code in ReactOS,
there will often be cases where ReactOS patches target Wine code.

Instead of just rejecting those patches, which is likely to make them
never see the light of day, the ReactOS programmers who maintain
our Wine code could act as liaisons, and review/post them to Wine.

I think that would make it more likely that Wine will commit those
patches in a timely fashion, since they are likely to know our liaisons,
and we would gain by a faster turnaround on fixes in Wine code.

What do You think?



Best Regards
// Love


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

[Sylvain Petreolle]

See https://jira.reactos.org/browse/CORE-7020 for details.Alter has fixed the 
crash in 0.45c1.There is only a hang remaining when debug is off.
 Kind regards,Sylvain Petreolle
  De : Thomas Faber thomas.fa...@reactos.org
 À : ReactOS Development List ros-dev@reactos.org 
 Envoyé le : Jeudi 30 octobre 2014 14h51
 Objet : Re: [ros-dev] BuildBot changes
   
On 2014-10-29 19:11, Colin Finck wrote:
 What's still not working is ReactOS itself though:
 * bootcd works well, but bootcdregtest doesn't boot up at all, see
 http://build.reactos.org/builders/Carrier-Win7%20VBox-Testbot/builds/43/steps/test/logs/stdio
 I've put up this bootcdregtest for download at
 http://iso.reactos.org/temp/bootcdregtest_win7_broken.7z
 
 * The building process of the bootcdregtest also leaves out the gnutls
 files in the modules/optional folder, see
 http://build.reactos.org/builders/Trunk_x86_GCCWin%20Debug/builds/48/steps/compile_5/logs/stdio
 They definitely exist though, I've checked it in Explorer.
 
 Can anybody help here? Maybe these problems are even reproducible on
 Windows hosts?

I tried to reproduce the configuration according to your log and indeed
VBox terminated with a Guru Meditation.
Switching to a PIIX4 IDE controller instead of the SATA one makes it
work here.

For reference, my usual config would be something like:
- Windows Server 2003 (32 bit)
- 512 MB RAM, PIIX3 chipset, PS/2 Mouse, I/O APIC, PAE, VT-x
- 20 MB video memory, no acceleration
- Single PIIX4 IDE controller with HDD as master, CD as slave
- No sound card
- Single PCnet-FAST III network adapter
- Single COM port
- USB enabled, EHCI enabled


As for the problem with the AHCI controller, the last few lines of the
VBox log before the Guru Meditation indeed seem to indicate we're
talking to the controller incorrectly. I guess that's another thing
that should be addressed in UniATA (since 0.45c1 didn't fix it from
what I see on BuildBot).

00:00:04.054099 RTC: period=0x1000 (4096) 8 Hz
00:00:04.179276 PIT: mode=2 count=0x45e4 (17892) - 66.68 Hz (ch=0)
00:00:04.938043 AHCI#0: Reset the HBA
00:00:04.944072 AHCI#0: Reset the HBA
00:00:04.945271 AHCI#0: Port 0 reset
00:00:04.964756 
!!
00:00:04.964757 !!
00:00:04.964758 !!                Guru Meditation -2634 (VERR_IOM_MMIO_IPE_1)



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


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

Re: [ros-dev] BuildBot changes

[Sylvain Petreolle]

I will commit the uniata update that fixes the boot.We have 2 bugs about it.
 Kind regards,


Sylvain Petreolle
  De : Hermès BÉLUSCA - MAÏTO hermes.belu...@sfr.fr
 À : 'ReactOS Development List' ros-dev@reactos.org 
 Envoyé le : Mercredi 29 octobre 2014 19h37
 Objet : Re: [ros-dev] BuildBot changes
   
(ntoskrnl/io/iomgr/driver.c:1630) '\Driver\sacdrv' initialization failed,
status (0xc037)
(ntoskrnl/io/iomgr/driver.c:64) Deleting driver object '\Driver\sacdrv'
(hal/halx86/legacy/bussupp.c:1159) Slot assignment for 5 on bus 0
(hal/halx86/legacy/bus/pcibus.c:719) WARNING: PCI Slot Resource Assignment
is FOOBAR
[SYSREG] timeout
Exception occured in the LogReader.Run():
Thread was being aborted.

Normally, if I recall correctly, the next drivers to be loaded are Uniata /
disk drivers... Something failing at this point?

H.



-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Colin Finck
Envoyé : mercredi 29 octobre 2014 19:12
À : ros-dev@reactos.org
Objet : Re: [ros-dev] BuildBot changes

Thomas Faber wrote:
 Looks like VBoxManage fails to communicate with the RPC server due to 
 session 0 isolation.

Thomas, that was it indeed, many thanks for the hint!
While it wasn't running as a service but from Task Scheduler, it was also
running in session 0. VBoxVMService was no option for us, but I could put
the Buildslave task into a user session now by starting it only when the
user logs in and then auto-logging in that user on system startup.

With the help of Amine and Sylvain, sysreg3 is also getting its debug log
now.

What's still not working is ReactOS itself though:
* bootcd works well, but bootcdregtest doesn't boot up at all, see
http://build.reactos.org/builders/Carrier-Win7%20VBox-Testbot/builds/43/step
s/test/logs/stdio
I've put up this bootcdregtest for download at
http://iso.reactos.org/temp/bootcdregtest_win7_broken.7z

* The building process of the bootcdregtest also leaves out the gnutls files
in the modules/optional folder, see
http://build.reactos.org/builders/Trunk_x86_GCCWin%20Debug/builds/48/steps/c
ompile_5/logs/stdio
They definitely exist though, I've checked it in Explorer.

Can anybody help here? Maybe these problems are even reproducible on Windows
hosts?

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] [tkreuzer] 64593: [NTOSKRNL] Modify MiCreatePebOrTeb to use MiInsertVadEx instead of doing everything by hand. No, this does not change Windows behavior. The TEB creation

[Sylvain Petreolle]

Pourquoi Linda Wang ?? :)

 
Kind regards,


Sylvain Petreolle



 De : Alex Ionescu ion...@videotron.ca
À : ReactOS Development List ros-dev@reactos.org 
Cc : Linda Wang ros-di...@reactos.org 
Envoyé le : Samedi 11 octobre 2014 18h38
Objet : Re: [ros-dev] [ros-diffs] [tkreuzer] 64593: [NTOSKRNL] Modify 
MiCreatePebOrTeb to use MiInsertVadEx instead of doing everything by hand. 
No, this does not change Windows behavior. The TEB creation works exactly as 
befor...
 


Why do you think PEB creation cannot fail in the first place?


Best regards,
Alex Ionescu

On Tue, Oct 7, 2014 at 5:31 PM, tkreu...@svn.reactos.org wrote:

Author: tkreuzer
Date: Wed Oct  8 00:31:49 2014
New Revision: 64593

URL: http://svn.reactos.org/svn/reactos?rev=64593view=rev
Log:
[NTOSKRNL]
Modify MiCreatePebOrTeb to use MiInsertVadEx instead of doing everything by 
hand. No, this does not change Windows behavior. The TEB creation works 
exactly as before, and the only difference in the PEB creation is that if the 
first attempt fails, we will no longer try again from the top of the address 
space. But since this cannot fail in the first place, at least not due to the 
VA range not being free, another attempt would be pointless anyway!

Modified:
trunk/reactos/ntoskrnl/mm/ARM3/procsup.c

Modified: trunk/reactos/ntoskrnl/mm/ARM3/procsup.c
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/procsup.c?rev=64593r1=64592r2=64593view=diff
==
--- trunk/reactos/ntoskrnl/mm/ARM3/procsup.c[iso-8859-1] (original)
+++ trunk/reactos/ntoskrnl/mm/ARM3/procsup.c[iso-8859-1] Wed Oct  8 
00:31:49 2014
@@ -50,14 +50,11 @@
  IN ULONG Size,
  OUT PULONG_PTR BaseAddress)
 {
-PETHREAD Thread = PsGetCurrentThread();
 PMMVAD_LONG Vad;
 NTSTATUS Status;
 ULONG_PTR HighestAddress, RandomBase;
 ULONG AlignedSize;
 LARGE_INTEGER CurrentTime;
-TABLE_SEARCH_RESULT Result = TableFoundNode;
-PMMADDRESS_NODE Parent;

 /* Allocate a VAD */
 Vad = ExAllocatePoolWithTag(NonPagedPool, sizeof(MMVAD_LONG), 'ldaV');
@@ -70,6 +67,7 @@
 Vad-u.VadFlags.PrivateMemory = TRUE;
 Vad-u.VadFlags.Protection = MM_READWRITE;
 Vad-u.VadFlags.NoChange = TRUE;
+Vad-u1.Parent = NULL;

 /* Setup the secondary flags to make it a secured, writable, long VAD */
 Vad-u2.LongFlags2 = 0;
@@ -77,10 +75,11 @@
 Vad-u2.VadFlags2.LongVad = TRUE;
 Vad-u2.VadFlags2.ReadOnly = FALSE;

-/* Lock the process address space */
-KeAcquireGuardedMutex(Process-AddressCreationLock);
+Vad-ControlArea = NULL; // For Memory-Area hack
+Vad-FirstPrototypePte = NULL;

 /* Check if this is a PEB creation */
+ASSERT(sizeof(TEB) != sizeof(PEB));
 if (Size == sizeof(PEB))
 {
 /* Create a random value to select one page in a 64k region */
@@ -100,68 +99,27 @@

 /* Calculate the highest allowed address */
 HighestAddress = RandomBase + AlignedSize - 1;
-
-/* Try to find something below the random upper margin */
-Result = MiFindEmptyAddressRangeDownTree(ROUND_TO_PAGES(Size),
- HighestAddress,
- PAGE_SIZE,
- Process-VadRoot,
- BaseAddress,
- Parent);
-}
-
-/* Check for success. TableFoundNode means nothing free. */
-if (Result == TableFoundNode)
-{
-/* For TEBs, or if a PEB location couldn't be found, scan the VAD 
root */
-Result = MiFindEmptyAddressRangeDownTree(ROUND_TO_PAGES(Size),
- 
(ULONG_PTR)MM_HIGHEST_VAD_ADDRESS,
- PAGE_SIZE,
- Process-VadRoot,
- BaseAddress,
- Parent);
-/* Bail out, if still nothing free was found */
-if (Result == TableFoundNode)
-{
-KeReleaseGuardedMutex(Process-AddressCreationLock);
-ExFreePoolWithTag(Vad, 'ldaV');
-return STATUS_NO_MEMORY;
-}
-}
-
-/* Validate that it came from the VAD ranges */
-ASSERT(*BaseAddress = (ULONG_PTR)MI_LOWEST_VAD_ADDRESS);
-
-/* Build the rest of the VAD now */
-Vad-StartingVpn = (*BaseAddress)  PAGE_SHIFT;
-Vad-EndingVpn = ((*BaseAddress) + Size - 1)  PAGE_SHIFT;
-Vad-u3.Secured.StartVpn = *BaseAddress;
-Vad-u3.Secured.EndVpn = (Vad-EndingVpn  PAGE_SHIFT) | (PAGE_SIZE - 1);
-Vad-u1.Parent = NULL;
-
-/* FIXME: Should setup VAD bitmap */
-Status = STATUS_SUCCESS;
-
-/* Pretend as if we own the working set

Re: [ros-dev] Status Meeting (July 2014)

[Sylvain Petreolle]

Hi,
I won't be able to attend this meeting.

Envoyé depuis Yahoo Mail pour Android

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

Re: [ros-dev] Fezile server down

[Sylvain Petreolle]

We can buy these now.


Tyan M3291 is available on ebay.
http://www.ebay.com/itm/like/170358554712?item=170358554712lgeo=1vectorid=229466
http://www.ebay.com/itm/like/121350748466?item=121350748466lgeo=1vectorid=229466
Other shops are listed here:

http://www.pricebat.ca/m3291-tyan-smdc-remote-management-adapter/


For the ASUS ASMB3 :
http://www.ao3.com.au/product.asp?ManufPartNo=MB3-IKVM


 
Kind regards, 

Sylvain Petreolle



 De : Colin Finck co...@reactos.org
À : ReactOS Development List ros-dev@reactos.org; ros-gene...@reactos.org 
Envoyé le : Vendredi 20 juin 2014 23h02
Objet : [ros-dev] Fezile server down
 

Hi all,

Fezile, one of our servers in Sweden, unexpectedly disappeared after a
reboot today. Unfortunately, this is one of our older servers without an
IPMI module, so we have to wait till it's rebooted manually. I'll keep
you informed when this is done.

The server outage affects the following services:
* iso.reactos.org
* doxygen.reactos.org
* cppcheck.reactos.org
* VMware Player Test slave
* VMware Player Patchbot


We apologize for the inconveniences!

If you have any idea where we can still get a suitable IPMI module for
these servers, we would be highly interested!
The needed models are ASUS ASMB3 and Tyan M3291.

Best regards,

Colin Finck

___
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] 62562: [EXT2] try_return() == try_return(S) with nothing in S . The code sometimes use it. Shut up MSVC warning C4003: not enough actual parameters for macro 'try_

[Sylvain Petreolle]

I checked the original source from http://sourceforge.net/projects/winext2fsd/.

try_return(S) with nothing in S are ours exclusively. those are to be fixed 
instead.


 
Kind regards,


Sylvain Petreolle



 De : Thomas Faber thomas.fa...@reactos.org
À : ReactOS Development List ros-dev@reactos.org 
Envoyé le : Mardi 25 mars 2014 10h44
Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 62562: [EXT2] try_return() == 
try_return(S) with nothing in S . The code sometimes use it. Shut up MSVC 
warning C4003: not enough actual parameters for macro 'try_return'.
 

I took the warning form the GCC builder.
Looks like it should be C4005 on MSVC though.
Shouldn't you have seen that when you built it? ;)


Hmm, also, ext2 has allow_warnings for some reason (which is why this
even builds). We should really remove them all, only ntdll_winetest
should need one at this point.


On 2014-03-25 02:20, Hermès BÉLUSCA - MAÏTO wrote:
 Hmmm also, is there any C error code associated with that, on MSVC ?
 
 -Message d'origine-
 De : ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] De la
 part de Thomas Faber
 Envoyé : lundi 24 mars 2014 23:29
 À : ros-dev@reactos.org
 Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 62562: [EXT2] try_return() ==
 try_return(S) with nothing in S . The code sometimes use it. Shut up MSVC
 warning C4003: not enough actual parameters for macro 'try_return'.
 
 That's illegal, macros can't be overloaded.
 
 drivers/filesystems/ext2/inc/ext2fsd.h:64:0: warning: try_return redefined
 [enabled by default]
 
 You could try
 #define try_return(...) { __VA_ARGS__; goto try_exit; }
 
 If that doesn't do it, it might simply need a separate macro (I'm not sure
 to what extent this is third party code though)
 
 (also if these were the last instances of that -- and I think so --, we
 might want to make 4003 an error)
 
 
 On 2014-03-24 23:20, hbelu...@svn.reactos.org wrote:
 Author: hbelusca
 Date: Mon Mar 24 22:20:52 2014
 New Revision: 62562

 URL: http://svn.reactos.org/svn/reactos?rev=62562view=rev
 Log:
 [EXT2]
 try_return() == try_return(S) with nothing in S . The code sometimes use
 it.
 Shut up MSVC warning C4003: not enough actual parameters for macro
 'try_return'.

 Modified:
     trunk/reactos/drivers/filesystems/ext2/inc/ext2fsd.h

 Modified: trunk/reactos/drivers/filesystems/ext2/inc/ext2fsd.h
 URL: 
 http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/e
 xt2/inc/ext2fsd.h?rev=62562r1=62561r2=62562view=diff

 
 ==
 --- trunk/reactos/drivers/filesystems/ext2/inc/ext2fsd.h    [iso-8859-1]
 (original)
 +++ trunk/reactos/drivers/filesystems/ext2/inc/ext2fsd.h    [iso-8859-1]
 Mon Mar 24 22:20:52 2014
 @@ -60,6 +60,7 @@
  extern Ext2Data                Ext2GlobalData;
  
  // try-finally simulation
 +#define try_return()    { goto try_exit; }
  #define try_return(S)    { S; goto try_exit; }
  #define try_return1(S)    { S; goto try_exit1; }
  #define try_return2(S)    { S; goto try_exit2; }


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

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


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

Re: [ros-dev] [ros-diffs] [hbelusca] 62140: [REACTOS] Go fully to Win2k3 SP2 version reporting. CORE-6611 #resolve #comment Fixed in r62140.

[Sylvain Petreolle]

Why didn't you say so in CORE-6611 ?


Also, is Linda diff...erent ? ;-) 


Kind regards, 



Sylvain Petreolle



 De : Alex Ionescu ion...@videotron.ca
À : ReactOS Development List ros-dev@reactos.org 
Cc : Linda Wang ros-di...@reactos.org 
Envoyé le : Mercredi 12 février 2014 23h27
Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 62140: [REACTOS] Go fully to 
Win2k3 SP2 version reporting. CORE-6611 #resolve #comment Fixed in r62140.
 

I am so sick of these types of changes being made without consultation.

The kernel is not SP2. Please do not update this value, as we are
missing exports/functionality exposed on SP2.
Best regards,
Alex Ionescu


On Wed, Feb 12, 2014 at 12:03 PM,  hbelu...@svn.reactos.org wrote:
 Author: hbelusca
 Date: Wed Feb 12 20:03:57 2014
 New Revision: 62140

 URL: http://svn.reactos.org/svn/reactos?rev=62140view=rev
 Log:
 [REACTOS]
 Go fully to Win2k3 SP2 version reporting.
 CORE-6611 #resolve #comment Fixed in r62140.

 Modified:
     trunk/reactos/boot/bootdata/hivesys.inf
     trunk/reactos/include/psdk/ntverp.h
     trunk/reactos/ntoskrnl/ex/init.c

 Modified: trunk/reactos/boot/bootdata/hivesys.inf
 URL: 
 http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/hivesys.inf?rev=62140r1=62139r2=62140view=diff
 ==
 --- trunk/reactos/boot/bootdata/hivesys.inf     [iso-8859-1] (original)
 +++ trunk/reactos/boot/bootdata/hivesys.inf     [iso-8859-1] Wed Feb 12 
 20:03:57 2014
 @@ -1143,8 +1143,8 @@
  ; ReactOS specific - by default we report ourselves as Server for the user,
  ; but we can also report as Workstation if some application needs it.
  
HKLM,SYSTEM\CurrentControlSet\Control\ReactOS\Settings\Version,ReportAsWorkstation,0x00010001,0x
 -; Some installers check for SP1
 -HKLM,SYSTEM\CurrentControlSet\Control\Windows,CSDVersion,0x00010001,0x0100
 +; Some installers check for SP2
 +HKLM,SYSTEM\CurrentControlSet\Control\Windows,CSDVersion,0x00010001,0x0200

  
HKLM,SYSTEM\CurrentControlSet\Control\SecurityProviders,SecurityProviders,2,schannel.dll
  
HKLM,SYSTEM\CurrentControlSet\Control\SecurityProviders\SaslProfiles,,0x0012

 Modified: trunk/reactos/include/psdk/ntverp.h
 URL: 
 http://svn.reactos.org/svn/reactos/trunk/reactos/include/psdk/ntverp.h?rev=62140r1=62139r2=62140view=diff
 ==
 --- trunk/reactos/include/psdk/ntverp.h [iso-8859-1] (original)
 +++ trunk/reactos/include/psdk/ntverp.h [iso-8859-1] Wed Feb 12 20:03:57 2014
 @@ -14,10 +14,10 @@
   */

  //
 -// Windows NT Build 3790.1830
 +// Windows NT Build 3790.3959
  //
  #define VER_PRODUCTBUILD                    3790
 -#define VER_PRODUCTBUILD_QFE                1830
 +#define VER_PRODUCTBUILD_QFE                3959

  //
  // Windows NT Version 5.2

 Modified: trunk/reactos/ntoskrnl/ex/init.c
 URL: 
 http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ex/init.c?rev=62140r1=62139r2=62140view=diff
 ==
 --- trunk/reactos/ntoskrnl/ex/init.c    [iso-8859-1] (original)
 +++ trunk/reactos/ntoskrnl/ex/init.c    [iso-8859-1] Wed Feb 12 20:03:57 2014
 @@ -1072,12 +1072,12 @@
      /* Setup initial system settings */
      CmGetSystemControlValues(LoaderBlock-RegistryBase, CmControlVector);

 -    /* Load static defaults for Service Pack 1 and add our SVN revision */
 +    /* Load static defaults for Service Pack 2 and add our SVN revision */
      /* Format of CSD : SPMajor - SPMinor */
 -    CmNtCSDVersion = 0x100 | (KERNEL_VERSION_BUILD_HEX  16);
 +    CmNtCSDVersion = 0x200 | (KERNEL_VERSION_BUILD_HEX  16);
      CmNtCSDReleaseType = 0;

 -    /* Set Service Pack data for Service Pack 1 */
 +    /* Set Service Pack data for Service Pack 2 */
      CmNtSpBuildNumber = VER_PRODUCTBUILD_QFE;
      if (!(CmNtCSDVersion  0x))
      {



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

[Sylvain Petreolle]

Please, tell it before the day of the meeting, especially if you know it since 
2 days.
 We need those.


Kind regards,
Sylvain Petreolle



 De : Pierre Schweitzer pie...@reactos.org
À : ros-dev@reactos.org 
Envoyé le : Jeudi 5 décembre 2013 14h43
Objet : Re: [ros-dev] Status Meeting (November 2013)
 

Meeting postponed.

We will merge November meeting (which was postponed due to
Thanksgivings) and December meeting (which would take place during End
of Year events).

More information to follow.

On behalf of Aleksey.


On 11/28/2013 10:18 AM, Aleksey Bragin wrote:
 Rescheduling for 1 week.

 New date: 5th of December.


 Regards,
 Aleksey Bragin

 On 27.11.2013 23:37, Zachary Gorden wrote:
 Reschedule.

 On Wed, Nov 27, 2013 at 7:03 AM, Aleksey Bragin alek...@reactos.org
 wrote:
 I forgot to mention: It's thanksgiving day in America. Is it ok to
 have the
 meeting the same day, or should we reschedule?

 Regards,
 Aleksey Bragin


 On 27.11.2013 14:44, Aleksey Bragin wrote:
 Hello,
 Let me invite you to the monthly status meeting taking place last
 Thursday
 of this month, 28th of November, 19:00 UTC. Put that into your
 calendars so
 you don't forget. And 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.
 If someone still is not getting passwords sent before a meeting -
 please
 email Pierre before the meeting started to get one.

 The agenda will be posted shortly before the meeting, suggestions are
 welcome (send them to me shortly before the meeting starts). Hermes
 sent the
 first suggestion well before the meeting, so please follow his
 example and
 send your suggestions too.

 Regards,
 Aleksey Bragin



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


-- 
Pierre Schweitzer pie...@reactos.org
System Administrator
ReactOS Foundation




___
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] getdate.exe being pulled from SVN repository

[Sylvain Petreolle]

getdate.exe needs to be available when we run configure, no build action can be 
done at this time.
getdate.cmd/.c are here as sources only.
 
Kind regards,
Sylvain Petreolle



 De : J. C. Jones jaibudu...@gmail.com
À : 'ReactOS Development List' ros-dev@reactos.org 
Envoyé le : Jeudi 2 mai 2013 6h22
Objet : [ros-dev] getdate.exe being pulled from SVN repository
 


Small nit-pick:
 
.\reactos\reactos\tools\getdate.exe is being pulled from SVN even though it is 
being generated by getdate.cmd and getdate.c that are both in the same 
directory?
 
-John
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

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

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

[Sylvain Petreolle]

While we have to fix the kernel check asap, jerome's commit is not a hack since 
it uses existing MESA defines.
 
Kind regards,
Sylvain Petreolle



 De : Aleksey Bragin alek...@reactos.org
À : ReactOS Development List ros-dev@reactos.org 
Envoyé le : Vendredi 5 avril 2013 10h14
Objet : Re: [ros-dev] [ros-diffs] [jgardou] 58660: [MESA32] * Disable SSE 
optimizations, as they only cause mayhem.
 
I think he's referring to the actual commit, which I find weird too.

Regards,
Aleksey Bragin

On 05.04.2013 2:42, Kamil Hornicek wrote:
 LOL, I'm not trying to fix anything - disabling the whole SSE 
 support is on par with disabling just the check. You fix the kernel and you 
 better do it soon.
 
 Dne 4.4.2013 21:58, Timo Kreuzer napsal(a):
 
 LOL, we have a bug in the kernel and you try to fix this in MESA?
 
 
 Am 04.04.2013 14:33, schrieb Kamil Hornicek:
 If I recall correctly there's a check whether the OS can handle
 masked/unmasked sse exceptions. It causes trouble even in Windows if
 the app using Mesa has it's own exception handlers installed IIRC. SSE
 works just fine. Just disable the (useless) _mesa_check_os_sse_suppor
 stuff (ReactOS supports this, no need to do the check) or find a way
 to stop the exception from propagating.
 
 Regards,
 Kamil
 
 Dne 4.4.2013 12:34, Jérôme Gardou napsal(a):
 It causes some kernel mode exception. The code deliberately throws an
 SSE exception to see if the OS supports them. The trap handler considers
 this as a k-mode exception and bug checks.
 
 See http://jira.reactos.org/browse/CORE-6776
 
 Timo Kreuzer a écrit :
 
 What exactly does it cause? And shouldn't we rather fix that,
 instead of
 disabling optimizations? mesa is already slow enough.
 
 Am 03.04.2013 14:02, schrieb jgar...@svn.reactos.org:
 Author: jgardou
 Date: Wed Apr  3 12:02:58 2013
 New Revision: 58660
 
 URL: http://svn.reactos.org/svn/reactos?rev=58660view=rev
 Log:
 [MESA32]
   * Disable SSE optimizations, as they only cause mayhem.
 
 Modified:
 trunk/reactos/dll/opengl/mesa/src/mesa/CMakeLists.txt
 
 Modified: trunk/reactos/dll/opengl/mesa/src/mesa/CMakeLists.txt
 URL:
 http://svn.reactos.org/svn/reactos/trunk/reactos/dll/opengl/mesa/src/mesa/CMakeLists.txt?rev=58660r1=58659r2=58660view=diff
  
 
 
 
 ==
  
 
 
 
 --- trunk/reactos/dll/opengl/mesa/src/mesa/CMakeLists.txt [iso-8859-1]
 (original)
 +++ trunk/reactos/dll/opengl/mesa/src/mesa/CMakeLists.txt [iso-8859-1]
 Wed Apr  3 12:02:58 2013
 @@ -33,17 +33,18 @@
           x86/3dnow_xform3.S
           x86/3dnow_xform4.S
           x86/3dnow_normal.S
 -        x86/sse_xform1.S
 -        x86/sse_xform2.S
 -        x86/sse_xform3.S
 -        x86/sse_xform4.S
 -        x86/sse_normal.S
 +        # x86/sse_xform1.S
 +        # x86/sse_xform2.S
 +        # x86/sse_xform3.S
 +        # x86/sse_xform4.S
 +        # x86/sse_normal.S
           x86/read_rgba_span_x86.S)
       add_definitions(
           -DUSE_X86_ASM
           -DUSE_MMX_ASM
           -DUSE_3DNOW_ASM
 -        -DUSE_SSE_ASM)
 +        # -DUSE_SSE_ASM
 +    )
   endif()
   list(APPEND SOURCE
 
 
 
 


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


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

Re: [ros-dev] Development server downtime

[Sylvain Petreolle]

You should send those to our other mailing lists too.
Our users need to know about this.
 
Kind regards,
Sylvain Petreolle



 De : Pierre Schweitzer pie...@reactos.org
À : ros-dev@reactos.org 
Envoyé le : Vendredi 1 mars 2013 17h14
Objet : [ros-dev] Development server downtime
 
Hi,

in order to perform an important maintenance on the development server, it 
will be down on Wed 6th March, starting in the morning (approx 9h30 CET). It 
means that during this period: git, svn, buildbot won't be available to anyone.

We are sorry for the caused consequences.

With my best regards,

-- Pierre Schweitzerpie...@reactos.org
System Administrator
ReactOS Foundation



___
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] 57526: [BOOTDATA-CMAKE] Add a bin\data directory for holding data files which can be used for tests.

[Sylvain Petreolle]

+1.
You don't need to add the directory in PATH even if the helper is into bin\data.
 
Kind regards,
Sylvain Petreolle


- Mail original -
 De : Timo Kreuzer timo.kreu...@web.de
 À : ros-dev@reactos.org
 Cc : 
 Envoyé le : Mercredi 10 octobre 2012 9h52
 Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 57526: [BOOTDATA-CMAKE] Add a 
 bin\data directory for holding data files which can be used for tests.
 
 
 Why is it in the PATH variable?
 Why not just put the test data in the bin folder?
 
 Am 10.10.2012 00:00, schrieb hbelu...@svn.reactos.org:
  Author: hbelusca
  Date: Tue Oct  9 22:00:47 2012
  New Revision: 57526
 
  URL: http://svn.reactos.org/svn/reactos?rev=57526view=rev
  Log:
  [BOOTDATA-CMAKE]
  Add a bin\data directory for holding data files which can be used for 
 tests.
 
  Modified:
       trunk/reactos/boot/bootdata/hivesys_amd64.inf
       trunk/reactos/boot/bootdata/hivesys_arm.inf
       trunk/reactos/boot/bootdata/hivesys_i386.inf
       trunk/reactos/boot/bootdata/packages/reactos.dff.in
       trunk/reactos/cmake/CMakeMacros.cmake
 
  Modified: trunk/reactos/boot/bootdata/hivesys_amd64.inf
  URL: 
 http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/hivesys_amd64.inf?rev=57526r1=57525r2=57526view=diff
 
 ==
  --- trunk/reactos/boot/bootdata/hivesys_amd64.inf [iso-8859-1] (original)
  +++ trunk/reactos/boot/bootdata/hivesys_amd64.inf [iso-8859-1] Tue Oct  9 
 22:00:47 2012
  @@ -1200,7 +1200,7 @@
      ; System environment settings
    HKLM,SYSTEM\CurrentControlSet\Control\Session 
 Manager\Environment,ComSpec,0x0002,%SystemRoot%\system32\cmd.exe
  -HKLM,SYSTEM\CurrentControlSet\Control\Session 
 Manager\Environment,Path,0x0002,%SystemRoot%\bin;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\system32\wbem
  +HKLM,SYSTEM\CurrentControlSet\Control\Session 
 Manager\Environment,Path,0x0002,%SystemRoot%\bin;%SystemRoot%\bin\data;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\system32\wbem
    HKLM,SYSTEM\CurrentControlSet\Control\Session 
 Manager\Environment,windir,0x0002,%SystemRoot%
    HKLM,SYSTEM\CurrentControlSet\Control\Session 
 Manager\Environment,TEMP,0x0002,%SystemDrive%\TEMP
    HKLM,SYSTEM\CurrentControlSet\Control\Session 
 Manager\Environment,TMP,0x0002,%SystemDrive%\TEMP
 
  Modified: trunk/reactos/boot/bootdata/hivesys_arm.inf
  URL: 
 http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/hivesys_arm.inf?rev=57526r1=57525r2=57526view=diff
 
 ==
  --- trunk/reactos/boot/bootdata/hivesys_arm.inf [iso-8859-1] (original)
  +++ trunk/reactos/boot/bootdata/hivesys_arm.inf [iso-8859-1] Tue Oct  9 
 22:00:47 2012
  @@ -755,7 +755,7 @@
      ; System environment settings
    HKLM,SYSTEM\CurrentControlSet\Control\Session 
 Manager\Environment,ComSpec,0x0002,%SystemRoot%\system32\cmd.exe
  -HKLM,SYSTEM\CurrentControlSet\Control\Session 
 Manager\Environment,Path,0x0002,%SystemRoot%\bin;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\system32\wbem
  +HKLM,SYSTEM\CurrentControlSet\Control\Session 
 Manager\Environment,Path,0x0002,%SystemRoot%\bin;%SystemRoot%\bin\data;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\system32\wbem
    HKLM,SYSTEM\CurrentControlSet\Control\Session 
 Manager\Environment,windir,0x0002,%SystemRoot%
    HKLM,SYSTEM\CurrentControlSet\Control\Session 
 Manager\Environment,TEMP,0x0002,%SystemDrive%\TEMP
    HKLM,SYSTEM\CurrentControlSet\Control\Session 
 Manager\Environment,TMP,0x0002,%SystemDrive%\TEMP
 
  Modified: trunk/reactos/boot/bootdata/hivesys_i386.inf
  URL: 
 http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/hivesys_i386.inf?rev=57526r1=57525r2=57526view=diff
 
 ==
  --- trunk/reactos/boot/bootdata/hivesys_i386.inf [iso-8859-1] (original)
  +++ trunk/reactos/boot/bootdata/hivesys_i386.inf [iso-8859-1] Tue Oct  9 
 22:00:47 2012
  @@ -1200,7 +1200,7 @@
      ; System environment settings
    HKLM,SYSTEM\CurrentControlSet\Control\Session 
 Manager\Environment,ComSpec,0x0002,%SystemRoot%\system32\cmd.exe
  -HKLM,SYSTEM\CurrentControlSet\Control\Session 
 Manager\Environment,Path,0x0002,%SystemRoot%\bin;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\system32\wbem
  +HKLM,SYSTEM\CurrentControlSet\Control\Session 
 Manager\Environment,Path,0x0002,%SystemRoot%\bin;%SystemRoot%\bin\data;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\system32\wbem
    HKLM,SYSTEM\CurrentControlSet\Control\Session 
 Manager\Environment,windir,0x0002,%SystemRoot%
    HKLM,SYSTEM\CurrentControlSet\Control\Session 
 Manager\Environment,TEMP,0x0002,%SystemDrive%\TEMP
    HKLM,SYSTEM\CurrentControlSet\Control\Session 
 Manager\Environment,TMP,0x0002,%SystemDrive%\TEMP
 
  Modified: trunk/reactos/boot/bootdata/packages/reactos.dff.in
  URL: 
 http

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

[Sylvain Petreolle]

I may not be able to attend the meeting today. (will be late at least)

 
Kind regards,
Sylvain Petreolle


- Mail original -
 De : Aleksey Bragin alek...@reactos.org
 À : ReactOS Development List ros-dev@reactos.org
 Cc : 
 Envoyé le : Mardi 28 août 2012 17h19
 Objet : [ros-dev] Monthly meeting - August 2012
 
 Hello,
 Let me invite you to the monthly status meeting taking place last Thursday of 
 this month, 30th of August, 19:00 UTC.
 
 The meeting will be at irc://fezile.reactos.org (Port 6667, no SSL) in the 
 channel #meeting, if the server works. If not, then an alternative place will 
 be 
 announced here. Note that the IRC service will only be started shortly before 
 the meeting. Your participation passwords will be emailed to you shortly 
 before 
 the meeting starts.
 If someone still is not getting passwords sent before a meeting - please 
 email 
 Colin or Pierre before the meeting started to get one.
 
 In order to save time, let's choose who is going to be the minute taker on 
 the upcoming meeting. As usual, Z98 is welcome to volunteer.
 
 The agenda will be posted shortly before the meeting, suggestions are welcome 
 (send them to my email as usual).
 
 With the best 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] Re : (no subject)

[Sylvain Petreolle]

Thats why I love web-mails :) no contact lists stealed by a generic attack.
 
Kind regards,
Sylvain Petreolle



 De : Aleksey Bragin alek...@reactos.org
À : ReactOS Development List ros-dev@reactos.org 
Envoyé le : Dimanche 17 juin 2012 22h29
Objet : Re: [ros-dev] (no subject)
 

Poor Marc, a victim of some email contacts stealer ;(

On 17.06.2012 22:14, Timo Kreuzer wrote: 

I strongly recommend NOT to open the link. This seems to be some
virus/worm.


Am 17.06.2012 12:46, schrieb Marc Piulachs:

 
h**p://secondlife**.zhaarteth.net/wp-content/themes/dark-wood/googles.html?fgoh=ge.sxfscn=un.hkmmbf=mwuu
 



___
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] Re : Debug log problems

[Sylvain Petreolle]

 
Kind regards,
Sylvain Petreolle



 De : Aleksey Bragin alek...@reactos.org
À : ReactOS Development List ros-dev@reactos.org 
Envoyé le : Mercredi 6 juin 2012 14h45
Objet : [ros-dev] Debug log problems
 
Hello,
it's time for my periodical rant about debug log mess again. The example below 
is made using latest VirtualBox 3.

3. What happened to the floppy driver?
(/srv/buildbot_cmake/full_cmake/build/ntoskrnl/io/iomgr/driver.c:1579) 
'\Driver\FLOPPY' initialization failed, status (0xc00e)
(/srv/buildbot_cmake/full_cmake/build/ntoskrnl/io/iomgr/driver.c:61) Deleting 
driver object '\Driver\FLOPPY'
(/srv/buildbot_cmake/full_cmake/build/ntoskrnl/io/iomgr/driver.c:87) HACK: Not 
unloading the driver image due to critical bugs!
(/srv/buildbot_cmake/full_cmake/build/ntoskrnl/io/iomgr/driver.c:1961) 
IopInitializeDriver() failed (Status c00e)
(/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:935) Leaking 
driver: floppy.sys

Fix it? Don't enable it in trunk builds if it's buggy and not fixed?






All that resulted from my desire to just compare logs attached to the bug 
report. New log is totally unreadable, I had to spend time figuring out where 
actually that Live Essentials app was started, what problems it shows, etc.


Best regards,
Aleksey.


___
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] Re : Debug log problems

[Sylvain Petreolle]

You don't have a floppy drive attached to your VM, do you ?
Except the HACK thing this is the normal output when a device isn't there.

Kind regards,
Sylvain Petreolle



 De : Aleksey Bragin alek...@reactos.org
À : ReactOS Development List ros-dev@reactos.org 
Envoyé le : Mercredi 6 juin 2012 14h45
Objet : [ros-dev] Debug log problems
 
3. What happened to the floppy driver?
(/srv/buildbot_cmake/full_cmake/build/ntoskrnl/io/iomgr/driver.c:1579) 
'\Driver\FLOPPY' initialization failed, status (0xc00e)
(/srv/buildbot_cmake/full_cmake/build/ntoskrnl/io/iomgr/driver.c:61) Deleting 
driver object '\Driver\FLOPPY'
(/srv/buildbot_cmake/full_cmake/build/ntoskrnl/io/iomgr/driver.c:87) HACK: Not 
unloading the driver image due to critical bugs!
(/srv/buildbot_cmake/full_cmake/build/ntoskrnl/io/iomgr/driver.c:1961) 
IopInitializeDriver() failed (Status c00e)
(/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:935) Leaking 
driver: floppy.sys

Fix it? Don't enable it in trunk builds if it's buggy and not fixed?
Best regards,
Aleksey.
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[ros-dev] Kdserial use in first stage

[Sylvain Petreolle]

Automatic Continue in kdb has been implemented and improves the debugging on 
the test bots.
However, the KVM bot can't use it in the first stage because it is controlled 
by keyboard entries at this time.

I propose to switch the first stage to kdserial as well.
Any objections ?

Kind regards,
Sylvain Petreolle___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

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

[Sylvain Petreolle]

I fully agree with Timo.
We don't need to have useless files in tree.
Remember we recently deleted stuff from the main tree for the same reasons : 
space used and download time.

We do need tests, they are critical, but not in every reactos checkout.
I am for making tests a complete separated project, which would lower build 
times even more.
 
Kind regards,

Sylvain Petreolle



 De : Timo Kreuzer timo.kreu...@web.de
À : ReactOS Development List ros-dev@reactos.org 
Envoyé le : Jeudi 8 mars 2012 1h27
Objet : Re: [ros-dev] [ros-diffs] [jgardou] 56082: [DAMN_IT] - addendum to 
r56081
 
Am I the only one against that?
Tests are tests, not reactos.
Why do I need to have another bazillion files in my source tree that I don't 
need or want?
I have ONE checkout of rostests, but a dozen checkouts of reactos. For amd64 
work I even disabled build of a lot of stuff that was pointless. Now even more 
stuff spread thoughout the whole tree? Possibly even built by default?
Deleting a full reactos checkout is already slow enough. Also every commit to 
rostetsts is a possible build breaker and can cause massive rebuilds. 
Configure time will also increase.
I would rather prefer to make it even more modular, instead of mixing stuff 
even more.

-1


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


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

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

[Sylvain Petreolle]

I didn't say tests are useless(!), but critical.

Instead of having them in the regular checkout, build them as a separate 
project.
This will lower build/configure time, and leave it for OS, libraries, drivers 
and apps.

Kind regards,
Sylvain Petreolle



 De : Ged Murphy gedmurphy.mailli...@gmail.com
À : 'ReactOS Development List' ros-dev@reactos.org 
Envoyé le : Jeudi 8 mars 2012 16h29
Objet : Re: [ros-dev] Re : [ros-diffs] [jgardou] 56082: [DAMN_IT] - addendum 
to r56081
 
 We don't need to have useless files in tree.

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

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

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

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

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



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

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

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

On Thu, Mar 8, 2012 at 10:21 AM, Sylvain Petreolle spetreo...@yahoo.fr wrote:
 I fully agree with Timo.
 We don't need to have useless files in tree.
 Remember we recently deleted stuff from the main tree for the same reasons :
 space used and download time.

 We do need tests, they are critical, but not in every reactos checkout.
 I am for making tests a complete separated project, which would lower build
 times even more.

 Kind regards,
 Sylvain Petreolle

 
 De : Timo Kreuzer timo.kreu...@web.de
 À : ReactOS Development List ros-dev@reactos.org
 Envoyé le : Jeudi 8 mars 2012 1h27
 Objet : Re: [ros-dev] [ros-diffs] [jgardou] 56082: [DAMN_IT] - addendum to
 r56081

 Am I the only one against that?
 Tests are tests, not reactos.
 Why do I need to have another bazillion files in my source tree that I don't
 need or want?
 I have ONE checkout of rostests, but a dozen checkouts of reactos. For amd64
 work I even disabled build of a lot of stuff that was pointless. Now even
 more stuff spread thoughout the whole tree? Possibly even built by default?
 Deleting a full reactos checkout is already slow enough. Also every commit
 to rostetsts is a possible build breaker and can cause massive rebuilds.
 Configure time will also increase.
 I would rather prefer to make it even more modular, instead of mixing stuff
 even more.

 -1


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



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

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


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

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

[ros-dev] Re : Cmake result differences

[Sylvain Petreolle]

De : Bernd Blaauw bbla...@home.nl

À : ReactOS Development List ros-dev@reactos.org 
Envoyé le : Mercredi 29 février 2012 22h29
Objet : Re: [ros-dev] Cmake result differences
 
Were Arwinss binaries planned to be bundled or perhaps offered as a separate 
ISO? People might consider the removal of Rbuild generated downloads as an 
opportunity to offer an other/additional type of build instead.

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

[ros-dev] Re : Cmake result differences

[Sylvain Petreolle]

De : Bernd Blaauw bbla...@home.nl

À : ReactOS Development List ros-dev@reactos.org 
Envoyé le : Mercredi 29 février 2012 22h29
Objet : Re: [ros-dev] Cmake result differences
 
Op 29-2-2012 12:09, Kamil Hornicek schreef:
 Dbg-win ISOs contain winetests, hence their bigger size. Also if you
 compare build times (http://build.reactos.org/waterfall) you will find
 out that the windows build slave is faster than the linux one, so
 dbg-win builds are actually available sooner despite their size.

Thank you for your detailed explanation about additional (test-)files causing 
the majority of the size difference. Then the Windows build is more complete 
(if preferred to be so called) while the Linux build is faster to download, 
thus justifying both being available.

Were Arwinss binaries planned to be bundled or perhaps offered as a separate 
ISO? People might consider the removal of Rbuild generated downloads as an 
opportunity to offer an other/additional type of build instead.

Bernd

The Arwinss builds are available on SourceForge:
http://sourceforge.net/projects/reactos/files/Arwinss/
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[ros-dev] Re : change in email

[Sylvain Petreolle]

It should work everywhere when the URL is correct ;)
 http://j00ru.vexillium.org/win32k_syscalls/

not
http://j00ru.vexillium.org/w32k_syscalls/

 
Kind regards,
Sylvain Petreolle



 De : mikey sibert mik...@live.com
À : ros-dev ros-dev@reactos.org 
Envoyé le : Jeudi 23 février 2012 4h55
Objet : Re: [ros-dev] change in email
 

 

it works in linux on google so maybe it is just your browser it comes up here



From: cae...@myopera.com
To: ros-dev@reactos.org
Date: Wed, 22 Feb 2012 10:48:35 +0100
Subject: Re: [ros-dev] change in email


On the link you shared



Not Found

The requested URL /w32k_syscalls/ was not found on this server.

Additionally, a 404 Not Found error was encountered while trying to use an 
ErrorDocument to handle the request.



On Tue, Feb 21, 2012, at 06:55 PM, mikey sibert wrote:



hmmm look up windows system call list when win32k.sys comes up click on it 
then click on the link in there



 From: johannes.anderw...@reactos.org

 To: ros-dev@reactos.org

 Date: Wed, 22 Feb 2012 03:43:09 +0100

 Subject: Re: [ros-dev] change in email

 

 

 

 ReactOS Development List ros-dev@reactos.org schrieb am Mi, 22.02.2012 
 03:32:

  i changed email to this one microsoft windows live is better than google.

  now i saved the best part for last, go her for a list of win32 api 
  functions:

  http://j00ru.vexillium.org/w32k_syscalls/

  it will help a lot in the development of reactos and make a lot mor 
  programs run on then system

 

 Hi!

 

 Thank you for sharing, however the link is broken.

 

 WBR

 

 

 ___

 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 





-- 

With best regards

Caemyr



___
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] Re : Merry Christmas!!

[Sylvain Petreolle]

Happy Christmas and keep Reacting !!

 
Kind regards,
Sylvain Petreolle



 De : Javier Agustìn Fernàndez Arroyo elh...@gmail.com
À : ReactOS Development List ros-dev@reactos.org 
Envoyé le : Samedi 24 Décembre 2011 10h25
Objet : [ros-dev] Merry Christmas!!
 

hey!!

this is to wish ReactOS community a big and fun night !!

Cheers!

___
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] Re : [ros-diffs] [cgutman] 54415: [I8042PRT] - Implement support for hot plugging PS/2 mice if one was present at boot (same requirement as Windows) - Fixes bug 1395

[Sylvain Petreolle]

 De : Timo Kreuzer timo.kreu...@web.de
À : ReactOS Development List ros-dev@reactos.org 
Envoyé le : Vendredi 18 Novembre 2011 22h55
Objet : Re: [ros-dev] [ros-diffs] [cgutman] 54415: [I8042PRT] - Implement 
support for hot plugging PS/2 mice if one was present at boot (same 
requirement as Windows) - Fixes bug 1395
 
Am 18.11.2011 09:48, schrieb Javier Agustìn Fernàndez Arroyo:
 if one was present at boot
 
 wouldn't it be a new ROS feature to allow hotplugging even if there is no 
 mice at startup?
 
 As always, im about not just copying Windows, but enhance it as possible.
PS/2 standard doesn't support hot-plugging at all. In fact you might damage 
your mainboard with that.

Timo

There is the standard, but thats what people do, and Windows implemented it 
too. 

Kind regards,
Sylvain Petreolle

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

[ros-dev] Re : Two petitions

[Sylvain Petreolle]

If no one already take it, I volounter to write cmake files for rosapps.


Kind regards,
Sylvain Petreolle


De : cae...@myopera.com cae...@myopera.com
À : ReactOS Development List ros-dev@reactos.org
Envoyé le : Vendredi 21 Octobre 2011 23h38
Objet : Re: [ros-dev] Two petitions

On Thursday, October 20, 2011 9:23 PM, Aleksey Bragin alek...@reactos.org 
wrote:
 I support both 1 and 2. With the only exception that when we move to 
 cmake, rosapps will be moved too, so it would still remain a museum, but 
 a working museum. In fact, rosapps contains quite a bunch of important 
 stuff too (like all those cmd line utilities).

That would require porting rosapps to cmake (and building it, occasionally). I 
cannot do it and i cannot make anyone do that. If there are no volounters

 Also I would want indeed 2 screensavers in trunk - one simple and one 
 opengl based. Everything else should go to rosapps as 
 additional/optional stuff. Which of those - please decide, I don't have 
 any strong preference myself.

I`m fine with reducing the screensavers to two of them. Which one should be 
picked apart from starfield?

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


-- 
With best regards
Caemyr


___
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] Re : RosBE-Unix 2.0-RC1

[Sylvain Petreolle]

Hello Colin,

My system has a cmake package installed and cmake is available in $PATH.
What should I do in order to use the RosBE one ?
 
Kind regards,
Sylvain Petreolle



De : Colin Finck co...@reactos.org
À : ReactOS Development List ros-dev@reactos.org
Envoyé le : Mercredi 21 Septembre 2011 0h58
Objet : [ros-dev] RosBE-Unix 2.0-RC1

Hi all,

A first release candidate of RosBE-Unix 2.0 is now available on 
http://svn.reactos.org/RosBE-Temp/. Compared to 1.5, it finally includes CMake 
2.8.5 (with Jerome's patches), an updated GNU Make and new GMP and MPFR 
libraries. For the latter ones, I've added a patch to fix building under Mac 
OS X 10.7.

Please try it out and tell me about your results. If there's anything that 
needs to be fixed before the release, please tell me in a reply to this mail.

For the reference, the current CMake building commands in a ReactOS checkout 
are as follows:
- ./configure.sh
- cd output-i386-MinGW/host-tools
- makex
- cd ../reactos
- makex bootcd

I'll also set up this Build Environment on the Debug Buildslave as soon as 
possible.

Happy building,

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] Re : [ros-diffs] [tkreuzer] 53399: [VMWINST] Fix amd64 build [NTDLL] add missing amd64 specific exports [MSVCRT*] Fix mangled c++ exports for amd64 [OLEAUT32] Add amd64 adm stub for call_met

[Sylvain Petreolle]

Vmwinst was meant to work with old vmware layout, and it grabbed the files 
automatically.
Now you have to extract the files from the MSI package in order to have it 
working,
which is far from a convenient way.

I don't know what is the benefit to use vmware's video driver either, as we can 
now switch video resolution on the fly.


Kind regards,
Sylvain Petreolle



De : Aleksey Bragin alek...@reactos.org
À : ReactOS Development List ros-dev@reactos.org
Envoyé le : Dimanche 4 Septembre 2011 17h24
Objet : Re: [ros-dev] [ros-diffs] [tkreuzer] 53399: [VMWINST] Fix amd64 build 
[NTDLL] add missing amd64 specific exports [MSVCRT*] Fix mangled c++ exports 
for amd64 [OLEAUT32] Add amd64 adm stub for call_method, fix MSVC/amd64 buil...

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


It's written for the most common testing platform of ReactOS, the maintaining 
effort spent over years was minimal, and it just does its job very quickly, 
even with VMWare 7 (provided you copy necessary video driver files from its CD 
to modules\optional when building your bootcd).

WBR,
Aleksey. 

___
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] Re : Re : Another regression

[Sylvain Petreolle]

Indeed agreed , the bug should be fixed.
 
Kind regards,
Sylvain Petreolle



De : cae...@myopera.com cae...@myopera.com
À : Sylvain Petreolle spetreo...@yahoo.fr; ReactOS Development List 
ros-dev@reactos.org
Envoyé le : Lundi 15 Août 2011 12h24
Objet : Re: [ros-dev] Re :  Another regression

Shouldn't the bug be fixed instead of workaround?

On Mon, 15 Aug 2011 10:37 +0100, Sylvain Petreolle spetreo...@yahoo.fr 
wrote:
 Does the VM have ACPI enabled ? Try to turn it off then.
 
  
 Kind regards,
 Sylvain Petreolle
 
 
-- 
With best regards
Caemyr

___
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] Re : Regular meeting

[Sylvain Petreolle]

Hi all,

I won't be able to attend the meeting today.


Kind regards,
Sylvain Petreolle



De : Aleksey Bragin alek...@reactos.org
À : ros-dev@reactos.org
Envoyé le : Mer 27 avril 2011, 9h 45min 37s
Objet : [ros-dev] Regular meeting

 
Hello,

I want to remind you of the  regular meeting, Thursday the 28th at 20:00 UTC 
at 
freenode  #reactos-meeting.

The suggested meeting agenda is:
- Status of our  GSoC participation
- Current ReactOS work. Developers saying what they are  working on
- Action List proposal
- Status of the upcoming LinuxTag event  preparations
- Website revamp. Current status, who is working, who is willing  to help

If nobody else volunteers, Amine would be ready to take the  minute taker 
position again in this meeting and I would lead the meeting. In  case I am 
late, 
Amine will open the up meeting and I will join as soon as I get  online.

The current list of ReactOS members is as follows. Only these  people will be 
able to participate in the discussions and votings, please tell  us if we have 
forgotten anybody or if you want to be added to this  list:

- Giannis Adamopoulos (smiley1_)
- Johannes Anderwald  (janderwald)
- Javier Agustìn Fernàndez Arroyo (elhoir)
- Maciej Bialas  (niski)
- Aleksey Bragin (abragin)
- Colin Finck (Colin_Finck)
- Danny  Götte (dangerground)
- Cameron Gutman (aicom)
- Ziliang Guo (ZWabbit)
-  Rafal Harabien (rafalh)
- Kamil Hornicek (Pigglesworth)
- Amine Khaldi  (AmineKhaldi)
- Timo Kreuzer (tkreuzer)
- Matthias Kupfer (Collibri)
-  Michael Martin (mjmartin)
- Victor Martinez (vicmarcal)
- Roel Messiant  (Mephisto)
- Andrew Munger (WaxDragon)
- Ged Murphy (GedMurphy)
-  Sylvain Petreolle (Usurp)
- Hervé Poussineau (hpoussin)
- Daniel Reimer  (dreimer)
- Pierre Schweitzer (HeisSpiter)
- Samuel Serapion  (encoded)
- Olaf Siejka (Caemyr)
- James Tabor (jimtabor)
- Art Yerkes  (arty)

Everybody may join the meeting channel as a non-participating  observer though.
 
See you at the meeting today,
Aleksey  Bragin.___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

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

[Sylvain Petreolle]

- Message d'origine 
 De : Roel Messiant roelmessi...@gmail.com
 À : ReactOS Development List ros-dev@reactos.org
 Envoyé le : Lun 17 janvier 2011, 17h 37min 25s
 Objet : Re: [ros-dev] Getting a Windows Server 2003 license for the project?
 
 
 Wine  already performs testing on several Win2K3 setups, so this would
 mostly be  duplicate effort.
 
 WBR,
 
 Roel  Messiant
Thats right, but we can't compare results with them easily.
Having it integrated with testman would show exactly where results differ.

We also added our tests that Wine doesn't run.

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

[ros-dev] Re : [ros-diffs] [pschweitzer] 50090: [FASTFAT] Fix for a buffer overflow and then a buffer overrun (if ever it fixes something) The way filenames are handled for FAT entries should be REALL

[Sylvain Petreolle]

We actually have one in include/crt from mingw64.
see http://doxygen.reactos.org/d1/dd7/dos_8h.html

 Kind regards,
Sylvain Petreolle



- Message d'origine 
 De : James Tabor jimtabor.ros...@gmail.com
 À : ReactOS Development List ros-dev@reactos.org
 Envoyé le : Mer 22 décembre 2010, 5h 39min 26s
 Objet : [ros-dev] [ros-diffs] [pschweitzer] 50090: [FASTFAT] Fix for a buffer 
overflow and then a buffer overrun (if ever it fixes something) The way 
filenames are handled for FAT entries should be REALLY simplified. This 
would...
 
 Hi!
 I guess once long tyme ago, there was a little file called  dos.h!
 
 Need this #define _A_VOLID0x08/*  Volume ID file */
 
  VolumeLabelDirEntry.Fat.Attrib =  0x08;
 }
 
 ___
 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] Re : Networking

[Sylvain Petreolle]

Hello and welcome Oleg.

If you have problems to access IRC using regular clients,
you can use freenode's webchat. All you need is a javascript enabled browser.
http://webchat.freenode.net/

Kind regards,
Sylvain Petreolle


De : Oleg Baikalow obaika...@gmail.com
À : ReactOS Development List ros-dev@reactos.org
Envoyé le : Jeu 28 octobre 2010, 10h 42min 12s
Objet : Re: [ros-dev] Networking


My humble message seems to generate big flame :) Olaf - thank you, I will join 
IRC if I need to ask something about compiling, however ReactOS really looks 
very easy to build. I just downloaded RosBE, installed it, and that's it. I 
have 
yet to figure out how to test better (going to try different virtual 
machines), 
but that's not a big problem.
 
I will keep all development related issues on this mailing list as you wish. 
On 
my dayjob access to IRC is also very problematic.
 
// Oleg Baikalow


2010/10/27 Olaf Siejka cae...@gmail.com

 create a wiki page and post the link everytime someone needs that 
introduction



I am sorry, my cloning machine is currently out of order and i`m stuck with 
only 
myself. Its getting hard to keep several things at order, also i dont see 
many 
volounteers, willing to help us out...


Again, my proposal regarding irc was strictly limited to what i explained in 
my 
previous message. Please do not escalate it into quarel regarding project 
communication. This thread was dedicated to our new guest and his possible 
work 
on ROS networking. It is not very polite to hijack it for own opinions on 
something completely unrelated. 


I am sorry, Oleg, it should not have happened.

___
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] Re : Debug Build is Broken

[Sylvain Petreolle]

Actually, release build is broken.
Here is a fix for that, gDebugChannel has to be only defined for debug builds.

http://www.reactos.org/paste/index.php/7755/


Please test  report comments.
 Kind regards,
Sylvain Petreolle



- Message d'origine 
 De : James Tabor jimtabor.ros...@gmail.com
 À : ReactOS Development List ros-dev@reactos.org
 Envoyé le : Mar 21 septembre 2010, 5h 08min 16s
 Objet : [ros-dev] Debug Build is Broken
 
 [CC]   dll/win32/kernel32/file/file.c
 cc1: warnings being  treated as errors
 dll/win32/kernel32/file/dir.c:21: error: 'gDebugChannel'  defined but not used
 make: ***  
[/mnt/ramdisk/buildbot/release/obj/dll/win32/kernel32/file/dir_kernel32.o]
 Error  1
 make: *** Waiting for unfinished  jobs
 
 ___
 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] Re : ASSERT while shutting down ReactOS with VirtualBox Guest Additions

[Sylvain Petreolle]

Looking at latest VBoxWindowsAdditions-x86.exe, there is only one version of 
VBoxVideo.sys inside that archive.
 Kind regards,
Sylvain Petreolle



De : victor martinez vicmar...@hotmail.com
À : ros-dev@reactos.org
Envoyé le : Ven 17 septembre 2010, 9h 55min 03s
Objet : Re: [ros-dev] ASSERT while shutting down ReactOS with VirtualBox Guest 
Additions

 Nope.
It is just that we are following 2003/XP architecture, so we have to use a XP 
driver. Seems VBox additions has installed a 2008 driver(for Vista/7) not 
compatible with ReactOS/XP Kernel.

Did you created the Virtual Machine as Windows XP one?If not, could you test 
if the Assert happens too?
Virtual Box is supposed to install the correct Additions depending on the 
Virtual Machine OS selected when creating the VM. So if VBOX installs a 2008 
driver when you have set your VM as Windows XP compatible then it is a VBOX 
bug.




Date: Fri, 17 Sep 2010 08:58:46 +0200
From: elh...@gmail.com
To: ros-dev@reactos.org
Subject: Re: [ros-dev] ASSERT while shutting down ReactOS with VirtualBox 
Guest 
Additions

ugh... so... its a VirtualBox bug?


On Fri, Sep 17, 2010 at 6:22 AM, Michael Martin martinm...@hotmail.com wrote:

You are indeed correct, sir. The ReactOS website even reads that its XP/2003. 
Sorry, my mistake.

Mike

 From: ros@reactos.org

 To: ros-dev@reactos.org
 Date: Fri, 17 Sep 2010 04:33:14 +0200

 Subject: Re: [ros-dev] ASSERT while shutting down ReactOS with VirtualBox 
 Guest 
Additions
 
 I believe it was communicated to my team we are shooting for win2003, not 
 2008, 
which is an entirely different kernel architecture (Vista/Win7).
 
 You should use a more appropriate driver, or file a bug with the driver 
developer.
 
 -r
 
  I don't think this has anything to do with amount of memory. 
  Just glancing at the assert, I think that the vbox video driver that got 
installed was for made for win2008, in which MmFreeContiguousMemory can be 
called at IRQL=DISPATCH_LEVEL. In reactos we Are using PAGED_CODE, which 
causes 
the assert. We should remove it as we are shooting for win2008.
  
  Date: Thu, 16 Sep 2010 22:30:44 +0200
  From: elh...@gmail.com
  To: ros-dev@reactos.org
  Subject: Re: [ros-dev] ASSERT while shutting down ReactOS with VirtualBox 
Guest Additions installed
  
  its official build
  i will try to regtest
  
  On Thu, Sep 16, 2010 at 10:21 PM, Olaf Siejka cae...@gmail.com wrote:
  
  Is it official build or your own? Could you regress-test it to precise 
revision when it got broken?
  
  
  2010/9/16 Javier Agustìn Fernàndez Arroyo elh...@gmail.com
  
  16 MB, default, i did not touch it
  
  On Thu, Sep 16, 2010 at 10:05 PM, Olaf Siejka cae...@gmail.com wrote:
  
  
  
  How much mem did you assign to video card?
  
  Regards
  2010/9/16 Javier Agustìn Fernàndez Arroyo elh...@gmail.com
  
  
  
  
  steps to reproduce are:
  
  
  1.- Install VBox guest additions
  
  2.- Change color depth to 32-bit
  3.- reboot
  
  4.- Once rebooted in 32-bit color depth mode, shutdown ReactOS
  
  ReactOS will crash
  
  
  2010/9/16 Javier Agustìn Fernàndez Arroyo elh...@gmail.com
  
  
  
  
  
  hello, 
  
  this is to sir_richard, mostly,
  
  i got this crash (assert) when shutting down ReactOS with the VirtualBox 
Guest Additions installed.
  i think the video driver is guilty for some reason i cannot understand... 
probably you know :)
  
  
  
  
  
  
  
  http://www.reactos.org/paste/index.php/7731/
  
  
  
  
  ___
  
  Ros-dev mailing list
  
  Ros-dev@reactos.org
  
  http://www.reactos.org/mailman/listinfo/ros-dev
  
  
  
  ___
  
  Ros-dev mailing list
  
  Ros-dev@reactos.org
  
  http://www.reactos.org/mailman/listinfo/ros-dev
  
  
  
  
  ___
  
  Ros-dev mailing list
  
  Ros-dev@reactos.org
  
  http://www.reactos.org/mailman/listinfo/ros-dev
  
  
  
  ___
  
  Ros-dev mailing list
  
  Ros-dev@reactos.org
  
  http://www.reactos.org/mailman/listinfo/ros-dev
  
  
  
  
  ___
  Ros-dev mailing list
  Ros-dev@reactos.org
  http://www.reactos.org/mailman/listinfo/ros-dev 
___
  Ros-dev mailing list
  Ros-dev@reactos.org
  http://www.reactos.org/mailman/listinfo/ros-dev
 
 
 
 ___
 Ros-dev mailing list
 Ros-dev@reactos.org
 http://www.reactos.org/mailman/listinfo/ros-dev

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


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

[ros-dev] Re : Re : [ros-diffs] [akhaldi] 48687: [FREELDR] -Convertfat12/16 boot secto

[Sylvain Petreolle]

The branch version has 99% comments changes (// versus ;),
#define versus equ at the top for the constants,
and the last change is to tell gas its using intel syntax.

Almost the entire tree is built using gas, hence the change.

 Kind regards,
Sylvain Petreolle



- Message d'origine 
 De : Brian Palmer bri...@sginet.com
 À : ReactOS Development List ros-dev@reactos.org
 Envoyé le : Mar 7 septembre 2010, 19h 12min 34s
 Objet : Re: [ros-dev] Re : [ros-diffs] [akhaldi] 48687: [FREELDR] 
-Convertfat12/16 boot secto
 
 
 Since fathelp was already in Intel syntax originally, why did we require  a
 new version from another branch? What was changed?
 
 -Original  Message-
 From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org]  On
 Behalf Of Sylvain Petreolle
 Sent: Friday, September 03, 2010 8:50  AM
 To: ReactOS Development List
 Subject: [ros-dev] Re : [ros-diffs]  [akhaldi] 48687: [FREELDR]
 -Convertfat12/16 boot secto
 
 It has already  been addressed :
 Next commit replaced fathelp by the intel syntax version  from amd64 branch, 
 written by Timo.
 No code style change was required by  this, no new bugs.
  Kind regards,
 Sylvain Petreolle
 
 
 
 -  Message d'origine 
  De : Pierre Schweitzer pierre.schweit...@reactos.org
   À : ReactOS Development List ros-dev@reactos.org
  Envoyé le  : Ven 3 septembre 2010, 12h 50min 59s
  Objet : Re: [ros-dev] [ros-diffs]  [akhaldi] 48687: [FREELDR]
 -Convertfat12/16 
 boot secto
  
  Pushing the question (which was the real question in Ionescu's  mail...).
 http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/gnu-assembler/i
 386-syntax.html
 l
  
  Best  regards,
  Pierre
  
  PS: Nice to see  you back Alex ;).
  
   What  was the reason for the  change?
   It would be preferable to keep everything  in intel  syntax. Especially
 as
   this is an NT OS.
   
It  should also be noted that this is in a branch, not trunk.

Ged.
   
   
-Original Message-
   From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org]
 On
Behalf Of Aleksey Bragin
   Sent: 02 September 2010   21:55
   To: ReactOS Development List
   Subject: Re:  [ros-dev]  [ros-diffs] [akhaldi] 48687: [FREELDR] - Convert
fat12/16 boot sector  helper code to gas syntax. Brought to you by  the
 Arty.
   [CMAKE] - Add  freeldr and setupldr to  build.
   
   I'm anti-ATT syntax guy too   :)
   
   WBR,
   Aleksey.
   
P.S. Nice to see  Alex's post here, in his good old style.

 --
   From: Daniel  Reimer  daniel.rei...@reactos.org
 Sent: Thursday, September 02, 2010 11:33 PM
   To:  ReactOS Development  List ros-dev@reactos.org
Subject:  Re: [ros-dev] [ros-diffs] [akhaldi] 48687: [FREELDR] -  Convert
 
   fat12/16  boot sector helper code to gas syntax.  Brought to you by the
 Arty. 
 
[CMAKE] - Add freeldr and  setupldr to build.
   
 Err,  nice to call  ppl idiots who try to get the project further...

 If there are bugs, feel free to fix them...
 
   
Am 02.09.2010 21:17, schrieb Alex   Ionescu:
This is retarded, GAS supports Intel syntax. Why  did  this require
rewriting everything in ATT  syntax and  introducing bugs? And what's
up with  calling ATT syntax  GAS Syntax.
   
 I wonder what Brian would  say
   
 It's funny how this project gets rid  of old developers, gets  new
developers, and has them make the  same  mistakes/idiotic things the
 old
developers left for in  the  first place...
   
Good  job!

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

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

[ros-dev] Re : Fedora 13 Build Error

[Sylvain Petreolle]

Hi James,
reactos has now officially 2 fedora 13 users ;)

Since noone notified until today, not even the unix buildbot,
Im building reactos using the same kind of fix since months.
Feel free to commit.

Kind regards,
Sylvain Petreolle



- Message d'origine 
 De : James Tabor jimtabor.ros...@gmail.com
 À : ReactOS Development List ros-dev@reactos.org
 Envoyé le : Mar 27 juillet 2010, 5h 48min 54s
 Objet : [ros-dev] Fedora 13 Build Error
 
 I ran into this on Fedora 13,
 
 [HOST-CC]   tools/cabman/cabinet.cxx
 tools/cabman/cabinet.cxx: In member function  ‘bool
 CCabinet::CreateSimpleCabinet()’:
 tools/cabman/cabinet.cxx:2177:  error: no matching function for call to
 ‘stat::stat(char [260],  stat*)’
 /usr/include/bits/stat.h:40: note: candidates are:  stat::stat()
 /usr/include/bits/stat.h:40: note:  stat::stat(const stat)
 
 from http://code.google.com/p/libproxy/issues/detail?id=122 the patch
 is  based on this;
   
http://code.google.com/p/libproxy/issues/attachmentText?id=122aid=2002375034865556637name=fix_fedora_13_build.patchtoken=8817da5d966f54916b41556ec0ec1722

 
 
 Index: tools/cabman/cabinet.cxx
 ===
 --- - tools/cabman/cabinet.cxx(revision 48297)
 +++  tools/cabman/cabinet.cxx(working copy)
 @@ -21,7 +21,8  @@
  #if !defined(WIN32)
  # include dirent.h
  #endif
 -#if  defined(__FreeBSD__) || defined(__APPLE__)
 +#if !defined(WIN32) ||  defined(__FreeBSD__) || defined(__APPLE__)
 +# include sys/types.h
   # include sys/stat.h
  #endif // __FreeBSD__
  #include  cabinet.h
 
 Not sure this is right, so~ posted here for fast review and  fix,
 James
 
 ___
 Ros-dev  mailing list
 Ros-dev@reactos.org
 http://www.reactos.org/mailman/listinfo/ros-dev
 

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

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

[Sylvain Petreolle]

I fully agree on this.
This will also remove the need to rebuild the dll (and possibly other dependant 
modules)
if we have to disable a registration for testing/debugging purposes.

As I previously said on IRC, we shouldn't expect making coffee from our build 
system.

 Kind regards,
Sylvain Petreolle


- Message d'origine 
 De : Eric Kohl eric.k...@t-online.de
 À : ReactOS Development List ros-dev@reactos.org
 Envoyé le : Dim 13 juin 2010, 20h 11min 49s
 Objet : [ros-dev] Removing the autoregister feature from rbuild
 
 Hi!

I want to remove the autoregister feature from rbuild. Let me 
 explain why I want to do this.

The autoregister feature in rbuild is 
 used to automatically add dlls to the syssetup.inf file which require an ole 
 server registration. The ole servers in these dlls will then be registered in 
 the 2nd setup stage.

The gain of adding the ole server dlls to 
 syssetup.inf automatically is almost non existant as a developer needs to add 
 an 
 'autoregister' element to the rbuild file of the dll.
For example:
  
   autoregister infsection=OleControlDlls type=DllInstall 
 /
The corresponding line in the 'OleControlsDll' section of syssetup.inf 
 is:
11,,comctl32.dll,2

Please remember that the line 
 above only needs to be added once.

Now, what do we loose by generating 
 syssetup.inf automatically? Right now it is only the comments in this file as 
 it 
 is parsed and serialized by the inflib library.

OTOH, my future plans for 
 syssetup.inf are severely hampered by the way rbuild handles syssetup.inf 
 because rbuild is not able to create or modify a Unicode version of 
 syssetup.inf. But, a Unicode version of syssetup.inf is required in order to 
 replace the hard-coded creation of the start menu and desktop links in 
 syssetup.dll by a configurable, localizable and Windows compatible inf-based 
 method.

And finally since Timo suggested to replace rbuild by cmake: The 
 autoregister feature would surely be one of the victims of this change.
So 
 why not drop this almost useless feature now?

What do you 
 think?


Regards,
Eric

___
Ros-dev 
 mailing list

 href=mailto:Ros-dev@reactos.org;Ros-dev@reactos.org

 href=http://www.reactos.org/mailman/listinfo/ros-dev; target=_blank 
 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] Re : I need help fixing rbuild and testing builds on *nix machines!

[Sylvain Petreolle]

Are the usetup changes implying a unicode conversion of reactos.dff ?
Doing tests and looking at testbot output shows that usetup is having problem 
parsing the file.

(base/setup/usetup/interface/usetup.c:2758) SetupFindFirstLine() failed (1st 
stage)It also fails finding gecko cab file in 2nd stage.

 Kind regards,
Sylvain Petreolle



- Message d'origine 
 De : Eric Kohl eric.k...@t-online.de
 À : ReactOS Development List ros-dev@reactos.org
 Envoyé le : Ven 23 avril 2010, 11 h 42 min 41 s
 Objet : [ros-dev] I need help fixing rbuild and testing builds on *nix 
 machines!
 
 Hi!

In order to fix bug #2482 I needed to make inflib Unicode-aware. My 
 local ReactOS setup is curently able to build Boot-CD and Live-CD using 
 Unicode 
 hive*.inf files.

Rbuild is the only tool that still uses the original 
 inflib. Could someone who knows more about C++ and STL than I do have a look 
 at 
 rbuild and make it work with the new inflib?

I can provide a patch that 
 includes newinflib (Unicode-aware inflib) and  my changes to usetup and 
 mkhive.

I also need someone who can test the whole patch on a *nix 
 machine. Any 
 volunters?


Regards,
Eric

___
Ros-dev 
 mailing list

 href=mailto:Ros-dev@reactos.org;Ros-dev@reactos.org

 href=http://www.reactos.org/mailman/listinfo/ros-dev; target=_blank 
 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] Re : Test Bot Crash

[Sylvain Petreolle]

The bot is broken.
Its actually building the tests when doing the bootcd part.
Please lock trunk until bot's fixed.

Kind regards,
Sylvain Petreolle



- Message d'origine 
 De : James Tabor jimtabor.ros...@gmail.com
 À : ReactOS Development List ros-dev@reactos.org
 Envoyé le : Dim 21 Février 2010, 12 h 52 min 48 s
 Objet : Re: [ros-dev] Test Bot Crash
 
 Wow!
 This is odd!
 
 From:
 http://build.reactos.org:8010/builders/x86_%28Debug%29/builds/4214/steps/svn/logs/stdio
 
   USER=root
   _=/sbin/start-stop-daemon
 closing stdin
 using PTY: False
 At revision 45644. --- the change? Where is the rest?
 elapsedTime=4.005306
 /usr/bin/svnversion .
 in dir /opt/buildbot/debug/full/build
 
 Here is the change in the svn log:
 http://www.reactos.org/archives/public/ros-diffs/2010-February/035380.html
 
 On Sun, Feb 21, 2010 at 12:24 AM, James Tabor wrote:
  I'm aware of the crash and it should have updated on the next commit.
  I'll add the ros hack back to the gdi32 font.c test when I get back.
  James
 
 
 ___
 Ros-dev mailing list
 Ros-dev@reactos.org
 http://www.reactos.org/mailman/listinfo/ros-dev


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

[ros-dev] Re : [ros-diffs] [sir_richard] 45223

[Sylvain Petreolle]

We have to switch to gcc 4.4 and this will be resolved.
RosBE-Windows is ready and RosBE-Unix has a release candidate.
Is there still something missing to switch ?

Kind regards,
Sylvain Petreolle



- Message d'origine 
 De : Dmitry Gorbachev gorbac...@reactos.org
 À : ReactOS Development List ros-dev@reactos.org
 Envoyé le : Dim 24 Janvier 2010, 4 h 01 min 19 s
 Objet : Re: [ros-dev] [ros-diffs] [sir_richard] 45223
 
 It produces many warnings warning: 'noreturn' function does return
 (which are treated as errors). Probably GCC 4.1.3 does not recognize
 that exit() hack or __builtin_trap() never returns. Unfortunately, I
 deleted old GCC a long time ago and now can't check how it behaves.
 
 ___
 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] Re : [ros-diffs] [spetreolle] 45091: Disable spooler service. This allows bootcdregtest to start here under qemu-kvm.

[Sylvain Petreolle]

This is a hack, it allows rpcss to not crash at every boot.
Since we have no known clue about the builbot breakage, I tried this.

 
The next step would be adding debug info to rosautotest :
we know that regtest.cmd is started since the log contains the ip configuration 
of the bot.

Kind regards,
Sylvain Petreolle


- Message d'origine 
 De : Ged Murphy gedmur...@gmail.com
 À : ros-dev@reactos.org
 Envoyé le : Sam 16 Janvier 2010, 5 h 48 min 20 s
 Objet : Re: [ros-dev] [ros-diffs] [spetreolle] 45091: Disable spooler 
 service. This allows bootcdregtest to start here under qemu-kvm.
 
 This sounds like a hack.
 Why would disabling a service fix an operating system?
 Also, don't we need this service for certain Wine tests?
 
 
 -Original Message-
 From: ros-diffs-boun...@reactos.org [mailto:ros-diffs-boun...@reactos.org] On 
 Behalf Of spetreo...@svn.reactos.org
 Sent: 15 January 2010 22:17
 To: ros-di...@reactos.org
 Subject: [ros-diffs] [spetreolle] 45091: Disable spooler service. This allows 
 bootcdregtest to start here under qemu-kvm.
 
 Author: spetreolle
 Date: Fri Jan 15 23:17:16 2010
 New Revision: 45091
 
 URL: http://svn.reactos.org/svn/reactos?rev=45091view=rev
 Log:
 Disable spooler service.
 This allows bootcdregtest to start here under qemu-kvm.
 
 Modified:
 trunk/reactos/boot/bootdata/hivesys_i386.inf
 
 Modified: trunk/reactos/boot/bootdata/hivesys_i386.inf
 URL: 
 http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/hivesys_i386.inf?rev=45091r1=45090r2=45091view=diff
 ==
 --- trunk/reactos/boot/bootdata/hivesys_i386.inf [iso-8859-1] (original)
 +++ trunk/reactos/boot/bootdata/hivesys_i386.inf [iso-8859-1] Fri Jan 15 
 23:17:16 2010
 @@ -1198,7 +1198,7 @@
 HKLM,SYSTEM\CurrentControlSet\Services\Spooler,Group,0x,SpoolerGroup
 HKLM,SYSTEM\CurrentControlSet\Services\Spooler,ImagePath,0x0002,%SystemRoot%\system32\spoolsv.exe
 HKLM,SYSTEM\CurrentControlSet\Services\Spooler,ObjectName,0x,LocalSystem
 -HKLM,SYSTEM\CurrentControlSet\Services\Spooler,Start,0x00010001,0x0002
 +HKLM,SYSTEM\CurrentControlSet\Services\Spooler,Start,0x00010001,0x0004
 HKLM,SYSTEM\CurrentControlSet\Services\Spooler,Type,0x00010001,0x0110
 
 ; WLAN service
 
 
 
 ___
 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] Re : [ros-diffs] [jimtabor] 44902: [Win32k] - Patch by Dan Kegel: Fix minor read buffer overrun in CombineRgn. http://bugs.winehq.org/show_bug.cgi?id=20851 - When locking and unlocking regio

[Sylvain Petreolle]

Well, it seems James committed more than the original patch,
which is a one liner.

--- a/dlls/gdi32/region.c
+++ b/dlls/gdi32/region.c
@@ -2216,7 +2216,8 @@ static BOOL REGION_SubtractO (WINEREGION *pReg, RECT *r1, 
RECT *r1End,
 if (!add_rect( pReg, left, top, r1-right, bottom )) return 
FALSE;
}
r1++;
-   left = r1-left;
+   if (r1 != r1End)
+   left = r1-left;
}
 }


 Kind regards,
Sylvain Petreolle



- Message d'origine 
 De : Timo Kreuzer timo.kreu...@web.de
 À : ros-dev@reactos.org
 Envoyé le : Dim 3 Janvier 2010, 10 h 26 min 55 s
 Objet : Re: [ros-dev] [ros-diffs] [jimtabor] 44902: [Win32k] - Patch by Dan 
 Kegel: Fix minor read buffer overrun in CombineRgn. 
 http://bugs.winehq.org/show_bug.cgi?id=20851 - When locking and unlocking 
 regions, use probe to check attribute space first before read or write access.
 
 
 Why the KeEnterCriticalRegion?
 
 jimta...@svn.reactos.org wrote:
  - if (pAttr) FreeObjectAttr(pAttr);
  + if (pAttr)
  + {
  +KeEnterCriticalRegion();
  +FreeObjectAttr(pAttr);
  +KeLeaveCriticalRegion();
  + }
break;
   
 
 
 ___
 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] Re : MmSecureVirtualMemory

[Sylvain Petreolle]

Faking success for this kind of function can lead to great race conditions,
according to its documentation...
Is this ok to have a it mysteriously (doesn't) work state ?

 Kind regards,
Sylvain Petreolle



De : Alex Ionescu ion...@videotron.ca
À : ReactOS Development List ros-dev@reactos.org
Envoyé le : Sam 2 Janvier 2010, 3 h 08 min 15 s
Objet : Re: [ros-dev] MmSecureVirtualMemory

It's already been fixed.


On 2010-01-01, at 8:02 PM, Olaf Siejka wrote:

Could anyone please consider implementing the above? According to 
http://msdn.microsoft.com/en-us/library/ms802934.aspx - 
MmUnsecureVirtualMemory could be required as well.

Lack of those functions is currently breaking up 3d acceleration passthrough 
with Virtualbox 3.1.0 and newer.



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


Best regards,
Alex Ionescu 
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[ros-dev] Re : Code hacking rules, currently applying for NTOSKRNL

[Sylvain Petreolle]

Who should we ask for ros-arm-bringup code then,
like in the MDL PROBE FAILED case ?

 Kind regards,
Sylvain Petreolle

- Message d'origine 
 2.2. you want to either hack or revert the offending commit which  
 contains a certain regression but doesn't cause important  
 consequences like inability to install the OS, or major loss of  
 functionality: This is allowed only from permission of author of the  
 code which you want to hack or, as alternative, from my permission.
 
 
 I think this way we can get some order into the coming commits flow,  
 which is hard to track.
 Also, please comment on this, so that we can alter those rules and  
 maybe accept them for all modules.
 
 
 Thanks for understanding,
 Aleksey Bragin.

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

[ros-dev] Re : 0.3.9 Status

[Sylvain Petreolle]

Looking at thee commit that adds a link to downloader on the desktop,
and considering that the app is now part of trunk, couldnt we add it 
permanently to the desktop ?
It looks like the first thing to do after a fresh install.

 Kind regards,
Sylvain Petreolle



- Message d'origine 
 De : Aleksey Bragin alek...@reactos.org
 À : ReactOS Development List ros-dev@reactos.org
 Envoyé le : Jeudi, 16 Avril 2009, 22h07mn 19s
 Objet : [ros-dev] 0.3.9 Status
 
 Hi,
 by today most of the bugs which were having 0.3.9 as a milestone are  
 fixed - including fixing 4-months old bug with richedit control,  
 properly trimming DLL names during PE loading so that apps now can  
 find their DLLs (previously that failed in some cases), newest  
 downloader problem introduced yesterday and fixed today (not to speak  
 about yesterday's fixes too!).
 
 This is a very good example of team collaboration, team effort aimed  
 at a narrow set of problems. It worked very well, and I think we  
 would utilise such bugfixing sessions in future too.
 
 Branching date is now set to tomorrow, 17th of April, 2009 and is not  
 going to be changed anymore. As soon as the 0.3.9 branch is created,  
 feature freeze is considered to be finished.
 
 After the release is branched, usual testing will be conducted,  
 actual packages built and released as usual.
 
 
 Thank you for your efforts and for being patient with regards to the  
 feature freeze.
 
 WBR,
 Aleksey Bragin.
 ___
 Ros-dev mailing list
 Ros-dev@reactos.org
 http://www.reactos.org/mailman/listinfo/ros-dev


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

[ros-dev] Re : Year 2038 problem

[Sylvain Petreolle]

Please keep reading, this affect non unix systems also.

 Kind regards,
Sylvain Petreolle




De : Ged gedmur...@gmail.com
À : ReactOS Development List ros-dev@reactos.org
Envoyé le : Dimanche, 12 Avril 2009, 1h19mn 26s
Objet : Re: [ros-dev] Year 2038 problem

 
This is NT, not unix (thankfully)
 
From:ros-dev-boun...@reactos.org
[mailto:ros-dev-boun...@reactos.org] On Behalf Of Javier Agustìn
Fernàndez Arroyo
Sent: 12 April 2009 00:02
To: ReactOS Development List
Subject: [ros-dev] Year 2038 problem
 
Hi all,
i hope you have already taken into account this:

http://en.wikipedia.org/wiki/Year_2038_problem

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

[ros-dev] Re : Year 2038 problem

[Sylvain Petreolle]

I also noticed a funny thing browsing the year 2038 website : 
http://www.2038bug.com/demo.html shows the first negative date given by a 
negative int32 number.

-2147483648, Fri Dec 13 20:45:52 1901
Kind regards,
Sylvain Petreolle





De : Ged gedmur...@gmail.com
À : ReactOS Development List ros-dev@reactos.org
Envoyé le : Dimanche, 12 Avril 2009, 1h19mn 26s
Objet : Re: [ros-dev] Year 2038 problem

 
This is NT, not unix (thankfully)
 
From:ros-dev-boun...@reactos.org
[mailto:ros-dev-boun...@reactos.org] On Behalf Of Javier Agustìn
Fernàndez Arroyo
Sent: 12 April 2009 00:02
To: ReactOS Development List
Subject: [ros-dev] Year 2038 problem
 
Hi all,
i hope you have already taken into account this:

http://en.wikipedia.org/wiki/Year_2038_problem

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