> From: gvg(a)svn.reactos.com
>
> Don't use svn command line tool to get revision number
> XML code stolen from the xmlbuildsystem branch, we need
> to merge this when merging the xmlbuildsystem back into trunk
If you get weird error messages when svn up'ing in reactos/tools on Linux,
remove reactos/tools/buildno. "reactos/tools/buildno" used to be an
executable, now it's a directory. Doing a "make clean" first and then a "svn
up" works ok. Windows shouldn't be a problem, there is no name conflict
there as the old executable was named buildno.exe.
Gé van Geldorp.
Hi,
Some things that need to be fixed ASAP:
1) Gunnar's additions to ntdll's critical.c break cmd.exe. This is not
his fault per-se, since his checks are legitimate. It seems cmd.exe is
not intiailizing the CS before using it. Although I understand that his
changes are needed, I would prefer devs to actually test their changes
and fix the broken apps, and not just break them, since this is a
regression in a way (much like Thomas's pseh fixes).
2) Thomas' recent patches flood debug output with an error about
NtGdiCombineRgn. Once again, please either fix the broken apps which do
this, or show the message only once. It makes debugging impossible.
Best regards,
Alex Ionescu
hbirr(a)svn.reactos.com wrote:
>- Started the rewriting of the cache manger.
>- The new cache manager uses section objects and maps the content of cached files
> into the kernel address space for functions like CcCopyRead.
>- The implementation isn't complete. It works for me to compile ros on ros if enough ram is available.
>
>
Very good work!
I tried it and needed the attached changes in order to boot...
[cc02.diff] Don't try to map data past the end of file in VFAT.
[cc03.diff] Fix incorrect check in CcMapData.
Also I've patch which fixes fast mutex implementation and it's usage,
which depends on these cache manager changes.
Regards,
Filip
> From: gvg(a)svn.reactos.com
>
> Include svn revision in build string
It seems that there are quite some woosies out there who don't have the
"svn" command line tool installed. I'll change buildno to not depend on svn,
but this might take a little while.
Gé van Geldorp.
crt: [CC] float/clearfp.c
float/clearfp.c: In function `_clearfp':
float/clearfp.c:8: warning: implicit declaration of function `_statusfp'
make[1]: *** [float/clearfp.o] Error 1
make: *** [crt] Error 2
Here is a Oops!
James
I'm running into a problem importing the latest Wine winmm sources. The
resource file winmm_res.rc now contains Unicode strings (in the CORE and
VIDEODISC resources). Windres from binutils 2.15.94 doesn't like those.
I'm not sure how to solve this. Any ideas?
Gé van Geldorp.
Hey, I was snooping around and found a nice program that boots FreeBSD
in Windows itself, I have not tested it to see what it does exactly,
but this may be a good thing to see if ReactOS can be booted from it
;)
The link for the full source code and binary is below...
http://ftp5.se.freebsd.org/FreeBSD-current/xperimnt/winboot/
--
-David W. Eckert
I have modified crt to use native-mingw headers and deleted the
ros-local copies. This works fine on windows but people are having
problems on linux. It seem on linux the search order for header files
are different from windows. On windows, mingw\include is searched first,
then mingw\lib\gcc\mingw32\x.x.x\include, but on linux
mingw/x.x.x/include is searched first, then mingw/include. This means
that some mingw headers are never included in linux (those who exist
both places), specially float.h. The mingw float.h has #include_next
<float.h>, so its obvious that the mingw headers are supposed to go first.
How do i fix this? Is this a mingw bug?
Regards
Gunnar
De: ros-dev-bounces(a)reactos.com en nombre de Gunnar Dalsnes
Enviado el: Mar 2/1/2005 3:58 p.m.
Para: ReactOS Development List
Asunto: Re: [ros-dev] msvcrt/crtdll "merge"
Waldo Alvarez Cañizares wrote:
> Hi Gunnar:
>
>
>>And about the strlen=ntdll.strlen stuff. Forwarded functions doesnt show
>>up as imported because they arent really imported, so this is normal.
>
>
> I think that it is not normal. The better way should be to really forward them, this is just half baked stuff.
They are really forwarded. stuff=SOMEDLL.stuff means its forwarded. This
is standard module-definition (.def) syntax and its nothing half baked
about it.
Forwarded functions are resolved by the loader thus they are not
imported by the dll forwarding them.
They are used internally by some other functions inside msvcrt so they must be somewhere
what is going on now is that internally a stically linked library is used but anything referencing those functions
from the outside are being redirected to ntdll.
What I mean is: If you are forwarding them, why you don´t import them too instead of the static link?
If you are statically linking then why forward them?
> If you are not going to forward it, I think that it would be better to not declare them as such because that can cause confusion.
What do you mean "not going to forward it"??? stuff=SOMEDLL.stuff means
its forwarded!!!
>
>
>>Dont understand what XP's ntdll exporting "WindowsCE" functions has to
>>do with anything?
>
>
> Was just a comment about ntdll, they are exported and nothing is mentioned in msdn. I said that because I think
> ntdll is very close to the runtime.
>
Hmm, still dont understand:-/ Ntdll exports loads of functions that
arent documented anywhere.
But we better document that. Because we want to be compatible Right? And that probably means that at some degree WinCE and XP have common source code and maybe are not so far away one of each other as some ppl around think. Hey just some curiosity nothing more is like when win2k came out it inherited win98/Me 's explorer, it inherited the same bugs also, that´s why. At the end nothing important, well unless you try to reduce the code of some other library maybe.
Best Regards
Waldo
Gunnar
I get this error compiling with gcc 3.3.1:
crt: [CC] stdio/wtmpnam.c
stdio/wtmpnam.c:5:2: #import is obsolete, use an #ifndef wrapper in the header f
ile
make[1]: *** [stdio/wtmpnam.o] Error 1
make: *** [crt] Error 2
____________________________________________________________
6X velocizzare la tua navigazione a 56k? 6X Web Accelerator di Libero!
Scaricalo su INTERNET GRATIS 6X http://www.libero.it