Ros-dev December 2004

ros-dev@reactos.org

62 participants
119 discussions

RE: [ros-dev] SYSCALL instruction
by Waldo Alvarez Cañizares 27 Dec '04

27 Dec '04

Hi Filip: Yes that could work better so we have a single DLL and that does not consume RAM anyway ReactOS would be ready for a CPU downgrade too. btw I built some cvs snapshot today and saw the OARCH flag in the configuration file, the cpls being worked out mesa building (usable?), some text strings not in source code anymore. It failed at some point compiling explorer and I really needed to leave home but i'll keep playing with it for a while (not too much am on final exams almost) Regards Waldo ________________________________ From: ros-dev-bounces(a)reactos.com on behalf of Filip Navara Sent: Thu 12/23/2004 12:37 PM To: ReactOS Development List Subject: Re: [ros-dev] SYSCALL instruction Waldo Alvarez Cañizares wrote: >Another thing that could be done is to detect the CPU at some time during initialization and use one of two ntdll (on with SYSCALL an another without it). > It's implemented in WinXP much easier than that. On startup it's detected if the processor supports SYSCALL and the appropriate code is sticked into the user shared page. The user mode code then just does jmp at the place in user shared page and it uses the correct code. Easy ;-) - Filip _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev

1 0

Linux build && _mingw.h
by David Kredba 26 Dec '04

26 Dec '04

Hello. I have problems on linux with missing _mingw.h with both gcc-3.4.1 and 3.4.2. It is probably caused by the last cvs commit to reactos/include/msvcrt/string.h file. There is mingw32/include/_mingw.h in the cross compiler directory. Thanks, David ROS Version : 0.3-CVS (Build 20041226) ar: creating zlib.host.a In file included from ../../include/tchar.h:41, from ../../include/tgetopt.h:4, from ../../include/getopt.h:1, from /usr/include/unistd.h:783, from ../../include/wine/port.h:44, from import.c:23: ../../include/msvcrt/string.h:42:20: _mingw.h: není souborem ani adresářem make[2]: *** [import.o] Error 1

2 7

PCTV Rave - Driver loading problem
by Gge 26 Dec '04

26 Dec '04

I am testing the PCTV Rave from Pinnaclesystem . Hivesys.inf was setup accordingly and the Pctvrave drivers installed (bt848.sys,stream.sys,ks.sys) The drivers of this Tuner TV card starts to load but fails to initialize as per Debug messages below The driver is from http://btwincap.sourceforge.net/ Please anybody have a look ? Thanks Gerard -------------------------------------------------------------------- DriverBase for \SystemRoot\system32\drivers\bt848.sys: dce37000 DriverBase for \SystemRoot\system32\drivers\STREAM.SYS: dcea8000 DriverBase for \SystemRoot\system32\drivers\ks.sys: dcedc000 (ldr/loader.c:1476) LdrPEGetExportByName(): failed to find ExSemaphoreObjectType (ldr/loader.c:1561) Failed to import ExSemaphoreObjectType from ntoskrnl.exe (ldr/loader.c:373) Could not process module (ldr/loader.c:319) Could not open module file: \SystemRoot\system32\ks.sys (ldr/loader.c:1323) Unknown import module: ks.sys (Status c0000034) (ldr/loader.c:373) Could not process module (ldr/loader.c:319) Could not open module file: \SystemRoot\system32\STREAM.SYS (ldr/loader.c:1323) Unknown import module: STREAM.SYS (Status c0000034) (ldr/loader.c:373) Could not process module (io/pnpmgr.c:1518) Initialization of service pctvrave failed (Status c0000034) (io/pnpmgr.c:1452) IopActionInitChildServices(ccc227e8, ccc40ef8, 0) DriverBase for \SystemRoot\system32\drivers\bt848.sys: dcefd000 DriverBase for \SystemRoot\system32\drivers\STREAM.SYS: dcf59000 DriverBase for \SystemRoot\system32\drivers\ks.sys: dcf66000 (ldr/loader.c:1476) LdrPEGetExportByName(): failed to find ExSemaphoreObjectType (ldr/loader.c:1561) Failed to import ExSemaphoreObjectType from ntoskrnl.exe (ldr/loader.c:373) Could not process module (ldr/loader.c:319) Could not open module file: \SystemRoot\system32\ks.sys (ldr/loader.c:1323) Unknown import module: ks.sys (Status c0000034) (ldr/loader.c:373) Could not process module (ldr/loader.c:319) Could not open module file: \SystemRoot\system32\STREAM.SYS (ldr/loader.c:1323) Unknown import module: STREAM.SYS (Status c0000034) (ldr/loader.c:373) Could not process module (io/pnpmgr.c:1518) Initialization of service pctvrave failed (Status c0000034) (io/pnpmgr.c:1452) IopActionInitChildServices(ccc22910, ccc40ef8, 0) (io/pnpmgr.c:1523) Service <NULL> is disabled or already initialized (io/pnpmgr.c:1452) IopActionInitChildServices(ccc22a38, ccc40ef8, 0) (io/pnpmgr.c:1523) Service <NULL> is disabled or already initialized (io/pnpmgr.c:1452) IopActionInitChildServices(ccc22b60, ccc40ef8, 0) (io/pnpmgr.c:1523) Service <NULL> is disabled or already initialized (io/pnpmgr.c:1452) IopActionInitChildServices(ccc22c88, ccc40ef8, 0)

2 1

Patch for win32k/eng/gradient.c
by Stephen Hodges 26 Dec '04

26 Dec '04

This fixes the build error for building with optimized = 1 , DBG =1 Stephen Hodges Cell: (786)256-0339 AIM: theteofscuba Web: http://www.thespoke.net/MyBlog/stevo/MyBlog.aspx

8 13

RE: [ros-dev] Binary download
by Murphy, Ged (Bolton) 24 Dec '04

24 Dec '04

On occasions I have grabbed the latest binaries and replaced the ReactOS folder. It always works for me and seems to be a very quick and easy way of updating ROS without the need for burning a CD everytime. I would say the binaries are very useful Gedi -----Original Message----- From: Jason Filby [mailto:jason.filby@gmail.com] Sent: 23 December 2004 20:07 To: ReactOS Development List Subject: [ros-dev] Binary download Hi all Do we really need the binary download anymore? The binary is highly downloaded, but I suspect that those that do download it then proceed to the iso/livecd/bochs/qemu downloads which are more usable (if they aren't too frustrated at that point). Should we remove it? Does anyone object to that? Cheers Jason _______________________________________________ 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

3 4

RE: [ros-dev] Binary download
by Murphy, Ged (Bolton) 24 Dec '04

24 Dec '04

-----Original Message----- From: Casper Hornstrup [mailto:chorns@users.sourceforge.net] Sent: 24 December 2004 11:13 To: 'ReactOS Development List' Subject: RE: [ros-dev] Binary download > It was to be dropped for releases only, not daily builds. The > registry is more likely to change from release to release than > from day to day. If you are living on the edge and are using the > daily builds then you are on your own and need to handle the > errors that can occur from overwriting the installation with > the binaries (eg. by making a clean install). Hi Casper. For some reason I assumed we were talking about the binaries on your site. If your only talking about dropping the binaries on major releases via sourceforge, then I don't see this causing a problem. Gedi. ************************************************************************ 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

RE: [ros-cvs] CVS Update: reactos
by Casper Hornstrup 24 Dec '04

24 Dec '04

Unless it will fix a bug this shouldn't go to the release branch. PS. We should write some rules in wiki about preparing for releases. I can make a draft version unless someone else already beat me to it. Casper > -----Original Message----- > From: ros-cvs-bounces(a)reactos.com > [mailto:ros-cvs-bounces@reactos.com] On Behalf Of > royce(a)cvs.reactos.com > Sent: 23. december 2004 22:01 > To: ros-cvs(a)reactos.com > Subject: [ros-cvs] CVS Update: reactos > > CVSROOT: /CVS/ReactOS > Module name: reactos > Repository: reactos/subsys/win32k/eng/ > Changes by: royce(a)mok.osexperts.com 04/12/23 22:01:13 > > Modified files: > reactos/subsys/win32k/eng/: Tag: ros-branch-0_2_5 gradient.c > > Log message: > IntEngGradientFill() fix ASSERT statements > > _______________________________________________ > Ros-cvs mailing list > Ros-cvs(a)reactos.com > http://reactos.com/mailman/listinfo/ros-cvs >

2 1

RE: [ros-dev] Binary download
by Murphy, Ged (Bolton) 24 Dec '04

24 Dec '04

-----Original Message----- From: Jason Filby [mailto:jason.filby@gmail.com] Sent: 24 December 2004 10:06 To: ReactOS Development List Subject: Re: [ros-dev] Binary download > Sounds good; but what about registry entries that have been created by > applications; would such an update wipe the registry or just add new > entries and modify system entries? That's a good point. I suppose for that to work, it would need someone to write an update script every day to patch the existing system. That doesn't seem viable. It takes M$ a month to do theirs, lol. What would be the best way of updating an existing system without the need to a complete reinstall from a CD. Burning a CD everyday to get the latest binaries would become tedious and expensive. Ged. ************************************************************************ 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

2 1

Binary download
by Jason Filby 24 Dec '04

24 Dec '04

Hi all Do we really need the binary download anymore? The binary is highly downloaded, but I suspect that those that do download it then proceed to the iso/livecd/bochs/qemu downloads which are more usable (if they aren't too frustrated at that point). Should we remove it? Does anyone object to that? Cheers Jason

2 2

RE: [ros-dev] more sharing with Wine?
by Waldo Alvarez Cañizares 23 Dec '04

23 Dec '04

Hi guys: May I suggest something? I believe that the current code flow ros-wine is something like this Let's hope this ASCII drawing won't break on the way ROS developers WINE developers | | | | v v ROS Code <--- merges ---> WINE Code ^ | ---- Here seems that things won't merge quite well sometimes that takes considerable work and also a source of lost work. So what about this? I beleive it will be better for everybody in the long run. ROS developers ------- (ROS + WINE changes) -----><--------------- WINE developers | | | (ROS only changes) | v v ROS code in <--- Automatic Mirroring (scripts?)---- WINE code in cvs server (subversion?) of common code I bet WINE people will be happy with this without doubt (thing won't change too much for them) I guess there will be some friction at the beginning here(maybe) because now ROS developers have to use both systems also ROS code implementing things not present or better than the one in wine will need to be merged into WINE but the good part is that is only once. Also ROS needs to be changed to be able to receive WINE code without changes but again this is only once and also does not needs to be done for all dlls/applications at once. I suggest to do this in small scale to see how it works. Well guys you all know more about this than me so I guess you could improve this. Regards Waldo Alvarez ________________________________ From: ros-dev-bounces(a)reactos.com on behalf of Alex Ionescu Sent: Tue 12/21/2004 1:41 PM To: ReactOS Development List Subject: Re: [ros-dev] more sharing with Wine? Gunnar Dalsnes wrote: > Hi, > > I'm tired of fixing bugs in code ported from wine <x> years ago. In > most cases the bugs has already been fixed in the wine code we ripped > from, but the ros variant is forked so much its impossible to inc. > those fixes into ros, so the only choice is to rip the whole wine > source over again, loosing any possible fixes/improvements we had made > to the ros variant vs. the wine variant. > > Take for example the file lib\kernel32\misc\profile.c. This file is > 99.9% unchanged from wine, and only includes and some prototypes > needed changes. I want to move files like this into wine subdirs. like > lib\kernel32\misc\wine\profile.c and generate an initial diff > lib\kernel32\misc\wine\profile.diff with changes made to make it run > on ros using the wine porting headers. It does not mean that this diff > will contain ERR changed to DPRINT etc. Only the bare changes to make > it compile. Moving files into wine dirs in off course not necesary, > but it makes it clear that this file(s) are shared thus there are > rules to follow when changing them. > > I have made scripts that updates our profile.c, using the profile.diff > and any updated profile.c from wine, and i have made a script for > generating patches that we send to wine. It all seems to work fine. > HELP: where does the winehq2ros.patch files used in comctl32 etc. fit > into this? > > The only problem is wines strange unicode strings, their FIXME, ERR > etc. and indentation. I think its worth it if we can share more, but > dunno if the majority agrees. > > From what i can see, much of kernel32 and ntdll can be shared this > way, and probably much stuff in user32/gdi32 also. > > Regards > Gunnar Personally, what bugs me is that if Wine fixes something, it's our responsability to merge it and cope with it. If we fix something, it's still our responsability. This latter statement bugs me. Of course it's up to us to implement Wine's changes, but why should we be the ones that also send our pathces back to wine, and have them all formatted back into Wine mode. It seems unfair to me that they don't submit their bug fixes to us, and it's up to us to sync and make them proper, while it's ALSO up to us to wineize our patches and send them to Wine. Anyways, whatever tool/script makes importing Wine's code into ROS and making it look nice is 100% OK with me. Best regards, Alex Ionescu _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev

3 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev December 2004