The 'Standard' PC serial ports are as follows:
COM1 (address 3F8-3FF) and COM3 (address 3E8-3EF) share IRQ4.
COM2 (address 2F8-2FF) and COM4 (address 2E8-2EF) share IRQ3.
I remember from my DOS days that you can add more serial cards into the
system just as long
as you kept the address's from overlapping, and your software was configured
correctly.
As far as I'm aware the BIOS data area only has place for 4 port addresses:
0000:0400 COM1 address
0000:0402 COM2 address
0000:0404 COM3 address
0000:0406 COM4 address
-----Original Message-----
From: Royce Mitchell III [mailto:royce3@ev1.net]
Sent: Thursday, 17 March 2005 12:04 p.m.
To: ReactOS Development List
Subject: Re: [ros-dev] serial driver bug
Robert Köpferl wrote:
> Be aware that it makes a difference wether you have got a so called
> multi serial card or several plain old serial HW. I may be wrong, but
> isn't 4 the limit. Due to 'reserved' ports for that kind of HW?
>
It's a multi-serial card. The 4 limit for plain serial is due to
reserved/limited irq if I understand correctly.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev
This communication is confidential and may contain privileged material.
If you are not the intended recipient you must not use, disclose, copy or retain it.
If you have received it in error please immediately notify me by return email
and delete the emails.
Thank you.
arty(a)svn.reactos.com wrote:
>consw has not been needed for a long time.
>
>
>
Actually, that was never needed. It was there for a planned extended
feature of our Win32 emulator: the possibility to switch back to text
mode on the active desktop belonging to the winstation attached to the
primary console.
Still getting it: Unhandled UserMode exception, terminating thread.
Jason
On Wed, 16 Mar 2005 19:30:11 +0200, Jason Filby <jason.filby(a)gmail.com> wrote:
> I wanted that record ;)
> Great to know though!
>
> Cheers
> Jason
>
> On Wed, 16 Mar 2005 18:15:50 +0100, Filip Navara <xnavara(a)volny.cz> wrote:
> > Jason Filby wrote:
> >
> > >Hi all
> > >
> > >Loading up the OpenOffice.org 1.1.2 Setup no longer works; the initial
> > >progress bar completes and then nothing happens. I'm sure I've seen
> > >this bug before! Any help welcome.
> > >
> > >
> > Just for the record, today I successfully installed OOo 1.1.1, ROS SVN
> > revision 14087.
> >
> > - Filip
> >
> >
>
Hi!
I switch to an older serial driver, BTW the new one set the baud to 19.2k.
(KERNEL32:mem/global.c:412) Memory Load: 8
CSR: NtOpenProcess() failed for handle duplication
Failed to tell csrss about new process. Expect trouble.
(KERNEL32:mem/global.c:412) Memory Load: 8
Funny debug message,
James
Alex's patches are in, and I saw him call for 0.2.6 on irc, but
there have been a few regressions discovered. Do we need to have a
bughunt / regression test / code freeze? The last couple of releases
(that I have been around for) we have created the branch, then applied
bugfixes against it, then backported to HEAD. Is this the way we
should do this? Should we "freeze" HEAD and then branch?
I found that vncviewer no longer starts for me, and Alex said that
Abiword doesn't work for him. The wallpaper was reported to have
regressed also. I personally will test the wallpaper and all the
other things I care about tonight. Maybe we should have others check
over things too..
Just curious,
WD
--
The cheese stands alone.
Hi all
Loading up the OpenOffice.org 1.1.2 Setup no longer works; the initial
progress bar completes and then nothing happens. I'm sure I've seen
this bug before! Any help welcome.
Thanks
Jason
--- James Tabor <jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net> wrote:
> We don't have this yet? Is there a plan to include this in our
> code tree?
According to Thomas and Dmitry's tests its not correct so we are waiting to
see if someone comes up with a better implementation.
Thanks
Steven
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
Hi Steven,
Steven Edwards wrote:
> Changelog:
> Christoph von Wittich <Christoph(a)ApiViewer.de>
> Implement GetComboBoxInfo
>
>
>
We don't have this yet? Is there a plan to include this in our
code tree?
Looks great!
James
ReactOS will not build on Windows with the latest version of Nasm (
0.98.39 ), because at least some public releases of that version ( I
just downloaded the official from sourceforge.net ), do not support long
file names, and we have a long file name in PSEH.
We can just shorten that asm's file name, but we could also configure
the build system to reject that version.
I don't feel like dealing with it, so I thought I would just send a
head's up here :)
--- Alex Ionescu <ionucu(a)videotron.ca> wrote:
> This goes beyond debug information. This is reproduceable behaviour that
> probably any driver developper out there knows. Checked builds are
> builds recommended for testing your driver for bugs. If you call that
> function with a Queue Object, you WILL see that assert line-by-line on
> your screen. From that point on, one should stich his eyes out for
> having seen it, and shoot himself for knowing this behaviour?
So fix a ReactOS driver to match this behavior and work under Windows and
then you will have justification for making related changes in the kernel.
> Notwithstanding that they cannot sue the project, and that they would
> not sue you. This was a public comment to a friend... why would they sue
> Steven when Alex said what he said? And yes, I cannot wait to be sued...
> I can see the headlines -- Driver Developer sued for being aware of
> Windows Assertion --. I hope they also go after Mark Russinovich for
> having used the checked build to generate a tree of the Windows Source
> code!!
The last time I looked Mr Russinovich was not try to make a replacement
for Windows but rather provide more information people wanting to use
Windows.
> If you aren't, then why am I always the one being targeted with such
> comments. There are functions in ROS which are almost copies of their
> binary versions. There are structures in ROS which look like clones of
> the Windows ones (undocumented ones). There is functionality that was
> directly reversed engineered so that it would be compatible.
Yes we have reverse engineered quite a bit but the question is what methods
are being used to reverse certain behavior. We cannot help but be compatible
with the structures in Windows and take any means needed to be compatible.
> Yet, nobody says a word; everyone goes after Alex for having a
> conversation with a friend and mentionning a reproducible fact in every
> driver developer's life -- you do not KeWaitXxx on a Queue.
> Probably as much as jumping on a guy who has written some of the highest
> quality and most useful code in the OS for the fact he used public
> information during an argument.
You stated the other day there were regressions that were only found by
developing test cases. You would have a lot more good will from developers
on this project if you committed test cases for some of the patches you develop
and commit them to rosapps/tests or write a dummy driver to show the behavior
rather than than pointing to checked builds.
Thanks
Steven
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
Hi,
--- Mike Swanson <mikeonthecomputer(a)gmail.com> wrote:
> Just put a trademark on the name but allow it to be used on
> derivations on the circumstance that it clearly shows that it is not
> _the_ ReactOS.
I have looked in to this a bit with the legal council I have on retainer as part of the ReactOS
Foundation work. I think it is around $250 to file in a state and around $1000 to file the federal
paperwork. I will call the lawyer this week and get numbers and a timeframe on what it would take
to make it happen.
Thanks
Steven
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
--- Alex IoIonescuioionucuivideotrona> wrote:
> This climate of paranoia is getting to my nerves.
You could at least try to be civil in your discussion. Some of us have spent more than a few years
on this project and have a right to be a little paranoid about if our lives work might be put in
to danger.
> As for Steven... WINE, ROS, and any other compatibility product out there is not 100% clean
> room. It has never been, will never be, cannot be. Especially if we consider debug information
> as being "dirty". Reminds me of people freaking out when I added functions that were in the IFS
> -- you'd hope people would've grown up by now--.
Still it depends on the source of the information. We have discussed in private my views on using
the debug information. I will publicly state I think the law is ambiguous at best and the debug
information should be a valid source given Microsoft position of being a monopoly as found by
Anti-trust proceedings. That being said a court might not agree with me so any behavior must be 1.
Reproduceable or 2. Documented.
> I could make a list of over 25 parts of ReactOS Which are not 100% clean. But I won't, because
> that would tarnish our image. I would appreciate if you'd stop tarnishing mine and making
> accusations.
I am not trying to trash your image. I am simply mentioning the truth that everyone already knows
but could be deadly to this project and others in a kangaroo court in the US. When your source of
information comes from documentation or a third part program exhibiting certain behavior then
there is not a legal question as to if a reimplementation is a original work. If you are basing
your implementation of a feature only on the debug information then clearly, at least in my mind
it runs the danger being found a derived work and everytime you do so it at the very least
tarnishes ReactOS's image.
Thanks
Steven
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
--- Alex Ionescu <ionucu(a)videotron.ca> wrote:
> What the fsck are you implying.
Its hard to claim our implementation is "clean room" if you are basing your implementation on
debug information rather than reverse enginered behavior. I am not opposed to observing the
implementation via debug information and then writting tests to match behavior but there is a fine
line...
Thanks
Steven
__________________________________
Do you Yahoo!?
Make Yahoo! your home page
http://www.yahoo.com/r/hs
What if winlogon.exe is run by csrss.exe and not by smss.exe?
A winlogon process, in its own desktop, is needed for each Win32 session.
If we make csrss.exe multiuser, it must create session 0 (console) or
die and therefore run winlogon in it.
This change shouldn't have any effect on compatibility with Windows NT.
smss will assume only csrss is critical.
ea
Wow!
Current SVN (Head)!
Used memory 1015744Kb
(mm/mminit.c:375) Kernel Stack Limits. InitTop = 0x80133000, Init = 0x80130000
(mm/virtual.c:214) FIXME: MEMORY_AREA_SYSTEM case incomplete (or possibly wrong)
for NtQueryVirtualMemory()
(ke/bug.c:56) Found Bugcheck Resource Data!
(ke/bug.c:67) Got Pointer to Bugcheck Resource Data!
(ke/clock.c:80) KiInitializeSystemClock()
(ke/clock.c:99) Finished KiInitializeSystemClock()
No current process
Entered debugger on last-chance exception number 14 (Page Fault)
Memory at 0x9c could not be read: Page not present.
No current process
KeBugCheckWithTf at ke/catch.c:224
A problem has been detected and ReactOS has been shut down to prevent damage to
your computer.
The problem seems to be caused by the following file: ntoskrnl.exe
KMODE_EXCEPTION_NOT_HANDLED
Technical information:
*** STOP: 0x0000001E (0xc0000005,0x8002f410,0x00000000,0x00000018)
*** ntoskrnl.exe - Address 0x8002f410 base at 0x80000000, DateStamp 0x0
Page Fault Exception: 14(0)
Processor: 0 CS:EIP 8:8002f410 <ntoskrnl.exe:2f410>
cr2 18 cr3 26000 Proc: 0
DS 10 ES 10 FS 30 GS 10
EAX: 00000000 EBX: 00000680 ECX: 00026000
EDX: 00000064 EBP: 8013245c ESI: 80132834 ESP: 801323ac
EDI: 80132be0 EFLAGS: 00210046 kESP 801323ac Frames:
<ntoskrnl.exe:300fc>
<ntoskrnl.exe:de31>
<ntoskrnl.exe:1285>
<ntoskrnl.exe:1aff>
<ntoskrnl.exe:382d>
<ntoskrnl.exe:c4a3e>
<46C>
KeBugCheckWithTf at ke/catch.c:224
A problem has been detected and ReactOS has been shut down to prevent damage to
your computer.
The problem seems to be caused by the following file: ntoskrnl.exe
KMODE_EXCEPTION_NOT_HANDLED
Technical information:
*** STOP: 0x0000001E (0x80000003,0x80005c47,0x00000000,0x00000000)
*** ntoskrnl.exe - Address 0x80005c47 base at 0x80000000, DateStamp 0x0
Hi Hartmut,
> I'm not sure but a native application can only import ntdll.dll. If you
> enable the code, smss will import smdll.dll.
You are probably right. It is the time to make smdll static.
Thank you.
Emanuele
____________________________________________________________
Navighi a 2 MEGA e i primi 3 mesi sono GRATIS.
Scegli Libero Adsl Flat senza limiti su http://www.libero.it
I was wondering if there was a project that would be doing a binary compatible OS X system. What reactos does for windows maybe this project can do for OS X. I was just wondering. I know that pearpc emulates a ppc processor, but wether or not a full os exists is the question. I know also that some versions of linux exist for ppc.
Thanks
Also - is reactos going to do a mips, ppc, arm, ia64 system?
weiden(a)svn.reactos.com wrote:
>Alex Ionescu <ionucu(a)videotron.ca>
>
> Dispatcher Objects Rewrite (minus Queues, coming in next patch).
>
>
>
There is now only one large patch left + a smaller one related to it,
which will complete the Dispatcher fixes. After those two patches,
everything in my branch will have been committed. The branch will be
destroyed and I will create the Winsock branch on which Arty and I will
work.
Best regards,
Alex Ionescu
Hi,
Right now, someone has set up an XDCC IRC bot to distribute copies of
ReactOS. While I welcome the move, it raises a question on who is
responsible for the quality of those files. Even if the person means no
harm, the files can get corrupted/infected by the following events:
1) Download corruption
2) Viral infection
3) Hard-disk damage
And perhaps many more. In all cases, this would result in unusable,
dangerous or even damaging releases of ReactOS, which we could not
control. As such, I propose a vote:
[ ] Yes, allow 3rd-party distribution of the OS through the #ros-xdcc
channel and ROS-XDCC-001 bot. (support and encourage this distribution)
[ ] Yes, allow 3rd-party distribution of the OS, but it must clearly
distance itself from officially supported releases (tolerate but do not
support this distribution)
[ ] No, only sourceforge and other official ReactOS distribution points
should be used.
Myself I vote for the first choice, but I would like the following to be
done:
1) Create MD5 Hashes to verify authenticity
2) Set up official communications with the bot's maintainer and
establish a set of guidelines.
Best regards,
Alex Ionescu