ReactOS.Bugzilla(a)reactos.org wrote:
>http://www.reactos.org/bugzilla/show_bug.cgi?id=1326
>
> Summary: Ctrl+Alt+Del has no effect
> Product: ReactOS
> Version: 0.2.9
> Platform: x86 Hardware
> OS/Version: ReactOS
> Status: NEW
> Severity: normal
> Priority: P3
> Component: Kernel
> AssignedTo: ros-bugs(a)reactos.org
> ReportedBy: the_real_martian(a)msn.com
> QAContact: ros-bugs(a)reactos.org
>
>
>When Ctrl+Alt+Del is pressed, there is no effect. This can really get annoying
>if a program is not responding, and you have to right-click the taskbar to open
>Task Manager.
>
>
>
There is a hotkey meta bug please make this a dependency
.
Brandon
I was wondering if there was any plan on implementing Intel's EFI in
the near or distant future. I hear that Intel wants to move away from
BIOS and work more closely with EFI. I know that support for the BIOS
will never totally disappear but EFI is a better architecture in my
opinion.
So here is my request for EFI support in ReactOS.
I had this same problem when developing my bootsector. When I reset the
bootdrive before I jumped to freeldr the problem went away. I think that
the first thing that freeldr needs to is to reset the boot drive before
it moves on.
ReactOS.Bugzilla(a)reactos.org wrote:
> http://www.reactos.org/bugzilla/show_bug.cgi?id=390
>
>
>
>
>
> ------- Additional Comments From simona(a)informatik.tu-muenchen.de 2006-02-25 00:17 CET -------
> got the same problem with the boot cd 2.9 on a travelmate 290.
> shoud be the same hardware and the same crappy "insyde software" bios (v2.0 on
> my chip):
> Press any key to boot from CD <enter>
>
> Failed to read the PVD.
> Press any key
> Failed to read the super block.
> Press any key <enter>
> Failed to read boot sector.
> Press any key <enter>
> Failed to read boot sector.
> Press any key <enter>
> Unable to locate boot parition
>
> Press any key <enter>
> Error opening boot partition for file access. <enter>
>
> Press any key to boot from CD
>
> And so on...
> Notice that one time the any-key message appears without waitig for any key.
>
> And, after the first "round" it waits way shorter for any keypress to boot
> from CD (the time between two dots printed has decreased).
> I experienced this problem with the first LiveCD version i tried (2.0 i
> think).
>
>
Brandon Turner wrote
>
> " B - Sections of ReactOS which require auditing are
> 'locked', that being
> that the source is fully available to download and build, but no
> development work should be undertaken until the said code has
> passed the
> audit. The lock will be removed only when that section of
> code has been
> audited."
>
> I have asked 3-4 times but still havent got an answer as far
> as I can tell. Does the definition of "audit" in the pharse
> mean the code needs to be looked through and documented and
> bad code be marked. Or does it mean all that and the marked
> code needs to be rewritten for it to be considered "audited".
Here is my understanding (although I'm not saying it's correct)
First of all, we must take the authors word on whether something needs
auditing or not.
If a particular author says the code which he wrote is clean, then this
automatically bypasses the audit.
This clears up James' worry about his dll code which he has declared clean.
If an author can't be contacted, it is classes as unknown and must go
through the audit process.
Once we have a list of all code which has not been verified, a new SVN user
is generated and he is used to lock all the code (this is done with a
separate user to avoid certain features of SVN lock)
Any developer is able to remove a lock. Locking the code only really acts as
a reminder that the code has not passed an audit. This code shouldn't be
modified / improved until it has done so. The lock therefore ensures all the
code is audited and nothing is missed. It also acts as an incentive to get
the code audited.
Without the lock, I think it will be conveniently forgotten about.....
Once code has been locked how does it get out of locked status?
I think there are 3 possibilities:
- look through the code looking for anything even remotely strange. (I think
Alex's description which I have linked to the end of this mail makes some
good points). If all the code seems perfectly legitimate, it passes the
audit and the lock is removed.
- If code doesn't seem legitimate, search for documentation. If docs are
found to cater for all the questionable code, the docs are added and the
code passes audit.
- If the code doesn't seem legitimate and docs can't be found, then the code
is deemed dirty and further action must be taken (e.g. part of the code
rewritten, all the code rewritten, docs written, etc). This would have to be
discussed at greater length.
HTH
Ged.
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
Vote topic : Ensure code auditing is carried out
Start date : 16/02/06
Period : 7 days discussion, 7 days voting
With the success of proposal B in the recent vote and the old repository
reopening for business, we need to discuss ways to ensure the code is
audited and doesn't take a backseat.
Following the correct voting procedure, there will be a 7 day discussion
period, followed by a 7 day voting period.
Until this decision is made, I propose for the repository to be fully
open, with developers being diligent with their actions.
This topic has been discussed somewhat between developers, although not
extensively.
Two viable proposals have so far been put forward and are as follows :
A - The repository is completely open to all development and ReactOS
developers must take it upon themselves to ensure all code is audited.
B - Sections of ReactOS which require auditing are 'locked', that being
that the source is fully available to download and build, but no
development work should be undertaken until the said code has passed the
audit. The lock will be removed only when that section of code has been
audited.
Discussion of these topics and any further proposals should be in reply
to this topic.
How do we feel about having the documentation directory from the casper
tree (the one where audit documentation is being written) moved to
svn://svn.reactos.ru/reactos/trunk/documentation?
--
Discordant is the murmur at such treading down of lovely things while
god's most lordly gift to man is decency of mind. Call that man only
blest who has in sweet tranquility brought his life to close.
If only I could act as such, my hope is good.
-- Aeschylus' Agamemnon (translated by H. W. Smyth)
At
http://www.reactos.org/pipermail/ros-dev/2006-February/007878.html
and on other places there is mentioned, that the way to audit is, to look at
the ReactOS-Source-Code, look if it looks understandable.
The problem is, that is possible, that people disasseble MS-Windows-code and
port then the Assembler-Code in stupid C code.
And - because (not clean room) reverse engineering isn't allowed - all
code, which looks stupd will be eliminated.
That was also discussed in a german forum. There someone have at
http://www.heise.de/newsticker/foren/go.shtml?read=1&msg_id=9920469&forum_i…
discribed, how a normal C program can be compiled to assebler code and an
other people create stupied C code, where you can see, that it was reverse
engineered.
But in the same forum, someone have mentioned, that there existing
decompiler like Boomerang
http://boomerang.sourceforge.net/
which creates from binary code logical, easy to read C code. (Don't know
before, that something like this exists).
Have a look at
http://boomerang.sourceforge.net/cando.php
I want with this mail only to say, that it would be very hard to find the
reverse engineered code (if there existing one).
Greatings
theuserbl
martinf(a)svn.reactos.org wrote:
> fix build with _ROS_ define
>
>
> Updated files:
> trunk/reactos/base/shell/explorer/shell/mainframe.cpp
>
Hi,
Should you move your changes to the new svn?
Thanks,
James
Through an intriguing article on Slashdot I have read that ipods are
now being used for things other than audio. They are being used to
obtain data from a computer, and computer network obtaining business
documents and such in seconds.
One way to make ReactOS a safer operating environment is to use a
virtual encrypted file system that would restrict the copying of
files to any usb, or network device via an encryption algorithm. So I
propose a VEFS that would restrict this. The VEFS would disallow the
passage of documents to any removable device unless the user has
permission to archive them, which would be the "a" attribute. The
VEFS would make use of two AES encryption algorithms which would
encrypt the file's contents. One being a key another a lock, however
the user must provide a password to unlock and decrypt the files.
This would allow the user to unlock the files, only if they have the
password. This would also allow users to secure their personal and
corporate data.
Any ideas?
Has anyone looked at the Haiku Project lately. There hasn't been much
change in status but I do think the status page has a great graph
that reactos should implement.
http://haiku-os.org/learn.php?
mode=status&haikuusersession=80b7ab5450deadb0c18c136376ee33d0
