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