Ros-dev February 2005

ros-dev@reactos.org

42 participants
88 discussions

Re: [ros-dev] RE: Collection of wine tools on windows

by Boaz Harrosh

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

20 years, 1 month

RE: [ros-dev] Release 0.2.6

by Murphy, Ged (Bolton)

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

20 years, 1 month

Release 0.2.6

by Jason Filby

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

20 years, 1 month

added a proposed patch to bugzilla

by Roman Hoegg

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)

20 years, 1 month

Build is now VERBOSE=yes

by WaxDragon

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.

20 years, 1 month

State of the WIDL

by Eric Kohl

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

20 years, 1 month

RE: [ros-dev] msvcrt/crtdll "merge"

by Waldo Alvarez Cañizares

> 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

20 years, 1 month

Implementing a help system

by Karim Liman-Tinguiri

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

20 years, 1 month

RE: Collection of wine tools on windows

by Casper Hornstrup

> -----Original Message----- > From: wine-devel-admin(a)winehq.org > [mailto:wine-devel-admin@winehq.org] On Behalf Of Ivan Leo Puoti > Sent: 21. februar 2005 09:26 > To: wine-devel(a)winehq.com > Cc: ros-dev(a)reactos.com > Subject: Re: Collection of wine tools on windows > > Dimitrie O. Paun wrote: > > Heh, the MinGW folks seem to have some strange > requirements for their > > headers, I don't think they'll drop theirs. But we can > start by having > > ReactOS adopt our headers. > > > > We should also offer our headers as a separate package that > works out > > of the box as a replacement for the MinGW ones. This way people can > > just get our headers if they are better than the MinGW ones. > > Can't the win32api package headers be used to replace the > mingw headers? > > Ivan. W32api IS the MinGW headers. I might vote for using WINE headers in ReactOS if WINE relicensed its headers to a w32api or BSD like license that will allow use in a non-free application. What I would like to see most though, is for all three projects to share w32api. Casper

20 years, 1 month

Weekend Coder Project - Object Manager Shell Namespace Extension

by Steven Edwards

Pinging any weekend coders! Currently the ReactOS Explorer implements a browse button for the Object Manager FS and the Registry FS. It would be nice if rather than being hard coded in to explorer this was done via a shell extension that could be used in the Windows explorer or the ReactOS explorer. There example code for creating a Shell Namespace using a Unix filesystem at the following Url. http://www.winehq.org/hypermail/wine-devel/2005/02/0606.html There is example code on how to read the object manager in the following source file. http://svn.reactos.com/viewcvs/trunk/reactos/subsys/system/explorer/shell/n… Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250

20 years, 1 month

← Newer
1
2
3
4
5
6
7
8
9
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev February 2005