Ros-dev June 2006

ros-dev@reactos.org

39 participants
57 discussions

Re: [ros-dev] Wine libs vendor import
by Murphy, Ged (Bolton) 13 Jun '06

13 Jun '06

> > I spoke with Gé and he explained me the vendor import process in > > short. As soon as I find some time I will try out it myself and update > > the Wine libs in our SVN tree, if you don't mind. I have just updated comctl32 to 0.9.15, and will continue to keep this lib updated at every Wine release. Although r22329 was not mailed out via svn-diff (any ideas Aleksey??) I may also look after one or two other libs along with this. ************************************************************************ 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

Wine libs vendor import
by Aleksey Bragin 13 Jun '06

13 Jun '06

I'm answering to ros-dev so all developers could share their point of view (Klemens' original email is attached below). As I basically outlined in an irc conversation, there are 3 possible ways for us to sync with the Wine project: 1) Do manual syncs (the current way), keeping their code in our tree, building with our build system 2) Do auto-import of their source code into our tree, plus automatically detect changes in their build files and propogate them to our .rbuild files 3) Do binary-syncing of the dlls which are free from reactos and wine hacks, and do manual syncs for dlls which are forked (like setupapi which is better implemented, directx dlls which are partly shared and partly implemented differently, etc). However, it was not possible to easily come to a solution what to do. I will give a small overview of all ways: 1) We lag behind, providing outdated, featureless and buggy version of dlls. And even more, we depend on dlls bugs, reactos hacks in them. Syncing them requires time and constant efforts. From the good side we have absolute control over the libraries - we can enable/disable debug messages, build them for different architectures, optimize for different CPUs etc 2) This could sound like an ideal way, because it keeps advantages of 1. plus removing disadvantages of having to waste time doing syncs. However conversion from Wine's build system makefiles to ReactOS's build system .rbuild isn't trivial. Plus developing an auto-syncer between Cvs/Git and our SVN doesn't look like an easy task too. 3) Reduces compilation time, however wine dlls are built on another server, and just downloaded during build process (or kept in SVN server in binary form). It'd be needed to adjust building mechanism to be able to produce other platform binaries. Updates will be "heavy" (but initial download smaller). I'm listening to your (all ReactOS and Wine devs) comments, and probably I will write answers to Klemens' email later. WBR, Aleksey Bragin. On Jun 12, 2006, at 2:35 PM, Klemens Friedl wrote: > Hi Aleksey, > > I spoke with Gé and he explained me the vendor import process in > short. As soon as I find some time I will try out it myself and update > the Wine libs in our SVN tree, if you don't mind. > > Or do you want to switch to a binary wine files in trunk anyway? > > I will try to update Wine files about every months after the first > time, if that is okay. The changes of wine 0.9.x of every two week are > minor things so, every months should be fine. sdwards mentioned that > timeframe too, as we discussed about that topic about one week ago on > #winehackers and #reactos (the first time). > > btw. Gé mentioned there ARE reasons why our Wine libs DO differ from > WineHQ's one. Well Gé is not a ros dev anymore but he had not done the > vendor import work and maintain all the changes for fun, it's > important to have our adjustments in there. > Imagine for example all icons would got lost. > > Wine does use Unix specific functions like "unixfs" in several libs, > the sound libs will get a lot different in near future too > (silverblade is working in this area) and several directx libs. So a > quick auto vendor import won't work anyway. > > > In my opinion, the binary idea is not worth any efford: > > In my opinion, binary files on in a svn dir is a very bad solution. > You cannot view the source and commit the changes, you have to > download all binary files every time (every 2 weeks), binary files are > not portable, etc. > The advantages of source code is in addition to the oposite of the > facts above that you have to download only the diffs of the file > changes (svn client does that for you) and that have everything > (source) on your local hdd. > Sure the build-time would decrease about 10-15% if we use binary > files, but i don't bother about 15% time. > > And please shift the wine lib conversation to ros-dev(a)reactos.org. > The irc chat is not suitable for such a discussion where more than 3-4 > devs are involved. It is not possible to answer to more then one msg > the same time. And while you write, several other persons post other > msg's. > Mailing lists does have a purpose and does make sense here! > E-Mail's are written in a better english, no short abbreviations, etc. > and the devs does think a bit longer about what the write (no offence > here!). > > > Best regards, > Klemens

3 2

Kernel-mode COM: PORTCLS.SYS and sound
by Andrew "Silver Blade" Greenwood 09 Jun '06

09 Jun '06

Someone on this mailing list gave me a crash-course on using COM (possibly KJK, but it was a while ago so I'm not sure.) Anyway, I'm fairly comfortable with the various macros and sort of understand how it works now. == SOUND ARCHITECTURE == I've been told that Windows Vista has a new user-mode set of audio/multimedia APIs, which replace kernel-mode streaming. Evidently most of the kernel-mode components for this no longer exist in Vista. Instead, communication goes via user-mode components until PORTCLS.SYS, the only remaining kernel-streaming related component. PORTCLS.SYS interacts with WDM audio drivers. WDMAUD.DRV interacts with the MME API (winmm.dll). So the path from the MME API to the WDM driver may be different, but older applications and drivers should see no difference there. I think implementing the audio system used in Vista would be a good thing to do - since the kernel streaming components have been completely removed from Vista, there is no point in implementing them in ReactOS. There should be no reason why an NT4 audio driver wouldn't work even on Vista, and XP drivers should work too. Obviously this won't be the case, though, as all drivers will probably need to be designed specifically for Vista. My point however, is that the MME API has changed slightly, but will still work with older drivers. (As a side-note, I recall that our implementation of WINMM.DLL - as copied over from WINE - doesn't appear to deal with Plug and Play at all. This is something that will need to be remedied.) == PORTCLS.SYS : COM IN THE KERNEL == This took a while for me to get my head around, and I'm at the stage now where I can happily declare a COM interface or class. But I'm having difficulty figuring out how I should actually create an instance of one in the kernel. Apparently, there exists some kernel equivalent of CoCreateInstance. In any case, I'd prefer to work with classes using C++, which I believe can be done with COM. So I just need to know how to implement a COM class using C++. Up until now I've guessed it as being: class IBlahBlah_Impl : public IBlahBlah Is this right? I'm working on the IPort code at the moment, and am wondering how to implement this: PORTCLASSAPI NTSTATUS NTAPI PcNewPort( OUT PPORT *OutPort, IN REFCLSID ClassId) { /* ClassId must be one of: CLSID_PortDMus (IPortDMus) defined in dmusicks.h CLSID_PortMidi (IPortMidi) CLSID_PortTopology (IPortTopology) CLSID_PortWaveCyclic (IPortWaveCyclic) CLSID_PortWavePci (IPortWavePci) */ } Yes, it's just a commented function. From the documentation, the caller passes one of the CLSID's from the above list, and receives a pointer to an IPort. Question is, how do I compare the parameter with one of the CLSIDs? And again, how do I create an instance of the class in kernel-mode? If anyone can shed a little light on this, I'd appreciate it. -Andrew

1 0

CD Logo
by David Johnson 07 Jun '06

07 Jun '06

Any thoughts? -- Dave Johnson http://www.davefilms.us DaveFILMS(r) http://thevoicezone.us The Voice Zone™ Voice Talent Writer, Producer, Director Independent Audio Theater Producer http://www.perditioncity.us voiceoverjobs(a)gmail.com Member of the Darker Projects team. http://www.darkerprojects.com ShadoeWorld.com Correspondent ---------------------------------------------------------- Tired of a proprietary Windows on your computer ? Use free ReactOS instead ( http://www.reactos.org )

5 9

Target Hardware
by David Johnson 06 Jun '06

06 Jun '06

I would like to propose a target hardware list. Like a type of motherboard that should be used. Sound card and video card. Thoughts? -- Dave Johnson http://www.davefilms.us DaveFILMS(r) http://thevoicezone.us The Voice Zone™ Voice Talent Writer, Producer, Director Independent Audio Theater Producer http://www.perditioncity.us voiceoverjobs(a)gmail.com Member of the Darker Projects team. http://www.darkerprojects.com ShadoeWorld.com Correspondent ---------------------------------------------------------- Tired of a proprietary Windows on your computer ? Use free ReactOS instead ( http://www.reactos.org )

3 2

Trunk Foobared
by Alex Ionescu 06 Jun '06

06 Jun '06

Hi, I am aware that I broke trunk. This is because I've removed the code in ObReferenceObjectByHandle which allowed GENERIC access masks to be converted. This API does NOT support GENERIC access masks and converting to them was incorrect, however, as always, plenty of code in ROS abused the system and calls this API incorrectly. Although ObOpenObjectByName should return a handle and IoCreateFile should be done with it, because parsing is broken (so it creeps up again!), we try to re-reference it by handle to get its pointer... however, this attempt is made with the current AccessMode, which happens to be User, and if the AccessMask was GENERIC... we fail. ObOpenObjectByName is made to be used with GENERIC access masks so that's really not a problem. Hopefully the I/O File stuff is the only place where this happens, so I will implement a simple hack - call ObReferenceObjectByHandle with a KernelMode parameter so that access checks are skipped (we've already done them in ObOpenObjectByName anyways!). Best regards, Alex Ionescu

1 1

Policy question
by Myria 06 Jun '06

06 Jun '06

Should ReactOS copy unnecessary restrictions that Windows has? The example I'm thinking of is NtSetLdtEntries. In Windows NT (and currently ReactOS as well), this function will not let you create an LDT entry whose limit is above the user/kernel barrier. This restriction sounds like it was made with security in mind, but it doesn't affect security. The processor's page table will already block access to kernel memory no matter what selector you use. After all, the default user CS and DS already have a limit of FFFFFFFF. Should such a problem be fixed? Fireball said "no, unless some 3rd party app or driver depends on them" when I asked about whether such restrictions should be copied. Pretty much the only thing using NtSetLdtEntries is NTVDM, and this restriction already causes some DOS programs to break that would otherwise work. (Such programs are usually setting selectors that wrap the address space.) Melissa

3 5

ULONG vs. SIZE_T
by Myria 05 Jun '06

05 Jun '06

I've noticed that in the ReactOS source code, there are many places where a parameter or structure is ULONG when it should really be SIZE_T. Using ULONG instead of SIZE_T is not portable. It will be difficult to port ReactOS to x64 and Itanium in the future because of this. I think the project should stop the bleeding by requiring all new code to make proper use of ULONG versus SIZE_T. This does mean going against the documentation of native syscalls on the Internet, but it must be done sometime. Of course, I'm not really part of the project... Melissa

3 2

X-Chat 2
by James Tabor 05 Jun '06

05 Jun '06

Hi all Could be all based on wine patches, I can no longer get xchat 2 and the new one to run. I noticed it can not find the lib directory in the launch directory. Wine has this problem too. Also when installing the new X-Chat 2 from http://www.silverex.org/download/xchat-2.6.2-1.exe, It installs the Font to C:\ReactOS\Fonts not C:\ReactOS\media\fonts. I had to create C:\ReactOS\Fonts so I can have a clean install. I tested my GGO patch and the SVN and the result are the same. Okay, wine does this too, I tested it. (dll/ntdll/ldr/utils.c:2019) Failed to create or open dll section of 'libgtk-win 32-2.0-0.dll' (Status c0000135) (dll/ntdll/ldr/utils.c:1347) failed to load libgtk-win32-2.0-0.dll (dll/ntdll/ldr/utils.c:1812) failed to load libgtk-win32-2.0-0.dll (dll/ntdll/ldr/utils.c:1934) LdrFixupImports() failed for xchat.EXE (dll/ntdll/ldr/startup.c:485) Failed to initialize image Then do it from lib, "..\xchat" (dll/ntdll/ldr/utils.c:2019) Failed to create or open dll section of 'pango-1.8.2/lib/pango/1.4.0/modules/pango-basic-win32.dll"' (Status c0000135) You will get a popup. This has been a problem for years! Thanks, James

1 0

Break in 22232
by James Tabor 05 Jun '06

05 Jun '06

Hi, I'm getting this with Mozilla, Firefox and SeaMonkey. KeBugCheck at ntoskrnl/cm/regobj.c:528 A problem has been detected and ReactOS has been shut down to prevent damage to your computer. Technical information: *** STOP: 0x00000051 (0x00000000,0x00000000,0x00000000,0x00000000) Frames: <ntoskrnl.exe:1d50 (ntoskrnl/ke/bug.c:493 (KeBugCheckEx))> <ntoskrnl.exe:1d67 (ntoskrnl/ke/bug.c:514 (KeBugCheck))> <ntoskrnl.exe:129c6 (ntoskrnl/cm/regobj.c:528 (CmiObjectDelete))> <ntoskrnl.exe:52c6b (ntoskrnl/ob/oblife.c:151 (ObpDeleteObject))> <ntoskrnl.exe:1290c (ntoskrnl/cm/regobj.c:523 (CmiObjectDelete))> <ntoskrnl.exe:52c6b (ntoskrnl/ob/oblife.c:151 (ObpDeleteObject))> <ntoskrnl.exe:50f4c (ntoskrnl/ob/obhandle.c:153 (ObpDecrementHandleCount))> <ntoskrnl.exe:510b0 (ntoskrnl/ob/obhandle.c:244 (ObpDeleteHandle))> <ntoskrnl.exe:52166 (ntoskrnl/ob/obhandle.c:1125 (NtClose))> <ntoskrnl.exe:66527 (ntoskrnl/ke/i386/trap.s:306 (KiFastCallEntry))> <ADVAPI32.dll:7dd9 (dll/win32/advapi32/reg/reg.c:1178 (RegDeleteKeyA))> All three are the same, James

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev June 2006