Ros-dev September 2005

ros-dev@reactos.org

67 participants
129 discussions

Re: [ros-svn] [hpoussin] 17751: Fix build, by correcting include paths and updating xml files of USB components
by TwoTailedFox 08 Sep '05

08 Sep '05

Corrected, just as I was trying to work out while it wasn't compiling with Mingw ;) On 9/8/05, hpoussin(a)svn.reactos.com <hpoussin(a)svn.reactos.com> wrote: > Fix build, by correcting include paths and updating xml files of USB components > > > Added files: > trunk/reactos/drivers/usb/usbport/usbport.def > > Updated files: > trunk/reactos/drivers/usb/miniport/linux/pci_hal.c > trunk/reactos/drivers/usb/miniport/usbohci/ohci-hcd.c > trunk/reactos/drivers/usb/miniport/usbohci/ohci_main.c > trunk/reactos/drivers/usb/miniport/usbohci/usbohci.xml > trunk/reactos/drivers/usb/miniport/usbuhci/uhci-hcd.c > trunk/reactos/drivers/usb/miniport/usbuhci/uhci.h > trunk/reactos/drivers/usb/miniport/usbuhci/usbuhci.xml > trunk/reactos/drivers/usb/usbhub/usbhub.h > trunk/reactos/drivers/usb/usbhub/usbhub.xml > trunk/reactos/drivers/usb/usbport/buffer_simple.c > trunk/reactos/drivers/usb/usbport/config.c > trunk/reactos/drivers/usb/usbport/core_drivers/usbkey.c > trunk/reactos/drivers/usb/usbport/core_drivers/usbmouse.c > trunk/reactos/drivers/usb/usbport/hcd-pci.c > trunk/reactos/drivers/usb/usbport/hcd.c > trunk/reactos/drivers/usb/usbport/hub.c > trunk/reactos/drivers/usb/usbport/message.c > trunk/reactos/drivers/usb/usbport/urb.c > trunk/reactos/drivers/usb/usbport/usb-debug.c > trunk/reactos/drivers/usb/usbport/usb.c > trunk/reactos/drivers/usb/usbport/usbcore.c > trunk/reactos/drivers/usb/usbport/usbport.xml > > Deleted files: > trunk/reactos/drivers/usb/usbport/usbcore.def > > _______________________________________________ > Ros-svn mailing list > Ros-svn(a)reactos.com > http://reactos.com:8080/mailman/listinfo/ros-svn > -- "I had a handle on life, but then it broke"

1 0

Re: [ros-svn] [ion] 17727: Implement NTDLL's CSR routines in a compatible way. Fix prototypes, argument count, deprecated functions and new functions. Some functions will not work (or are designed not to work) fully until the new CSR is committed, but they keep the same functionality as the previous versions (no regressions found; tested with cmd, cmt, putty, telnet, ps). Also added NtSecureConnectPort.
by Hartmut Birr 08 Sep '05

08 Sep '05

Hi, this changes does break booting for me. I get an error message: (subsys\csrss\api\wapi.c:198) CSR: NtListenPort() failed, status=c0000005 - Hartmut

3 3

Replacement for Bitstream fonts
by Mikhail Y. Zvyozdochkin 08 Sep '05

08 Sep '05

Hi All. I think it's a good idea to use Dejavu fonts http://dejavu.sourceforge.net/ instead Bitstream Vera. Reasons are: - it based on Bitstream fonts (1.10); - it's distributing under SAME license; BUT - it supported MUCH more unicode pages than original Bitstream fonts; it was main goal of Dejavu Projects "to provide a wider range of characters", to support various languages and codepages. In particular, I tried to activate Russian language in ReactOS 0.2.7-REL with Dejavu fonts. It working correctly without any proprietary fonts :). Unicode coverage table: http://cvs.sourceforge.net/viewcvs.py/*checkout*/dejavu/dejavu-fonts/unicov… At this September they want make new release, 1.14. I think, it new version may be integrated with ReactOS 0.3 :) WBR, DarkHobbit

1 0

problem with current svn
by Hartmut Birr 08 Sep '05

08 Sep '05

Hi, I'm trying to compile ros on ros with the current svn tree. It isn't possible. After some time, it fails with a message cannot execute 'bla bla'. The build does corrupt the file system. If I run chkdsk from w2k I get many messages about multiple files like 'wrc.ex'. It seems that something is wrong with the string functions. - Hartmut

3 5

RE: Ros-dev Digest, Vol 13, Issue 14
by Lucio Diaz 08 Sep '05

08 Sep '05

Sorry, but i still cant see the point. 0.2.7 is a release, and thus is oriented to the user (maybe power user or fan at this moment), to test and play around. Users, like me, dont go to bugzilla cause most of us can not make sense of all that techicall information. I knew there was a problem, a blocking problem for anyone trying to install the OS in real hardware and i wrote about it where a user (like me) may find out, in the wiki. I can not understand why you become angry. I am just filling some documentation for the user, and that is the only whay i can colaborate ( i doubt you would apretiate my little pascal and delphy coding skill). Known problems is for that... enumerating the known problems of a determinated version, while 0.2.7 is the last version i consider relevant the fact that it can not be installed in Real Hardware. I wish i could debug and find the problem, but i dont have the experience or the tools to do so. with my best wishes to the team, Lucio Diaz. WaxDragon wrote--> Message: 5 Date: Wed, 7 Sep 2005 13:15:19 -0400 From: WaxDragon <waxdragon(a)gmail.com> Subject: Re: [ros-dev] RE: Ros-dev Digest, Vol 13, Issue 13 To: ReactOS Development List <ros-dev(a)reactos.com> Message-ID: <9b0d5f3205090710157abc163f(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 I think you missed the point. I'm talking about http://www.reactos.com/wiki/index.php/Known_Problems When calling things "known problems" I want bugs for them. I'm going to assume you are talking about this known problem: http://www.reactos.com/bugzilla/show_bug.cgi?id=688 Which was even noted on the 0.2.7 changelog page: http://www.reactos.com/wiki/index.php/ChangeLog-0.2.7#Known_Bugs PLEASE, if you write ANYWHERE that ReactOS has a "known bug" please provide a link to the bug in bugzilla. If there is no bug in BugZilla, then there is a great possibility the Testing team doesn't know about it. By filing bugs, we can reduce the amount of duplicate effort required to fix said bug. When filing bugs, please review http://www.reactos.com/wiki/index.php/File_Bugs first. With that out of the way, I know that noone has looked at that bug since 0.2.7 was released. If you can gather any useful info about the hardware (the i8042 controller specifically) that you are experienceing the problem with, update the bug, this may help with getting it resolved. WD PS. I'm very tempted to make the "Know Problems" page go away, or heavily modify it. ______________________________________________ Renovamos el Correo Yahoo! Nuevos servicios, más seguridad http://correo.yahoo.es

1 0

RE: Ros-dev Digest, Vol 13, Issue 13
by Lucio Diaz 07 Sep '05

07 Sep '05

> Message: 1 > Date: Tue, 6 Sep 2005 08:42:13 -0400 > From: WaxDragon <waxdragon(a)gmail.com> > Subject: Re: [ros-dev] Bootcd installation failure > To: ReactOS Development List <ros-dev(a)reactos.com> > Message-ID: > <9b0d5f32050906054215dd322b(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Well, I have no idea what Lucio means by that "known > problem", since > he isn't very specific. 17600 is not even close to > where we forked > 0.2.7. I remember there were some problems around > then. Try 17604, I > personally tested that rev and it seemed to work ok. > > In the future, if you are going to call something a > "known problem" > please link to the bug in Bugzilla. If the "known > problem" isn't in > bugzilla, it isn't "known" as far as I care. > > Thanks > WD > I reported it in both the general and dev mailing lists, it happens in real hardware in two complitely diferent computers, one Intel and one AMD, with completely diferent OSes as base instalation and both with previus sucesfull reactos instalations. In both the instalation CD hangs before installing anything (maybe reading the partitions?) to the Hard drive. Not many people test reactos in Real Hardware, but i was told the problem was already known. I have not tested the SVN since long so i can not say if it is solved. Still it is a KNOW reproducible problem of 0.2.7. With best regards, Lucio Diaz. ______________________________________________ Renovamos el Correo Yahoo! Nuevos servicios, más seguridad http://correo.yahoo.es

3 2

Re: [ros-dev] Re: [ros-svn] [hbirr] 17665: - Copy the map registers to the buffer only, if they are used (in IoFlushAdapterBuffers).
by Filip Navara 07 Sep '05

07 Sep '05

1 0

Re: [ros-diffs] [gdalsnes] 17713: make co_WinPosShowWindow take pWnd, not hWnd
by Royce Mitchell III 07 Sep '05

07 Sep '05

gdalsnes(a)svn.reactos.com wrote: > > > >+ //faxme: temp hack >+ UserDereferenceWindowObjectCo(Window); >+ > > What's your fax #? :P

1 0

Re: [ros-svn] [hbirr] 17665: - Copy the map registers to the buffer only, if they are used (in IoFlushAdapterBuffers).
by Filip Navara 06 Sep '05

06 Sep '05

hbirr(a)svn.reactos.com wrote: >- Copy the map registers to the buffer only, if they are used (in IoFlushAdapterBuffers). >- Do not use the byte offset into the page from a given buffer if the map registers are used, > because the caller didn't request for one additional register in the call to IoAllocateAdapterChannel > and it will not work for a 64k buffer. > > Sorry, but these changes are wrong. I won't argue that there isn't bug, but you're just workarounding it. - At first, the UseMapRegisters variable you added to MAP_REGISTER_ENTRY structure isn't needed. IoFlushAdapterBuffers can determine the information itself and the case was clearly marked as UNIMPLEMENTED and FIXME. - The byte offset is added for a reason. I know the stuff that it is supposed to solve is broken atm, but the rationale is that there can be more IoMapTransfer calls and together with MAP_REGISTER_ENTRY->Counter you can setup more transfers... It's explained in http://download.microsoft.com/download/e/b/a/eba1050f-a31d-436b-9281-92cdfe…. I certainly welcome any help and review of the DMA code and I'll try to add comments where appropriate, but I would like to discuss these changes first on the Mailing List / IRC / mail since this piece of code is pretty complex and any changes are prone to break some feature... - Filip

2 5

RE: [gdalsnes] 17695: naming changes:
by Ge van Geldorp 06 Sep '05

06 Sep '05

> From: gdalsnes(a)svn.reactos.com > > naming changes: > -remove annying "Object" from variables. prepend handles with > "h" instead. > -rename window->Self -> Window->hSelf I hope we're not going to convert everything to Hungarian notation? Personally I think that's both ugly and useless. Gé van Geldorp.

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev September 2005