> I had an idea about this....
>
> ExRosSetDebugLevel() and ExRosGetDebugLevel() can be ntdll umode
> syscalls into ntoskrnl. We should shadow the debug level in umode so
> that ExRosGetDebugLevel() doesn't have to jump to kmode every time we
> query it.
ExWineSetDebugLevel()
ExWineGetDebugLevel()
____________________________________________________________
Libero ADSL: 3 mesi gratis e navighi a 1.2 Mega, senza costi di attivazione.
Abbonati subito su http://www.libero.it
Hi All,
We have been invited to attend LinuxWorld in Boston on February 15-17, 2005. If anyone is
interested in attending please let me know. Arty and I may be going.
Thanks
Steven
__________________________________
Do you Yahoo!?
Send a seasonal email greeting and help others. Do good.
http://celebrity.mail.yahoo.com
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
>
>
>
>
Hi,
--- Jason Filby <jason.filby(a)gmail.com> wrote:
> Out of interest, does WINE have a spacing standard, and if so where
> can I read about it?
Its mostly free form with a few exceptions. Its not really documented. You can read about it here
http://www.kerneltraffic.org/wine/wn20020530_124.html#3http://www.winehq.com/hypermail/wine-devel/2002/11/1340.html
> Sounds good; why not change to WINEs macros everywhere in ReactOS?
I am not opposed to it, I just don't know how we would support debugging
a driver vs a dll if we had support to toggle the messages. I guess it
could be done with little trouble everywhere.
> Aiee! That looks painful. Is there nothing that can be done on WINE's
> side to make this easier? I suppose not or they would have done it
> already.
The problem is in GCC on *nix. I don't think there is much we can do about
it short of fixing GCC. If we ever do a ELF building using gcc on linux to
build ReactOS for another CPU then we will have the same issue.
Thanks
Steven
__________________________________
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com
Hi
On Tue, 14 Dec 2004 09:54:32 -0800 (PST), Steven Edwards
<steven_ed4153(a)yahoo.com> wrote:
> Also I am not talking about issues like tabs and spaces. That can be debated all day
> long.....
Out of interest, does WINE have a spacing standard, and if so where
can I read about it?
> 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.
Sounds good; why not change to WINEs macros everywhere in ReactOS?
> 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','\\',
Aiee! That looks painful. Is there nothing that can be done on WINE's
side to make this easier? I suppose not or they would have done it
already.
Are there any objections to the above changes from anyone?
Cheers
Jason
gdalsnes(a)cvs.reactos.com wrote:
> -NtSetInformationToken: lie and say we succeded
>
>
>
It would be nice to say what apps take advantage of this change, or why
it was done? What app now works because of this?
And in either case, this function is extremly easy to implement...
Best regards,
Alex Ionescu
Couldnt we do like some software do today ? (like Wine ? :))
make depends && make
--- Ge van Geldorp <ge(a)gse.nl> a écrit :
> I agree, but it's a bit of a chicken-and-egg problem. The Makefiles include
> the dependency files which refer to the now-removed header. To regenerate
> the dependency files we have to run make, which uses the Makefiles...
>
> Gé van Geldorp.
>
> > -----Original Message-----
> > From: Syl_sf [mailto:spetreolle@users.sourceforge.net]
> > Sent: Thursday, December 09, 2004 23:34
> > To: Ge van Geldorp; spetreolle(a)users.sourceforge.net;
> > 'ReactOS Development List'
> > Subject: RE: [ros-dev] Problem in dependancies
> >
> >
> > Actually I was already doing it to have a successful
> > compilation. But I dont think running 'make clean' after
> > every commit is the best thing to do.
> >
> > My "aclui" choice was totally random, but no file was changed
> > in the aclui CVS since 7 weeks. (It doesnt use mmsystem nor
> > imports it)
> >
> > Many thanks for your help.
> >
=====
Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net)
humans are like computers,
yesterday the BIOS was all
- today its just a word
Hi!
I asked on #ReactOS and ros-general, but received no answer. So I'm
asking for help here. How to fix this error? Can anybody at least give
ma a hint what files am I missing, please?
WinME, GCC 3.3.1, fresh sources.
[DEPENDS] i386/.setjmplongjmp.d
[DEPENDS] .rosglue.d
[RC] freetype.rc
[CC] rosglue.c
[AS] i386/setjmplongjmp.s
[AR] freetype.a
ar: objs/*.o: No such file or directory
MAKE.EXE: *** [freetype.a] Error 1
