Ros-dev

ros-dev@reactos.org

5790 discussions

Re: [ros-dev] SUSPICIOUS: SESSION_5 BSOD
by Murphy, Ged (Bolton) 14 Jun '06

14 Jun '06

Alex Ionescu wrote: > In defense to Hervé, you actually need to clean *TWICE*. That's right, > you must write: > make intrlck_clean && make intrlck_clean & make ntdll_clean & make > ntdll_install. What does running 'make intrlck_clean' do the second time which it doesn't do the first time round? ************************************************************************ 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

Disk Controller Install Failure
by James Tabor 14 Jun '06

14 Jun '06

Hi all! When the install popup for the disk controller is displayed. I can install from and select everything but NEXT! Select *Next* this will happen, (tested this 4 times now, same thing) (dll/win32/newdev/newdev.c:745) Installing Other ACPI device (ACPI\PNP0C04\1&7313ac9&0000) (dll/win32/newdev/newdev.c:466) Include removable devices: no (dll/win32/newdev/newdev.c:467) Include custom path : no (dll/win32/newdev/newdev.c:534) Installing driver (Generic system devices): Math coprocessor (dll/win32/newdev/newdev.c:745) Installing Disk controller (ACPI\PNP0700\1&7313ac9&0000) (dll/win32/newdev/newdev.c:466) Include removable devices: no (dll/win32/newdev/newdev.c:467) Include custom path : no (dll/win32/shell32/classes.c:381) HCR_GetFolderAttributes should be called for simple PIDL's only! (dll/win32/shell32/shellpath.c:1688) Failed to create directory 'L".\\Desktop"'. (dll/win32/newdev/newdev.c:466) Include removable devices: yes (dll/win32/newdev/newdev.c:467) Include custom path : no KeBugCheckWithTf at ntoskrnl/ke/i386/exp.c:1241 A problem has been detected and ReactOS has been shut down to prevent damage to your computer. The problem seems to be caused by the following file: ntoskrnl.exe Technical information: *** STOP: 0x0000001E (0xC0000005,0x80033CF6,0x00000000,0x00000030) *** ntoskrnl.exe - Address 0x80033CF6 base at 0x80000000, DateStamp 0x0 Page Fault Exception: 14(0) Processor: 0 CS:EIP 8:80033cf6 <ntoskrnl.exe:33cf6 (ntoskrnl/io/file.c:970 (IoCreateFile))> cr2 30 cr3 3be68000 Proc: 8178f328 Pid: d8 <umpnpmgr.exe> Thrd: 817a4558 Tid: e8 DS 23 ES 23 FS 30 GS 0 EAX: 00000000 EBX: 9fa43c34 ECX: 000023be EDX: 81f5d6e4 EBP: 9fa43cf0 ESI: 00000000 ESP: 9fa43b50 EDI: 00000000 EFLAGS: 00010296 kESP 9fa43b50 kernel stack base 9fa3e000 Frames: <ntoskrnl.exe:3459a (ntoskrnl/io/file.c:1527 (NtCreateFile))> <ntoskrnl.exe:66657 (ntoskrnl/ke/i386/trap.s:306 (KiFastCallEntry))> <KERNEL32.dll:9c6f (dll/win32/kernel32/file/volume.c:57 (InternalOpenDirW))> I think my hardware is not ReactOS compatible. Thanks, James

1 1

SESSION_5 BSOD
by Alex Ionescu 14 Jun '06

14 Jun '06

Hi, Annoyed by the ever-growing blame on my patches as well as the continuing lack of attention regarding the SESSION_5 BSOD, I've taken the liberty to momentarily put on hold my current paid work and take a look at the issue (which thankfully only took 30 minutes). As I suspected, it has absolutely nothing to do with any Ob stuff and is the result of ntdll being messed up after the recent changes to lib\intrlck. Revert them, clean interlck/ntdll, rebuild, and voila, you're back to a working ROS. In defense to Hervé, you actually need to clean *TWICE*. That's right, you must write: make intrlck_clean && make intrlck_clean & make ntdll_clean & make ntdll_install. It is *NOT* enough to merely write ntdll_clean, either. I'm going to assume that Hervé only cleaned interlck once (as anyone would normally do) and kept using the "correct" library. As soon as he (and others) built a new copy of the tree (probably around one of my patches), the interlck lib now got cleaned twice and the broken one started coming into use. Score one for my complaints against rbuild. If I could give some advice, next time, spend less time assigning blame on me, and actually try to find the bug (yes, this sounds arrogant, but it DOES get annoying to be the poster boy for boot BSODs. The last one I caused was over 12 months ago). Best regards, Alex Ionescu

2 2

ROS A memory hog? Rubbish!
by Alex Ionescu 13 Jun '06

13 Jun '06

Hi, With ROS_LEAN_AND_MEAN and DBG = 1, with all drivers and the bells and whistles, a boot to NCLI with 8MB gave me a working system with still 2MB to spare (perhaps for a native FTP server or other application). If I remove the network layer, I can boot with 6MB, and I still have 1MB free. I'm trying with DBG = 0 now. Maybe I can boot with 4MB :D. Best regards, Alex Ionescu

4 4

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

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