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
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
> > 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
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
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
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.comShadoeWorld.com Correspondent
----------------------------------------------------------
Tired of a proprietary Windows on your computer ?
Use free ReactOS instead ( http://www.reactos.org )
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
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
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
