I know I've mentioned this before, but I'll do it officially now :)
Can we change the text format svn-diff sends its messages In from rich text
to plain text?
Every diff I read, I have to click 'reply' first in order for it to be
readable. (my client changes to plain text when replying)
Diff's in rich text are pretty ugly and difficult to follow.
Cheers,
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
Hi all!
I've installed 0.3RC1 on HD. Besides that it didn't overwrite
the MBR, the install went fine.
* FireFox 1.5.0.4 doesn't install correctly - XUL error window
pops up at startup.
* when dragging and dropping a file in explorer from CD to the
desktop, it immediately shut down the box, just like pulling
the plug. Later drag/drop in explorer didn't work at all.
* when trying to install other progs (clicking on the install
EXE) nothing happens - not even an error dialog
* tried to install the Java Runtime - installation went fine,
but there are no java related files anywhere, except
Program Files\Java\jre1.5.....\COPYRIGHT
Let me know if you want some details and how I can provide them.
I'm primarily a linux geek ;-)
Best regards,
Hannes.
Since our MmNotPresentFault handler and kin need to lock the
associated MADDRESS_SPACE, we often need to lock an address space
when it's already been locked. Until now, this has caused a
recursive acquisition of a kernel mutex.
The current kernel bugchecks for me when running the wget binary
here:
http://www.superheterodyne.net/reactos/mm_edit/wget.exe
So I've added a boolean to MADDRESS_SPACE to specify that it's been
locked and propogated its use (and also disentangled this flag from
the one specifying that pages are locked in various cases).
The patch is here:
http://www.superheterodyne.net/reactos/mm_edit/mm.diff
There's a sore spot in section.c at line 684 where I got a bugcheck,
but it was easy enough to check for a NULL region. This probably
isn't right however.
jimtabor was seeing bugchecks at startup that are at least
apparently solved by this patch, but I'm sure that those more in
tune with the kernel can weigh in on whether we should do something
like this or whether the real problem is deeper or different.
--
Discordant is the murmur at such treading down of lovely things while
god's most lordly gift to man is decency of mind. Call that man only
blest who has in sweet tranquility brought his life to close.
If only I could act as such, my hope is good.
-- Aeschylus' Agamemnon (translated by H. W. Smyth)
sata harddisk support needed
2006/6/20, ros-dev-request(a)reactos.org <ros-dev-request(a)reactos.org>:
>
> Send Ros-dev mailing list submissions to
> ros-dev(a)reactos.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.reactos.org/mailman/listinfo/ros-dev
> or, via email, send a message with subject or body 'help' to
> ros-dev-request(a)reactos.org
>
> You can reach the person managing the list at
> ros-dev-owner(a)reactos.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Ros-dev digest..."
>
>
> Today's Topics:
>
> 1. 0.3.0 RC1 Update (Brandon Turner)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 19 Jun 2006 12:48:35 -0400
> From: Brandon Turner <turnerb7(a)msu.edu>
> Subject: [ros-dev] 0.3.0 RC1 Update
> To: ReactOS Development List <ros-dev(a)reactos.org>
> Message-ID: <4496D563.5090201(a)msu.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> I have added a debug bootcd build of RC1 to sourceforge. So anyone out
> there looking to get there hands one for troubleshooting 0.3.0 can hop
> on there and grab it.
>
> Brandon
>
>
> ------------------------------
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
> End of Ros-dev Digest, Vol 22, Issue 23
> ***************************************
>
I have added a debug bootcd build of RC1 to sourceforge. So anyone out
there looking to get there hands one for troubleshooting 0.3.0 can hop
on there and grab it.
Brandon
After I made some german translation updates and new translations, I
spotted a small problem. I dont know if you see a problem here, but
thats why I post it here. While looking through the .rc Files I found
out that most apps use one font (Most use MS Shell Dlg which I think is
the best one) but not all. Some use Tahoma, others use MS Sans Serif and
one even uses Bitstream Verdana. I think this way it does not look like
a professional work. It more looks like a thrown together bunch of work,
which does not fit together. Especially if a app uses different fonts in
some parts than in others. Thats why I made some patches to set the Font
to MS Shell Dlg Size 8 except for Asian Languages (Like XP uses it and
we should do, too for compatibility) and talked to frik85 about it. He
said I should ask you all and that's what I do here. How do you think
about it?
Daniel "EmuandCo" Reimer
What are we waiting on for this now?
I see RC1 still isn't on sourceforge, I thought this was meant to be out a
few weeks ago??
Can someone list the requirements and any potential blockers to try and
prompt some action
Cheers,
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
I've been trying to sync riched20 for the past hour but am not getting
anywhere.
Our last sync was 0.9.5, but since then quite a bit more code has been
added.
The 2 problematic lines are in 0.9.15, editor.c, lines 1093 and 1912.
They refer to IRichEditOleCallback callbacks in richole.idl, which is
new for us.
I'm not familiar with idl files, but we seem to implement them in
/include/reactos/idl.
I've tried dropping the idl in there, creating the respective .acf and
modding the rbuild file.
However I'm still having problems.
Can anyone shed any light on this?
I've dropped 0.9.15 into our vendor dir, if anyone wants to sync it for us.
It's a straight sync, we have no ROS specific code in this lib.
Ged
Hi all!
This is the hivesys.inf PCNet section. I copied fetnd5a.sys to pcnet.sys.
I can query network properties w/o a crash! All I get is IPHLPAPI.dll need
more work and GetAdapterInfo did not return the expected data.
Bus 0, device 18, function 0, Ven 1106/Dev 3065/class 0200.
Start->Settings->Settings Menu->Network Properties
Select VT6102->Properties, get the VIA PCNet Status Menu, select Properties,
get the VIA PCNet Pro~ Menu, select Internet Protocol (TCP/IP), select
Properties, get the Error menu.
Wow! Did not crash!
Need to check if I'm on the right track here!
Thanks,
James
; ReactOS PCNet NIC driver
; To use the AMD supplied driver change the driver name to pcntn5m.sys
;
HKLM,"SYSTEM\CurrentControlSet\Services\PCNet","ErrorControl",0x00010001,0x00000000
HKLM,"SYSTEM\CurrentControlSet\Services\PCNet","Group",0x00000000,"NDIS"
HKLM,"SYSTEM\CurrentControlSet\Services\PCNet","ImagePath",0x00020000,"system32\drivers\pcnet.sys"
HKLM,"SYSTEM\CurrentControlSet\Services\PCNet","Start",0x00010001,0x00000003
HKLM,"SYSTEM\CurrentControlSet\Services\PCNet","Type",0x00010001,0x00000001
HKLM,"SYSTEM\CurrentControlSet\Services\PCNet\Enum","0",0x00000000,"PCI\VEN_1106&DEV_3065\0000"
HKLM,"SYSTEM\CurrentControlSet\Services\PCNet\Enum","Count",0x00010001,0x00000001
HKLM,"SYSTEM\CurrentControlSet\Services\PCNet\Enum","NextInstance",0x00010001,0x00000001
HKLM,"SYSTEM\CurrentControlSet\Enum\PCI\VEN_1106&DEV_3065&SUBSYS_01021106&REV_10\0000","Service",0x00000000,"PCNet"
HKLM,"SYSTEM\CurrentControlSet\Enum\PCI\VEN_1106&DEV_3065&SUBSYS_01021106&REV_10\0000","Class",0x00000000,"Net"
HKLM,"SYSTEM\CurrentControlSet\Enum\PCI\VEN_1106&DEV_3065&SUBSYS_01021106&REV_10\0000","ClassGUID",0x00000000,"{4D36E972-E325-11CE-BFC1-08002BE10318}"
HKLM,"SYSTEM\CurrentControlSet\Enum\PCI\VEN_1106&DEV_3065&SUBSYS_01021106&REV_10\0000","Driver",0x00000000,"{4D36E972-E325-11CE-BFC1-08002BE10318}\0000"
; Configuration Entries for the PCNet Adapter
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","Characteristics",0x00010001,0x00000000
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","DriverDesc",0x00000000,"VT6102"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","ProviderName",0x00000000,"VIA
Tech"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","NetCfgInstanceId",0x00000000,"{RANDOMCFGGUIDFOR_PCNET1}"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000\Linkage","Export",0x00000000,"\Device\PCNet1"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000\Linkage","RootDevice",0x00000000,"PCNet1"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000\Linkage","UpperBind",0x00000000,"Tcpip"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","BUS_TO_SCAN",0x00000000,"ALL"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","BUSTIMER",0x00000000,"0"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","BUSTYPE",0x00000000,"5"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","EXTPHY",0x00000000,"0"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","FDUP",0x00000000,"0"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","LED0",0x00000000,"10000"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","LED1",0x00000000,"10000"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","LED2",0x00000000,"10000"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","LED3",0x00000000,"10000"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","MPMODE",0x00000000,"0"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","TP",0x00000000,"1"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","AdapterCFID",0x00000000,"811929862"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","AdapterType",0x00000000,"5"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","SlotNumber",0x00000000,"8"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","BusNumber",0x00000000,"0"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","FunctionNumber",0x00000000,"0"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","EarlyReceive",0x00000000,"0"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","EarlyTransmit",0x00000000,"0"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","BurstLength",0x00000000,"1"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","ReceiveBurstIndicate",0x00000000,"64"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","ReceiveBuffers",0x00000000,"64"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","TransmitBuffers",0x00000000,"32"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","ReceiveThreshold",0x00000000,"0"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","TransmitThreshold",0x00000000,"0"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","MapRegisters",0x00000000,"32"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","ConnectionType",0x00000000,"0"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","ValidatePacketLen",0x00000000,"1"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","IPXSPXAutoFrame",0x00000000,"0"
HKLM,"SYSTEM\CurrentControlSet\Control\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}\{RANDOMCFGGUIDFOR_PCNET1}",,0x00000000,"Network
Adapters"
HKLM,"SYSTEM\CurrentControlSet\Control\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}\{RANDOMCFGGUIDFOR_PCNET1}\Connection","Name",0x00000000,"VIA
PCNet"
HKLM,"SYSTEM\CurrentControlSet\Services\PCNet1\Parameters\Tcpip","DefaultGateway",0x00010000,"10.65.145.1"
HKLM,"SYSTEM\CurrentControlSet\Services\PCNet1\Parameters\Tcpip","IPAddress",0x00010000,"10.65.145.79"
HKLM,"SYSTEM\CurrentControlSet\Services\PCNet1\Parameters\Tcpip","SubnetMask",0x00010000,"255.255.255.0"
We search an author for our "ReactOS Weekly Newsletter".
History:
Jason Filby had established the ReactOS Weekly Newsletter (called
"ReactOS Weekly") in 1999 as a useful weekly news summary located on
www.reactos.com. In 2000 the newsletter had been discontinued. With
the website redesign in summer 2005, the newsletter came back with
Stuart "TwoTailedFox" Robbins as author.
Requirements:
Here are requirements for an author:
1. Have enough time once a week to write the newsletter text (e.g. every sunday)
2. Be good in english language
3. Understand our technlogy (svn, reactos, windows nt, win32, kernel,
drivers, apps, etc.)
4. Be in frequent contact with the ReactOS developer, and come in our
IRC channels too (because mailing list traffic may be sometimes slow)
5. HTML knowledge is not required but an advantage
Goal:
The "ReactOS Weekly Newsletter" should be weekly (as the name implies)
and sum up the ongoing mailing list discussions as well as irc
conversations.
Additionally it should contain ReactOS news, like new releases.
>From time to time interviews, reviews (of apps compatibility and
reactos functions and releases) and maybe audio-podcasts, etc. would
be great too.
The layout of the newsletter issue page can be the same as the latest
one (e.g. http://www.reactos.org/xhtml/en/newsletter_11.html), similar
as WineHQ's one, or different.
Previous newsletters - links:
10/2005 - 02/2005:
http://www.reactos.org/?page=newsletters
1999 - 2000:
http://web.archive.org/web/20000522174140/reactos.com/public/weekly.html
WineHQ'S newsletters:
http://www.winehq.com/?issue=back
Mailing List Information:
http://www.reactos.org/?page=community_mailinglists
IRC Channel Information:
http://www.reactos.org/?page=community_irc
So... if this sounds like something you would like to do, please reply
to this mailing list email explaining why you you think you would be a
good newsletter author.
Klemens Friedl
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
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
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