- Ros-dev - ReactOS.org

Re: [ros-dev] [ros-diffs] [sedwards] 40485: add telnet service, enable it by default
by WaxDragon 15 Apr '09

15 Apr '09

Those of us willing and able to help you test telnetd already are building rosapps. On Apr 15, 2009 2:13 AM, "Steven Edwards" <winehacker(a)gmail.com> wrote: On Tue, Apr 14, 2009 at 2:14 PM, Ged <gedmurphy(a)gmail.com> wrote: > Because we recently had a discus... Sure I agree with keeping down the build time but I thought we were going to implement a subset of build targets so the apps that make up the main distro would still be in the reactos checkout. If there is consensus that telnetd should be disabled or set to manual then I'll turn it off. Otherwise my plan was to leave it on until we reach 0.4 in the hopes that people would stress it out and help me develop it. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an id... Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev

2 1

Re: [ros-dev] [ros-diffs] [dchapyshev] 40480: - Add more check on CodePage = 0. +2 passed wine tests
by Aleksey Bragin 13 Apr '09

13 Apr '09

Shouldn't it have only the return STATUS_UNSUCCESSFUL; changed to return STATUS_INVALID_PARAMETER; in the original version? I doubt IsValidCodePage should return true for a 0 codepage. WBR, Aleksey Bragin. On Apr 13, 2009, at 4:33 PM, dchapyshev(a)svn.reactos.org wrote: > Author: dchapyshev > Date: Mon Apr 13 16:33:33 2009 > New Revision: 40480 > > URL: http://svn.reactos.org/svn/reactos?rev=40480&view=rev > Log: > - Add more check on CodePage = 0. +2 passed wine tests > > Modified: > trunk/reactos/subsystems/win32/csrss/win32csr/conio.c > > Modified: trunk/reactos/subsystems/win32/csrss/win32csr/conio.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/ > win32/csrss/win32csr/conio.c?rev=40480&r1=40479&r2=40480&view=diff > ====================================================================== > ======== > --- trunk/reactos/subsystems/win32/csrss/win32csr/conio.c > [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/csrss/win32csr/conio.c > [iso-8859-1] Mon Apr 13 16:33:33 2009 > @@ -3023,12 +3023,20 @@ > > Request->Header.u1.s1.TotalLength = sizeof(CSR_API_MESSAGE); > Request->Header.u1.s1.DataLength = sizeof(CSR_API_MESSAGE) - > sizeof(PORT_MESSAGE); > - if (IsValidCodePage(Request- > >Data.SetConsoleOutputCodePage.CodePage)) > + if (Request->Data.SetConsoleOutputCodePage.CodePage == 0) > + { > + ConioUnlockConsole(Console); > + return STATUS_INVALID_PARAMETER; > + } > + else > + { > + if (IsValidCodePage(Request- > >Data.SetConsoleOutputCodePage.CodePage)) > { > Console->OutputCodePage = Request- > >Data.SetConsoleOutputCodePage.CodePage; > ConioUnlockConsole(Console); > return STATUS_SUCCESS; > } > + } > ConioUnlockConsole(Console); > return STATUS_UNSUCCESSFUL; > } >

1 0

Re: [ros-dev] [ros-diffs] [sedwards] 40481: move telnetd to main tree, not enabled yet
by Ged 13 Apr '09

13 Apr '09

Why? Do we really need a telnet server in trunk? -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of sedwards(a)svn.reactos.org Sent: 13 April 2009 14:29 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [sedwards] 40481: move telnetd to main tree, not enabled yet Author: sedwards Date: Mon Apr 13 17:29:21 2009 New Revision: 40481 URL: http://svn.reactos.org/svn/reactos?rev=40481&view=rev Log: move telnetd to main tree, not enabled yet Added: trunk/reactos/base/services/telnetd/ (props changed) - copied from r40480, trunk/rosapps/applications/sysutils/telnetd/ Modified: trunk/reactos/boot/bootdata/packages/reactos.dff Propchange: trunk/reactos/base/services/telnetd/ ------------------------------------------------------------------------------ svn:mergeinfo = Modified: trunk/reactos/boot/bootdata/packages/reactos.dff URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/packages/rea… ============================================================================== --- trunk/reactos/boot/bootdata/packages/reactos.dff [iso-8859-1] (original) +++ trunk/reactos/boot/bootdata/packages/reactos.dff [iso-8859-1] Mon Apr 13 17:29:21 2009 @@ -670,7 +670,6 @@ modules\rosapps\applications\sysutils\pedump\pedump.exe 1 optional modules\rosapps\applications\sysutils\regexpl\regexpl.exe 1 optional modules\rosapps\applications\sysutils\tcat\tcat.exe 1 optional -modules\rosapps\applications\sysutils\telnetd\telnetd.exe 1 optional modules\rosapps\applications\sysutils\tlist\tlist.exe 1 optional modules\rosapps\applications\sysutils\screenshot\screenshot.exe 1 optional modules\rosapps\applications\sysutils\utils\binpatch\binpatch.exe 1 optional

1 0

Year 2038 problem
by Javier Agustìn Fernàndez Arroyo 12 Apr '09

12 Apr '09

Hi all, i hope you have already taken into account this: http://en.wikipedia.org/wiki/Year_2038_problem Regards, Javier

7 10

Re: [ros-dev] [ros-diffs] [cgutman] 40471: - Don't close the connection handle and dereference the connection object when we run out of memory because it will cause a crash when AfdCleanupSocket tries to do the same - Fixes bug 4362
by Aleksey Bragin 12 Apr '09

12 Apr '09

On Apr 12, 2009, at 9:07 AM, cgutman(a)svn.reactos.org wrote: > - /* Is this correct? */ > - TdiCloseDevice( FCB->Connection.Handle, > - FCB->Connection.Object ); Turned out it was not :)

1 0

Downloader tool
by Ged 11 Apr '09

11 Apr '09

I think we should make an exception for the downloader tool and move it out of rosapps into the main source. I think the argument for having it in there would exceed the argument against. Any thoughts?

10 13

Alexandre Julliard : include: Update and document the TEB/ PEB offsets on 64-bit.
by James Tabor 10 Apr '09

10 Apr '09

http://www.winehq.org/pipermail/wine-cvs/2009-April/054575.html LOL with tears, The accuracy of this will kill your research and give you a headache. It is so sad for a professional to commit and propagate misinformation, it smacks of counterintelligences. I'm starting to feel sorry for that project. It's not a state secret to match what is published as a standard from microsoft. 8^( James

3 3

Re: [ros-dev] [ros-diffs] [fireball] 40430: - Make it possible to assign drive letters to all partitions, not only to the first partition of a primary partition table. - Make AssignDriveLetters in partlist.c to actually assign drive letters to all partitions found (the list corresponds to how Windows 2003 install CD assign driver letters, but more investigation would not hurt). - Make CheckActiveBootPartition actually search for partition with a boot flag, instead of hardcoding it to partition 0 of disk 0.
by Aleksey Bragin 10 Apr '09

10 Apr '09

It's a stoneage "bug", which was present from the very beginning of ReactOS's installer (usetup) - it read, recognized and could be installed only on the first primary partition. Now, after my today's commits it recognizes and could be installed to any primary partition. Extended partitions logic was not changed, was not tested and hopefully didn't regress (if it was existing at all). However, there is still a bug preventing booting ReactOS from non- first partition, probably due to incorrect freeldr.ini. Everyone is welcome to have a look and try to fix it. Also, very important, don't use create/delete partition functionality - it's good only to create or delete only one primary partition. If you use it with multiple primary partitions, it's gonna mess up everything. Again, patches are welcome. WBR, Aleksey Bragin. On Apr 9, 2009, at 10:59 PM, fireball(a)svn.reactos.org wrote: > Author: fireball > Date: Thu Apr 9 22:59:28 2009 > New Revision: 40430 > > URL: http://svn.reactos.org/svn/reactos?rev=40430&view=rev > Log: > - Make it possible to assign drive letters to all partitions, not > only to the first partition of a primary partition table. > - Make AssignDriveLetters in partlist.c to actually assign drive > letters to all partitions found (the list corresponds to how > Windows 2003 install CD assign driver letters, but more > investigation would not hurt). > - Make CheckActiveBootPartition actually search for partition with > a boot flag, instead of hardcoding it to partition 0 of disk 0. > - Fix SetMountedDeviceValues to take multiple partitions in a > partition table into account. > - Fix Select Partition, Format Partition, Check File System, Delete > Partition interface page to take partition number into account. > - IMPORTANT: Create/Delete partitions must not be used to > repartition the harddrive! They can only be used to create/delete > an initial primary partition on a clean harddisk. > > Modified: > trunk/reactos/base/setup/usetup/interface/usetup.c > trunk/reactos/base/setup/usetup/partlist.c > trunk/reactos/base/setup/usetup/partlist.h

2 1

Re: [ros-dev] [ros-diffs] [fireball] 40428: - Recognize up to 4 partitions inside every primary partition table. However, installation will be performed to the first partition anyway.
by Steven Edwards 09 Apr '09

09 Apr '09

On Thu, Apr 9, 2009 at 8:42 AM, <fireball(a)svn.reactos.org> wrote: > Author: fireball > Date: Thu Apr 9 16:42:09 2009 > New Revision: 40428 > > URL: http://svn.reactos.org/svn/reactos?rev=40428&view=rev > Log: > - Recognize up to 4 partitions inside every primary partition table. However, installation will be performed to the first partition anyway. How is this going to work for GPT disks? I am not quite sure about how the bootcamp emulation does its magic. Logically it seems to me the BSD slice would seem to be the first partition and bootcamp would show up as partition 2. Are we not going to be able to do this? 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

2 1

Brainstorming about testing team, roadmap and ReactOS usability
by Aleksey Bragin 09 Apr '09

09 Apr '09

Hi, I had a chat with Olaf a few days ago, regarding a few issues, and we thought it would be beneficial to bring them up for collective brainstorming. Background information: In the past and nowadays work in ReactOS is getting done "as it flows". E.g. if we get developers, who wanted to implement sound support, would do it, and we advertise this in a release. Or, like Evgeniy Boltik who shows a nice cooperation with Timo, Jim and Ged on fixing various nasty palette and drawing issues which were not touched for a few years, often fixing errors introduced in revisions like 1000 or 4000. There is no central plan, just a very rough roadmap, mainly relatively short-term. Same applies to testing team: we usually perform testing when an obvious problem occurs, in our very well known apps list, which someone remembers to work in a certain revision. If that's known to regress, Olaf usually organizes a regression-testing, a guilty revision is found, and problem hopefully gets fixed. All of this is very good, for an operating system which is developed just for the sake of development: noone sets any milestones, noone demands to meet them. And noone pays for achieving them either. But when Linux got a real spin-off? An answer is: when it aimed to become useful for the most needed application - as a platform to run a web server and a mail server. http://en.wikipedia.org/wiki/ Linux_adoption says that in 2001 Linux servers experienced 15% annual growth rate, and by 2004 50% of the worldwide blade servers are shipped with Linux-based OS. This was preceded by hard work of a number of people, like Andrew Morton. Who aimed not just at gettign more and more features, but more at getting existing code as stable as it's possible. That included going through all the issues people reported, asking them to provide more info if needed, finding the actual bug, fixing it, asking them to retest... At some point all most frequently encountered bugs were fixed, and potential Linux usage base extended substantially. For ReactOS, we have different aims, but we could use this strategy now, when core parts of our operating system are becoming feature- complete and mostly need debugging, and when we finally are getting very close to going Beta. This involves, first of all, getting hardware support at a decent level. From a billion of personal computers in the world, we could easily support the most common hardware without need to develop complex drivers or different HALs. Even SATA would not really be a strong requirement, since most of PCs have IDE compatibility mode, which many non-technical people even forget to switch to "SATA" mode in the BIOS when installing their Windows OS! Again Linux's philisophy could help us: they are proud that their hardware is Linux- compatible, while we are embarrased that "our OS doesn't support specific hardware". Feel the difference. Some good step in this direction is this wikipage: http:// www.reactos.org/wiki/index.php/Supported_Hardware/Network_cards Next, software. We have a unique situation when our OS targets a vast amount of WinAPI compatible software. There is a lot of bugs in our Win32 subsystem, however if we can find a set of apps we support right now, or find common software which we could easily support - it should be our "road ahead". Now back to what I started writing this email about. I was speaking with Olaf and Klemens about the software compatibility database. Existing "Support Database" is not used by people, and not liked by most of our developers and testers because it takes more time to file an entry into that database than to actually install ReactOS and test the app. Another problem is that community-driven database won't work since we can't confirm people's data. What we thought would work good so far is a list of working apps. As Olaf said: "it'll be ugly, not scientifically statistically fine, crude comparing to wine appdb and limited. Bit it can be done". The amount of text to enter for an app entry must be as minimal as possible: app name, platform (real hardware, emulator), bug number in bugzilla for possible issues (max. 2 bugs for one entry). Also, no division for "installs, but doesn't start" or "works only via manual installation". Either it works, or it doesn't, no intermediate stages. As we thought later, it may even be just three columns: appname, ROS revision, Comments. A wikipage could suit this need, but if necessary, we could think further of some web-app. I think that's enough for one email, I'll be glad to listen to comments and more ideas. Everyone is welcome to take part in the discussion. With the best regards, Aleksey Bragin.

5 8

Re: [ros-dev] Ros-dev Digest, Vol 56, Issue 8
by Olaf Siejka 08 Apr '09

08 Apr '09

I`ll participate in testing team, no matter what shape or methode will be chosen, this is above discussion. The approach should be discussed though. In the years i`ve been with ROS, we had a remarkable increase in stability, from the point when you had to be careful to finish up the planned test, so ReactOS doesnt hang in the process, to the point when you actually have to try hard to crash it. Certainly, we are stilll miles from being rock solid, but the progress has been made. We have one primary problem with our project: too many problems at the same time. Its not only stability (with Mm, Cc and vfat issues) or hardware support (unimplemented PnP and HAL, busted resource reporting), or Win32 subsystem issues Timo has pointed. At the same time we have problems with WINE userland and their approach to implementation, general code untidyness, header mess, miriads of old and often undocumented hacks, on which future assumptions were made, rbuild/compiler issues, lack of decent debugging tools, general lack of manpower in all areas, lack of standarised testing platform as well as problems determining our future goals or attracting more publicity. I think you could add a bunch more. You know what? We try to solve all of those problems at once. And yet we are unable to finish off a single one.

2 1

Re: [ros-dev] [ros-diffs] [gschneider] 40418: - Offset coordinates with viewport origin for gradient filled triangular and rectangular shapes
by Timo Kreuzer 08 Apr '09

08 Apr '09

The DC origin is in device coordinates and should be the last translation. gschneider(a)svn.reactos.org schrieb: > Author: gschneider > Date: Wed Apr 8 20:53:21 2009 > New Revision: 40418 > > URL: http://svn.reactos.org/svn/reactos?rev=40418&view=rev > Log: > - Offset coordinates with viewport origin for gradient filled triangular and rectangular shapes > > Modified: > trunk/reactos/subsystems/win32/win32k/objects/fillshap.c > > Modified: trunk/reactos/subsystems/win32/win32k/objects/fillshap.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/ob… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/objects/fillshap.c [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/objects/fillshap.c [iso-8859-1] Wed Apr 8 20:53:21 2009 > @@ -907,6 +907,8 @@ > > DitherOrg.x = dc->ptlDCOrig.x; > DitherOrg.y = dc->ptlDCOrig.y; > + IntLPtoDP(dc, (LPPOINT)&DitherOrg, 1); > + > Extent.left += DitherOrg.x; > Extent.right += DitherOrg.x; > Extent.top += DitherOrg.y; > > >

1 0

Brainstorming about testing team, roadmap and ReactOS usability
by victor martinez 08 Apr '09

08 Apr '09

First of all sorry because i dont have idea how to follow a thread when answering one post. And i didnt find any info about how to do that :) Now about the Topic: Some days ago I made one Wiki Page which ( I hope) could be useful for Testing purposes. It was created just to share suggestions among Devs and Testers about it. Here it´s: http://www.reactos.org/wiki/index.php/Testing_Central The idea is to have a Main Testing page which leads to proper Bugzilla reports, (as an online newspaper which sums up the info in Headers and clicking on them redirects to Full description),also it can help to have info of the same App together so we can track working/no working Apps instead working/no working Bugs(which is Bugzilla Work). To sum up the Wiki page is divided in 3 sections: 1)Testing Apps: In an easy way we can find which Bugs are preventing the Apps working, and easily redirect to the Bugzilla reports. I think this is (almost) Aleksey proposal. The table has the following Cols: Tester Name, App Name,Revision,4 columns for the 3 VM+RH, Bug Installing,Bug Working. 2)Developer Request: This is a Post-it Table. Here any Dev can write any request (related with testing),so it creates a small TODO list for Testers. Of course it can link to other Wikipages. (i.e : Aicom request about testing Network cards fits here) I have seen a lot of Dev requests in Bugzilla (i.e: "please test this TestBox", or "please test more Apps which uses Pipes", etc...), there isnt any search option to find these requests in Bugzilla, so this Table could track them. The table has the following Cols: DEV,Request,Application/TestBox,Way of Testing,Tester, LRT (Last Revision Tested),RESULT 3)Regression Testing: When a Regression is found a Regression Search begins, or maybe not..because the Tester/Dev doesnt have time enough to begin with it. To avoid losing this info the Regression Testing Table is created, you can fill it with a Regression you have found and other testers can work in it. But the main objective is to Coordinate efforts among Testers, so in Real Time Testers who are performing a regression test doesnt waste time: Testers can see which Revisions are being tested and which is the current Gap so they can guess which is the best revision to test. Also if one Regression Search (by any chance or missing builds ;) ) was left without finding the guilty revision,we will have a GAP for future testing. The table has the following Cols: Name,Regression,4 columns for the 3 VM+RH,Works Rev,Fails Rev,Current Testing. Any comments,suggestions,or criticisms are wellcome. For a full detailed description visit the Wiki page :)..it´s just a prototype and of course un-official. Víctor Martínez Calvo vicmarcal _________________________________________________________________ El nuevo Windows Live te une a los que más quieres http://www.windowslive.es

1 0

Different repository for web stuff
by Aleksey Bragin 07 Apr '09

07 Apr '09

Hi, how about using a different repository for all web-specific stuff we have? Vendor drops of web apps, whole trunk/web, etc. All of these are totally unrelated (in terms of repository-internal relations) with the actual OS components. Current situation went from long time ago when there was only one repository possible. It's been a long time since we migrated to svn:// svn.reactos.org/repostiory/... path, so it's possible now. rosweb, or web could be a name for a new one. Comments are welcome. WBR, Aleksey Bragin.

7 14

Re: [ros-dev] Different repository for web stuff
by WaxDragon 06 Apr '09

06 Apr '09

+1 I'd like to see all the non-OS stuff put in a separate repository, including the promotional stuff in /media. WD On Apr 6, 2009 11:36 AM, "Aleksey Bragin" <aleksey(a)reactos.org> wrote: Hi, how about using a different repository for all web-specific stuff we have? Vendor drops of web apps, whole trunk/web, etc. All of these are totally unrelated (in terms of repository-internal relations) with the actual OS components. Current situation went from long time ago when there was only one repository possible. It's been a long time since we migrated to svn:// svn.reactos.org/repostiory/... path, so it's possible now. rosweb, or web could be a name for a new one. Comments are welcome. WBR, Aleksey Bragin. _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev

1 0

Re: [ros-dev] [ros-diffs] [fireball] 40368: - Compile UniATA with stdcall default calling convention instead of cdecl.
by Alex Ionescu 05 Apr '09

05 Apr '09

Please don't do this. -MRTD has NOTHING to do with stdcall and has been broken since gcc 2.9.5 Best regards, Alex Ionescu On Sun, Apr 5, 2009 at 7:46 AM, <fireball(a)svn.reactos.org> wrote: > Author: fireball > Date: Sun Apr 5 15:46:53 2009 > New Revision: 40368 > > URL: http://svn.reactos.org/svn/reactos?rev=40368&view=rev > Log: > - Compile UniATA with stdcall default calling convention instead of cdecl. > > Modified: > trunk/reactos/drivers/storage/ide/uniata/uniata.rbuild > > Modified: trunk/reactos/drivers/storage/ide/uniata/uniata.rbuild > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/storage/ide/uniata… > > ============================================================================== > --- trunk/reactos/drivers/storage/ide/uniata/uniata.rbuild [iso-8859-1] > (original) > +++ trunk/reactos/drivers/storage/ide/uniata/uniata.rbuild [iso-8859-1] Sun > Apr 5 15:46:53 2009 > @@ -4,6 +4,7 @@ > <bootstrap installbase="$(CDOUTPUT)" /> > <include base="uniata">.</include> > <include base="uniata">inc</include> > + <compilerflag>-mrtd</compilerflag> >  > <library>ntoskrnl</library> > <library>hal</library> > >

1 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 40306: win32k brush update: - fix EBRUSHOBJ_vSetSolidBrushColor - Initialize text and background brush in DC_AllocDC - Update the DCs EBRUSHOBJs on demand - Use the DCs EBRUSHOBJs for drawing where appropriate This makes things faster and finally adds support for DC_BRUSH and DC_PEN
by Aleksey Bragin 05 Apr '09

05 Apr '09

Evgeniy Boltik complains that EBRUSHOBJ_vInit is necessary because it has something to do with changing brush color or palette. He's going to file a bug about it in BZ. WBR, Aleksey Bragin. On Apr 1, 2009, at 5:49 AM, tkreuzer(a)svn.reactos.org wrote: > Author: tkreuzer > Date: Wed Apr 1 05:49:18 2009 > New Revision: 40306 > > URL: http://svn.reactos.org/svn/reactos?rev=40306&view=rev > Log: > win32k brush update: > - fix EBRUSHOBJ_vSetSolidBrushColor > - Initialize text and background brush in DC_AllocDC > - Update the DCs EBRUSHOBJs on demand > - Use the DCs EBRUSHOBJs for drawing where appropriate > This makes things faster and finally adds support for DC_BRUSH and > DC_PEN > > - EBRUSHOBJ_vInit(&dc->eboLine, pbrushPen, dc->rosdc.XlatePen); > - > - EBRUSHOBJ_vInit(&BrushInst, pbrush, DCDest- > >rosdc.XlateBrush);

1 0

Re: [ros-dev] [ros-diffs] [fireball] 40363: Evgeniy Boltik <bstsoft@narod.ru> - Enable and use mask support in UserDrawIconEx, fully compatible with Windows, based on tests in bug 4336. - Remove IntSet[Text/Bk]Color hacks from UserDrawIconEx, no longer required due to fix in CreateCompatibleDC. - Change a few comments in the code of UserDrawIconEx. See issue #4336 for more details.
by Aleksey Bragin 04 Apr '09

04 Apr '09

That was from bug 4294, and test app was in bug 4294 too. WBR, Aleksey Bragin. On Apr 4, 2009, at 10:52 PM, fireball(a)svn.reactos.org wrote: > Author: fireball > Date: Sat Apr 4 22:52:14 2009 > New Revision: 40363 > > URL: http://svn.reactos.org/svn/reactos?rev=40363&view=rev > Log: > Evgeniy Boltik <bstsoft(a)narod.ru> > - Enable and use mask support in UserDrawIconEx, fully compatible > with Windows, based on tests in bug 4336. > - Remove IntSet[Text/Bk]Color hacks from UserDrawIconEx, no longer > required due to fix in CreateCompatibleDC. > - Change a few comments in the code of UserDrawIconEx. > See issue #4336 for more details.

1 0

Partitions support in usetup
by Aleksey Bragin 02 Apr '09

02 Apr '09

Hi, I researched my partition problem (in my hardware setup, I have an IDE harddisk, which has 3 primary partitions, and I don't want to use the first partittion), and sharing my findings. So far, kernel and drivers have all necessary support and the problem is in usetup directly. Right now, it stores information about partition tables in a linked list of PARTENTRY structures, and displays ONLY the information about the first out of 4 possible partititions in that entry. I checked with Windows 2003 installation CD, it showed me all my partitions as they are, without limiting me anyhow. And certainly it allows installation on any of those partitions. Anyone volunteers to fix this problem properly? WBR, Aleksey Bragin.

3 2

Google Summer of Code
by Aleksey Bragin 02 Apr '09

02 Apr '09

Hi, I'd like to let you know our application has not been accepted into Google Summer of Code, for the third time in a row. I attached an (autogenerated) reply, which encourages us to reapply for future instances of the program. I would not find a better way to express sarcasm than asking us to reapply in future. Amongst accepted organizations there are: WinLibre - a distribution of opensource software for Windows platform. Battle for Wesnoth - a free turn based strategy game. Umit - a frontend for a network scanner (one of their GSoC ideas is to create a "Umit Assistant" which would look like a Clippit - the animated assistant that features Microsoft Office). TurboGears - a web framework written in Python. Thousand Parsec - a bunch of games based on a common framework for building turn based space empire building games. Systers: Woman in computing - a community of women in computing. For some strange reason the founding person is "Robin". Singularity Institute for Artificial Intelligence - non-profit org founded to develop safe artificial intelligence software and to raise awareness of dangers of AI technologies. I just stated a few examples. I highly value those projects, however I just can't understand that yet another framework in python, or a game engine for a turnbased strategies, or a collection of FOSS software for Windows with a package manager (which we already have, and which could have been improved), or an institution which believes that AI takes over the world and tries to stop that are way more important than supporting an organization whose product would be of use for millions of people, and would create a real alternative operating system compatible with the vast majority of existing software and hardware. Our friendly OS project Haiku gets accepted every year, so being an OS is not a problem. Wine is certainly accepted every year from the beginning, and this year is not an exception. So it's definately not a problem of "legal fear" of Microsoft. What is the problem then? I leave it to you to decide what's the problem. However, as for me, I see Google Summer of Code is nothing close to supporting free software world, but rather an expensive way of advertising. I want to hope I am wrong. With the best regards, Aleksey Bragin ReactOS Foundation President. ---------- Forwarded message ---------- From: <socghop.noreply(a)gmail.com> Date: Thu, Mar 19, 2009 at 12:48 AM Subject: Thank you for your application To: xxx(a)reactos.org Hi Aleksey Bragin, Thank you for submitting "ReactOS" organization application to Google Summer of Code 2009. Unfortunately, we were unable to accept your organization's application at this time. We received many more applications for the program than we are able to accommodate, and we would encourage you to reapply for future instances of the program. Best regards, Google Open Source Programs

7 10

Re: [ros-dev] [ros-diffs] [jimtabor] 40305: - Implement NtUserProcessConnect. Moving to client information format for User32. PPROCESSINFO and PTHREADINFO are references not user land structures. - Added and removed structure types. - Tested with old
by James Tabor 02 Apr '09

02 Apr '09

Hi! Fixed in 40308! Thanks, James On Tue, Mar 31, 2009 at 8:59 PM, Timo Kreuzer <timo.kreuzer(a)web.de> wrote: > These are already in win32k/include/desktop.h >

1 0

debug builds
by Gabriel ilardi 01 Apr '09

01 Apr '09

Hi everyone, Lately I wanted to use latest debug builds to do some testing but they weren't yet available, can't we upload them before doing the tests? This way they'd be ready sooner for us to use... Regards, Gabriel. _________________________________________________________________ Quante ne sai? Scoprilo con CrossWire! http://clk.atdmt.com/GBL/go/140630367/direct/01/

1 0

Re: [ros-dev] [ros-diffs] [jimtabor] 40305: - Implement NtUserProcessConnect. Moving to client information format for User32. PPROCESSINFO and PTHREADINFO are references not user land structures. - Added and removed structure types. - Tested with old AbiWord, FireFox and explorer.
by Timo Kreuzer 01 Apr '09

01 Apr '09

These are already in win32k/include/desktop.h jimtabor(a)svn.reactos.org schrieb: > /* PRIVATE FUNCTIONS **********************************************************/ > + > +PVOID > +FASTCALL > +DesktopAlloc(PDESKTOP DesktopObject, SIZE_T Size) > +{ > + return RtlAllocateHeap(DesktopObject->pheapDesktop, HEAP_NO_SERIALIZE, Size); > +} > + > +BOOL > +FASTCALL > +DesktopFree(PDESKTOP DesktopObject, PVOID HeapBase) > +{ > + return RtlFreeHeap(DesktopObject->pheapDesktop, HEAP_NO_SERIALIZE, HeapBase); > +} > >

1 0

Wine syncing process
by Aleksey Bragin 31 Mar '09

31 Mar '09

Hello, I'd like to improve the existing situation we have with Wine syncing. Right now, we have a group of people, occasionally doing Wine syncs, and that group of people included me some time ago too. However, date was never really specified, and syncing happens "when someone wants to sync", "before releasing", or when something is fixed in Wine and we import that code. How it should happen (in my opinion). All non-forked DLLs, tools and programs must be synced after each Wine minor release. This is going to be manual process, so we need a person to organize this process, and a few people who could participate in doing actual work (syncers). What this "team" leader / responsible person should do: * Share the work (modules) between syncers. * Leave hard-to-sync modules to experienced developers and himself. * Ensure all syncers are instructed to do basic testing (running our "golden" list of apps - FireFox, AbiWord, mIRC, and testing ole32/ rpcrt4/widl with a real app which uses OLE mechanism) before committing the work. * Be aware about syncing dependencies (e.g. when syncing widl, it makes sense to sync rpcrt4 simulteneously) * Be aware about problematic syncs (like icmp.dll sync, which possibly introduces memory corruption, and which is still not fixed in Wine). * Keep a log of what has been synced, what has not, keep a note of all problems. If that proves to work good, this team may be officially announced as "wine syncing team". There are already at least two successfully working teams this way: Bugzilla maintaining (with Amine being the maintainer, and my point of contact when I want to complain or ask about something), and Testing team (with Olaf being often my point of contact, and organizing and doing all the hard work of regress testing, testing apps, drivers, real hardware testing and getting results submitted). Also, I think those two teams cooperate the best. I wish we could expand this idea to the Wine syncing team, and get it to work that smoothly too, and that cooperative too. With the best regards, Aleksey Bragin.

5 6

Re: [ros-dev] [ros-diffs] [jmorlan] 40289: Make cmd able to (sort of) work without a console.
by Steven Edwards 30 Mar '09

30 Mar '09

Hi! 2009/3/29 <jmorlan(a)svn.reactos.org>: > Author: jmorlan > Date: Sun Mar 29 23:17:45 2009 > New Revision: 40289 > > URL: http://svn.reactos.org/svn/reactos?rev=40289&view=rev > Log: > Make cmd able to (sort of) work without a console. Thanks! I am now able to run telnetd and connect in to my ReactOS VM. Certain applications such as ctm don't seem to like running without a console due to making calls to GetConsoleMode. I am going to test telnetd on Windows with Windows cmd.exe and ReactOS cmd.exe to compare behavior of these applications. Its possible cmd.exe returns some bogus console mode or something when running without a console. 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

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev