Wineism

[Gunnar Dalsnes]

Again I must say that I don't like this. Taking code from wine and then
changing it on purpose goes agains my beliefs that wine/ros should share
as much as possible and that changes should go _both_ ways. My hope for
the future of ros/wine is that ros/wine spesific stuff is placed into
seperate files/libraries/etc. to make merging/sharing possible/easier.
This would probably mean that most ros umode dlls eventually will be
completely wineismed, but if that means we can share more code, i
couldn't care less.
Gunnar
ekohl(a)cvs.reactos.com wrote:
>   CVSROOT:        /CVS/ReactOS
>  Module name:   reactos
>  Repository:    reactos/lib/kernel32/misc/
>  Changes by:    ekohl(a)mok.osexperts.com 04/12/13 13:16:28
>  Modified files:
>         reactos/lib/kernel32/misc/: profile.c
>  Log message:
>         - Remove Wine-isms from the profile code.
>         - Wrap single-line if-statements.
>         - Cleanup the indentation.
>  _______________________________________________
>  Ros-cvs mailing list
>  Ros-cvs(a)reactos.com
>  http://reactos.com/mailman/listinfo/ros-cvs
>

[Casper Hornstrup]

>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.com
>  [mailto:[e-mail]] On Behalf Of Gunnar Dalsnes
>  Sent: 14. december 2004 00:16
>  To: ros-dev(a)reactos.com
>  Subject: [ros-dev] Wineism
>  Again I must say that I don't like this. Taking code from
>  wine and then changing it on purpose goes agains my beliefs
>  that wine/ros should share as much as possible and that
>  changes should go _both_ ways. My hope for the future of
>  ros/wine is that ros/wine spesific stuff is placed into
>  seperate files/libraries/etc. to make merging/sharing
>  possible/easier.
>  This would probably mean that most ros umode dlls eventually
>  will be completely wineismed, but if that means we can share
>  more code, i couldn't care less.
>  Gunnar 
You are completely ignoring the resources it requires to share
code. If you cannot share the whole component and without #ifdef
this and that then don't do it at all. If you want to rewrite
the lower level WINE and ReactOS components, then be my guest,
but it is a lot of work and it puts more restrictions on both
projects.
Casper

[Steven Edwards]

Hi,
--- Casper Hornstrup <chorns(a)users.sourceforge.net> wrote:
>   You are completely ignoring the resources it requires
> to share
>  code. If you cannot share the whole component and without #ifdef
>  this and that then don't do it at all. If you want to rewrite
>  the lower level WINE and ReactOS components, then be my guest,
>  but it is a lot of work and it puts more restrictions on both
>  projects. 
Some of the source files can be taken with only changing the header
files. Read the comment in this patch
http://cvs.reactos.com/cgi-bin/cvsweb.cgi/reactos/lib/kernel32/misc/profile…
By changing the formating just to make it look like the coding style in the rest of the
dll makes
generating a diff of a change later almost imposssible. The question is "Why should
we rewrite
large sections of code that can be shared with Wine just because of coding style
issues?".
Here is another example. This file was rippped from Wine. Other than the header changes
the
function body is intact.
http://cvs.reactos.com/cgi-bin/cvsweb.cgi/reactos/lib/gdi32/objects/linedda…
Should I be forced to reformat it to match the coding style in the rest of the dll which
will then
make generating diffs a pain?
Thanks
Steven
__________________________________
Do you Yahoo!?
Dress up your holiday email, Hollywood style. Learn more.
http://celebrity.mail.yahoo.com

[Casper Hornstrup]

>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.com
>  [mailto:[e-mail]] On Behalf Of Steven Edwards
>  Sent: 14. december 2004 16:25
>  To: ReactOS Development List
>  Subject: RE: [ros-dev] Wineism
>  Should I be forced to reformat it to match the coding style
>  in the rest of the dll which will then make generating diffs a pain?
>  Thanks
>  Steven 
Yes. You can also document a coding style, a platform SDK, and a native
API that both projects can use so there is no need for any project
specifics in the sourcecode.
Casper

[Jason Filby]

On Tue, 14 Dec 2004 17:14:35 +0100, Casper Hornstrup
<chorns(a)users.sourceforge.net> wrote:
>   Yes. You can also document a coding style, a platform
> SDK, and a native
>  API that both projects can use so there is no need for any project
>  specifics in the sourcecode. 
That both projects agree on? What about debug prints, for example:
ReactOS: DbgPrint, DPRINT, DPRINT1
WINE: TRACE, ?
How open is the WINE project to changing things to meet us half-way?
There will be things they would need to change, that they don't need
to, to accomodate our needs - as well as the other way around.
Cheers
Jason

[Robert Shearman]

Jason Filby wrote:
>  On Tue, 14 Dec 2004 17:14:35 +0100, Casper Hornstrup
> <chorns(a)users.sourceforge.net> wrote:
> >  Yes. You can also document a coding style, a
> > platform SDK, and a native
> > API that both projects can use so there is no need for any project
> > specifics in the sourcecode.
> >  
> That both projects agree on? What about debug prints, for example:
> ReactOS: DbgPrint, DPRINT, DPRINT1
> WINE: TRACE, ?
> How open is the WINE project to changing things to meet us half-way?
> There will be things they would need to change, that they don't need
> to, to accomodate our needs - as well as the other way around.
>  
Why would you want us to change from a very flexible debug logging
system to a less flexible one?
Rob

[Jason Filby]

On Tue, 14 Dec 2004 10:59:10 -0600, Robert Shearman <rob(a)codeweavers.com> wrote:
>   Why would you want us to change from a very flexible
> debug logging
>  system to a less flexible one? 
Obviously not; I don't know the WINE debugging system, I was just
giving an example of where our systems probably differ quite a bit.
There could be resistance on either side depending on the issue. If we
can agree on common ground to make porting easier, it would be great!
Cheers
Jason

[Robert Shearman]

Jason Filby wrote:
>  On Tue, 14 Dec 2004 10:59:10 -0600, Robert Shearman
> <rob(a)codeweavers.com> wrote:
> >  Why would you want us to change from a very
> > flexible debug logging
> > system to a less flexible one?
> >  
> Obviously not; I don't know the WINE debugging system, I was just
> giving an example of where our systems probably differ quite a bit.
> There could be resistance on either side depending on the issue. If we
> can agree on common ground to make porting easier, it would be great!
>  
I don't understand why there is a need for converting to DPRINT,
DPRINT1, etc. Why can't you just define TRACE, WARN and FIXME to DPRINT?
You won't get the runtime enabling or disabling of debug channels, but
then presumably you don't want support for this.
Rob

[Steven Edwards]

Hi Rob,
--- Robert Shearman <rob(a)codeweavers.com> wrote:
>   I don't understand why there is a need for
> converting to DPRINT,
>  DPRINT1, etc. Why can't you just define TRACE, WARN and FIXME to DPRINT?
>  You won't get the runtime enabling or disabling of debug channels, but
>  then presumably you don't want support for this. 
For Wine ported DLLs we already do this. Our libwine is a static lib that maps FIXME and
ERR to
DPRINT1 so you always see it and WARN and TRACE to DPRINT so you will see those messages
if
compiled with DBG = 1. reactos/include/wine/debug.h The debate comes in with do we want to
do this
in all of ReactOS? My vote is of course yes. I would much rather just dump DPRINT and
DPRINT1 and
use the Wine macros directly.
Also it would be nice if someone could figure out a way to enable runtime switching of
debug
channels so a recompile is not required if I want to enable more verbose output.
Thanks
Steven
__________________________________
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com

[Jason Filby]

Hi Steven
>   Also it would be nice if someone could figure out a
> way to enable runtime switching of debug
>  channels so a recompile is not required if I want to enable more verbose output. 
What are the the areas that we need to standardize on regarding coding style?
Thanks
Jason

[Steven Edwards]

Hi,
--- Jason Filby <jason.filby(a)gmail.com> wrote:
>   What are the the areas that we need to standardize on
> regarding coding style? 
OK This only applies to ntdll, user32, kernel32 or any other dll we might share with Wine.
ntoskrnl, the drivers and Win32k are off limits. Also I am not talking about issues like
tabs and
spaces. That can be debated all day long.....
DPRINT and DPRINT1 really need to go and we could just standise on using the Wine macros
in our Win32 system, FIXME, WARN, ERR, etc. It reduces the diff and if we ever get support
for switching the debug channels then it will make life less of a pain.
Also strings like this have to go
L"Software\\Microsoft\\"
This will work on Linux and Windows
static const WCHAR KeyW[] =
{'S','o','f','t','w','a','r','e','\\',
'M','i','c','r','o','s','o','f','t','\\',
I really did not want to commit the crypto stuff to advapi32 as I knew it would lead to
this
discussion but Thomas found that without it then Abiword would not work. This in turn lead
to Eric
making this patch:
http://cvs.reactos.com/cgi-bin/cvsweb.cgi/reactos/lib/advapi32/crypt/crypt.…
Which does make it conform to the ReactOS coding standard but now will make merging in
fixes from
Wine a bit more of a pain.
Thanks
Steven
__________________________________
Do you Yahoo!?
All your favorites on one personal page � Try My Yahoo!
http://my.yahoo.com

[Casper Hornstrup]

>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.com
>  [mailto:[e-mail]] On Behalf Of Steven Edwards
>  Sent: 14. december 2004 18:55
>  To: Jason Filby; ReactOS Development List
>  Subject: Re: [ros-dev] Wineism
>  Hi,
>  Also strings like this have to go
>  L"Software\\Microsoft\\"
>  This will work on Linux and Windows
>  static const WCHAR KeyW[] =
> {'S','o','f','t','w','a','r','e','\\',
> 'M','i','c','r','o','s','o','f','t','\\',
This is really a mess. I'd rather fix gcc to make this problem go away.
Can't -fshort-char be used?
Casper

[Filip Navara]

Casper Hornstrup wrote:
>  This is really a mess. I'd rather fix gcc to make
> this problem go away.
> Can't -fshort-char be used?
>  
Well, it can be, but Wine interfaces with Unix libraries which expect
that wchat_t is 4 bytes...
Regards,
Filip

[Casper Hornstrup]

>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.com
>  [mailto:[e-mail]] On Behalf Of Filip Navara
>  Sent: 14. december 2004 19:50
>  To: ReactOS Development List
>  Subject: Re: [ros-dev] Wineism
>  Casper Hornstrup wrote:
> >  This is really a mess. I'd rather fix gcc to
> > make this  
>  problem go away.
> >  Can't -fshort-char be used?
> >  
>  Well, it can be, but Wine interfaces with Unix libraries
>  which expect that wchat_t is 4 bytes...
>  Regards,
>  Filip 
The switch could be only used for the shared parts which
wouldn't interface directly with unix libraries.
Casper

[Casper Hornstrup]

>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.com
>  [mailto:[e-mail]] On Behalf Of Robert Shearman
>  Sent: 14. december 2004 17:59
>  To: Jason Filby; ReactOS Development List
>  Subject: Re: [ros-dev] Wineism
>  Jason Filby wrote:
> >  How open is the WINE project to changing things to
> > meet us half-way?
> > There will be things they would need to change, that they don't need
> > to, to accomodate our needs - as well as the other way around.
> >  
>  Why would you want us to change from a very flexible debug
>  logging system to a less flexible one?
>  Rob 
I would vote for using the WINE system in this case as it is more flexible.
Casper

[Steven Edwards]

Hi Jason,
--- Jason Filby <jason.filby(a)gmail.com> wrote:
>   That both projects agree on? What about debug prints,
> for example:
>  ReactOS: DbgPrint, DPRINT, DPRINT1
>  WINE: TRACE, ? 
Wine uses FIXME, TRACE, WARN and ERR. FIXME and ERR are always seen while
TRACE and WARN can be toggled via the Winedebug channel and as needed via
a option in taskmgr or from the debugger.
>   How open is the WINE project to changing things to
> meet us half-way?
>  There will be things they would need to change, that they don't need
>  to, to accomodate our needs - as well as the other way around. 
Well to be blunt the current system in ReactOS sucks. Asking Wine to
change its debugging system is kind of pointless when they have a system
that works much better. Having to rebuild dlls to get different levels
of verboseness is a pain in the ass.
Thanks
Steven
__________________________________
Do you Yahoo!?
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250

[Steven Edwards]

--- Casper Hornstrup <chorns(a)users.sourceforge.net> wrote:
>   Yes. You can also document a coding style, a platform
> SDK, and a native
>  API that both projects can use so there is no need for any project
>  specifics in the sourcecode. 
If someone does not like the coding style used in a source file based on wine its not like
it
takes that much extra time to send a patch to wine-patches. As for a Platform SDK that can
be used
by both projects I have suggested using the Wine headers as they are much more complete
and
correct when you compare them to the Microsoft PSDK.
If we randomly decide to reformat all of the sources we share with Wine (such as those in
user32)
then its just going to make merges harder, adds more time to the development process and
discourages someone like Gunner that is doing a rather boring and important job of fixing
bugs
spotted by regression tests.
Thanks
Steven
__________________________________
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250