dreimer(a)svn.reactos.org wrote:
> + if ("$ENV:ROS_AUTOMAKE" -eq "") {
> + $ENV:ROS_AUTOMAKE = "makefile-$ENV:ROS_ARCH.auto"
> + }
> [...]
That's not properly ported.
My script only sets these variables locally due to "setlocal", yours
permanently changes the environment variables. This will result in obvious
problems when ROS_ARCH is changed.
Don't know whether PS provides an equally elegant way to overwrite these
variables locally like Batch does ;-)
Best regards,
Colin
Hi!
These are Class Owned DCE starting at the end of allocations. When
closing the application the thread cleanup routine I added frees the
DCE's. (This was not implemented yet, so they never freed and the side
effect of slowing the system down due to hashing the long list of
allocations) Amazing! Look at the count! For every allocation of a
Class Owned DCE there is a menu and even one for every item in the
menu and not reusing the ones allocated and allocating more! This is
one reason AbiWord is slow when drawing! The overhead is crippling!
Most (mean all) applications use one or two DCE's and common to the
DCX_CACHE type. This is the best example of an UNIX ported program to
Windows I've ever seen. Unix hackers hacking it to draw in windows
without the proper research! This is a modest debug list here, what
would happen working with AbiWord all day? ReactOS would most likely
get the blame! Must I write more?
(subsystems/win32/win32k/ntuser/windc.c:96) Alloc DCE's! 152
(subsystems/win32/win32k/ntuser/windc.c:96) Alloc DCE's! 153
(subsystems/win32/win32k/ntuser/windc.c:96) Alloc DCE's! 154
(dll/win32/gdi32/misc/misc.c:317) Get Handle! Count 1 PEB 0x7ffdf000
(subsystems/win32/win32k/ntuser/windc.c:96) Alloc DCE's! 155
(subsystems/win32/win32k/ntuser/windc.c:96) Alloc DCE's! 156
(subsystems/win32/win32k/ntuser/windc.c:96) Alloc DCE's! 157
[Close App]
err:(dll/win32/user32/windows/menu.c:3687) MenuTrackMenu 2
(subsystems/win32/win32k/ntuser/timer.c:428) Invalid window handle
(subsystems/win32/win32k/ntuser/vis.c:75) ATM the Current Window or
Parent is dead!
(subsystems/win32/win32k/ntuser/vis.c:75) ATM the Current Window or
Parent is dead!
(subsystems/win32/win32k/ntuser/vis.c:75) ATM the Current Window or
Parent is dead!
(subsystems/win32/win32k/ntuser/vis.c:75) ATM the Current Window or
Parent is dead!
(subsystems/win32/win32k/ntuser/vis.c:75) ATM the Current Window or
Parent is dead!
(subsystems/win32/win32k/ntuser/vis.c:75) ATM the Current Window or
Parent is dead!
(subsystems/win32/win32k/ntuser/vis.c:75) ATM the Current Window or
Parent is dead!
(subsystems/win32/win32k/ntuser/vis.c:75) ATM the Current Window or
Parent is dead!
(subsystems/win32/win32k/ntuser/vis.c:75) ATM the Current Window or
Parent is dead!
(subsystems/win32/win32k/ntuser/vis.c:75) ATM the Current Window or
Parent is dead!
(subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 156
(subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 155
(subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 154
(subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 153
(subsystems/win32/win32k/ntuser/windc.c:96) Alloc DCE's! 154
(subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 153
(subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 152
(subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 151
(subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 150
(subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 149
(subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 148
<Snip>.....
(subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 11
(subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 10
(subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 9
(subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 8
(subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 7
(subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 6
(subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 5
(subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 4
(subsystems/win32/win32k/ntuser/windc.c:640) Freed DCE's! 3
sir_richard(a)svn.reactos.org wrote
>... (interesting that buildbot's QEMU does not support SYSENTER, as newer versions do)...
Buildbot doesn't use QEMU it uses KVM. I realise that KVM uses parts of QEMU, but I don't know to what extent.
Maybe this is the reason for the difference?
Maybe one day we'll have a real operating system running our build machine instead of linux ;)
Ged.
All,
today I would like to officially announce the (sub)project I was
working on for the last half a year, and make a call to developers to
participate.
ReactOS has been around for about 11 years, and it's been growing
each year since then. The demand for an open source Windows-
compatible operating system is huge: geek, servers, netbooks,
accounting, point of sales, CAD... The list could go on and on.
Time goes by, new versions of Windows operating systems are being
released. ReactOS usability still has not reached any significant
value. Not to say ReactOS didn't even officially enter the Beta
stage. Separately, there are many achievements: audio support
appeared, bootloader is able to boot real Windows, some Windows
binary drivers could be loaded and work in ReactOS, networking is
being improved every day, the kernel is being actively worked on too.
But all of that does not really matter for the end user. For a user
it's important that a web-browser loads websites, instant messenger
client connects and works, [Microsoft/Open] Office shows documents,
email client gets new messages.
This bare usability is what's still missing, and if ti continues to
be like this, I am afraid our project won't be of much use in another
10 years. Certainly, I became very concerned and started analyzing
situation. Being opensource project without major commercial
sponsors, there are certain limitations as to what could be done to
improve the situation, so mainly it's a matter of picking right
priorities and properly managing (motivating) existing human resources.
The part of ReactOS which plays major role in compatibility and
usability is Win32 subsystem. Right now, it's a huge monster which
requires a lot more human resources than we have now. It's very hard
and time consuming to reach even Windows 2000 level of compatibility
with current amount of participating developers, and high entry level.
I came up with something which could solve this problem: Arwinss. To
better explain what it is, I made a special presentation (URL to
slides in PDF format is in the end of this email). Please imagine
myself talking through it as I didn't perform/record it.
Now, after you read through the presentation, I would like to make a
proposal to all developers (even newcomers, who never worked on
ReactOS before). Let's make an Arwinss week, or Arwinss month. Every
developer could definitely find a few hours during a week to hack
Arwinss. Entry level is rather low, there are some basic docs about
Arwinss in the wiki, and I am happy to consult about details.
If I could make this new subsystem out of nothing (out of Wine and
ReactOS) almost alone (Kamil and Smiley help is very valued and
appreciated!) within a few months, imagine what we could do all
together?
With the best regards,
Aleksey Bragin.
The presentation: (links to further information are in the
presentation too)
http://www.reactos.org/media/docs/2010/arwinss.pdf
This project is not wine so please keep it nice! You guys are newbies
and need to play nice! We old timers can kick it around, not you!
Until a year or two you guys can be asses....
Friendly warning,
James
sir_richard(a)svn.reactos.org wrote:
> Please, next time before you harass us with e-mails, try to read your logs.
> LD choses a random entrypoint if the symbol cannot be found.
I hope you aren't referring to the 2 emails stating that you broke the build?
The 2 guys who so rudely "harassed" you for highlighting your mistake are testers, they can't spot and fix your errors.
The fact that you broke the build stops them from testing. Please be a little more considerate.
Ged.
Hi Sir Richard,
just FYI, this rev introduced freeldr crash (happens after loading
initial drivers): http://bjauy.com/images/45155-freeloader.png
Best regards,
Maciej
----------------------------------------------------------------------
Rezerwując wczesniej kupisz bilety lotnicze taniej!
Sprawdz >>> http://link.interia.pl/f256c
Hi,
sir_richard wrote:
> /* GLOBALS *******************************************************************/
> +
> +/* Boot and double-fault/NMI/DPC stack */
> +UCHAR P0BootStackData[KERNEL_STACK_SIZE] __attribute__((aligned (16)));
> +UCHAR KiDoubleFaultStackData[KERNEL_STACK_SIZE] __attribute__((aligned (16)));
MinGW GCC 4.4.x can ignore in some situations attribute aligned on
uninitialized global variables because of a bug. A workaround is to
initialize a variable or to compile with -fno-common.
Hi Sir Richard,
Build's broken:
ntoskrnl/ke/i386/context.c: In function 'KiSwapProcess':
ntoskrnl/ke/i386/context.c:30: warning: passing argument 1 of '_InterlockedXor' makes pointer from integer without a cast
ntoskrnl/ke/i386/context.c:31: warning: passing argument 1 of '_InterlockedXor' makes pointer from integer without a cast
make: *** [/mnt/ramdisk/buildbot/debug/obj/ntoskrnl/ke/i386/context_ntkrnlmp.o] Error 1
make: *** Waiting for unfinished jobs....
Command exited with non-zero status 2
from: http://build.reactos.org:8010/builders/x86_%28Debug%29/builds/3789/steps/co…
Gabriel.
_________________________________________________________________
25 Gygabite gratis online. Archivia e condividi i tuoi file!
http://www.windowslive.it/skyDrive.aspx
hello guys,
I am sorry for not mentioning a specific area that I am interested. I
am interested in filesystems. Thank you Aleksey , victor and others for
providing the list of projects. From the list I am interested in the
partition manger as arty shed some light it. Any suggestions and help
are most welcome.
Thanks & Regards,
sudheer.
I read the PDF and other information earlier today. I've just updated the Wikipedia page (in English, at least)
regarding Arwinss with the newer, more detailed information. Hopefully, once more people know about Arwinss
and what it will do for ReactOS, more people will appreciate the potential of this project and join in.
I felt you guys should know, since I brought up the issue earlier. Feel free to check on it and correct any errors
I've made. :)
-Joshua Bailey
If you guys don't know me by know, my name is Joshua Bailey, though you may recognize me better as RaptorEmperor on the forums. I infrequently do software testing for the ReactOS project, and I've also just
started teaching myself how to do debugging work. If I knew C, better understood the Windows architecture, and felt more comfortable in my abilities as a programmer I would probably join in development outright.
I'm a pretty frequent visitor to the forums, but I don't generally post anything to the ros-dev mailing list because I'd rather not distract the developers with my random questions about GDI support or whatever else
crosses my mind and leave this mailing list open to more important matters.
For as long as I have been involved with the ReactOS project I've also been a Wikipedia editor. I check on the ReactOS article on Wikipedia periodically to see if there are any points in the article to which I can add
relevant information so readers are better informed (and hopefully more interested) in the ReactOS project. A few weeks ago I added a reference to Arwinss in the paragraph of the article detailing the relationship
between ReactOS and other projects, more specifically Wine. Tonight I checked the article, and I noticed that the reference to Arwinss was removed by LoneRifle, with the attached comment "Current and future
development: Remove information about arwinss on request of the Dev team".
I initially linked my reference to Arwinss in the Wikipedia article to the Arwinss wiki page, and another user by the name of XRideBMX changed the reference to Newsletter #62, which was the first announcement on
the main page about Arwinss. Both of these sources are publicly available from the ReactOS website. There's nothing dubious about their accuracy or point of view. Considering this, and the outright statement on
the article's revision history, I'm left to conclude that the only reason that my edit was removed was censorship on the part of the ReactOS development team.
The reason I find this disturbing is that Wikipedia standards dictate a non-point-of-view policy. By having underlings edit the article to best reflect the preferred viewpoints of the developers, the integrity of the article is
compromised. If my edits were removed for a more legitimate reason, for example, because someone didn't feel they were relevant, I could argue the point with them personally. But as a source of free information,
without intent of bias, seeing the developers complicit in censorship on Wikipedia makes me feel extremely uncomfortable about ReactOS. I'm sure Dick Cheney and the CIA don't appreciate their dirty laundry
(waterboarding, etc.) being plastered in a public encyclopedia, but flags would be immediately raised if the waterboarding article was changed with the article history stating "Remove information about CIA
waterboarding on the request of George Tenet". Seeing this kind of behavior coming from free and open-source project, and the flagrant nature of it, is extremely disturbing to me.
I'm formally asking you, the development team, why my comments were
deemed necessary for removal. Since I was the one who made the edit, and considering the concerns I have listed, I deserve some
explanation. As far as I can tell, mentioning Arwinss in a public encyclopedia, using publicly available sources, does no harm to the project. What about the existence of Arwinss was deemed too secret for a
Wikipedia page? How can Arwinss be considered public enough for the ReactOS front page, but not enough for a Wikipedia page? What legitimate reason is there for removing the reference to Arwinss in
Wikipedia? Outside of a sloppy attempt at censorship?
I have been very excited about the ReactOS project since I first discovered it around 2005, and with Arwinss on the radar I'm more excited to see what is going to come out of the project than I have been in a long
time. However, if the development team is not comfortable enough to trust that people can make their own opinions about ReactOS without censoring irrelevant details on a Wikipedia page, maybe I should consider
whether or not ReactOS really adheres to the principles of openness and freedom that I do. As much as I like ReactOS, the I hold the values of open-source first.
I apologize if my formatting appears to be poor, because I don't send emails to mailing lists from this email account that often.
I would greatly appreciate a response. If there is a misunderstanding here I would very much like to resolve it, to clear up my current reservations about the ReactOS project. If not, I reserve my right to revert the
changes to the article.
-Joshua Bailey
>yes, I asked LoneRifle to remove the reference because I was preparing much better information (which has just been released yesterday) and
>didn't want people to read old incomplete info. So from now on you could use this information in our wikipedia article.
If that was the case, that makes sense. Removing the information from the article outright, as opposed to simply waiting and updating the article
with more detailed information when it was available might have been a better way of doing things so no red flags pop up, in my mind
or the mind of others. Alternately, you, LoneRifle, or whoever is the one most in charge of maintaining the Wikipedia page should have at least
noted that the information was going to be replaced with updated information so no other Wikipedia editors were left to assume that the information
was simply going to disappear. Probably the only reason I didn't revert the changes immediately was because I wanted to ask the devs about it
first to see if there was a misunderstanding. My desire to see ReactOS succeed was tempering my natural instinct to assume the worst about the
situation.
Betov already made accusations of ReactOS fans tampering with Wikipedia a while back, and while I don't believe that his claims are true, a
random person reading Betov's accusations and then seeing that kind of a statement in the article's revision history might be more apt to be
apprehensive about the project. Because of the bad rap ReactOS has gotten in the past, we have to be more careful to avoid feeding into any
misinformation that has been spread about ReactOS. Hopefully you can see why I was concerned. It's cool now, we'll just have to do things a bit
differently in the future.
Thanks for getting back to me so quickly.
Since that's cleared up, now I can sit around and get excited about Arwinss again. When should us testers expect to see a working Arwinss in the
trunk builds to test?
-Joshua Bailey
hello,
Thank you very much for all the help guys. I am interested in the Fast FAT project. Also arty and colibri gave me an idea to work on partmgr.sys. I am more interested towards Fast FAT as I have prior experience on file systems and I can show something concrete to my professor. The other thing is for partmgr.sys I need to start from the scratch and there isnt much info about it. Is it fine for others ??(since some one might be working on it).The idea of adding list of all the medium sized task to the wiki is good as its going to help people like me.
Thanks & Regards,
sudhir.
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-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of spetreolle(a)svn.reactos.org
Sent: 15 January 2010 22:17
To: ros-diffs(a)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=45091&view=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…
==============================================================================
--- 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",0x00000000,"SpoolerGroup"
HKLM,"SYSTEM\CurrentControlSet\Services\Spooler","ImagePath",0x00020000,"%SystemRoot%\system32\spoolsv.exe"
HKLM,"SYSTEM\CurrentControlSet\Services\Spooler","ObjectName",0x00000000,"LocalSystem"
-HKLM,"SYSTEM\CurrentControlSet\Services\Spooler","Start",0x00010001,0x00000002
+HKLM,"SYSTEM\CurrentControlSet\Services\Spooler","Start",0x00010001,0x00000004
HKLM,"SYSTEM\CurrentControlSet\Services\Spooler","Type",0x00010001,0x00000110
; WLAN service