Ros-dev

ros-dev@reactos.org

2 participants
5791 discussions

ntoskrnl issue on my Dell Latitude C610
by Steven Edwards 25 Feb '05

25 Feb '05

Hi, A little background info. I have a dell Latitude c610 with a P3m 1ghz CPU, 256Megs of Ram and a 20 Gig hard disk. ATI Mobile Radeon Graphics chip with 16megs of Vram. When I try to boot ReactOS the screen always go black after freeldr loads the drivers and everything even if /NOGUIBOOT is selected and bootvid.sys is removed from the system. The screen never goes blue and the kernel never gets a point where HalDisplayString or the kernel debugger will work. I have added a function to my ke\main.c to manually write to the screen in text mode and have been using that to try to debug the boot process. The problem is that it never consistantly crashes at one line of code. It always seems to be around a call to KeLowerIrql but depending on where I stick my debug statements it will change. Whats odd is that it will fail 100% of the time in the same place depending on where I move my debug statements. The only thing I can figure is that but writting to the display its interupting which is changing the failure location. The farthest in the boot process I can get is the call to KeLowerIrql that happens around the calls to SeInit1 and SeInit2. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250

2 2

RE: [ros-dev] Release 0.2.6
by Casper Hornstrup 24 Feb '05

24 Feb '05

> -----Original Message----- > From: ros-dev-bounces(a)reactos.com > [mailto:ros-dev-bounces@reactos.com] On Behalf Of Karim Liman-Tinguiri > Sent: 24. februar 2005 12:34 > To: ReactOS Development List > Subject: Re: [ros-dev] Release 0.2.6 > > Greetings everyone, > > I totally agree with Murphy and I believe we should launch another > 0.2.x release before the next 0.3 release. I think before we can > launch a 0.3 release, we need to have a solid support for Win32 > drivers: networking doesn't limit to LAN-Ethernet, but it also > includes PPP and modem connection (analogic and broadband). > > With the growing amounts of winmodems, Win32 driver support must > definitely be implemented before claiming "networking > support": this is one of the weaker points of Linux: driver > compatibility (though lots of efforts are being made by manufacturers > and hackers), many drivers are still only available on the windows > platform. It'd be much cheaper, programming-effort wise, to natively > support windows driver than try to port them to ReactOS, (I'm not even > mentionning the case of closed-source drivers and undocumented > hardware). > > As is stated in the status page of the library "Driver Support At the > moment, work to support 3rd party drivers (Microsoft Windows > compatible) is restricted. The focus is more on only basic drivers > that are written in conjunction with the various kernel facilities." ; > there's not much 3rd party Microsft Driver support. It'd definitely > have to be implemented before > 0.3 release. That would be nice, but it's not practical since nobody has volunteered to work on it and thus it will not get implemented any time soon. If you will work on it or can find someone who will and can give a rough timeframe for its completion (say 5-6 months), I might vote for a delay of a 0.3 release. Casper

2 1

Re: [ros-dev] RE: Collection of wine tools on windows
by Boaz Harrosh 24 Feb '05

24 Feb '05

Rolf Kalbermatter wrote: >This is rubish. > Yes ^ 3 ( that is Yes cubed) Let us all get back on track of this discussion. Must ReactOS and MinGW use the Wine set of headers. 1. ReactOS & MinGW are by themselves GPL, So they are more strict than Wine's header set 2. Headers are out of the scope for License as Rolf explained. Or to be more precise they are the boundary put by the License. "From this API down you are in Library territory". The header is the Line drawn by the Library writer, as what is public API. A GPL program is an LGPL library with the trivial public header of: <c> int main(int argc ,char* argc[]) ; // use only </c> 3. Wine Headers are description of the Win32 API by Microsoft, so what the hell are you talking about. And back to the subject. I have proved that Wine-headers are not only, nice-to-have, but a must in a gcc compilation environment on Windows, like MinGW or Cygwin. Could/did any one see if ReactOS has every thing they need in wine-headers and if not patch in the diff. So is it accepted than! Free Life Boaz

6 5

RE: [ros-dev] Release 0.2.6
by Murphy, Ged (Bolton) 24 Feb '05

24 Feb '05

Jonathan Wilson wrote: > (do we have a DHCP client yet? If not, how hard would > writing one be?) I'm hoping to get started on one very soon. Gedi _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev ************************************************************************ 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

1 0

Release 0.2.6
by Jason Filby 24 Feb '05

24 Feb '05

Hi all The consensus on IRC appears to be that we need another 0.2.x release. The reason is that 0.3 is our "network" release and there's still some work to do to justify this. Everyone agree? Cheers Jason

5 5

added a proposed patch to bugzilla
by Roman Hoegg 23 Feb '05

23 Feb '05

Hello everybody! I've been a long time lurker and have decided to finaly contribute something to this wonderful project. quick introduction: 29, male, research assistent at the University of St. Gallen (Switzerland), some C/C++ knowledge (but not enough for serious contributions to an OS) I'm in the process of creating a keyboard layout (it's nearly finished) and have run into a problem which I posted in bugzilla. I was told on #reactos that this is the way to do it. http://reactos.com/bugzilla/show_bug.cgi?id=509 would be cool if someone with experience with keyboard layouts could give me a tip. thanks! Roman Hoegg (RomanH)

1 0

Build is now VERBOSE=yes
by WaxDragon 22 Feb '05

22 Feb '05

ekohl commited some variables into rules.mak for his 13704 change, are all these correct? --- /trunk/reactos/rules.mak 2005/02/21 11:01:32 13703 +++ trunk/reactos/rules.mak 2005/02/21 12:38:50 13704 @@ -1,3 +1,7 @@ +export VERBOSE = yes +export BUILD_MAP = yes +export BUILD_SYM = no + # Default to half-verbose mode ifeq ($(VERBOSE),no) Q = @ @@ -163,6 +167,7 @@ export XSLTPROC = $(Q)xsltproc export MS2PS = $(Q)$(TOOLS_PATH)/ms2ps/ms2ps export WRC = $(Q)$(TOOLS_PATH)/wrc/wrc +export WIDL = $(Q)$(TOOLS_PATH)/widl/widl export STD_CFLAGS = -I$(PATH_TO_TOP)/include -I$(W32API_PATH)/include -pipe -march=$(OARCH) -D_M_IX86 export STD_CPPFLAGS = $(STD_CFLAGS) Andrew -- The cheese stands alone.

3 2

State of the WIDL
by Eric Kohl 22 Feb '05

22 Feb '05

Hi all, there is some good news to tell about WIDL. It is able to build the header file, client stub file and server stub file for _very_ simple rpc applications. I got a slightly modified version of the hello example from MSDN working. There are still a lot of features missing from WIDL but it is able to create stubs for simple functions that don't take any arguments and return no or basic type values. Returning pointers is not supported yet. So, supported functions look like that: void My1stRpcFunc(void); int My2ndRpcFunc(void); unsingned long My3rdRpcFunc(void); Another restriction is the handling of implicit binding handles. These binding handles are usually declared in an ACF file. But since ACF files are not supported yet the declaration must take place in the IDL file. MIDL supports this as well if you use the '/app_config' option. Explicit binding handles are not supported yet. Finally, WIDL does not support MIDLs '/oldnames' option. This option is used to enable the old naming conventions for interface handles. This is a minor issue because the MSDN examples use the old naming conventions. Next, I want to implement support for basic type function arguments. The whole source code to WIDL is published under the LGPL so feel free to contribute it to WINE. Regards, Eric

4 7

RE: [ros-dev] msvcrt/crtdll "merge"
by Waldo Alvarez Cañizares 22 Feb '05

22 Feb '05

> They are used internally by some other functions inside msvcrt so they must be somewhere > what is going on now is that internally a stically linked library is used but anything referencing those functions > from the outside are being redirected to ntdll. > > What I mean is: If you are forwarding them, why you don´t import them too instead of the static link? > If you are statically linking then why forward them? First: it was not me who added those forwards to ntdll. But it can't see anything wrong with it either. Sure they are all right. In fact I proposed something similar a long time ago. Ask Hyperion :) However the final solution was better. It seems none of the forwarded functions are implemented/duplicated in crt and they are not called from within crt either thus none of the forwarded routines are imported from ntdll by msvcrt/crtdll. Gunnar Maybe I'm out of sync by far or maybe I'm wrong. Snapshots do no work anymore since the move to subversion I guess. I will check again using the old sources and will tell in such case so if you have a chance check it on the most recent ones. In the last snapshot I was able to download there was a libary strings.a statically linked with several components of ReactOS such as ntoskrnl, ntdll, crtdll.dll and msvcrt.dll that means that there are/were at least 4 copies in RAM of the same set of routines. This can be easily ckecked if for example you pick one of the functions and do a binary search on the ROS tree. I think that there could be only one If both crtdll and msvcrt forward them to ntdll and ntdll import them from ntoskrnl and they are set as executable ring0 <-> ring3. But maybe that's to ask a lot for now. I beleive that just taking away the duplicated code crtdll/msvcrt and in case that I'm right import those from ntdll will help more and will be alot easier than the last one. Regards Waldo

1 0

Implementing a help system
by Karim Liman-Tinguiri 22 Feb '05

22 Feb '05

Hello, I've recently joined the ReactOS project (1) where I intend to work as a coder primarily. After downloading the LiveCD and trying it out, I found out it lacks (amongst many) a help system. I believe it should be added amongst the urgent TO-DOs checklist now that the OS runs, provides a minimal GUI, and is stable. Built-in user assistance is essential since the React Operating System is intended for the large audience; not only for hackers. Therefore I am wondering if there is a current project started to code one. If not, I plan to code an open-source version of the winhlp32.exe file located in the system folder able to open and show windows .hlp files. The goal is to have a winhlp32.exe that runs and behaves exactly like (or very close to) that of the Microsoft copyrighted winhlp32.exe. It should therefore be able to serve existing windows apps with a help server without any modification to the program. I've verified the dependencies of winhlp32.exe; all of them have already been implemented in ReactOS, so it should not be a big deal to code it from scratch. Despite the fact that the .hlp file format isn't officially documented, it has already been reverse engineered and its documentation can be found on the web (2). However, if there already is a help support project up and running, I intend to join it. Besides, as soon as this is ready (why not before ?), I advise we convert all documentation on the reactos.com's library (and all further documentation) to the DocBook (SGML) format: it has the advantage of being easily converted on-the-fly to pdf, html, post-script and many others. A tool chain to convert it to .hlp will however have to be created (meanwhile we can use the standard tools for compiling .hlp files). (1) I'm referring to the developer mailing list (2) http://www.geocities.com/mwinterhoff/helpfile.htm

4 6

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev