Ros-dev

ros-dev@reactos.org

5790 discussions

Must Read!!!! Msi.dll and Bison Alert!!!!
by James Tabor 04 Dec '04

04 Dec '04

Hi All! Jim Tabor wrote: > CVSROOT: /CVS/ReactOS > Module name: reactos > Repository: reactos/lib/msi/ > Changes by: jimtabor(a)mok.osexperts.com 04/11/30 11:10:55 > > Added files: > reactos/lib/msi/: .cvsignore Makefile Makefile.in > Makefile.ros-template action.c cond.y create.c > distinct.c handle.c insert.c msi.c msi.spec > msipriv.h msiquery.c order.c package.c query.h > record.c regsvr.c select.c sql.y string.c > suminfo.c table.c tokenize.c update.c > version.rc where.c winehq2ros.patch > > Log message: > First port of Wine projects msi.dll > With this commit, we will be using bison to build cond.y and sql.y. Okay, for those using a Window 32 based system 8^p you will need *bison*! http://gnuwin32.sourceforge.net/packages/bison.htm http://www.mingw.org Good luck, James

13 29

RE: [ros-cvs] CVS Update: reactos
by Ge van Geldorp 04 Dec '04

04 Dec '04

> From: Ge van Geldorp > > Log message: > Current versions of VMware provide a correct BIOS memory map I removed this code: #ifndef ACPI /* FIXME: VMware does not like it when ReactOS is using the BIOS memory map */ KeLoaderBlock.Flags &= ~MB_FLAGS_MMAP_INFO; #endif Casper added this code a few years back, at that point using the BIOS memory map prevented ReactOS from booting. It appears to work fine now (with VMware 4). This email is just a heads-up for everyone, if ReactOS fails to boot now this change may cause it (and I will reverse the change if it causes problems). Gé van Geldorp

2 1

msiexec.exe
by David Kredba 04 Dec '04

04 Dec '04

There is little problem with msiexec.exe : make[1]: Entering directory `/home/dave2/ros/reactos/subsys/system/msiexec' mingw32-gcc -I../../../include/wine -D_WIN32_IE=0x0501 -D_WIN32_WINNT=0x0501 -D__USE_W32API -I. -I../../../include -I../../../w32api/include -pipe -march=i486 -D_M_IX86 -g -M msiexec.c | ../../../tools/depends . .msiexec.d make[1]: Leaving directory `/home/dave2/ros/reactos/subsys/system/msiexec' make[1]: Entering directory `/home/dave2/ros/reactos/subsys/system/msiexec' mingw32-windres --include-dir ../../../include --include-dir ../../../w32api/include version.rc -o version.coff mingw32-gcc -I../../../include/wine -D_WIN32_IE=0x0501 -D_WIN32_WINNT=0x0501 -D__USE_W32API -I. -I../../../include -I../../../w32api/include -pipe -march=i486 -D_M_IX86 -g -c msiexec.c -o msiexec.o mingw32-ar -rc msiexec.a msiexec.o make[1]: *** No rule to make target `../../../dk/w32/lib/liblibwine.a', needed by `msiexec.nostrip.exe'. Stop. make[1]: Leaving directory `/home/dave2/ros/reactos/subsys/system/msiexec' make: *** [msiexec] Error 2 fixable by deleting 'lib' from libwine in subsys/system/msiexec/ /Makefile. Regards, David -- David Kredba <kredba at ibot.cas.cz> GPG: ID 1024D/5B6B02DE Fingerprint: F0B3312596BEDCF91DFB 0699E06AACD75B6B02DE

1 0

Re: [ros-cvs] CVS Update: reactos
by James Tabor 03 Dec '04

03 Dec '04

Hi! navaraf(a)cvs.reactos.com wrote: > CVSROOT: /CVS/ReactOS > Module name: reactos > Repository: reactos/w32api/include/ > Changes by: navaraf(a)mok.osexperts.com 04/12/01 12:06:18 > > Modified files: > reactos/include/wine/: objidl.h > reactos/lib/oleaut32/: Makefile.in oaidl_p.c olefont.c > tmarshal.c typelib.c typelib.h typelib2.c > reactos/lib/uuid/: uuid.c > reactos/w32api/include/: oaidl.h objidl.h ocidl.h oleauto.h > rpc.h rpcndr.h rpcproxy.h > > Log message: > - Get full OLEAUT32 to compile. > I dont understand what happen but when the oleaut32.a is first generated it is 297702 bytes in dk/w32/lib. After oleaut32.dll it built, oleaut32.a is 492292 bytes. With the larger file in dk/w32/lib, it causes build errors with explorer. When making msi.dll with the smaller or first file, I get undefined reference to `LoadTypeLib', with the larger; ../../dk/w32/lib/oleaut32.a(oleaut.o)(.text+0x803):oleaut.c: multiple definition of `DllMain@12' msi.o(.text+0x3ad3):msi.c: first defined here make: *** [msi.nostrip.dll] Error 1 Explorer; ../../../dk/w32/lib/oleaut32.a(variant.o)(.text+0x2004):variant.c: undefined reference to `DbgPrint' ../../../dk/w32/lib/oleaut32.a(variant.o)(.text+0x201a):variant.c: undefined reference to `DbgPrint' ../../../dk/w32/lib/oleaut32.a(variant.o)(.text+0x2d05):variant.c: undefined reference to `DbgPrint' ../../../dk/w32/lib/oleaut32.a(variant.o)(.text+0x2d21):variant.c: undefined reference to `DbgPrint' ../../../dk/w32/lib/oleaut32.a(variant.o)(.text+0x2da5):variant.c: undefined reference to `DbgPrint' ../../../dk/w32/lib/oleaut32.a(variant.o)(.text+0x2dc1):variant.c: more undefined references to `DbgPrint' follow ../../../dk/w32/lib/oleaut32.a(oleaut.o)(.text+0x314):oleaut.c: undefined reference to `StringFromGUID2@12' ../../../dk/w32/lib/oleaut32.a(oleaut.o)(.text+0x333):oleaut.c: undefined reference to `CreateItemMoniker@12' ../../../dk/w32/lib/oleaut32.a(oleaut.o)(.text+0x367):oleaut.c: undefined reference to `GetRunningObjectTable@8' ../../../dk/w32/lib/oleaut32.a(oleaut.o)(.text+0x42a):oleaut.c: undefined reference to `GetRunningObjectTable@8' ../../../dk/w32/lib/oleaut32.a(oleaut.o)(.text+0x4a1):oleaut.c: undefined reference to `StringFromGUID2@12' ../../../dk/w32/lib/oleaut32.a(oleaut.o)(.text+0x4c0):oleaut.c: undefined reference to `CreateItemMoniker@12' ../../../dk/w32/lib/oleaut32.a(oleaut.o)(.text+0x4f4):oleaut.c: undefined reference to `GetRunningObjectTable@8' ../../../dk/w32/lib/oleaut32.a(oleaut.o)(.text+0x6a0):oleaut.c: undefined reference to `DbgPrint' ../../../dk/w32/lib/oleaut32.a(oleaut.o)(.text+0x6b0):oleaut.c: undefined reference to `DbgPrint' ../../../dk/w32/lib/oleaut32.a(oleaut.o)(.text+0x784):oleaut.c: undefined reference to `GetPaletteEntries@16' ../../../dk/w32/lib/oleaut32.a(safearray.o)(.text+0x57f):safearray.c: undefined reference to `DbgPrint' ../../../dk/w32/lib/oleaut32.a(safearray.o)(.text+0x595):safearray.c: undefined reference to `DbgPrint' ../../../dk/w32/lib/oleaut32.a(safearray.o)(.text+0xf42):safearray.c: undefined reference to `DbgPrint' ../../../dk/w32/lib/oleaut32.a(safearray.o)(.text+0xf52):safearray.c: undefined reference to `DbgPrint' ../../../dk/w32/lib/oleaut32.a(vartype.o)(.text+0x453c):vartype.c: undefined reference to `DbgPrint' ../../../dk/w32/lib/oleaut32.a(vartype.o)(.text+0x4552):vartype.c: more undefined references to `DbgPrint' follow ../../../dk/w32/lib/oleaut32.a(vartype.o)(.text+0x602f):vartype.c: undefined reference to `strtoulW' ../../../dk/w32/lib/oleaut32.a(vartype.o)(.text+0x803e):vartype.c: undefined reference to `DbgPrint' ../../../dk/w32/lib/oleaut32.a(vartype.o)(.text+0x8058):vartype.c: undefined reference to `DbgPrint' make: *** [explorer.nostrip.exe] Error 1 So, with the smaller, there are no refs to the typelib code. FYI, James

2 2

HAL reorganisation
by Ge van Geldorp 02 Dec '04

02 Dec '04

As most of you know, I'm dabbling around a little bit with a port of ReactOS to the Xbox. I think most of the differences between a standard PC and the Xbox can be handled by using a custom HAL for the Xbox, after all, that's what the HAL is for. At the moment, we build 1 HAL, based on the value of MP in config it's either a UniProcessor HAL or a MultiProcessor HAL. Which code is compiled is based on preprocessor statements. I'd like to be able to build 3 HALs in parallel, the UP, MP and Xbox HALs. When installing ("make install"), the correct HAL would be selected based on the MP config var. When creating a boot cd, all three would be copied to the CD and the setup program would select the correct one to copy to the harddisk. This will allow us to build a single boot CD for different configurations. I'm aware that we'll need a NTKRNLMP.EXE on the boot CD too (I will try very very hard not to need a different kernel for Xbox) for this "single boot CD" idea to work, but that's a different problem and I'd like to tackle that later. The three HALs will share a lot of the code. To avoid code duplication, I propose to create a directory structure like this: hal | --- hal | --- halx86 | | | +----- generic | | | | | +----- include | | | +----- up | | | +----- mp | | | +----- xbox | +-- hal68k :-) | +-- etc... The "generic" subdir will contain most of the code. The "up" subdir will contain mostly simple .c files which just include a .c file from generic. For example, the HalMakeBeep() function will be defined in generic/beep.c. In "up" there will be a file beep_up.c which contains only 'include "beep.c"', which will be compiled with the include path set to "../generic". The "mp" and "xbox" directories can either include "generic" files or have their own implementation of a given routine (e.g. display_xbox.c for HalDisplay* functions on the Xbox). Doing it this way we should have little code duplication and our dependency tracking system should work. Comments? Gé van Geldorp.

7 11

DirectX
by Maarten Bosma 02 Dec '04

02 Dec '04

Hi, I have started coding the Direct3d 9 dll. It isn't something usable yet, but only a few kernel calls have to be made to run the first (very simple) Direct3D program. I have already looked up those functions, but most of them need some huge structs as parameters. At the moment I don't have the time to work on it. Maybe one of you would like to do so. But be warned this is the first time that i am working on an open source project and my coding style isn't the best. Maarten Bosma

3 5

RE: [ros-dev] Very bad Idea.
by Waldo Alvarez Cañizares 01 Dec '04

01 Dec '04

Hi Robert: How are you? I think that putting a little generated file won´t hurt, notice that you could add a warning like /* ======================================== this is a machine generated code modify xfile.l instead ========================================*/ I think that dealing with bison could make the build system a little more complex and remember that with the current one some people gets confused when starting. In fact lots of compilers source packages have both files in case you want to modify grammar rules the (.l .lex .y .ycc) and the .c in case you don´t have a parser generator, the gcc team does that and they are not the only ones, so seems to be a good choice. Regards Waldo Alvarez ________________________________ From: ros-dev-bounces(a)reactos.com on behalf of Robert Köpferl Sent: Wed 12/1/2004 4:16 PM To: ReactOS Development List Subject: [ros-dev] Very bad Idea. Sorry guys, but some of you never heared about (lets say) compiler and code. Never, never import generated artifacts into a VCS. The only thing allowed is doc and code (models). At a generated peace of code is not worked on (one mustn't). Instead one has to work on it's model (its source). This sadly implies that the matching tool (a compiler/transformer) must be available. As you mentioned: People will start working on generated code (baaaad). Also I hate projects where establishing a build env. seems like programming an app. But you can't ascribe everything back to Gcc as a minimum dominator. Gcc is not the high-level language to produce parsers. Try to run a make script with gcc :-/ Thus I am for adding bison to our tool list and against importing generated code (=not source). And think: Bison is litle more C++ affine than a Pascal compiler or the like. In my sight it's not harder than providing an archive which contains bison beneath mingw etc. If you want me to, I'd create that archive. Steven Edwards wrote: > Hi Alex, > > I understand everyones problem with bison and I agree with Filip, > Casper and GvG. Importing the generated C file in to CVS is fine as far > as I see it. The issue I worry about is people not submitting stuff > back toi Winehq and having thier code get lost in the merges. I have > some ideas about how to deal with this problem but I need to talk them > over with GvG, Eric, Filip and others that have done a lot of work on > ported Wine code. > > I have tried to address some of the other questions inline. > > --- Alex Ionescu <ionucu(a)videotron.ca> wrote: > >>All great points but I must ask, why should be bend our "rules" in >>order >>to be able to mingle cleanly with WINE, and why shouldn't they be the > > >>ones that should also try to be more flexible. From what you're >>saying >>(I have no personal experience to base this upon), it seems that they >>aren't trying very hard to make sure everything stays easily >>portable. I >>agree we need wine for the user dlls, but they also need our fixes to >>be >>easily implementable in their tree. > > > The Wine developers spent a year looking in to how to implement MSI you > would have come to the same answer they did and that was using bison to > generate the database was the best way to go. This is a tool that is > going to be used on Linux by Linux people for Linux people. I mean when > you talk about porting Wine you have to understand that Winelib runs on > Linux, Solaris, Mac OS/X. It does not get much more portable than that > for a Unix application. And yes its audited vs MS_VC from time to time. > I can build more of Wine with MS_VC than I can ReactOS. > > Most of the world still laughs at the ideal of ReactOS but Wine project > (and Mingw) have been one of our closest supporters. A good number of > the Wine developers lurk on this lists and try to do things to help > both projects. > > If you give a example of a real problem we have had working with them > so far then we can have that problem addressed in little to no time. > The Wine development process is a little slow but its also for all the > bad talk it gets one of the most stable and cleanest FreeSoftware > projects there is. I have never checked out Wine CVS and had the build > be broken, had a major regression that lasted more than a day or had > any problem getting a good answer as to why something could not go in > to CVS. > > >>I think the best solution is for everyone to work together, and to >>try >>to respect our project's guidelines. If they really need to do stuff >>their own way, we really need to do stuff our own way too. Maybe some > > >>sort of mega conversion tool could be built or something of the sort. >>I >>think WINE has gotten really far, but because they are such an old >>project, they are carrying a lot of cruft that needs to cleaned out >>(just like any other project). It would be unsensical to have to >>import >>such cruft (I'm not referring to Bison, but those x-level DLL >>messes). > > > This is not going to happen overnight. If you look at the revision > history of Wine you will see where Alexandre and the Wine team has > added many things to aid in our development. Supporting seperating the > Win16 and Win32 dlls in the build, adding cross-compiling support, > cleaning up the header dependancy mess in the Wine tree, removing > Wineisms/Unixisms etc.... > > An import/conversion tool would be nice and GvG started working on > making it a little less painful by adding support for Wine makefiles to > the build system. Importing some of the other Wine tools would make > things easy too such as WIDL and using the Wine headers but most of the > ReactOS does not want to do that. > > >>I don't see why the .C code would force everyone to use linux? Why >>would >>mingw32 not want to build it? Anyways, I restate, I'm against Bison > > > Sure and I am not opposed to having the generated sources imported in > the CVS. We already do this for the Wine Message Compiler that we have > used in ntoskrnl and kernel32 for years. > > Anyway if anyone has any ideas about how to make code sharing with Wine > more simple I am all ears. My patches to fix Wine building on MS_VC are > almost never rejected, ditto for the Win16/32 cleanups or anything else > that would make sharing code less of a pain. > > Thanks > Steven > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail - Helps protect you from nasty viruses. > http://promotions.yahoo.com/new_mail > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.com > http://reactos.com:8080/mailman/listinfo/ros-dev > _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev

1 0

RE: [ros-dev] HAL reorganisation
by Waldo Alvarez Cañizares 01 Dec '04

01 Dec '04

Hi Ge: Now that you talk it think that if some port is to be done that would be the ideal been a lot like the PC. IMHO the next could be a little endian well known arch. Regards Waldo ________________________________ From: ros-dev-bounces(a)reactos.com on behalf of Ge van Geldorp Sent: Tue 11/30/2004 5:21 PM To: 'ReactOS Development List' Subject: [ros-dev] HAL reorganisation As most of you know, I'm dabbling around a little bit with a port of ReactOS to the Xbox. I think most of the differences between a standard PC and the Xbox can be handled by using a custom HAL for the Xbox, after all, that's what the HAL is for. At the moment, we build 1 HAL, based on the value of MP in config it's either a UniProcessor HAL or a MultiProcessor HAL. Which code is compiled is based on preprocessor statements. I'd like to be able to build 3 HALs in parallel, the UP, MP and Xbox HALs. When installing ("make install"), the correct HAL would be selected based on the MP config var. When creating a boot cd, all three would be copied to the CD and the setup program would select the correct one to copy to the harddisk. This will allow us to build a single boot CD for different configurations. I'm aware that we'll need a NTKRNLMP.EXE on the boot CD too (I will try very very hard not to need a different kernel for Xbox) for this "single boot CD" idea to work, but that's a different problem and I'd like to tackle that later. The three HALs will share a lot of the code. To avoid code duplication, I propose to create a directory structure like this: hal | --- hal | --- halx86 | | | +----- generic | | | | | +----- include | | | +----- up | | | +----- mp | | | +----- xbox | +-- hal68k :-) | +-- etc... The "generic" subdir will contain most of the code. The "up" subdir will contain mostly simple .c files which just include a .c file from generic. For example, the HalMakeBeep() function will be defined in generic/beep.c. In "up" there will be a file beep_up.c which contains only 'include "beep.c"', which will be compiled with the include path set to "../generic". The "mp" and "xbox" directories can either include "generic" files or have their own implementation of a given routine (e.g. display_xbox.c for HalDisplay* functions on the Xbox). Doing it this way we should have little code duplication and our dependency tracking system should work. Comments? Gé van Geldorp. _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev

1 0

Re: [ros-cvs] CVS Update: reactos
by Filip Navara 01 Dec '04

01 Dec '04

greatlrd(a)cvs.reactos.com wrote: >CVSROOT: /CVS/ReactOS >Module name: reactos >Repository: reactos/lib/dinput/ >Changes by: greatlrd(a)mok.osexperts.com 04/12/01 07:20:14 > >Added files: > reactos/lib/dinput/: dinput.spec.def > >Log message: > forget add file dinput.spec.def > other wise dinput will not build > > This is wrong and this file should be autogenerated. Only the dinput.spec file should be in CVS! - Filip

2 1

RE: [ros-dev] HAL reorganisation
by Colin Burn 01 Dec '04

01 Dec '04

CXBX would not be suitable for developing ROS. CXBX doesn't try to emulate any of the hardware of an Xbox, it instead tries to convert an xbox executable (xbe) into a windows executable (exe). The conversion is done by locating DirectX calls in the xbe (Note: On an xbox the executables are directly linked to the DirectX libraries) and redirecting them appropriately under windows. -----Original Message----- From: Richard Campbell [mailto:eek2121@comcast.net] Sent: 01 December 2004 09:31 To: ReactOS Development List Subject: Re: [ros-dev] HAL reorganisation Keep in mind there is an XBOX emulator: CXBX available at http://www.caustik.com/cxbx/, that, though incomplete, runs at least 1 commercial game and might be complete enough to run an xbox port of ROS. Also, i'm sure you already know about the OpenXDK at http://www.openxdk.org/.

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev