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
Hi,
sir_richard wrote:
> * We really have to get a good DS/ES first before touching any data.
> *
> * These two reads will either go in a register (with optimizations ON) or
> * a stack variable (which is on SS:ESP, guaranteed to be good/valid).
> *
> * Because the assembly is marked volatile, the order of instructions is
> * as-is, otherwise the optimizer could simply get rid of our DS/ES.
Timo Kreuzer wrote:
> 2.) Segements should be fixed up before entering C code, as not doing so
> may introduce possible compiler dependend breakages. It's also much
> cleaner and there's no reason to do the same stuff later in inline assembly
> instead of direcly in the asm entry point.
Ros Arm wrote:
> Regarding #2, I unfortunately do not see the need to add more assembly
> when it is not needed. There are no subtle compiler breakages involved,
> since it is impossible for the compiler to add a DS/ES access for no reason
> at all (can you come up with an example?), this is part of the contract the
> compiler has to make (if compilers did this, it would break a whole class of
> embedded and real-mode software). Because the stack is safe, I think it's
> worth avoiding the extra lines of assembly. The C inlines will produce
> exactly the same code anyway.
Not as a guide to action, simply to note — there is no guarantee that
volatile asm statements (and code around them) will never be
reordered. As only two registers are needed to keep Ds and Es, it
seems to work there. But in a general case, GCC does not hesitate to
rearrange such stuff…
Hi,
I am interested to work on reactos developement. I want to take my work on reactos as a credit in my university. I spoke toAleksey Bragin (Fireball) regarding this. He asked me to mail to the developer mailing list. I need some concrete work to work for like five months or more so that I can show to professor to get his acceptance. My skills involve mostly on developing .I am mostly a C++ programmer with some experience in assembly language. I have some prior experience on filesystems and kernel but mostly linux. I have some experience on windows drivers too. By the way I am a masters student in computer science from US.
Thanks & Regards,
sudhir.
.
@Sir Richard,
While fixing trunk breakage, I also fixed another bug in
KiTrap0DHandler, which was always only checking one prefix.
I attached the patch.
Regards,
Timo
Index: traphdlr.c
===================================================================
--- traphdlr.c (Revision 45057)
+++ traphdlr.c (Arbeitskopie)
@@ -1103,19 +1103,23 @@
/* Skip prefix instructions */
for (j = 0; j < sizeof(KiTrapPrefixTable); j++)
{
- /* Is this NOT a prefix instruction? */
- if (Instructions[i] != KiTrapPrefixTable[j])
+ /* Is this a prefix instruction? */
+ if (Instructions[i] == KiTrapPrefixTable[j])
{
- /* We can go ahead and handle the fault now */
- Instruction = Instructions[i];
+ /* Stop looking */
break;
}
}
- /* Do we need to keep looking? */
- if (Instruction) break;
+ /* Is this NOT any prefix instruction? */
+ if (Instructions[i] != KiTrapPrefixTable[j])
+ {
+ /* We can go ahead and handle the fault now */
+ Instruction = Instructions[i];
+ break;
+ }
}
-
+
/* If all we found was prefixes, then this instruction is too long */
if (!Instruction)
{
:)
Begin forwarded message:
> From: Max Winter <maxwinter2001(a)yahoo.com>
> Date: January 13, 2010 1:26:11 AM GMT+03:00
> To: xxxxxxx(a)reactos.org
> Subject: removing ReactOS
>
> How do I get ReactOS off my computer? I downloaded a third of it
> and for various reasons stopped the download. I want to get it off
> my computer now but it is not giving me delete or cut options.
> This is as bad as malware, or Hotel California, you can check it
> in but you can't check out.
>
> M
>
Go into ntoskrnl and svn up -r 45013 should take care of it.......
On Wed, Jan 13, 2010 at 3:31 AM, Ged Murphy <gedmurphy(a)gmail.com> wrote:
> sir_richard,
>
> Trunk is still broken and is causing issues for some of the dev team.
>
> You can see the problems in our buildbot test machine:
> - Go to the following address : http://build.reactos.org:8010
> - under the x86_(Test) machine, click on the stdio for the 'test' stage.
> - You'll see stage 1 complete, the stage 2 bugchecks.
>
> Could you please address this problem before continuing your work as it's ruining the test system.
> The problem is that because our test machine can't run we aren't able to monitor other commits in other areas, meaning we're potentially introducing other bugs that we're now missing.
> According to our policy, failure to fix this soon (it's normally 24 hours) will result in us having to freeze development on trunk until the bug is fixed. If we're unable to fix it in a reasonable amount of time then the changes need to be reverted until we have a bootable OS again.
>
> Regards,
> Ged Murphy.
>
>
>
Hi,
I suggest the following changes to the current implementation:
1.) Replace the PUSHA in the trap entry code, by a series of MOVs to the
correct stack positions. The same for the trap exit code.
KiTrapFrameFromPushaStack can be removed then. This would result in more
clear, less complex and faster code, with only a few additional
assembly instructions in the trap entry macro. The exit could be done
either by normal call/return or by a jmp to an exit handler.
2.) Segements should be fixed up before entering C code, as not doing so
may introduce possible compiler dependend breakages. It's also much
cleaner and there's no reason to do the same stuff later in inline
assembly instead of direcly in the asm entry point.
The resulting code might looks something like this:
/* Allocate KTRAP_FRAME */
sub esp, KTRAP_FRAME_LENGTH - 10 * 4
/* Save integer registers */
mov [esp + KTRAP_FRAME_EBP], ebp
mov [esp + KTRAP_FRAME_EBX], ebx
mov [esp + KTRAP_FRAME_ESI], esi
mov [esp + KTRAP_FRAME_EDI], edi
mov [esp + KTRAP_FRAME_EAX], eax
mov [esp + KTRAP_FRAME_ECX], ecx
mov [esp + KTRAP_FRAME_EDX], edx
mov [esp + KTRAP_FRAME_EBX], ebx
/* Save segment regs */
mov [esp + KTRAP_FRAME_SEGDS], ds
mov [esp + KTRAP_FRAME_SEGES], es
/* Fixup segment regs */
mov ax, KGDT_R3_DATA | RPL_MASK
mov ds, ax
mov es, ax
Timo
dreimer(a)svn.reactos.org wrote:
> URL: http://svn.reactos.org/svn/reactos?rev=45050&view=rev
FYI, I already have a change like this ready for some months, see
http://reactos.colinfinck.de/files/Other_Stuff/Clean.cmd
I won't commit it though, because after a suggestion from KJK, I agree that
it would be the best if RosBE's basic clean logic goes into the Makefile
itself and RosBE's clean scripts only call "make rosbe-clean" (or whatever
it'll be called) afterwards.
Then no RosBE clean script would ever need to care about the environment
variables for object and output pathes again. We would stop duplicating
logic in the Makefile and in RosBE and a simple "clean" would always operate
on the same tree as a "make" by design.
This is another change that should be finished before we release RosBE 1.5,
because it'll break compatibility with older revisions (just like the new
toolchain will do), and I want to avoid doing this too often.
Best regards,
Colin
\o/
<3 <3 <3
dreimer(a)svn.reactos.org schrieb:
> Author: dreimer
> Date: Mon Jan 11 22:22:52 2010
> New Revision: 45050
>
> URL: http://svn.reactos.org/svn/reactos?rev=45050&view=rev
> Log:
> Ok, last time I delete my built main tree while playing with clean in a branch!
> Now clean cleans the branch you are in!
>
>
What do you all think about developer's email in source code? Is
there a need for it at all there?
WBR,
Aleksey.
On Jan 10, 2010, at 1:43 AM, ekohl(a)svn.reactos.org wrote:
> Author: ekohl
> Date: Sat Jan 9 23:43:16 2010
> New Revision: 45020
>
> URL: http://svn.reactos.org/svn/reactos?rev=45020&view=rev
> Log:
> Removed outdated email addresses.
> Modified: trunk/reactos/ntoskrnl/ke/queue.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/
> queue.c?rev=45020&r1=45019&r2=45020&view=diff
> ======================================================================
> ========
> --- trunk/reactos/ntoskrnl/ke/queue.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/ke/queue.c [iso-8859-1] Sat Jan 9
> 23:43:16 2010
> @@ -5,7 +5,7 @@
> * PURPOSE: Implements kernel queues
> * PROGRAMMERS: Alex Ionescu (alex.ionescu(a)reactos.org)
> * Gunnar Dalsnes
> - * Eric Kohl (ekohl(a)rz-online.de)
> + * Eric Kohl
> */
On 21:03 Fri 01 Jan , ros-arm-bringup(a)svn.reactos.org wrote:
> Author: ros-arm-bringup
> Date: Fri Jan 1 22:03:22 2010
> New Revision: 44861
>
> Modified: trunk/reactos/ntoskrnl/include/internal/i386/asmmacro.S
> @@ -87,18 +87,47 @@
> //
> // @name UNHANDLED_PATH
> //
> -// This macro TODO
> +// This macro prints out that the current code path is not expected yet
> //
> // @param None
> //
> // @remark None.
> //
> -.macro UNHANDLED_PATH
> +.macro UNHANDLED_PATH Reason
> +
> + /* Push reason */
> + push offset 1f
> +
> /* Get EIP */
> call $+5
>
> /* Print debug message */
> push offset _UnhandledMsg
> + call _DbgPrint
> + add esp, 12
> +
> + /* Loop indefinitely */
> + jmp $
> +
> +1:
> + .asciz \Reason
I think, this should be:
.asciz "\Reason"
I don't know why, but this line (both variants) doesn't compile for me
with RosBE 1.4.2 (Linux):
ntoskrnl/ke/i386/trap.s: Assembler messages:
ntoskrnl/ke/i386/trap.s:290: Error: junk at end of line, first unrecognized character is `o'
ntoskrnl/ke/i386/trap.s:290: Error: junk at end of line, first unrecognized character is `j'
ntoskrnl/ke/i386/trap.s:290: Error: junk at end of line, first unrecognized character is `o'
ntoskrnl/ke/i386/trap.s:425: Error: junk at end of line, first unrecognized character is `j'
ntoskrnl/ke/i386/trap.s:425: Error: junk at end of line, first unrecognized character is `j'
ntoskrnl/ke/i386/trap.s:425: Error: junk at end of line, first unrecognized character is `j'
ntoskrnl/ke/i386/trap.s:439: Error: junk at end of line, first unrecognized character is `j'
ntoskrnl/ke/i386/trap.s:439: Error: junk at end of line, first unrecognized character is `j'
ntoskrnl/ke/i386/trap.s:439: Error: junk at end of line, first unrecognized character is `j'
ntoskrnl/ke/i386/trap.s:467: Error: junk at end of line, first unrecognized character is `A'
ntoskrnl/ke/i386/trap.s:1677: Error: junk at end of line, first unrecognized character is `R'
ntoskrnl/ke/i386/trap.s:1677: Error: junk at end of line, first unrecognized character is `j'
ntoskrnl/ke/i386/trap.s:1677: Error: junk at end of line, first unrecognized character is `R'
ntoskrnl/ke/i386/trap.s:2415: Error: junk at end of line, first unrecognized character is `c'
ntoskrnl/ke/i386/trap.s:2594: Error: junk at end of line, first unrecognized character is `m'
make: *** [obj-i386/ntoskrnl/ke/i386/trap_ntoskrnl.o] Error 1
--
Alexander Potashev
Public Notice:
First and last warning! You do not have my permission to switch from
GPL unless it is LGPL! I've coded most of all parts of the project and
hold the copyrights with other developers from this project. We have a
primary copyright to GPL, take it or leave it! I've imported other
projects code into ReactOS and kept and respected their copyrights!
Flamed baited by wine for forgetting to pass on copyrights as well and
having to recommit them back into code! If it is good for me it is
good for you!
If you have a problem with this I will have my people contact your
people! You have my email address!
James
martinf(a)svn.reactos.org wrote:
> -#if defined(__STDC_WANT_SECURE_LIB__) && defined(_MS_VER) // secure CRT functions using VS 2005
> +#ifdef __STDC_WANT_SECURE_LIB__
> if (_tfopen_s(&_pfile, path, mode) != 0)
Hi Martin,
This change will break the build, reactos now has partial but not full support for secure CRT functions.
__STDC_WANT_SECURE_LIB__ is now defined in our build headers, but some areas are missing, _wfopen_s being one of these.
I added the '&& defined(_MS_VER)' check to get around this for our build env until we support it.
Regards,
Ged.
And now we all get back to a polite discussion about this topic and stop
comparing the lengths of our wieners, ok? I hate the way all this goes
to... last time we came to that point in the past, we lost some long
term devs and put the whole project into a big crisis. So PLEASE, I just
expect a mature talk and no kindergarten from you all. (OK, its a bit
funny that I say something like that :-P )
Ros Arm Devs: I understand that you don't wanna tell us who exactly you
are are, whatever your reasons are and I accept that, but you have to
understand that some here fear harm for the project if ppl noone ever
saw write risky components with the highest possibility to copyright
problems. Almost every kernel dev in here was suspected to write tainted
code at least once in their whole time here. That's the result of some
big crisis we had in the past, we became a bit afraid of great code
outta nowhere which just works. So don't take it personally, plz.
*fearabigdramacoming* Regarding the Devs in the header and the license.
Why not just readd the ppl if some of their code still exists in the
file? Noone would have any harm if there's one more guy in this list.
Lets discuss the relicense after the guys are in the headers again. But,
and this goes out to all ppl, in a kind and mature way.
You all, forget your "He stepped on my tail!!" behavior just for a
moment and think about the project we all code for and we try to get
mature. We can talk about anything, but not in this way.
Thank you very much.
Daniel Reimer
Not soo 1337 ReactOS Dev
"You may relicense my code as BSD" != "You make strip away copyright/ownership of my code".
Revert this.
On 2009-12-31, at 6:51 PM, ros-arm-bringup(a)svn.reactos.org wrote:
>
> - * PROGRAMMERS: Alex Ionescu (alex.ionescu(a)reactos.org)
> + * PROGRAMMERS: ReactOS Portable Systems Group
Best regards,
Alex Ionescu
On Jan 6, 2010, at 2:44 PM, dgorbachev(a)svn.reactos.org wrote:
> - // Always contigiously map low 1Mb of memory
> + // Always contiguously map low 1Mb of memory
Thanks for fixing my typos ;)
Hi,
I'm trying to compile React OS, however I encountered this error when I'm trying to compile:
[HOST-CC] lib/inflib/infcore.c
lib/inflib/infcore.c: In function `InfpAddSection':
lib/inflib/infcore.c:184: warning: implicit declaration of function `__builtin_offsetof'
lib/inflib/infcore.c:184: error: parse error before "INFCACHESECTION"
lib/inflib/infcore.c:184: error: parse error before ']' token
lib/inflib/infcore.c: In function `InfpAddFieldToLine':
lib/inflib/infcore.c:289: error: parse error before "INFCACHEFIELD"
lib/inflib/infcore.c:289: error: parse error before ']' token
make: *** No rule to make target `makefile.auto', needed by `all'. Stop.
Please help me, thanks.
Evans
Get your new Email address!
Grab the Email name you've always wanted before someone else does!
http://mail.promotions.yahoo.com/newdomains/aa/
I <3 this commit.
--
Matthieu Suiche
On Fri, Jan 1, 2010 at 6:31 PM, Alex Ionescu <ionucu(a)videotron.ca> wrote:
> "You may relicense my code as BSD" != "You make strip away
> copyright/ownership of my code".
> Revert this.
> On 2009-12-31, at 6:51 PM, ros-arm-bringup(a)svn.reactos.org wrote:
>
> - * PROGRAMMERS: Alex Ionescu (alex.ionescu(a)reactos.org)
> + * PROGRAMMERS: ReactOS Portable Systems Group
>
> Best regards,
> Alex Ionescu
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
To slow things down. ATM there is a fault created when the mouse moves
with updates, creates and destroying region handles. The kernel fault
occurs inside SEH which should not happen right?
What we need is a semaphore that is used for the whole handle manager.
This is my point over the years about the stability inside win32k. It
running full bore, spinning out of control. Surprised it still works
after turning everything on in my tree.
On Sun, Jan 3, 2010 at 3:26 AM, Timo Kreuzer <timo.kreuzer(a)web.de> wrote:
>
> Why the KeEnterCriticalRegion?
>
> jimtabor(a)svn.reactos.org wrote:
>> - if (pAttr) FreeObjectAttr(pAttr);
>> + if (pAttr)
>> + {
>> + KeEnterCriticalRegion();
>> + FreeObjectAttr(pAttr);
>> + KeLeaveCriticalRegion();
>> + }
>> break;
>>
>
Hi,
As far as I am aware, GCC 4.4.x now works on Linux through RosBE 1.5 (minus some missing patches for 64-bit hosts), and I've gotten it to work on SnowLeopard with some minor hacks -- ie, all that's missing is for Colin, when he has time, to integrate the little fixes for these non-standard hosts.
As for Windows, I think there is a fully working binary GCC 4.4.x/RosBE that builds trunk just fine.
So what's missing for 4.4.x to become official, RosBE 1.5 to RTM, and for the 4.4.x patch from BZ to be committed (The one that gets trunk building)?
Best regards,
Alex Ionescu
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
I guess you'll be claiming your Millennium Prize now.
(For the uninformed: http://en.wikipedia.org/wiki/P_versus_NP_problem)
On 2010-01-02, at 11:17 AM, ros-arm-bringup(a)svn.reactos.org wrote:
> and combines both NP and P code together.
Best regards,
Alex Ionescu
Hi All,
Just want to say thanks for this wonderful project. Works like a charm in
VritualBox image.
It is unbelievable that total size of this great OS is just 37MB.
In Virtual Box, default config for Video memory is too low which cause
error on loading the VirtualBox image, after increasing it to 16mb all
works fine. May be useful for someone else on the list.
Waiting for the stable version to use on my laptop.
Babar Shafiq Nazmi.
Do we have people for SOCAL 2010 this time?
> From: "Gareth J. Greenaway" <gareth(a)socallinuxexpo.org>
> Date: January 1, 2010 12:30:09 AM GMT+03:00
> To: aleksey(a)reactos.org
> Cc: joe(a)socallinuxexpo.org
> Subject: Invitation for ReactOS to Southern California Linux Expo 8x
>
> Greetings Aleksey,
>
> I hope this email finds you doing well. I wanted to formerly
> invite the ReactOS project to attend and exhibit the Southern
> California Linux Expo, which will be taking place February
> 19th-21st, 2010 in Los Angeles, California at the Westin LAX hotel.
>
> This would be an excellent venue to showcase all the great work
> going into the ReactOS project. We would provide a complementary
> booth including all the usual amenities as well as complementary
> passes to the show.
>
> If this sounds like something that the ReactOS project might be
> interested in, please let us know as space will be filling up quickly.
>
> Thanks and Happy New Year!
> Gareth
>
> --
> Gareth J. Greenaway | gareth(a)socallinuxexpo.org
> Voice - 877-831-2569 x130
> Southern California Linux Expo
> http://www.socallinuxexpo.org
>
ros-arm-bringup(a)svn.reactos.org schrieb:
> Author: ros-arm-bringup
> Date: Sat Jan 2 02:34:27 2010
> New Revision: 44871
>
...
> @@ -790,9 +791,138 @@
> .globl _KiTrap2
> .func KiTrap2
> _KiTrap2:
> -
> - /* FIXME: This is an NMI, nothing like a normal exception */
> - mov eax, 2
> + //
> + // Don't allow any other NMIs to come in for now
> + //
> + cli // Disable interrupts
>
But you know that CLI has no effect on NMIs?
Why don't you cache this instead of querying it for each TLB flush? Seems stupidly wasteful -- I thought the point was to "make it better"??
Isn't this what HalpGetFeatureBits is for?
On 2010-01-01, at 11:37 AM, ros-arm-bringup(a)svn.reactos.org wrote:
> + //
> + // Check for CPUID support
> + //
> + if (KeGetCurrentPrcb()->CpuID)
> + {
> + //
> + // Check for global bit in CPU features
> + //
> + __cpuid(CpuInfo, 1);
> + if (CpuInfo[3] & 0x2000)
> + {
Best regards,
Alex Ionescu
sserapion(a)svn.reactos.org wrote:
> Add definitions for the x86bios emulator.
>
http://www.geoffchappell.com/viewer.htm?doc=studies/windows/km/hal/api/x86bi
os/index.htm
>From the link: "The HAL in x86 builds of Windows Vista introduces a set of
functions for accessing the 16-bit firmware that Windows started from."
So you're adding functions from the x86 HAL in NT6 to our NT5.2-targeted
AMD64 HAL? Is it just me who gets confused here?
If it's alright, I'd like to hear some explanations.
Best regards,
Colin
Hello,
I have identified a major deficiency in the x86 kernel that requires minor overhaul of multiple low-level components, and stems from poorly understood implementation details of the x86 architecture, which is NMI support.
NMIs are Non Maskable Interrupts, similar to SMIs (generated for SMM) mode but typically used for critical hardware errors (somewhat a precursor to MCEs).
Most modern operating systems support NMI as a debugging tool: when a system is deadlocked due to interrupt issues or perhaps in a state with interrupts disabled, it is often hard to "break-in" the system to analyze the issue. They are also used as a last resort to terminate the system in case of major hardware error (such as power issues or parity errors).
NMIs can also be generated by external hardware:
This simple circuit generates a tri-state one-cycle SERR# pulse on the PCI bus, which causes an NMI. It can be used as an emergency dump switch, when other methods fail.
Â
The following issues exist in ReactOS that hinder NMI support:
Â
- The I/O Privilege Map (IOPM) configuration is done dangerously and incorrectly. A number of misunderstood hardcoded values are used throughout the code, assumptions are made on the number of IOPMs, and IOPM switching is done very poorly during BIOS Calls.
Â
- BIOS Calls are currently executing on the TSS context of the current state. This works fine with the normal KGDT_TSS that NTOS executes on, but causes dangerous errors on scenarios such as Double Faults (KGDT_DF_TSS) and NMIs (KGDT_NMI_TSS). These TSS segments do not have an IOPM allocated, which causes memory corruption when the BIOS Call code attempts to save and restore the IOPM by assuming it's there. It also causes BIOS code to fail during execution; after tracing with an IDP we discovered that BIOS I/O Port accesses were generating exceptions, which turned out to be due to the fact the BIOS was reading the bogus, non-existing IOPM and thus failing to validate I/O Port access. This is currently a problem in ReactOS as a double-fault trap will trigger massive corruption, as the panic code will attempt to draw the "Blue screen of death", requiring a Video ROM Interrupt 10h through a BIOS Call, which will fail as explained. In an NMI case, the same scenario would also happen.
Â
- The NMI trap code is not yet implemented.
Â
- The KeRegisterNmiCallback and KeDeregisterNmiCallback routines are not yet implemented.
Â
- KPRCB Context-switching is not yet implemented, along with related routines. Only the high-level routines used during debug traps are implemented, but not the support required for resuming after an NMI.
Â
- HalHandleNMI is subject to recursive NMI scenarios.
Â
- BIOS Calls do excessive TLB flushing.
Â
- The logic for IDT write-protection during BIOS Calls is overcomplicated. The IDT should always be made read-only and restore to its previous state.
Â
- TLB flushing in the HAL appears to be broken when global pages are used. Additionally, the same problem exists in NTOS -- there is no support for TLB flushing when Global Pages are used, even though Global Page support is enabled in the MMU and the bit is used on kernel PTEs. This leads to either over-flushing global pages during context switching, which shouldn't be done, or non-flushing of global pages, when they should be flushed.
Â
- Tangential issue: I have written a new UNIMPLEMENTED_PATH macro that now describes the exact path that was touched. Previously only the PC was given, which makes it nearly impossible to connect to the line of source causing the issue, especially for non developers. This new macro outputs a string reason. Additionally, an UNIMPLEMENTED_V86_PATH is used for scenarios where the path is only expected in VDM/V8086 scenarios, to differentiate from unlikely paths in normal execution flows.
Â
These issues have all been fixed in my toilet. All this work stemmed from doing some testing of the new ARM3 section code written recently (never debug other people's code!), which led to significant debugging pains without NMI support. It has nothing to do with the ARM port but since I've written it, I might as well pass it on instead of keeping it locally for eternity.
Â
Thoughts/comments?
Â
-r
Dear ReactOS Members,
We'd like to issue you our warmest holiday greetings and a happy new year!
Withal, receive our cordial gratitude for the recent work on getting the ARM tree building again as well as for extending support for Windows and Mac OS X build systems throughout this troubled time.
-r
Hi,
just for your information, I have already written a script and it's already
available in trunk (/trunk/tools/changelog/autocl.py), but Aleksey decided to
make the ChangeLog manually. Of course the script can't do any magic, but it
was intended to setup up a ChangeLog-base for manual adjustments with the
great advantage that nothing will be forgotten. Maybe we can improve the
script to fit it to our needs and make it as much flexible as possible, but
nevertheless, we have to give it a chance to judge...
Matthias
--
Matthias Kupfer phone +49 (0) 371 236 46 52
Wilhelm-Firl-Straße 21 mobile +49 (0) 160 859 43 54
09122 Chemnitz, Germany
Hi,
This is incredible. I can understand a delay in a release because fixing Blockers, i can understand a delay because we are afraid of "2012" movie.But i can not understand why the Changelog is not made!!. On 3rd of November Aleksey sent an email saying a Blocker was present to release 0.3.11, this means that on 3rd of November a full Changelog should have been done and just 2 lines (explaining the Fix,if needed) should have been added afterwards. But the fact is that the Blocker has been solved more than one week ago, that we are still waiting for changelog to be done(after more than a month) and that the binaries are stored in SF waiting indefinitely to link them.
So this strikes again, what is happening with Changelogs?What happens if noone wants to write his Changelog?Are we going to stay here waiting it indefinitely?Is our actual procedure correct?Or is it not practical?How can we shorten the time for a release?What happens if one of the Steps before releasing (like Changelog Step) is not properlly done?Do we have a PlanB?
Let´s review our Teorical steps before a release and finding Bottlenecks as i do in my work:
1) Coding Time.During this time Devs creates ReactOS code.Since 0.3.9 also the GoldenApps and CandidateApps are being tested during this time in regular basis to reduce the possible Blockers.
2) Choosing Minute. An ISO is chosen as Candidate. Doubts: When the Candidate is chosen?Following which criterias?Why sometimes we take an ISO after one month and other times after 2 months?
3) Colin creates a Pre-release ISO.
4) Colin creates the 0.3.XX wikipage.Tests begins and Changelog begins to be written.
5) Performing Testing on Candidate. It usually takes less than a week, and thanks to previous testings in Coding Time, there are less Blockers each time.
6A) Blocker found. If a Blocker is found, a regression testing begins(if needed) and a patch/hack is made.GoTo 7
6B) Blocker not found. prerelease ISO is released as definitive.END.
7)Patch is added to release branch, Colin creates a second RC and testers perform a full test focusing in the regression. Release.END.
Let´s begin studying the 0.3.11 case.
Step 1 was done correctly.We have devs still working on ROS.great!
Step 2 was a CHAOS. I have been asked to select first an ISO before asking Colin to make a prerelease ISO of it. Testing that first ISO we found the Vmware regression but it took a little(more than a month to fix it) so we select a different ISO and we performed a full testing (again) before asking Colin to create a prerelease.
Changing the ISO is not inside the Teorical steps,but since the patch for Vmware wasnt made and we had time it didnt suppose really a lose of time.
Step 3.First bottleneck. It took a little to contact with Colin,because he was busy with RL, so we had to wait him to create a Branch,include the reverts and create the prerelease.If I recall correctly it took more than a Week. Without the prerelease done is impossible to test anything.We should have an alternative to Colin in case Colin is busy with RL.We dont have a PlanB for this situation.
Step4. Colin creates the Wikipage.
Step5.Test begins but Changelog didnt begin to be written, it has been asked twice via ML, and zillions via IRC. Currently we are waiting for having it complete.
And now second bottleneck:
In 0.3.11 case,Blockers were solved BEFORE prerelease was made, so when Colin uploaded the prerelease iso it doesnt have any Blocker and it is ready to be released.And then the bottleneck comes:Changelog. Changelog can be created without hurry if we are in step 6A(a Blocker found) but in case 6B (as 0.3.11 prerelease is) you dont have real time to create it. When a Blocker is found,Changelog can be created during the extra time of regtesting+finding a patch+adding to branch+creating a new iso+performing again all the Tests, (this extra time is usually 4 weeks). But when non Blocker is found in Step6, Changelog stops our release.You cant made a proper Changelog of 2 months changes in a week. So our procedure currently is not optimal at all.
First bottleneck: Relying in just one guy to merge stuff in the branch+create the ISO should be solved.
Second bottleneck: If we expect that our prereleases doesnt have any blocker,then Changelog will be stopping our releases. To avoid this i propose a new procedure for 0.3.12, which is more multitasking.
STEP1: Create 0.3.12 Changelog page.Open to include the changes since the Beginning.
STEP2: Coding time. Meanwhile,testers tests goldenapps and candidateapps.
STEP2: Choosing minute.The candidate ISO is selected, Devs are warned in Changelog page which is the latest revision to include the changes and that just they have one week to finish their Changelogs.
STEP3: Release Engineers(not just Colin) creates the branch and the prerelease iso.
STEP4: Release Engineers creates a Test 0.3.12 wikipage.
STEP5: Tests are performed. This gives one week of extra time to have the Changelog done(more if a blocker is found).
If Changelog is critical for releasing, then we need a PlanB if a Dev rejects or cant make a changelog.This is called SCRIPT. I´m really bored of those guys who doesnt want the Script but doesnt write their changes in Changelog neither.
we should have a Script that by request or by lazyness of the devs can make a Changelog giving a revision range,a component or|and an author.This will make the life easier and healthier.Btw, some Devs doesnt want to waste the time writting Changelogs and prefer coding, so this tool is a must.I dont want to see devs sending less code to avoid writting a changelog.
Sorry about this long post.My fingers were trained in our Wiki this morning, btw, i hope someone can review my recent changes on the Changelog 0.3.11 to be sure i put the commits in their correct place.Thanks.
_________________________________________________________________
Date una vuelta por Sietes y conoce el pueblo de los expertos en Windows 7
http://www.sietesunpueblodeexpertos.com/
On Tue, Dec 15, 2009 at 11:07 AM, <dreimer(a)svn.reactos.org> wrote:
> Author: dreimer
> Date: Tue Dec 15 17:07:47 2009
> New Revision: 44603
>
> URL: http://svn.reactos.org/svn/reactos?rev=44603&view=rev
> Log:
> Using the right Cross Compiler is useful, of course. Now We just need a native one, because the cygwin one has evil *nix, blasphemical, god negating and devil worshipping search paths.
Don't hold back. Tell us how you really feel.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
You victory Alex....you know...
--
Técnico en la FPGISB UCP 'Pepito Tey'
'Creo en el software libre'
Ubuntu "Linux for human beings"
Lo último que se sabe cuando se realiza un trabajo es por donde empezar.
(Blaise Pascal, matemático francés)
Hi,
Let us take in an example from the PROCESS/THREADINFO merge or
morphing. It was all done in small steps and it also needed more
structure support to make the move possible. The same is going on with
the move to Wnd. Naming the entries in WINDOW_OBJECT the same as Wnd
makes it just as easy so when the WINDOW_OBJECT is removed the minimum
changes are made. This too includes new code to replace missing
entries in Wnd that had been added to WINDOW_OBJECT. This is the new
support that is need. Another example is LastChild from WINDOW_OBJECT,
support to replace it will need to be added.
This is the safest way to merge and morph to the new structure without
killing ReactOS in the process.
Thanks,
James
On Mon, Dec 14, 2009 at 8:02 AM, Timo Kreuzer <timo.kreuzer(a)web.de> wrote:
>
> I don't see any use in renaming the WINDOW_OBJECT structures.
> spwndXxx means shared pointer to a WND, this does not reflect it's
> current usage in WINDOW_OBJECT.
> We already have a WND and it has spwndXxx members and they are in use.
> You should rather try to get rid of them completely inside WINDOW_OBJECT
> and only use the ones from WND instead.
> But that's probably the last move after all the rest is gone.
>
> Anyway, as long as we end up with the WND structure only, do as you like
> on the way to there.
>
> Regards,
> Timo
>
On Sat, Dec 12, 2009 at 8:40 PM, <hyperion(a)svn.reactos.org> wrote:
> Author: hyperion
> Date: Sun Dec 13 02:40:56 2009
> New Revision: 44558
>
> URL: http://svn.reactos.org/svn/reactos?rev=44558&view=rev
> Log:
> added Wine on ReactOS - Inkscape.svg
> added Wine on ReactOS.svg
> My "Wine on ReactOS" diagram, in SVG format, two variants (Inkscape-friendly and optimized for the web)
>
> added COPYING
> Licensing information on the images
>
> Added:
> trunk/press-media/art/COPYING
> trunk/press-media/art/Wine on ReactOS - Inkscape.svg
> trunk/press-media/art/Wine on ReactOS.svg
Maybe there should be translucent wine bottles over
user32/gdi32/kernel32/etc where we use snippets and whole source
files. I do like this image though! I will use it the next time I give
a presentation. Thanks!
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
I'm pretty much sticking to the way it is done in most other places.
Ref:
http://git.reactos.org/?p=reactos.git&a=search&h=HEAD&st=grep&s=ZeroInit
2009/12/12 KJK::Hyperion <hackbunny(a)reactos.org>
> gschneider(a)svn.reactos.org wrote:
> > - The field ZeroInit should be initialized to zero - do that by assigning
> the message type directly
>
> please do this by zero-initializing ZeroInit instead. Don't play with
> unions
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
cfinck(a)svn.reactos.org wrote:
> + ULONG i = 30 * 1000;
Can we give a meaningful name to this value and put it in a header file?
and document what it is for?
gschneider(a)svn.reactos.org wrote:
> - The field ZeroInit should be initialized to zero - do that by assigning the message type directly
please do this by zero-initializing ZeroInit instead. Don't play with unions
Building with _WINKD_ = 1 is broken
[COPY] output-i386\bootcd\reactos\ntfs.sys
[AS] ntoskrnl\ke\i386\boot.S
[CC] ntoskrnl\ke\i386\abios.c
In file included from ntoskrnl/include/internal/ntoskrnl.h:83,
from ntoskrnl/include/precomp.h:64,
from ntoskrnl/include/ntoskrnl.h:1,
from ntoskrnl\ke\i386\abios.c:11:
ntoskrnl/include/../kdbg/kdb.h:228: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'KdbEnterDebuggerException'
mingw32-make: *** [obj-i386\ntoskrnl\ke\i386\abios_ntkrnlmp.o] Error 1
I've gone down the path of virtually rewriting the msvc backend for rbuild.
Our current implementation had completely outgrown its original design and
was becoming very difficult to manage, as highlighted when I was adding
support for VS 2010.
Anyway, whilst I'm doing this I think it's a good time assess what we want
to support. We currently support Visual Studio 6, Visual Studio .NET 2002
and Visual Studio.NET 2003. This is a waste of time IMO and only adds to the
complexity of the module
I'm proposing to remove support for these 3 products unless anyone has any
reasons against.
Ged.
cfinck(a)svn.reactos.org schrieb:
> Author: cfinck
> Date: Wed Dec 2 21:32:16 2009
> New Revision: 44368
>
> URL: http://svn.reactos.org/svn/reactos?rev=44368&view=rev
> Log:
> [General]
> - Remove the "kernel32" library reference in all .rbuild files of user-mode modules, because this one is already added by "mingw_common". Also fix the indentation in some files.
>
Hi,
doesnt that break a few modules which used to build with msvc?
kind regards
Johannes
This is stupid!!! We had this discussion countless times!
It's not a bug to get back access denied! In many situations this is
normal, and the application will try again! (Ie: Writing to a
read-only file)
Best regards,
Alex Ionescu
On Tue, Dec 1, 2009 at 10:26 PM, <fireball(a)svn.reactos.org> wrote:
> Author: fireball
> Date: Tue Dec 1 22:26:40 2009
> New Revision: 44348
>
> URL: http://svn.reactos.org/svn/reactos?rev=44348&view=rev
> Log:
> [ntoskrnl/se]
> - Add a hack which prints an annoying message and grants access when it should not be. Callers/bugs should be fixed and this commit reverted after that.
> See issue #4169 for more details.
>
> Modified:
> trunk/reactos/ntoskrnl/se/semgr.c
>
> Modified: trunk/reactos/ntoskrnl/se/semgr.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/se/semgr.c?rev=44…
> ==============================================================================
> --- trunk/reactos/ntoskrnl/se/semgr.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/se/semgr.c [iso-8859-1] Tue Dec 1 22:26:40 2009
> @@ -608,10 +608,12 @@
> }
> else
> {
> - DPRINT1("Denying access for caller: granted 0x%lx, desired 0x%lx (generic mapping %p)\n",
> + DPRINT1("HACK: Should deny access for caller: granted 0x%lx, desired 0x%lx (generic mapping %p).\n",
> *GrantedAccess, DesiredAccess, GenericMapping);
> - *AccessStatus = STATUS_ACCESS_DENIED;
> - return FALSE;
> + //*AccessStatus = STATUS_ACCESS_DENIED;
> + //return FALSE;
> + *AccessStatus = STATUS_SUCCESS;
> + return TRUE;
> }
> }
>
>
>
>
Hello,
the trunk of our SVN server has been locked to prevent even more
regression from entering the tree.
So far, after more than 3 weeks after I filed the bug report and not
including all previous time when people were complaining about rapps
which can't download anything at all - either hangs or crashes, I see
that now even PCNet network card is being recognized in my VMWare
Workstation 6.5.
Trunk is writable right now by members of the bugfix team only,
that's so far Cameron (because he is the one supposed to fix
networking) and me. If someone volunteers to fix any of the existing
regressions, please let me know on irc/email, I'll include you into
the bugfix team.
Thanks for understanding, and patience. My patience is over.
WBR,
Aleksey Bragin.
Hi everybody,
The "clean" command in RosBE has often been criticized for not cleaning what
the user expected.
While in the past, it had just issued commands to delete the four
files/folders "makefile.auto", "obj-i386", "output-i386" and "reactos" in
the current directory, it's general behaviour has been changed significantly
over time, in particular by these two commits:
- 38756
If you set a different object or output directory for the built files
through RosBE Options, these directories are always cleaned instead of
"obj-i386" or "output-i386" in the current directory.
- 39138
If no dedicated object or output directory is set through RosBE Options,
we always clean the one set after RosBE has been started or which has been
set by "chdefdir". We even do so if this directory is not the current
working directory.
Especially the latter commit seems to have caused problems for many people
as you could easily clean the wrong tree now.
Therefore I made some efforts to rework this command a bit and published by
current script at http://reactos.colinfinck.de.
This script now first checks whether "makefile.auto", "obj-i386",
"output-i386" and "reactos" exist in the current directory. If all of them
exist, they are cleaned.
If not, it checks whether different object and output directories were set
using RosBE Options and checks for them instead of "obj-i386" and
"output-i386". If they exist together with "makefile.auto" and "reactos" in
the current working directory, all of them are cleaned.
Of course, this also works for every other architecture we support, i386 was
just taken as the most popular example here.
I'm posting this here now, because I don't want to upset other people now
that the script logic is changed again. If you rather like the current
"clean" logic instead of my proposal, please tell me.
I leave this discussion opened for several weeks as I currently don't have
much time anyway. If there are no negative comments, the new script will be
committed afterwards.
Best regards,
Colin
cgutman(a)svn.reactos.org wrote:
> - ULONG SocketError;
> + ULONG SocketError = 0;
FYI, I've already reported this bug some days ago at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42145.
As it only occurs in GCC >= 4.3 and the necessary code changes for compiling
ReactOS with GCC 4.4.x are currently collected in a big separate patch (see
http://www.reactos.org/bugzilla/show_bug.cgi?id=4810), no hack from my side
has been committed so far.
If this hack is going to stay, please mark it as such and add a reference to
the GCC bug report.
Hopefully, it's properly resolved someday... :-)
Best regards,
Colin
Hi,
as already said in the #reactos-dev IRC Chat yesterday I, too, think Z98
is right
(http://reactos.org/forum/viewtopic.php?f=13&t=7634&start=75#p67090),
this is not how a real mod has to behave. But this criticism counts for
him, me and all others in the privileged teams IMO! I know that some of
my behavior is more childish than anything else you could call useful
and professional, but I ask you, what ways to tidy the forums up, do I
have, except gallows humor and sarcasm? Lets explain what evilness I did
this time again. Every day on my way to university I sit in the train,
start Opera Mini on my Mobile and run through the forums to do my job
and in recent times more an more posts with harmful and destructive
meaning occur. Most are from our well known troll-friend nute, but there
are other flaws right now, too. For example the newly registered
members, who write one post with SPAM in their signature and hope that
noone of the Mods recognizes it, but this is another story. OK, back to
the main story. I looked trough his "When will Version 0.3.blablubb
finally be done you lame, useless dumbasses of so called Devs"-post,
which I already moved to Off Topic because his unintentional negative
influence does not belong to the General Forums IMO. Well, I know the
very last warning spoken by Z98 against me in the very same Thread and
realized that the same behavior he accused from both sides reoccurs
after just two days. Flaming and Bashing from both sides again... Well,
I lock topics and get bashed, I warn ppl and get bashed, I rename a
thread which has nothing to do with any Version 0.4.11 talk and more is
meant as a battleaxe against the forum and the project and get bashed
too, so I decided to do nothing except a good amount of sarcasm and
properly renamed the Thread to "nute's private playground" which it was
anyway at that time. Well, I had nothing to loose. All my steps would
have resulted in bashing anyway, so I chose the funniest path. Some
subjects in the forums play with us and noone cares. They spread crap
about us, which could even harm our image and noone cares! And if I dare
to try to sentence disciplinary actions, I get kicked from above. Well,
why should I behave like a real mod pretending to be one? I have lost
all power over the forums, because our own hierarchy fights against me.
I have as much power in there like all others users, because most of my
steps and actions are being reverted or openly criticised anyway. God
its fucking frustrating to have no ways to moderate the forum at all,
but being called mod! If we do not finally start to spread some
authority in the forums and stop to always see the good person in such
harmful subjects without the minimum of aggression needed to be a Mod
IMO or giving mods like me ways to do their job without anyone always
falling in their back, we can close down the forums immediately anyway.
Psychotic trolls like nute and more than enough others need limits,
otherwise they dance on our nose as they do right now and a hierarchical
system which fights itself is no way to get this done. It did not work
in the Weimarer Republik and won't work for us, too.
OK this had to be said, now kick me, degrade me, whatever you think is
best, but please finally do it once and for all, please. Only the best
for Project counts! I don't care what happens to me as long as we get
this problem solved. With or without me as mod. Have fun.
Daniel "dreimer" Reimer
(still for some last seconds) ReactOS Forum Moderator Team Member
ReactOS Build Environment for Windows Coordinator
Bugs like these would've NEVER happened if you stuck to your TARGET:
NT 5.2.3790.1800 SP1:
http://www.reactos.org/bugzilla/show_bug.cgi?id=4940
You can't just add Vista APIs and expect shit to work!
You should really revert this kind of garbage.
Best regards,
Alex Ionescu
Sorry, I mistyped his name. It's Alexander Yastrebov.
On Nov 18, 2009, at 5:37 PM, fireball(a)svn.reactos.org wrote:
> Author: fireball
> Date: Wed Nov 18 15:37:31 2009
> New Revision: 44225
>
> URL: http://svn.reactos.org/svn/reactos?rev=44225&view=rev
> Log:
> [rapps]
> Andrey Yastrebov <menone7(a)gmail.com>
> - Fix app uninstallation feature (wrong lparam usage - it's pointer
> to PINSTALLED_INFO and not an hkey).
> See issue #4961 for more details.
I'm pleased to announce that I've been able to boot reactos to the shell from an ext2 partition. This is something we've wanted for a long time and many of us have worked on. I've synced up arty-newcc to the current state of my git repository. This work is experimental, not quite complete, and has some important limitations:
- It probably won't currently work for a partition larger than 4gig and might even fail for one larger than 2gig. This limitation is lifted by other, unrelated code in my tree that I haven't merged yet.
- It probably has a lot more bugs left, especially in block allocation for large files.
- Some parts of the new section implementation leak pages.
I was planning to, but haven't yet made the new and old cache and cc and section implementations available side by side. The main work of separating the new files involved in the section implementation (now in ntoskrnl/mm/section/*) is done. This will be necessary when I merge it into the main tree, at least for regression testing.
Despite the branch being named for me, I invite anyone to work on, modify, or bugfix arty-newcc. This advance has been a long time coming, and I'd like to thank everyone for keeping the faith.
This starts on Monday.
So nobody's going??
Shocker .... I'll have to drink on my own then.
Ged.
From: Ged Murphy [mailto:gedmurphy@gmail.com]
Sent: 27 October 2009 15:41
To: 'ReactOS Development List'; 'ReactOS General List'
Subject: Microsoft PDC
I'll be attending this year's Microsoft PDC in Los Angeles and I should be
there between 16th November and 20th November.
If anyone else is going and wants to meet up for a chat at the conference or
a beer in the evening drop me a mail.
Cheers,
Ged.
The three Intel Book's which you refer me are only theoratical base not for Practical.I want to learn Assembly language or system programming.
My purpose is only that i want to understand the coding of reactos which is done in vc++ but use many lower level programming concepts which i couldn't understand.So you please tell me that which Book or People or Institute can help me to understand the lower level concepts which you can use in reactos coding.So i can also want to participate in making the coding of reactos by using the lower level concepts... :) (:
The three Intel Book's which you refer me are only theoratical base not for Practical.I want to learn Assembly language or system programming.
My purpose is only that i want to understand the coding of reactos which is done in vc++ but use many lower level programming concepts which i couldn't understand.So you please tell me that which Book or People or Institute can help me to understand the lower level concepts which you can use in reactos coding.So i can also want to participate in making the coding of reactos by using the lower level concepts... :) (:
Not sure about codeblocks but I still use the msvc backend to generate all the vcproj files.
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of hyperion(a)svn.reactos.org
Sent: 11 November 2009 03:41
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [hyperion] 44091: modified Makefile Give poor pefixup its own echo line modified ReactOS-amd64.rbuild modified ReactOS-arm.rbuild modified ReactOS-i386.rbuild Set global linker flags globally Goodbye NTOSKRNL_SHARED modified tools/rbuild/backe
modified tools/rbuild/backend/codeblocks/codeblocks.cpp
modified tools/rbuild/backend/msvc/vcprojmaker.cpp
Build fixes. I really want to delete these dead backends
Hey, i can get th source code of reactos, but i can't understand the coding, your programmer who wrote these type of coding can also be refer any book/notes.You please tell me the name of that book, for which i can also take refrence for understanding the lower level of coding for making kernel and other files.I know these type of languages(C,C++,Java Core,VC++,Oracle 8i,html),but not for the hardware level only for making user level programs.So Please help me do this task easier and i also tell you that i didn't know the way to access your channel #reactos also help me i have no sufficient time to take part in it but i try so please refer any book.Thanxxx for making me the member of your group and Congratulations for your Project Success... :) (:
I've recently been taking an interest in MinWin, especially as it's now
visible in Windows 7, and I want to bring up the possibility of introducing
something similar into ReactOS.
I know some of you will be familiar with WinWin and I know at least one of
you will know quite a bit more about it than I do, but for those who don't
here's an overview.
What is WinMin?
MinWin is an internal project at Microsoft that manifested around the time
of the Vista rewrite. Very basically explained, the aim is to detangle the
very core components from the full operating system, resulting in something
which can be built separately and leaving just enough components for a
working system. This minimal operating system can then boot and be tested
separately or be built as part of the full OS and tested in internally as
before.
The main problem in doing this, and one of the main benefits in solving it,
is module dependencies. By simply cutting out the bottom part of the OS
you're left with modules which potentially call out to other modules which
may now be missing. If these dependencies aren't understood you have the
possibility of an unstable OS as you never know where a code path may lead.
It also means you need to build more components to get the thing to link,
which also undermines one of the reasons for doing it.
What Microsoft did is to draw up a dependency tree and structure it in a
layered hierarchy. Modules were then rearranged to make architectural sense
according to the NT design and a top layer was decided upon. API call were
then rewritten within this hierarchy such that anything in one layer would
only call API's in the layers below it. Therefore if something in layer 8
called something in layer 7 which then called something in layer 12, the
APIs would be fixed to only use APIs at or below its level according to the
hierarchy. You're then left with a clean line where nothing calls out and
you have a tightly bound core OS which is completely independent from
anything.
What is essentially left in Microsoft's WinMin is what people class as
Cutlers NT along with supporting components to get a bootable system. The
main components are:
The kernel (main kernel, not the full ntoskrnl module), parts of the
executive, memory manager, networking, a file system driver and core drivers
(basc IO and Bus, etc)
This is then exposed in usermode by 2 dlls, ntdll.dll and the new
kernelbase.dll. On top of this you have a console for issuing commands.
This comprises of the full OS and amounts to about 25Mb on disk and has
around a 40Mb working set.
Let's quickly explain the new kernelbase dll.
As many of the API's in the lower level dlls such as kernel32 and advapi32
were targeting functionality which wasn't in WinMin, it was decided to pull
out any of the API's which were required to exercise WinMin and put them
into kernelbase. This dll could then be used when building a running WinMin
to provide all the functionality this kernel offered. The dlls which had
their APIs removed now forwarded their call onto kernelbase so from a user
perspective, nothing had changed.
Microsoft went a step further and designed a new technology around virtual
dlls. They split functionality of dlls into 'api sets' These can now be
seen in Win 7 in the system32 dir with the prefix
'api-ms-win-core-<function>-<num of>-1-0.dll'. WinMin components now link
against these virtual dlls which load up the real libs listed in
apisetschema.dll.
However this involves modification to the loader and I don't think it's
something worth us considering right now.
What are the reasons for doing this?
For a start, it's a much better design from an engineering perspective.
The more software you have running on a system the more noise is created and
the more things can interfere with each other.
It gives us a base to innovate with without worrying about affecting
anything outside.
It gives us a more reliable base for the OS and a better platform to run
comprehensive and efficient tests.
It makes us more attractive to external companies as we would have a slick
NT compatible kernel ready for companies to build their products on,
especially embedded applications.
With a few more additional items such as the base win32 subsystem, we'd have
something along the lines of a stripped out ServerCore or Windows PE.
This is only a quick overview for discussion purposes, but it outlines the
main design and goals of WinMin.
Comments, questions, concerns and gripes welcome J
Ged.
Hello,
updating everyone on the 0.3.11 status.
There is one blocker bug, http://www.reactos.org/bugzilla/
show_bug.cgi?id=4934, which is rapps's inability to complete any
download in VMWare.
Other regressions (including VMWare video driver, samba-TNG problm)
are also present, however they could be either hacked away for
release or shipped - e.g. not much of a problem since VMWare Video
Driver installer doesn't work in new VMWares anyway. Amount of
positive changes outweighs the negative.
Please try to have a look at the 4934 bug to fix it ASAP.
WBR,
Aleskey Bragin.
Hello, I'm the developper of ultracopier, I propose ultracopier as default
copier under reactOS for the reactOS explorer.
I will activly developpe it under reactOS.
It based on Qt. Only the version 0.2.0.0 is developped for reactOS.
Screenshot:
http://ultracopier.first-world.info/screenshots/reactOS-ultracopier.png
--
alpha_one_x86 <alpha_one_x86(a)first-world.info>
Main developper of Ultracopier, Esourcing and server management
IT, OS, technologies, security and business department
Booting via "ReactOS (Debug)" is broken - when trying to select it,
it jumps back to the first item in the list.
On Oct 31, 2009, at 6:09 PM, hpoussin(a)svn.reactos.org wrote:
> Author: hpoussin
> Date: Sat Oct 31 16:09:03 2009
> New Revision: 43875
>
> URL: http://svn.reactos.org/svn/reactos?rev=43875&view=rev
> Log:
> [freeldr/WINLDR] Simplify freeldr.ini syntax for common cases
> - If boot type is not specified, autodetect bootsector and Windows
> types
> - Try to automatically detect version of loaded Windows
> - Accept boot options after name of OS
> - Separate loading and scanning of system hive
> As a result, lines like "multi(0)disk(0)rdisk(0)partition(1)
> \WINNT="Windows NT4" /DEBUG /BREAK" work
>
> Modified:
> trunk/reactos/boot/freeldr/freeldr/bootmgr.c
> trunk/reactos/boot/freeldr/freeldr/include/winldr.h
> trunk/reactos/boot/freeldr/freeldr/oslist.c
> trunk/reactos/boot/freeldr/freeldr/windows/winldr.c
> trunk/reactos/boot/freeldr/freeldr/windows/wlregistry.c
here they just say:
Trick or Treat! Smell my feet! Give me sonething good to eat,
If you dont: I dont care. I just eat my underwere! :)
Happy halloween to all!!!!1
- original message -
Subject: Re: [ros-dev] Happy Halloween!!!
From: WaxDragon <waxdragon(a)gmail.com>
Date: 01/11/2009 12:23 am
My daughter preferred, "Trick or Treat, Piece of Meat!"
On Oct 31, 2009 8:17 PM, "Brian" <briandabrain(a)gmail.com> wrote:
Trick or treat! Smell my feet! Give me something good to eat!!!
--
brian
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
hi,
i wonder if this commit should be sync'ed in the reactx branch...... (and,
if DSound should be synced as a whole in there)
im not dev, so its up to you devs....
And if not.. why?
Hello,
I had noticed that some of the developers are working pretty vigorously to
get off of requiring GCC. I don't pretend to understand what that is about,
and I honestly would like to know.. However, I just wanted to list a couple
of alternative open source C/C++ compilers that could probably be used with
ReactOS.
Of course, what do I know, I'm just a newbie at being a C++ programmer...
Anyway, the two compilers are:
* OpenWatcom ( http://openwatcom.org/index.php/Main_Page )
* LLVM 2.6 w/clang ( http://llvm.org/ )
On Tue, Oct 27, 2009 at 9:32 AM, KJK::Hyperion <hackbunny(a)reactos.org> wrote:
> Alex Ionescu wrote:
>> I bet Hitler would've said the same at Nuremberg....
>
> he wouldn't have, unlike us he had written a specification beforehand
Too funny. I love the Mein Kampf as an example of how to do a proper
system design specification ;)
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Ged Murphy wrote:
> I’ll be attending this year’s Microsoft PDC in Los Angeles
> and I should be there between 16th November and 20th November.
You absolutely have to attend the session with Mark Russinovitch
"Windows 7 and Windows Server 2008 R2 Kernel Changes".
See if you can dig up something useful for our baby ROS.
(When they released NT, at least they gave us "Inside Windows NT" :)
Oh, and "C++ Forever: Interactive Applications in the Age of Manycore"
could be vaguely interesting I guess (the multicore bits).
All the other sessions seem to be boring application stuff,
C#, ASP.NET, SQL and all that goop.
Don't snore on the sessions ;)
Rock on // Love
__________ Information from ESET Smart Security, version of virus signature database 4549 (20091027) __________
The message was checked by ESET Smart Security.
http://www.eset.com
I'll be attending this year's Microsoft PDC in Los Angeles and I should be
there between 16th November and 20th November.
If anyone else is going and wants to meet up for a chat at the conference or
a beer in the evening drop me a mail.
Cheers,
Ged.
A whole branch for a little command line tool?
Am I missing something?
This must be quite some tool :)
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of hyperion(a)svn.reactos.org
Sent: 25 October 2009 20:43
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [hyperion] 43753: "nslookup" branch for anakha, me and Z98, and whoever wants to follow the import of BIND nslookup
Author: hyperion
Date: Sun Oct 25 21:43:02 2009
New Revision: 43753
URL: http://svn.reactos.org/svn/reactos?rev=43753&view=rev
Log:
"nslookup" branch for anakha, me and Z98, and whoever wants to follow the import of BIND nslookup
Added:
branches/nslookup/ (props changed)
- copied from r43752, trunk/reactos/
Propchange: branches/nslookup/
------------------------------------------------------------------------------
--- bugtraq:logregex (added)
+++ bugtraq:logregex Sun Oct 25 21:43:02 2009
@@ -1,0 +1,2 @@
+([Ii]ssue|[Bb]ug)s? #?(\d+)(,? ?#?(\d+))*(,? ?(and |or )?#?(\d+))?
+(\d+)
Propchange: branches/nslookup/
------------------------------------------------------------------------------
bugtraq:message = See issue #%BUGID% for more details.
Propchange: branches/nslookup/
------------------------------------------------------------------------------
bugtraq:url = http://www.reactos.org/bugzilla/show_bug.cgi?id=%BUGID%
Propchange: branches/nslookup/
------------------------------------------------------------------------------
--- svn:ignore (added)
+++ svn:ignore Sun Oct 25 21:43:02 2009
@@ -1,0 +1,14 @@
+*.iso
+makefile.auto
+makefile-*.auto
+config-*.rbuild
+obj-*
+output-*
+reactos
+reactos.*
+RosBE-Logs
+*.sln
+*.ncb
+*.suo
+versionreport.xml
+config.rbuild
Propchange: branches/nslookup/
------------------------------------------------------------------------------
--- svn:mergeinfo (added)
+++ svn:mergeinfo Sun Oct 25 21:43:02 2009
@@ -1,0 +1,1 @@
+/branches/ros-amd64-bringup/reactos:34711-34712,34743,34812,34839,34842,34917,35323-35324,35347-35348,35361,35436,35509,35515,35588,35739,35746,35771,35789,35823,35902,35904-35906,35942,35947-35949,35952-35953,35966,36013,36360,36388-36389,36570,36614,36930,37323,37434,37472,37475,37536,37820-37821,37868-37869,37873,37990-37991,38013-38014,38148,38151,38265,38268,39151,39333,39345,40991,41000,41027-41028,41030,41050,41052,41082-41086,41499,41549,43080,43426,43454,43677,43682
Propchange: branches/nslookup/
------------------------------------------------------------------------------
tsvn:logminsize = 10
On Sat, Oct 24, 2009 at 9:20 AM, <fireball(a)svn.reactos.org> wrote:
> Author: fireball
> Date: Sat Oct 24 15:20:16 2009
> New Revision: 43713
>
> URL: http://svn.reactos.org/svn/reactos?rev=43713&view=rev
> Log:
> - Update arwinss to Wine-1.1.32.
> - 16 bit code is well isolated by Wine team now, so amount of differences is substantially smaller. Also more compatibility due to rewritten user32/resource.c.
I was wondering when Alexandre committed this if the new
implementation of TranslateAccelerator magic could replace our
implementation in trunk? It would be nice to not have multiple
implementations of the same functionality floating around.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Ammendment to 43705 -- the KVM/QEMUversions we use on the build server today does, in fact, implement debug registers, and all the ntdll exception tests now pass.
_________________________________________________________________
Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail you.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/so…
Hi,
I have rewritten kdcom and I'm currently using it for the amd64 port
more or less successfully.
It works generally, but it still has some issues and sometimes packets
time out and it takes quite a while before WinDbg is fully connected
(every timeout is about 10 seconds)
Maybe someone likes to test it on x86.
I'm happy about any hints why these issues exist.
My current debugging methods are a second plain text debugging channel
and logging the transmitted data through a pipe using IO Ninja.
One problem here is that vbox serial to named pipe sucks and this way I
get lots of broken packets that ned to be resent. That's much better
using com0com, but then I cannot log the data.
Regards,
Timo
Hi everybody.
It's been a long time that I follow this project, even if I was pretty
quiet, and I think it is now time to make my own contribution.
Some of you might remind some attempts to work on kernel32 winetests.,
and it turned out that I needed something more motivational. I found
that reactX is an abandoned field, and so I think that it would be a
real challenge to get things working. I have already some patches, which
get the ddraw initialization a bit further that where it manages to go
in trunk.
Regards
Jérôme (aka zefklop)
PS: I'd like to talk with you about that on IRC, but unfortunately I am
behind proxy which refuses it....
This has been broken for quite some time now. Has anyone looked into this
yet?
I feel like I've lost a limb and findstr isn't a great prosthetic
replacement.
Cheers,
Ged.
On Tue, Oct 13, 2009 at 2:01 PM, <fireball(a)svn.reactos.org> wrote:
> - Fix an out-of-bounds read in RtlpDidUnicodeToOemWorked.
This has got to be the worst naming I have ever seen for a function.
It makes my internal grammar parser want to puke chunks of conjugation
and tense.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Hi, some recent changes in solitaire and the new spider solitaire can't
be built in RosBE 1.5B1. Seems to be a problem with the new cardlib as
static lib.
[RC] obj-i386\base\applications\games\solitaire\rsrc_sol.res
[CVTRES] obj-i386\base\applications\games\solitaire\rsrc_sol.coff
[LD] output-i386\base\applications\games\solitaire\sol.exe
mingw32-make.exe : c:/program
files/rosbe/i386/bin/../lib/gcc/mingw32/4.4.2/lib
stdc++.a(tinfo.o): In function `ZNSt9type_infoD0Ev':
Bei Zeile:1 Zeichen:2
+ & <<<< 'C:\Program Files\RosBE\i386\bin\mingw32-make.exe' -j 1
sol_clean sol
+ CategoryInfo : NotSpecified: (c:/program
file...type_infoD0Ev':
:String) [], RemoteException
+ FullyQualifiedErrorId : NativeCommandError
C:/msys/local/build/mingw32/libstdc++-v3/libsupc++/../../../../src/libstdc++-v3
/libsupc++/tinfo.cc:33: undefined reference to `strcmp'
c:/program
files/rosbe/i386/bin/../lib/gcc/mingw32/4.4.2/libstdc++.a(vterminate
.o): In function `ZN9__gnu_cxx27__verbose_terminate_handlerEv':
C:/msys/local/build/mingw32/libstdc++-v3/libsupc++/../../../../src/libstdc++-v3
/libsupc++/vterminate.cc:65: undefined reference to `fputs'
C:/msys/local/build/mingw32/libstdc++-v3/libsupc++/../../../../src/libstdc++-v3
/libsupc++/vterminate.cc:69: undefined reference to `fputs'
C:/msys/local/build/mingw32/libstdc++-v3/libsupc++/../../../../src/libstdc++-v3
/libsupc++/vterminate.cc:70: undefined reference to `fputs'
C:/msys/local/build/mingw32/libstdc++-v3/libsupc++/../../../../src/libstdc++-v3
/libsupc++/vterminate.cc:83: undefined reference to `fputs'
C:/msys/local/build/mingw32/libstdc++-v3/libsupc++/../../../../src/lib
stdc++-v3/libsupc++/vterminate.cc:84: undefined reference to `fputs'
C:/msys/local/build/mingw32/libstdc++-v3/libsupc++/../../../../src/libstdc++-v3
/libsupc++/vterminate.cc:85: undefined reference to `fputc'
C:/msys/local/build/mingw32/libstdc++-v3/libsupc++/../../../../src/libstdc++-v3
/libsupc++/vterminate.cc:91: undefined reference to `fputs'
c:/program
files/rosbe/i386/bin/../lib/gcc/mingw32/4.4.2/libstdc++.a(cp-demangl
e.o): In function `d_source_name':
C:/msys/local/build/mingw32/libstdc++-v3/libsupc++/cp-demangle.c:1427:
undefine
d reference to `memcmp'
c:/program
files/rosbe/i386/bin/../lib/gcc/mingw32/4.4.2/libstdc++.a(cp-demangl
e.o): In function `d_expression':
C:/msys/local/build/mingw32/libstdc++-v3/libsupc++/cp-demangle.c:2641:
undefine
d reference to `strcmp'
C:/msys/local/build/mingw32/libstdc++-v3/libsupc++/cp-demangle.c:2679:
undefine
d reference to `strcmp'
c:/program
files/rosbe/i386/bin/../lib/gcc/mingw32/4.4.2/libstdc++.a(cp-demangl
e.o): In function `d_print_comp':
C:/msys/local/build
/mingw32/libstdc++-v3/libsupc++/cp-demangle.c:3461: undefined reference
to `str
ncmp'
C:/msys/local/build/mingw32/libstdc++-v3/libsupc++/cp-demangle.c:3881:
undefine
d reference to `strcmp'
C:/msys/local/build/mingw32/libstdc++-v3/libsupc++/cp-demangle.c:4052:
undefine
d reference to `sprintf'
c:/program
files/rosbe/i386/bin/../lib/gcc/mingw32/4.4.2/libstdc++.a(cp-demangl
e.o): In function `d_demangle_callback':
C:/msys/local/build/mingw32/libstdc++-v3/libsupc++/cp-demangle.c:4495:
undefine
d reference to `strncmp'
c:/program
files/rosbe/i386/bin/../lib/gcc/mingw32/4.4.2/libstdc++.a(cp-demangl
e.o): In function `_cxa_demangle':
C:/msys/local/build/mingw32/libstdc++-v3/libsupc++/cp-demangle.c:4656:
undefine
d reference to `strcpy'
c:/program
files/rosbe/i386/bin/../lib/gcc/mingw32/4.4.2/libstdc++.a(cp-demangl
e.o): In function `d_growable_string_callback_adapter':
C:/msys/local/build/mingw32/libstdc++-v3/libsupc++/cp-demangle.c:3010:
undefine
d reference to `realloc'
c:/program files/rosbe/i386/bin/../lib/gcc/
mingw32/4.4.2/libgcc.a(unwind-sjlj.o): In function `fc_key_init':
C:/msys/local/build/mingw32/libgcc/../../../src/libgcc/../gcc/gthr-win32.h:578:
undefined reference to `TlsAlloc@0'
C:/msys/local/build/mingw32/libgcc/../../../src/libgcc/../gcc/gthr-win32.h:589:
undefined reference to `GetLastError@0'
c:/program
files/rosbe/i386/bin/../lib/gcc/mingw32/4.4.2/libgcc.a(unwind-sjlj.o
): In function `_gthread_getspecific':
C:/msys/local/build/mingw32/libgcc/../../../src/libgcc/../gcc/gthr-win32.h:605:
undefined reference to `GetLastError@0'
C:/msys/local/build/mingw32/libgcc/../../../src/libgcc/../gcc/gthr-win32.h:607:
undefined reference to `TlsGetValue@4'
C:/msys/local/build/mingw32/libgcc/../../../src/libgcc/../gcc/gthr-win32.h:609:
undefined reference to `SetLastError@4'
c:/program
files/rosbe/i386/bin/../lib/gcc/mingw32/4.4.2/libgcc.a(unwind-sjlj.o
): In function `_gthread_setspecific':
C:/msys/local/build/mingw32/libgcc/../../../src/libgcc/../gcc/gthr-win32.h:617:
undefined reference to `TlsSetValue@8'
C:/msys/local/build/mingw32/libgc
c/../../../src/libgcc/../gcc/gthr-win32.h:620: undefined reference to
`GetLastE
rror@0'
c:/program
files/rosbe/i386/bin/../lib/gcc/mingw32/4.4.2/libgcc.a(gthr-win32.o)
: In function `_gthr_win32_recursive_mutex_unlock':
C:/msys/local/build/mingw32/libgcc/../../../src/libgcc/../gcc/config/i386/gthr-
win32.c:256: undefined reference to `ReleaseSemaphore@12'
c:/program
files/rosbe/i386/bin/../lib/gcc/mingw32/4.4.2/libgcc.a(gthr-win32.o)
: In function `_gthr_win32_mutex_unlock':
C:/msys/local/build/mingw32/libgcc/../../../src/libgcc/../gcc/config/i386/gthr-
win32.c:187: undefined reference to `ReleaseSemaphore@12'
c:/program
files/rosbe/i386/bin/../lib/gcc/mingw32/4.4.2/libgcc.a(gthr-win32.o)
: In function `_gthr_win32_recursive_mutex_init_function':
C:/msys/local/build/mingw32/libgcc/../../../src/libgcc/../gcc/config/i386/gthr-
win32.c:198: undefined reference to `CreateSemaphoreA@16'
c:/program
files/rosbe/i386/bin/../lib/gcc/mingw32/4.4.2/libgcc.a(gthr-win32.o)
: In function `_gthr_win32_mutex_init_function':
C:/msys/local/build/mingw32/libgcc/../../../src/libgcc/../gcc/config/i386/gthr-
win32.c:150: undefined reference to `CreateSemaphoreA@16'
c:/program
files/rosbe/i386/bin/../lib/gcc/mingw32/4.4.2/libgcc.a(gthr-win32.o)
: In function `_gthr_win32_setspecific':
C:/msys/local/build/mingw32/libgcc/../../../src/libgcc/../gcc/config/i386/gthr-
win32.c:140: undefined reference to `TlsSetValue@8'
c:/program
files/rosbe/i386/bin/../lib/gcc/mingw32/4.4.2/libgcc.a(gthr-win32.o)
: In function `_gthr_win32_getspecific':
C:/msys/local/build/mingw32/libgcc/../../../src/libgcc/../gcc/config/i386/gthr-
win32.c:131: undefined reference to `GetLastError@0'
C:/msys/local/build/mingw32/libgcc/../../../src/libgcc/../gcc/config/i386/gthr-
win32.c:132: undefined reference to `TlsGetValue@4'
C:/msys/local/build/mingw32/libgcc/../../../src/libgcc/../gcc/config/i386/gthr-
win32.c:133: undefined reference to `SetLastError@4'
c:/program
files/rosbe/i386/bin/../lib/gcc/mingw32/4.4.2/libgcc.a(gthr-win32.o)
: In function `_gthr_win32_key_dele
te':
C:/msys/local/build/mingw32/libgcc/../../../src/libgcc/../gcc/config/i386/gthr-
win32.c:123: undefined reference to `TlsFree@4'
c:/program
files/rosbe/i386/bin/../lib/gcc/mingw32/4.4.2/libgcc.a(gthr-win32.o)
: In function `_gthr_win32_key_create':
C:/msys/local/build/mingw32/libgcc/../../../src/libgcc/../gcc/config/i386/gthr-
win32.c:105: undefined reference to `TlsAlloc@0'
c:/program
files/rosbe/i386/bin/../lib/gcc/mingw32/4.4.2/libgcc.a(gthr-win32.o)
: In function `_gthr_win32_setspecific':
C:/msys/local/build/mingw32/libgcc/../../../src/libgcc/../gcc/config/i386/gthr-
win32.c:143: undefined reference to `GetLastError@0'
c:/program
files/rosbe/i386/bin/../lib/gcc/mingw32/4.4.2/libgcc.a(gthr-win32.o)
: In function `_gthr_win32_key_delete':
C:/msys/local/build/mingw32/libgcc/../../../src/libgcc/../gcc/config/i386/gthr-
win32.c:123: undefined reference to `GetLastError@0'
c:/program
files/rosbe/i386/bin/../lib/gcc/mingw32/4.4.2/libgcc.a(gthr-win32.o)
: In function `_gthr_win32_key_create':
C:/msys/local/
build/mingw32/libgcc/../../../src/libgcc/../gcc/config/i386/gthr-win32.c:116:
u
ndefined reference to `GetLastError@0'
mingw32-make: ***
[output-i386\base\applications\games\solitaire\sol.exe] Error
1
Additionally ash mentioned similar linking errors with some of his
projects including a static lib. These Problems only occur in GCC 4.4.2
and not in 4.1.3.
The real fun is this: C:/msys/local/build/mingw32 Where is this path from??!
Any idea where the Problem is from? RBuild? GCC itself? How to fix?
Here is a summary of current status based on previous posts by email.
Current regressions:
- With ARM commit 41636, memory in use continously decreases, I
tested it with only task manager open, this is bug 4835.
- Toolbar in Abiword has some issues, introduced with 42706, comctl32
sync, bug 4811.
- Minimized windows can't be restored, introduced with 41772, bug 4677.
- Programs in startup folder don't start automatically anymore,
introduced with 40439, bug 4568.
- Can't close programs with alt+f4 anymore, introduced with 40299.
Bug 4463.
- VirtualBox needs more >=256 MB Ram to work (hangs in usbdriver.sys,
rel builds are unaffected). Bug 4851
Who is working on what:
Timo Kreuzer - Win32k driver loading and DC creation rewrite; dynamic
mode switching, requiring a rewrite of PDEV locking code. Time is
limited, busy with RL.
KJK::Hyperion - Involvement with mingw-w64.
Colin Finck - Busy with exams.
James Tabor - Class rewrite part2; Message subsystem; Fix menu and
window structures.
Gregor Schneider - Busy with Master thesis.
Johannes Anderwald - Sound support, audio input devices.
Ged Murphy - Lack of time for coding.
Michael Martin - Busy with RL till Nov-Dec. Later, fixing remaining
virtual memory winetests failures.
Aleksey Bragin - New FAT driver (based on FullFAT library), continue
working on Arwinss, fix remaining Configuration Manager bugs, etc.
WBR,
Aleksey Bragin.
CurInfo is an overengineered reactos construct. Mouse stuff is only
relevant for an interactive Windowstation and there is only one per
session. This way is correct,.but using the global variable
gspv.bMouseBtnSwap directly would be better.
Regards,
Timo
mkupfer(a)svn.reactos.org schrieb:
> Author: mkupfer
> Date: Sun Oct 4 22:45:51 2009
> New Revision: 43292
>
> URL: http://svn.reactos.org/svn/reactos?rev=43292&view=rev
> Log:
> temporarily workaround for swap mouse buttons feature
>
> Modified:
> trunk/reactos/subsystems/win32/win32k/ntuser/input.c
>
> Modified: trunk/reactos/subsystems/win32/win32k/ntuser/input.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt…
> ==============================================================================
> --- trunk/reactos/subsystems/win32/win32k/ntuser/input.c [iso-8859-1] (original)
> +++ trunk/reactos/subsystems/win32/win32k/ntuser/input.c [iso-8859-1] Sun Oct 4 22:45:51 2009
> @@ -1120,7 +1120,8 @@
> mi->time = MsqCalculateMessageTime(&LargeTickCount);
> }
>
> - SwapButtons = CurInfo->SwapButtons;
> + // FIXME: CurInfo->SwapButtons doesn't contain the correct value yet
> + SwapButtons = UserGetSystemMetrics(SM_SWAPBUTTON);//CurInfo->SwapButtons;
> DoMove = FALSE;
>
> IntGetCursorLocation(WinSta, &MousePos);
>
>
>
>
stefan__100__(a)hotmail.com wrote:
>> And the reason you couldn't pass Parameters?
> Because KeBugCheck expects the array to contain 4 entries, and Parameters isn't guranteed to be that big.
> What do you think of the following?
>
> NTSTATUS NTAPI ExpSystemErrorHandler (
> // ... abbreviated ...
> {
> ULONG_PTR BugCheckParameters[MAXIMUM_HARDERROR_PARAMETERS] = {0, 0, 0, 0};
> // ... abbreviated ...
> for (i = 0; i < NumberOfParameters; i++)
> {
> /* Copy them over */
> BugCheckParameters[i] = Parameters[i];
> }
If you are going to use that, you'd better include something like this first:
if (NumberOfParameters > MAXIMUM_HARDERROR_PARAMETERS)
NumberOfParameters = MAXIMUM_HARDERROR_PARAMETERS;
or make it
for (i = 0; i < min( NumberOfParameters, MAXIMUM_HARDERROR_PARAMETERS ); i++)
or you might create more problems than you solve, unless you're 100% guarateed
you can never receive more than MAXIMUM_HARDERROR_PARAMETERS.
(This said without studying the actual problem at hand).
Best Regards // Love
_________________________________________________________________
Keep your friends updated—even when you’re not signed in.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/so…
AND THE CROWD GOES WILD!
On Oct 1, 2009 9:56 AM, "Steven Edwards" <winehacker(a)gmail.com> wrote:
On Wed, Sep 30, 2009 at 9:32 AM, <sginsberg(a)svn.reactos.org> wrote:
> URL: http://svn.reactos.org/svn/reactos?rev=43236&view=rev
> Log:
> - Goodbye __USE_W32API
This is a historic day in ReactOS that unfortunately no one will
really remember. Let us celebrate while we can and have much
rejoicing!
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
On Wed, Sep 30, 2009 at 9:32 AM, <sginsberg(a)svn.reactos.org> wrote:
> URL: http://svn.reactos.org/svn/reactos?rev=43236&view=rev
> Log:
> - Goodbye __USE_W32API
This is a historic day in ReactOS that unfortunately no one will
really remember. Let us celebrate while we can and have much
rejoicing!
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
And now you have added zero to this discussion. Just because Alex questions
someone's basic skills doesn't mean that noobs are working on critical
components. For some, this is an entirely academic endeavor, and Alex's
feedback is essential criticisim.
Blah, blah, blah,
WD
(Sent from my G1)
On Sep 26, 2009 2:29 PM, <betam4x(a)gmail.com> wrote:
I'm sorry, had to reply to this one. I may be way off base here since the
contents of this email are based solely upon alex's reply.
People that don't understand the basics of programming are working on system
components? I understand that people want to help, but allowing this does
more harm than good. What happened to all of the talent anyway?
In my opinion, someone that does nor understand C should not be tasked with
working on the hardware abstraction layer.
This was not meant to be an insult or attack in any way, shape, or form to
anyone involved with this thread.
Posted from my crackberry.
Regards,
Richard Campbell
Sent from my Verizon Wireless BlackBerry
-----Original Message----- From: Alex Ionescu <ionucu(a)videotron.ca> Date:
Sat, 26 Sep 2009 14:06:4...
Hi,
I just wanted to let everyone know that Wineconf 2009 is going to be
held in Holland on Nov 6-8th. I am of course planning on attending and
Fireball said that he might as well. If any ReactOS developers are
interested in going and don't have the resources, speak up and perhaps
some of the users and advocates that follow ReactOS development would
be willing to contribute $5 or $10 to the Foundation on your behalf.
Information (what little there is currently) is here:
http://wiki.winehq.org/WineConf2009
The ReactOS foundation Donation page is here
http://www.reactos.org/en/foundation_donate.html
Also while there has been some heated exchanges with Wine and ReactOS
developers in the past, we do get quite a lot in terms of code from
them so if your interested in helping them out, you can donate to the
Wine Development Fund, which will help pay for Wine developers to
attend. The donation link is on the main page of Winehq.org
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Hello,
I'm back from my vacation which took part in Sweden this time (not
counting a day passing through Finland). I had a pleasure of meeting
Stefan Ginsberg ("Stefan100"), Magnus Olsen ("GreatLord"), Simon and
his wife, and of course Jan Kinander ("JaixBly") who drove some
hundreds kilometers from his city to meet all of us. I met all those
persons for the first time in RL except for Stefan, who I met earlier
this year in Brussels.
After a perfectly guided (mostly by Magnus ;)) tour through the Old
City (Gamla Stan) in Stockholm, we made the first ReactOS discussion
attempt in a very nice cafe at the island where Vasa museum is. We
talked mostly about the history of ReactOS project, how I ended up in
this project, what were the most problematic moments of its life and
development ("Hartmut incident", etc), persons involved in ReactOS at
various points in time. After Jan's parking ticked started expiring
Simon suggested to move into his office to continue the talk.
We logged in to #reactos from the office, under GreatLord's nickname
(it was a very unusual feeling when you type things, hit enter, and
it appears as "<GreatLord> ..."), and we all together discussed
future ways of ReactOS progress, possible commercial usage, possible
support, stability and compatibility as usual, products which could
utilize ReactOS and many many more things.
In the end, we shoot a video introducing all this "conference"
participants, and it actually shows "Magnus in action" for the first
time ever. The video seems rather black, and probably has poor
quality (I haven't transferred it to my PC yet) but it should
definately be interesting. I will edit it and put on youtube asap.
It was really great to meet all of you!
Now, to the actual development part of the email (why it ended up in
ros-dev and not ros-general). After I left, I saw number of commits
significantly decreased, and only some 94 commits were done in my
absence (roughly 6 per day). Quality matters though, not quantity!
It's time to think about stabilizing what has been done and preparing
a new release (without arwinss, if someone wonders).
1. Could someone of the testing team please provide me (here) a list
of regressions (with corresponding bug numbers) introduced with
recent ARMMM and other changes?
2. What is everyone up to right now, what unfinished work you have,
what work you are about to finish, what you want and what you don't
want to go to the next release? No need to write time consuming
paragraphs of course, just provide a very quick overview / status so
I and everyone else has idea what you are doing now and what to expect.
3. What's the most up to date GCC 4.4 status, estimates, problems
(bug # would be enough).
Thanks,
Aleksey Bragin.
Hi, I want to inform about a regression on the XBox which causes freeldr
not being able to load freeldr.ini and such failing to boot ROS. I tried
to track down the regression and was able to find two possible guilty revs:
42263 OK
42526 No build available.
42527 XX
Between 42263 and 42526 is not chnage in freeldr at all, so it has to be
42526 or 42527, both by hpoussin and both have something to do with
loading files. I hope someone can fix it, if you need someone to test
it, just send me a patch and i will try it.
Thx
Daniel Reimer
> timo.kreuzer(a)web.de wrote:
> ...
>> Ged Murphy wrote:
>> ...
> Quotes should start with leading ">" to make it more readable.
> Quoting signatures / footers is a waste of space.
>
>>> ros-dev-bounces(a)reactos.org wrote:
>>> Hi,
>>> sorry for OT, but http://learn.to/quote/
>>> thanks
>From Wikipedia, the free encyclopedia
OT may refer to:
* Oakville Trafalgar High School
* Oblivious transfer
* Occupational therapy
* Occupational therapist
* Off-topic
* Offensive tackle, either of two football positions
* Old Testament
* Old Trafford
* Operación Triunfo, a Spanish reality-show talent contest
* Operating Thetan, in Scientology, a spiritual state of a being able to operate
free of the encumbrances of the material universe
* Operating theatre
* Operational Transformation (OT) an optimistic concurrency control method for group editing
* Operation Transformation (TV series), a popular Gerry Ryan event
* Optimality theory
* Organisation Todt, a Third Reich civil and military engineering group
* Otago, a region of New Zealand
* O.T. Recordings, a record label
* Overtime, a designation indicating working past normal work hours
* Overtime (sports), playing a sports game past regulation because of a tie game
* The IATA airline designator for Aeropelican Air Services
* Obrněný Transportér, Czech for Armored Transporter
o OT-62 - Series of tracked armoured vehicles
o OT-64 - Series of 8X8 armoured vehicles
o OT-65 - Series of 4x4 Armoured Cars of Hungarian design similar to the BRDM-1
o OT-810 - Half-track infantry combat vehicle series
* Obsession Telescopes - a U.S. telescope maker
Excuse the OT, I'll behave after this. :D
By the way, I second Timo's remark above.
Keep up the good work..
- Love
_________________________________________________________________
Show them the way! Add maps and directions to your party invites.
http://www.microsoft.com/windows/windowslive/products/events.aspx
Hi all,
i would want to ask for some help from all of you, Vicmarcal (and
KJK::Hyperion) told se some time ago about next hackmeeeting event here in
Madrid, and asked me to apply about ReactOS being there.
I did it, and ReactOS has been accepted. The thing, now is that i dont feel
too confident to be able to get this stand into a succesful status..... You
will think reasons are childness, and probably they are, but as a result i
feel tied up for doing it...
What kind of help am i asking you for? well.. is anyone getting here so i
could ask him/her for help? what should be the next step i should do?
thank you so much
Sorry,
but I have some problems with sending mails to the list.
Matthias
--
Matthias Kupfer phone +49 (0) 371 236 46 52
Wilhelm-Firl-Straße 21 mobile +49 (0) 160 859 43 54
09122 Chemnitz, Germany
Hi,
Sometime back a month ago we lost networking initialization. At this
time, after each boot I have to reapply network settings manually. To
go back from July and regression test each build is a heavy task to
ask for anyone. I do hope someone has a revision to start from.....
Thanks,
James
Hi all,
I find ReactOS an interesting project, so I decided to read up on it and play around with the images.
However, I was really put down by the incredibly bad translation to Norwegian. So much that I quickly switched to English at the web page.
Some guys at IRC asked me to review the translation source for the OS proper as well, and the result was discouraging (I only checked 3-4 files). There's a lot of typos, strangely translated sentences and basic punctuation mistakes.
This is embarrassing to the extent that, IMO, the translations should be removed until new ones are in place.
Thanks,Jon
_________________________________________________________________
More than messages–check out the rest of the Windows Live™.
http://www.microsoft.com/windows/windowslive/
> From: timo.kreuzer(a)web.de
> To: ros-dev(a)reactos.org
> Date: Sun, 30 Aug 2009 21:30:02 +0200
> Subject: Re: [ros-dev] [ros-diffs] [sginsberg] 42973: - %llx -> %I64x - Don't pass a string literal to strcmp
>
> Huh? Why shouldn't one use a string literal in strcmp?
> What are you trying to "fix"?
IMHO: In regards to ReactOS proper, there's the internationalization/localization
issues to consider. But regarding dev utils like sysdump I'd say it's not critical.
Anyone feel different ?
- Love Nystrom (I'm sorry if responses are slow. I live in a technically deficient area)
_________________________________________________________________
Share your memories online with anyone you want.
http://www.microsoft.com/middleeast/windows/windowslive/products/photos-sha…
Hi,
as you can see I tried to sync Wine's D3D in our tree. This went quite
well and works fine. Problem is now... ddraw fails to build, ours and
the HEAD wine rev with the same error you can see in the build logs.
After some hours of toying with ddraw.h i got dozens of different
errors, but it fails. The only way for me to get it build is using
wine's ddraw.h and ddrawi.h which would again break even more stuff in
ROS's tree. Maybe someone has a idea? If not, i will revert it this
morning after i woke up.
Night
On Aug 27, 2009, at 1:18 PM, fireball(a)svn.reactos.org wrote:
> Author: fireball
> Date: Thu Aug 27 11:18:34 2009
> New Revision: 42955
>
> URL: http://svn.reactos.org/svn/reactos?rev=42955&view=rev
> Log:
> - Remove the window station hack, it's not really needed anymore.
> Window station is not properly created by winlogon.
A typo came here. Correct way would be "Window station is *now*
properly created by winlogon".
WBR,
Aleksey Bragin.
On Mon, Aug 24, 2009 at 2:19 PM, <sginsberg(a)svn.reactos.org> wrote:
> Author: sginsberg
> Date: Mon Aug 24 20:19:53 2009
> New Revision: 42920
>
> URL: http://svn.reactos.org/svn/reactos?rev=42920&view=rev
> Log:
> - Get rid of TAG() from the kernel
> - mmtypes.h: Goodbye TAG(), you won't be missed
Maybe this has already been done but if not, we should look in to
making a janitorial project for it, Alex and I talked years ago about
trying to maintain a list with all of the tags that were in use and
apply some consistency to the names. I think there is a list somewhere
on MSDN that shows all the tag's used in Windows, and we should try to
check ours to make sure they match up.
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Hi.
After two weeks of disappointing escapades over building GCC 4.4.X I
decided to try out the official mingw32 build from sf.net always in my
mind that all patches we had to use in GCC 4.1.3 are already included in
GCC 4.4.X. Well at first it built well (with disabled rsym, which fucks
up dwarf2 headers in a way which renders a executable unuseable) but
then it died with the error you can see in the bug report.
(http://www.reactos.org/bugzilla/show_bug.cgi?id=4810) OK, I hoped
someone comes up with a fix in our code, but hto answered with a patch
in gcc. My 1. question now: Is this patch needed or is the error our
fault? If we really need this patch i could need someone's helping hand
with building GCC. We started a wiki entry
(http://www.reactos.org/wiki/Compiling_GCC_From_Windows) which shows our
recent tries to build a recent GCC without dwarf2 support. it builds
quite well if i do "make all-gcc", but i want and need a full "make all"
and there i get this one:
http://img24.imageshack.us/img24/8817/1007360g.jpg Any Ideas? (Yes this
is question 2.) Question 3 is: Anyone succeeded building cloog-ppl? And
the last question: Any other useless crap in our settings in the wiki?
Any needed fixes settings etc?
Thx.
On Fri, Aug 21, 2009 at 3:13 PM, <fireball(a)svn.reactos.org> wrote:
> Author: fireball
> Date: Fri Aug 21 21:13:00 2009
> New Revision: 42833
>
> URL: http://svn.reactos.org/svn/reactos?rev=42833&view=rev
> Log:
> - Implement windows moving (with contents).
This is one of the Greatest. Commits. Ever. I wish that we could make
Office 2007 run just by removing half the commented out code. ;)
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Hello all,
I just wanted to announce some upcoming changes. Comments are appreciated.
Official removal of i486 support
---------------------------------
The Mingw-w64 project held an internal meeting today. One of the decisions
was to remove support for architectures older than i586 from their code.
As we already use some of their runtime code and loosely planned to switch
to a mingw-w64 x86/x64 multilib toolchain once that is released and stable
(which should be the case in gcc 4.5.x), we will be affected by this change,
too.
Of course, the Mingw-w64 code would just add another problem to the pot of
i486 incompatibilities.
For example, some of our assembly code makes use of the CMPXCHG8B
instruction (introduced in the Pentium).
Though I don't know anybody, who tried a recent ReactOS build on an i486
machine, I also never found a statement about the official removal of i486
support.
So as long as nobody objects, let's officially declare i486 support
abandoned now.
ISO cleaning on iso.reactos.org
--------------------------------
As we were right before running out of space on the ISO storage server (in
fact, that would have happened when Aleksey was on his planned holiday trip
:D), I've installed a script to clean old ISOs automatically now.
The script will remove bootcd-dbg ISOs older than 2 years and all other ISOs
older than half a year. This should free enough space while keeping enough
important ISOs for tracking down old regressions.
Testman log cleaning
---------------------
Another service that takes more space than you might think is Testman. Logs
for ~1300 revisions currently take around 2 GB.
My plan would be to delete logs (not the actual test result numbers) older
than half a year to keep the used space for them on an almost constant
level. If nobody objects, such a script will be installed in the upcoming
days.
Best regards,
Colin
dchapyshev(a)svn.reactos.org wrote:
> Modified: trunk/reactos/base/applications/rapps/CreateCabFile.bat
If you want to create a raw CAB file, you should rather try the "cabinet"
module of rbuild (see /trunk/reactos/media/vgafonts/vgafonts.rbuild for an
example).
Though I'm certainly in favor of a solution involving multiple plain XML
files (instead of several INI-like files put into a single cabinet) if this
is going to become a client/server system in the future. This would make it
more flexible and we could think about future usages such as showing that
application database on a website.
Reading XML shouldn't be that hard to implement considering that probably no
other source tree contains as many XML libraries as ours ;-)
After all, I think that rapps is a step in the right direction! :-)
Best regards,
Colin
Good catch, thanks!
(I'm getting used to finding a real change in reformatting commits
nowadays :)).
WBR,
Aleksey Bragin.
On Aug 9, 2009, at 6:40 PM, dgorbachev(a)svn.reactos.org wrote:
> Author: dgorbachev
> Date: Sun Aug 9 16:40:05 2009
> New Revision: 42566
>
> URL: http://svn.reactos.org/svn/reactos?rev=42566&view=rev
> Log:
> Fix IDT limit.
>
> Modified:
> trunk/reactos/boot/freeldr/freeldr/arch/i386/i386idt.S
> trunk/reactos/boot/freeldr/freeldr/windows/wlmemory.c
On Aug 8, 2009, at 10:03 PM, hyperion(a)svn.reactos.org wrote:
> Author: hyperion
> Date: Sat Aug 8 20:03:48 2009
> New Revision: 42530
>
> URL: http://svn.reactos.org/svn/reactos?rev=42530&view=rev
> Log:
> modified base/setup/vmwinst/vmwinst.c
> modified base/setup/vmwinst/vmwinst.rbuild
> Implement VMWare detection for Visual C++ as well
> For cleaner code, use SEH instead of VEH, even if it means
> losing this pearl of ReactOS wisdom:
>
> /* Setup a vectored exception handler to protect the
> detection. Don't use SEH
> here so we notice the next time someone removes support for
> vectored
> exception handling from ros... */
>
> (www.passiveaggressivecommits.com, brought to you by Arch
> Blackmann!)
> Of course, it also means trading our VEH bugs for our SEH bugs,
> so I'm not sure if it was worth changing
This test should be added to the test suite which we have now (or
maybe it is there already?). Putting various tests inside unrelated
apps was a great idea back then but reactos evolved from that.
WBR,
Aleksey Bragin.
hpoussin(a)svn.reactos.org wrote:
> Author: hpoussin
> Date: Sat Aug 8 23:11:40 2009
> New Revision: 42538
>
> URL: http://svn.reactos.org/svn/reactos?rev=42538&view=rev
> Log:
> Fix some typos and make PFILE a ULONG
>
I hope this is fully 64 bit compatible...
I think FILEID would look better and is less likely to confuse other
devs when working with it ;-)
This is very wrong!
PtrBCB should never ever be NULL... and if it is then it means that
CcMapData few lines above failed. In fact the whole chunk of code is
wrong. CcMapData return value is not properly checked. If it got far
enough that CcUnpinData crashed then
PtrParentFCB->NTRequiredFCB.CommonFCBHeader.FileSize == 0 and
obviously the mapping will fail. This case can easily be checked
without even attempting to map the data...
Best regards,
Filip Navara
On Sun, Aug 9, 2009 at 7:26 PM, <dgorbachev(a)svn.reactos.org> wrote:
> Author: dgorbachev
> Date: Sun Aug 9 19:26:10 2009
> New Revision: 42569
>
> URL: http://svn.reactos.org/svn/reactos?rev=42569&view=rev
> Log:
> Do not call CcUnpinData() with NULL PtrBCB.
>
> Modified:
> trunk/reactos/drivers/filesystems/ext2/src/create.c
>
> Modified: trunk/reactos/drivers/filesystems/ext2/src/create.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/ext2/s…
> ==============================================================================
> --- trunk/reactos/drivers/filesystems/ext2/src/create.c [iso-8859-1] (original)
> +++ trunk/reactos/drivers/filesystems/ext2/src/create.c [iso-8859-1] Sun Aug 9 19:26:10 2009
> @@ -1410,8 +1410,12 @@
> }
> }
>
> - CcUnpinData( PtrBCB );
> - PtrBCB = NULL;
> + // FIXME
> + if( PtrBCB )
> + {
> + CcUnpinData( PtrBCB );
> + PtrBCB = NULL;
> + }
>
> return InodeNo;
> }
>
>
>
Hey everyone, my name is Huzky, I'm a Graphic-Artist and I would like to present my graphics
for ReactOS to you:
This is my idea for a new ROS-BE Icon:
http://img188.imageshack.us/img188/2416/ros2.png
And this is a preview of a Theme I'am creating for ROS, because I think ROS should look like the modern os it is :)
http://img188.imageshack.us/img188/8097/task.png
I would be very happy about critics or suggestions for Improvement.
best regards, Huzky
______________________________________________________
GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://movieflat.web.de
On Sat, Aug 8, 2009 at 5:38 PM, Alex Ionescu<ionucu(a)videotron.ca> wrote:
> Awe, Thomas's "Fuck Alex" code is gone...
I think we should add it back with this discussion in comments so
posterity is left to ponder.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Awe, Thomas's "Fuck Alex" code is gone...
On 8-Aug-09, at 11:03 AM, hyperion(a)svn.reactos.org wrote:
> For cleaner code, use SEH instead of VEH, even if it means losing
> this pearl of ReactOS wisdom:
>
> /* Setup a vectored exception handler to protect the
> detection. Don't use SEH
> here so we notice the next time someone removes support for
> vectored
> exception handling from ros... */
Best regards,
Alex Ionescu
Hi all,
I have found a regression at 3rd stage, that prevents me to install my sound
card drivers anymore,
I have regtested it, and the range is 42150 - 42263
Unfortunately, there are no debug revisions between these 2 revs, so i cant
regtest anymore.
Since i was trying to install sound card drivers, i asked Janderwald about
it, and he has led me to the ML
This is the log im getting ( http://www.reactos.org/paste/index.php/5523/ ):
fixme:(dll/win32/setupapi/interface.c:307) Need to
InstallOneInterface({6994ad04-93ef-11d0-a3cc-00a0c9223196} L"FMSynth"
L"WDM_P16X.Interface.DMus" 0)
fixme:(dll/win32/setupapi/interface.c:307) Need to
InstallOneInterface({65e8773e-8f56-11d0-a3b9-00a0c9223196} L"FMSynth"
L"WDM_P16X.Interface.DMus" 0)
fixme:(dll/win32/setupapi/interface.c:307) Need to
InstallOneInterface({dff220f3-f70f-11d0-b917-00a0c9223196} L"FMSynth"
L"WDM_P16X.Interface.DMus" 0)
fixme:(dll/win32/setupapi/interface.c:307) Need to
InstallOneInterface({6994ad04-93ef-11d0-a3cc-00a0c9223196} L"Wave"
L"WDM_P16X.Interface.Wave" 0)
fixme:(dll/win32/setupapi/interface.c:307) Need to
InstallOneInterface({65e8773e-8f56-11d0-a3b9-00a0c9223196} L"Wave"
L"WDM_P16X.Interface.Wave" 0)
fixme:(dll/win32/setupapi/interface.c:307) Need to
InstallOneInterface({65e8773d-8f56-11d0-a3b9-00a0c9223196} L"Wave"
L"WDM_P16X.Interface.Wave" 0)
fixme:(dll/win32/setupapi/interface.c:307) Need to
InstallOneInterface({6994ad04-93ef-11d0-a3cc-00a0c9223196} L"Topology"
L"WDM_P16X.Interface.Topology" 0)
fixme:(dll/win32/setupapi/interface.c:307) Need to
InstallOneInterface({dda54a40-1e4c-11d1-a050-405705c10000} L"Topology"
L"WDM_P16X.Interface.Topology" 0)
fixme:(dll/win32/setupapi/interface.c:307) Need to
InstallOneInterface({6994ad04-93ef-11d0-a3cc-00a0c9223196} L"UART"
L"WDM_P16X.Interface.UART" 0)
fixme:(dll/win32/setupapi/interface.c:307) Need to
InstallOneInterface({65e8773e-8f56-11d0-a3b9-00a0c9223196} L"UART"
L"WDM_P16X.Interface.UART" 0)
fixme:(dll/win32/setupapi/interface.c:307) Need to
InstallOneInterface({65e8773d-8f56-11d0-a3b9-00a0c9223196} L"UART"
L"WDM_P16X.Interface.UART" 0)
err:(dll/win32/setupapi/queue.c:1659) copy error 2
L"C:\\ReactOS\\inf\\sysaudio.sys" ->
L"C:\\ReactOS\\System32\\sysaudio.sys"
err:(dll/win32/setupapi/queue.c:1659) copy error 2
L"C:\\ReactOS\\inf\\wdmaud.sys" ->
L"C:\\ReactOS\\System32\\wdmaud.sys"
err:(dll/win32/setupapi/queue.c:1659) copy error 2
L"C:\\ReactOS\\inf\\portcls.sys" ->
L"C:\\ReactOS\\System32\\portcls.sys"
err:(dll/win32/setupapi/queue.c:1659) copy error 2
L"C:\\ReactOS\\inf\\drmk.sys" -> L"C:\\ReactOS\\System32\\drmk.sys"
err:(dll/win32/setupapi/queue.c:1659) copy error 2
L"C:\\ReactOS\\inf\\kmixer.sys" ->
L"C:\\ReactOS\\System32\\kmixer.sys"
err:(dll/win32/setupapi/queue.c:1659) copy error 2
L"C:\\ReactOS\\inf\\wdmaud.drv" ->
L"C:\\ReactOS\\System32\\drivers\\wdmaud.drv"
err:(dll/win32/setupapi/queue.c:1659) copy error 2
L"C:\\ReactOS\\inf\\ksuser.dll" ->
L"C:\\ReactOS\\System32\\drivers\\ksuser.dll"
err:(dll/win32/shell32/shellpath.c:1454) Failed to create directory
L"%USERPROFILE%\\Configuraci\00f3n local\\Archivos temporales de
Internet".
err:(dll/win32/wininet/urlcache.c:554) Couldn't get path for default container 0
err:(dll/win32/shell32/shellpath.c:1454) Failed to create directory
L"%USERPROFILE%\\Configuraci\00f3n local\\Historial".
err:(dll/win32/wininet/urlcache.c:554) Couldn't get path for default container 1
err:(dll/win32/shell32/shellpath.c:1454) Failed to create directory
L"%USERPROFILE%\\Cookies".
err:(dll/win32/wininet/urlcache.c:554) Couldn't get path for default container 2
fixme:(dll/win32/setupapi/stubs.c:200) Stub 00638920 0132FF40 1 0132FF0C
(drivers/wdm/audio/backpln/portcls/adapter.c:48) PcInitializeAdapterDriver
(drivers/wdm/audio/backpln/portcls/adapter.c:52) Setting IRP handlers
(drivers/wdm/audio/backpln/portcls/adapter.c:98) PcAddAdapterDevice called
(drivers/wdm/audio/backpln/portcls/irp.c:142) unhandled function 15
(drivers/wdm/audio/backpln/portcls/irp.c:142) unhandled function 15
(drivers/wdm/audio/backpln/portcls/irp.c:142) unhandled function 15
(drivers/wdm/audio/backpln/portcls/irp.c:142) unhandled function 15
(drivers/wdm/audio/backpln/portcls/irp.c:142) unhandled function 15
Assertion 'PointerPte != NULL' failed at ARM³::SYSPTE line 177
Entered debugger on embedded INT3 at 0x0008:0x808c06f6.
kdb:> bt
Eip:
<NTOSKRNL.EXE:c06f7 (lib/rtl/i386/debug_asm.S:33 (DbgBreakPoint@0))>
Frames:
<NTOSKRNL.EXE:79d20 (ARM³::SYSPTE:177 (MiReserveSystemPtes@8))>
<NTOSKRNL.EXE:793dd (ARM³::POOL:270 (MiAllocatePoolPages@8))>
<NTOSKRNL.EXE:7666d (ARM³::EXPOOL:118 (ExAllocateArmPoolWithTag@12))>
<NTOSKRNL.EXE:8403c (ntoskrnl/mm/pool.c:87 (EiAllocatePool@16))>
<NTOSKRNL.EXE:8415d (ntoskrnl/mm/pool.c:166 (ExAllocatePoolWithTag@12))>
<FM801A.sys:6f4d>
<FM801A.sys:bfb9>
<NTOSKRNL.EXE:8415d (ntoskrnl/mm/pool.c:166 (ExAllocatePoolWithTag@12))>
<portcls.sys:997c (drivers/wdm/audio/backpln/portcls/pool.c:18 (AllocateItem))>
<portcls.sys:da36 (drivers/wdm/audio/backpln/portcls/registry.c:371
(PcNewRegistryKey@36))>
<FM801A.sys:e6ba>
<FM801A.sys:909>
<portcls.sys:4c65 (drivers/wdm/audio/backpln/portcls/irp.c:97 (PortClsPnp@8))>
<portcls.sys:4d31 (drivers/wdm/audio/backpln/portcls/irp.c:268
(PcDispatchIrp@8))>
<FM801A.sys:656f>
<FM801A.sys:63bb>
<NTOSKRNL.EXE:5a90a (ntoskrnl/io/pnpmgr/pnpmgr.c:534 (IopInitiatePnpIrp))>
<NTOSKRNL.EXE:5a3c3 (ntoskrnl/include/internal/ke_x.h:98 (IopStartDevice))>
<NTOSKRNL.EXE:5bd75 (ntoskrnl/io/pnpmgr/pnpmgr.c:2055
(IopActionInitChildServices))>
<NTOSKRNL.EXE:59e31 (ntoskrnl/io/pnpmgr/plugplay.c:577 (IopResetDevice))>
<NTOSKRNL.EXE:5a0cc (ntoskrnl/io/pnpmgr/plugplay.c:837
(NtPlugPlayControl@12))>--- Press q to abort, any other key to
continue ---
<NTOSKRNL.EXE:b8cf0 (ntoskrnl/ke/i386/trap.s:244 (KiFastCallEntry))>
<ntdll.dll:658d>
<umpnpmgr.exe:9614>
<rpcrt4.dll:1c0b3>
<rpcrt4.dll:1c479>
<rpcrt4.dll:1c54b>
<kernel32.dll:27b4f>
<ntdll.dll:179f2>
<ntdll.dll:181e6>
<00000000>
kdb:>
Your kung-fu is the best, Alex.
On Aug 3, 2009 7:22 PM, "Alex Ionescu" <ionucu(a)videotron.ca> wrote:
Just got back to San Francisco... I will take you up on the challenge.
Your ass is grass, and I'm the lawnmower.
Best regards,
Alex Ionescu
On Mon, Aug 3, 2009 at 11:15 AM, Timo Kreuzer <timo.kreuzer(a)web.de> wrote: >
> yeah ;-) > > Dmitr...
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Hi,
I just checked: ctime and asctime have a different behaviour when it comes
to parameter checks, although they work on the same buffer. I'll address
this soon.
Most param checks are missing indeed, but they'll be added one after
another. I'm just starting on that. The only real life problem with the code
that I could find is that mktime produces a time that is one or two hours
off.
Best regards
Gregor Schneider
On Tue, Aug 4, 2009 at 3:02 PM, <dchapyshev(a)svn.reactos.org> wrote:
> Author: dchapyshev
> Date: Tue Aug 4 21:02:56 2009
> New Revision: 42388
>
> URL: http://svn.reactos.org/svn/reactos?rev=42388&view=rev
> Log:
> - Add "ReactOS Application Manager". This program is replacement "Download !" and appwiz.cpl.
>
I don't have the time to do a build at the moment, are there
screenshots of this guy anywhere?
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Hi,
First of all, are you sure that this code is mature enough to care
about minor details? I would say, "@implemented" has been added by
mistake.
About this commit: I tried to call asctime from glibc-2.8 on Linux,
but tm_year=9 works fine (resulting in 1909). I know, it is not
msvcrt. But I don't see any good reason to not allow years before
1970. Furthermore, I'm sure, this function was once introduced to just
transform a date to human-readable format, and it shouldn't care about
the date. Btw, MSDN says nothing
Another tricky question is: How is the UNIX epoch connected with
Reactos (or Windows)?
About 'asctime': it might be holy, but it's "holey". It doesn't even
check the month and the day of week to fit the ranges 0..11 and 0..6
correspondingly.
So, please, fix the security problems first, and then revert this commit ;)
2009/8/4 <gschneider(a)svn.reactos.org>:
> Author: gschneider
> Date: Wed Aug 5 04:06:25 2009
> New Revision: 42402
>
> URL: http://svn.reactos.org/svn/reactos?rev=42402&view=rev
> Log:
> asctime/ctime: Check for too low input time, fixes one msvcrt time winetest
>
> Modified:
> trunk/reactos/lib/sdk/crt/time/ctime.c
>
> Modified: trunk/reactos/lib/sdk/crt/time/ctime.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/sdk/crt/time/ctime.c?r…
> ==============================================================================
> --- trunk/reactos/lib/sdk/crt/time/ctime.c [iso-8859-1] (original)
> +++ trunk/reactos/lib/sdk/crt/time/ctime.c [iso-8859-1] Wed Aug 5 04:06:25 2009
> @@ -1200,14 +1200,23 @@
> "Jul", "Aug", "Sep", "Oct", "Nov", "Dec"
> };
> static char result[26];
> -
> - (void) sprintf(result, "%.3s %.3s%3d %02d:%02d:%02d %d\n",
> - wday_name[timeptr->tm_wday],
> - mon_name[timeptr->tm_mon],
> - timeptr->tm_mday, timeptr->tm_hour,
> - timeptr->tm_min, timeptr->tm_sec,
> - TM_YEAR_BASE + timeptr->tm_year);
> - return result;
> + char* res = result;
> +
> + /* Check for invalid input time */
> + if (timeptr->tm_year <= 69)
> + {
> + res = NULL;
> + }
> + else
> + {
> + sprintf(res, "%.3s %.3s%3d %02d:%02d:%02d %d\n",
> + wday_name[timeptr->tm_wday],
> + mon_name[timeptr->tm_mon],
> + timeptr->tm_mday, timeptr->tm_hour,
> + timeptr->tm_min, timeptr->tm_sec,
> + TM_YEAR_BASE + timeptr->tm_year);
> + }
> + return res;
> }
>
> /*
>
>
>
A similar question would apply to the ninjas' "issue #" that crept up once
or twice...
Best regards,
Alex Ionescu
On Sun, Aug 2, 2009 at 3:26 PM, Steven Edwards <winehacker(a)gmail.com> wrote:
> On Sun, Aug 2, 2009 at 6:32 AM, <fireball(a)svn.reactos.org> wrote:
> > - Use combined clipping object everywhere to ensure drawing happens only
> in allowed rectangle, see arwinss nr. 15. As a side effect, it fixes FireFox
> and other apps which would corrupt memory if trying to blit to area outside
> of DC.
>
> I keep seeing these comments, 'see arwinss nr. #'. Where do I go to
> look this up?
>
> Thanks
> --
> Steven Edwards
>
> "There is one thing stronger than all the armies in the world, and
> that is an idea whose time has come." - Victor Hugo
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
On Sun, Aug 2, 2009 at 6:32 AM, <fireball(a)svn.reactos.org> wrote:
> - Use combined clipping object everywhere to ensure drawing happens only in allowed rectangle, see arwinss nr. 15. As a side effect, it fixes FireFox and other apps which would corrupt memory if trying to blit to area outside of DC.
I keep seeing these comments, 'see arwinss nr. #'. Where do I go to
look this up?
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
http://www.reactos.org/wiki/Arwinss ?
On Mon, Aug 3, 2009 at 12:26 AM, Steven Edwards <winehacker(a)gmail.com>wrote:
> On Sun, Aug 2, 2009 at 6:32 AM, <fireball(a)svn.reactos.org> wrote:
> > - Use combined clipping object everywhere to ensure drawing happens only
> in allowed rectangle, see arwinss nr. 15. As a side effect, it fixes FireFox
> and other apps which would corrupt memory if trying to blit to area outside
> of DC.
>
> I keep seeing these comments, 'see arwinss nr. #'. Where do I go to
> look this up?
>
> Thanks
> --
> Steven Edwards
>
> "There is one thing stronger than all the armies in the world, and
> that is an idea whose time has come." - Victor Hugo
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
Hello all. My name is John Jackson and I'm looking to start doing
driver development on Reactos. I've worked as a C++ / C# programmer
for about 7 years, and I want to get back into more hard-core C
development. Driver writing appeals to me since it sounds like a real
challenge. I've never programmed drivers before, but I've been reading
up on it and looking at code. (Also, I don't mean any of my questions
or wordings in a negative way, I'm not entirely sure how to phrase
some of my questions)
I'd like to start by working on USB support. I've taken a couple
glances through svn, and I've got some questions.
1. Does the reactos build environment support Windows Driver Framework
or just the Windows Driver model?
2. I see under /drivers/usb there is an nt4compat folder. I understand
basic usb keyboard/mouse support comes from here, but it's not coded
using the new driver models introduced in xp. Is anyone currently
working on a "proper" usb implementation? I see there are several
stubs in /drviers/usb/ that just return true.
3. I assume the place to start with usb support is bus drivers? Do
usb1 and usb2 mean different bus drivers? (I've not read up much on
usb yet, I'm still trying to wrap my head around driver development)
I'll try to get on the irc channel either tomorrow or Sunday to say hi
in person, but I think this is a good start for conversation.
--John Jackson
--taladon(a)gmail.com
Hello,
I will be thoroughly explaining the arwinss architecture, and the
very first start is the general flow diagram which could be seen here:
http://www.reactos.org/wiki/Arwinss_architecture
This page will also get more updates with regard to architecture and
design of all modules, but most attention will be paid to win32k.sys
internals and native gdi/user driver (so-called winent.drv).
With the best regards,
Aleksey bragn.
Hi Everyone,
I just thought I'd introduce myself. I am the author of a new FAT
implementation that was really designed for embedded systems. As such
it provides very good performance. (See www.fullfat-fs.co.uk).
Fireball contacted me a few days ago to discuss the current
development of FullFAT, and since I have agreed to implement an IFS
driver based on FullFAT with a view to replacing the current
fastfat.sys implementation. During the conversation we also discussed
implementing a special journaling extension to FullFAT via the windows
driver.
I hope to start work on this project in the next few weeks, and
further to this I would also like to help in some other areas of
ReactOS. I shall be taking a closer look at the ReactOS code over the
coming weeks, and will probably post some questions about various
aspects. I have just bought the Windows Internals, fifth edition
co-authored by Alex Ionescu, hopefully this will provide me with a
good overview of the Windows architecture etc.
For complete Windows XP compatibility, just how much of the
implementation is currently missing from ReactOS?
Nice to meet you all, and I hope to provide some good contributions to
ReactOS in the near future.
James
--
James Walmsley
----------------------------------------
james(a)worm.me.uk
Hello,
our debug buildslave is currently offline, I'd like to ask developers
to abstain from committing to trunk till it comes back online
(hopefully we can thing something up, have a spare buildslave, turn
release buildslave into a debug one or something).
Otherwise we may miss potential regressions.
Thanks for understanding,
Aleksey Bragin.
Here's the information required to patch the incorrect implementation.
Abstract:
- SendInput()/NtUserSendInput() broken:
--- Relative hardware mouse input "working", but not well implemented due
to lack of modifying the travel distance using cursor acceleration and
movement speeds (I've provided info on this as well below), input-virtual
vs screen-real coordinates (even in the relative moves), etc. The two
coordinate spaces are not the same thing!
--- Absolute hardware mouse input broken (used by things like
touchscreens), by a complete misunderstanding of how the virtual input
device coordinate space works (it's NOT in ANY way a 1:1 map that's
translatable to the screen, but the function uses it this way everywhere!)
read below for full info since this is the serious problem.
- SetCursorPos() broken (should NOT be using SendInput() since that's
pointless and ineffective and is meant for the hardware input queue, we
already have the desired coordinates and should move the cursor directly;
and even its use of SendInput() is incorrect since it should FIRST convert
the desired SCREEN coordinates to absolute-INPUT-coordinate-space), BUT
since it's using the broken SendInput() (which currently doesn't know that
absolute input coordinates have NOTHING to do with screen coordinates) it
works correctly and will place cursors at the right location. This will
have to be changed when SendInput() is patched; preferrably to a direct
cursor update (elaborated in the recap below, before the log), rather than
the current indirect/slow approach which places a message in the serial
(as in serial-processing, first-come-first-serve) mouse-input-translation
queue.
So to recap:
- Need to improve relative movement (to handle acceleration and mouse
speed modifiers)
- Need to change the code everywhere where you've been thinking that input
coordinates are the same as screen coordinates (most likely only within
SetCursorPos(), and SendInput()/NtUserSendInput())
- Absolute cursor placement inside SendInput() needs to be rewritten to
convert absolute input-space coordinates to absolute screen-space
coordinates (quite an easy change) using the algorithm I provide below,
which is what Windows uses internally.
- SetCursorPos() needs to COMPLETELY stop using SendInput() and instead
manipulate the cursor X/Y struct directly, or equivalent methods, instead
of injecting itself into the input queue. Alternatively, if it keeps using
the input queue, it needs a reverse-algorithm to turn the desired
screen-coordinates into virtual inputspace-coordinates, such as int
mouseinput_abs_x_or_y_pos = (((65536 * screen_x_or_y_pos) /
screen_width_or_height) + 1). The +1 is necessary for proper rounding.
However, I see no reason to use the input queue within this function as
that involves much more work than simply writing the cursor's location
directly (which is what SendInput EVENTUALLY gets around to doing after
LOTS of processing, and saving on cycles/jumps/calls is GOOD ;)).
All details on how to fix these things are in the below log. Let me know
if there's any questions.
Log (most unrelated discussions/events snipped and long breaks between
explaining different details have been separated with "..."):
19:56 Yewbacca . I am sure you've implemented SetCursorPos()
incorrectly. Checking your source code for it at cursor.c:280. This
function is SUPPOSED to take a SCREEN X/Y coordinate (ie X=1400, Y=800 on
a 1440x900 screen, and then moves the cursor location directly, without
emulating mouse movement.
19:57 Yewbacca . Instead, your version calls SendInput() with
the x/y unmodified, that's awful. SendInput()'s absolute space is a
virtual desktop square that stretches from 0-65535 in each direction and
will not even be remotely close to what the intended destination is.
19:57 _0_ . sounds like a patch is in order Yewbacca
19:57 _0_ . :P
19:58 +encoded . Yewbacca, file bug report!
19:58 Yewbacca . _0_ Well I'd have to know how you're writing
the cursor position inside NtSendUserInput etc.
19:58 Yewbacca . Or file a bug report, I'll do that.
20:01 Yewbacca . Related to this, Windows actually uses a
slightly unexpected algorithm for its SendInput() absolute-mode
coordinates-to-screen conversion.
20:01 Yewbacca . int destx_or_y = (screen_width_or_height *
x_or_y_abs_coord) / 65536
20:01 Yewbacca . If you want pixel precise SendInput() that
works as on windows you'd have to verify this. I'll bug report that too.
20:02 +encoded . <3 Yewbacca
20:02 Yewbacca . :)
20:02 +encoded . you can ofcourse see the source code of
NtSendUserInput
20:03 Yewbacca . Yeah I was about to check that to make sure
it's not already correct
20:04 +encoded . its in \subsystems\win32\win32k\ntuser\input.c
20:04 Yewbacca . Ah thanks, that saves a slow grep.
20:05 +encoded . wait opps
20:05 . garrythefish_
[n=fisher@unaffiliated/garrythefish] has joined #reactos
20:05 +encoded . oh well, nvm me
20:05 garrythefish_ . community choice award today. hope you guys
win. :D
20:10 Yewbacca . Okay after brief confusion I noticed that
IntMouseInput() contains the actual logic for mouse-type input to
SendInput(), input.c:1081. Time to check it.
...
20:14 Yewbacca . Okay now I'm really confused. I read through
IntMouseInput() from input.c:1081-1333 and unless I missed a call to a
driver-coordinates-to-screen-coordinates somewhere, this function is
miscoded as well. That'd mean that SetCursorPos() would work correctly
since SendInput() would work incorrectly, and that normal SendInput()
calls that expect a 0 to 65535 range would not work at all.
20:15 Yewbacca . It really seems to directly write the pointers
for cursor X and Y with the values it has received
20:15 Yewbacca . with no conversion whatsoever
20:15 Yewbacca . even though the incoming values are in a 0 to
65535 range
20:15 Yewbacca . of that virtual space
...
20:16 Yewbacca . Basically for anyone unfamiliar with it, the
driver implements a virtual space for the cursor to either move
relatively within, or absolutely, to allow things like touchscreens to
function easily (they'd just have to SendInput() their current position
as a percentage of the 65535 range).
20:16 Yewbacca . So all incoming absolute-mode coordinates must
be converted to screen coordinates, and microsoft does it with int
destx_or_y = (screen_width_or_height * x_or_y_abs_coord) / 65536
20:17 Yewbacca . I'm going to re-read it again to see if I
missed some conversion call. If not, that'll be 2 reports. Quite easy
fixes luckily.
20:18 +encoded . <3 Yewbacca
20:18 Yewbacca . I think the reason you got by this far is
because the HARDWARE mouse sends coordinates relatively
20:18 Yewbacca . The problem'd only appear with absolute input
like touchscreens. And since SendInput()'s absolute mode is broken that
means program's SetCursorPos() would work, so it's doubly broken and
would only cause problems for absolute hardware-input (again,
touchscreens mainly).
20:18 Yewbacca . :P
20:19 Yewbacca . Reading again
20:20 +encoded . Yewbacca, we can use someone like you who has
knowledge of windows internals
20:20 Yewbacca . Maybe, right now I'm tied up with some major
work :)
...
20:28 Yewbacca . Alright I've finished checking everything.
IntMouseInput() stretches from input.c:1081-1333 and is the function
that's called when NtUserSendInput()/SendInput() receives a mouse-type
event. At line 1140 it grabs the pointer to the cursor's X/Y struct with
IntGetCursorLocation(WinSta, &MousePos). Then we get to the significant
errors.
20:29 Yewbacca . At lines 1146-1150 it incorrectly writes the
virtual x/y of the INPUT coordinate system right into the memory holding
the SCREEN x/y cursor location
20:30 Yewbacca . At lines 1151-1155 it handles relative movement
but doesn't take into account cursor acceleration and movement speed
(those settings we all love in the control panel->mouse), which in turn
can increase the movement distance as much as 4 times the input value.
20:31 Yewbacca . Those two behaviours right there would need to
be patched. The first should determine the destination on the screen
through int destx_or_y = (screen_width_or_height * x_or_y_abs_coord) /
65536. The latter should implement handling for cursor acceleration
(check MSDN, it describes acceleration on SendInput()).
20:32 Yewbacca . And lastly, SetCursorPos() (forgot which file
it's in) needs to *completely* skip the SendInput() baloney that it's
doing right now (http://pastebin.com/d2db76985) and just directly grab
the cursor X/Y pointer and update it in a simple assignment, AFTER
checking that it's in range of course (otherwise clamping it to the
screen).
20:33 +Lone_Rifle . Yewbacca, suggest that you subscribe to ros-dev
and retype or copy-paste your findings there, it's quite a bit of text to
go through in one sitting
20:33 Yewbacca . Oh yeah and if you wanna be 100% complete, also
implement a check for ClipCursor() and don't allow the cursor to move
outside that, no matter if it's from hardware input or SetCursorPos(). If
it's outside, it should be clamped to the nearest inside value.
20:34 Yewbacca . Lone_Rifle Yeah, I agree and was going to
submit it. I'll do that now.
...
20:37 Yewbacca . Acceleration is described at
http://msdn.microsoft.com/en-us/library/ms646273(VS.85).aspx (info for
the MOUSEINPUT struct). I'll submit this log to the mailing list.
=EOF=