If the mutex is a named mutex and the object existed before this
function call, the return value is a handle to the existing object,
GetLastError returns ERROR_ALREADY_EXISTS
--
Best regards,
Alex Ionescu
On 17-Sep-07, at 10:41 PM, silverblade(a)svn.reactos.org wrote:
+ device_list_mutex = CreateMutex(NULL, FALSE,
DEVICE_LIST_MUTEX_NAME);
+
+ if ( ! device_list_mutex)
+ {
Hello,
it's long time that I compile ReactOS and I have some errors into the start menu bar.
My results are almost identical to this screenshot:
http://www.reactos.org/media/screenshots/2007/ros_033_xara3d.jpg
As you can see, the two icons after the start button and the '1','2','3','4' buttons are corrupted.
Actually I'm using the windres.exe that I received from here:
http://www.reactos.org/archives/public/ros-dev/2007-July/009548.html
Do you have some idea?
Sincerely,
Carlo Bramini
------------------------------------------------------
Leggi GRATIS le tue mail con il telefonino i-mode di Wind
http://i-mode.wind.it/
Does the order of .o files matter when linking against a static library?
I ask this because I'm having problems linking ntoskrnl with rtl
dependending on the order of object files when compiling rtl. For example on
the rbuild generated makefile.auto the order of .o files is :
rtl_OBJS := \
$(INTERMEDIATE)\lib\rtl\austin\avl.o \
$(INTERMEDIATE)\lib\rtl\austin\tree.o \
$(INTERMEDIATE)\lib\rtl\access.o \
$(INTERMEDIATE)\lib\rtl\acl.o \
$(INTERMEDIATE)\lib\rtl\atom.o \
$(INTERMEDIATE)\lib\rtl\bitmap.o \
$(INTERMEDIATE)\lib\rtl\bootdata.o \
$(INTERMEDIATE)\lib\rtl\compress.o \
$(INTERMEDIATE)\lib\rtl\condvar.o \
$(INTERMEDIATE)\lib\rtl\crc32.o \
$(INTERMEDIATE)\lib\rtl\critical.o \
$(INTERMEDIATE)\lib\rtl\dbgbuffer.o \
$(INTERMEDIATE)\lib\rtl\debug.o \
$(INTERMEDIATE)\lib\rtl\dos8dot3.o \
$(INTERMEDIATE)\lib\rtl\encode.o \
$(INTERMEDIATE)\lib\rtl\env.o \
$(INTERMEDIATE)\lib\rtl\error.o \
$(INTERMEDIATE)\lib\rtl\exception.o \
$(INTERMEDIATE)\lib\rtl\generictable.o \
$(INTERMEDIATE)\lib\rtl\handle.o \
$(INTERMEDIATE)\lib\rtl\heap.o \
$(INTERMEDIATE)\lib\rtl\image.o \
$(INTERMEDIATE)\lib\rtl\message.o \
$(INTERMEDIATE)\lib\rtl\largeint.o \
$(INTERMEDIATE)\lib\rtl\luid.o \
$(INTERMEDIATE)\lib\rtl\network.o \
$(INTERMEDIATE)\lib\rtl\nls.o \
$(INTERMEDIATE)\lib\rtl\path.o \
$(INTERMEDIATE)\lib\rtl\ppb.o \
$(INTERMEDIATE)\lib\rtl\process.o \
$(INTERMEDIATE)\lib\rtl\propvar.o \
$(INTERMEDIATE)\lib\rtl\qsort.o \
$(INTERMEDIATE)\lib\rtl\random.o \
$(INTERMEDIATE)\lib\rtl\rangelist.o \
$(INTERMEDIATE)\lib\rtl\registry.o \
$(INTERMEDIATE)\lib\rtl\res.o \
$(INTERMEDIATE)\lib\rtl\resource.o \
$(INTERMEDIATE)\lib\rtl\sd.o \
$(INTERMEDIATE)\lib\rtl\security.o \
$(INTERMEDIATE)\lib\rtl\sid.o \
$(INTERMEDIATE)\lib\rtl\sprintf.o \
$(INTERMEDIATE)\lib\rtl\srw.o \
$(INTERMEDIATE)\lib\rtl\swprintf.o \
$(INTERMEDIATE)\lib\rtl\splaytree.o \
$(INTERMEDIATE)\lib\rtl\thread.o \
$(INTERMEDIATE)\lib\rtl\time.o \
$(INTERMEDIATE)\lib\rtl\timezone.o \
$(INTERMEDIATE)\lib\rtl\timerqueue.o \
$(INTERMEDIATE)\lib\rtl\unicode.o \
$(INTERMEDIATE)\lib\rtl\unicodeprefix.o \
$(INTERMEDIATE)\lib\rtl\vectoreh.o \
$(INTERMEDIATE)\lib\rtl\version.o \
$(INTERMEDIATE)\lib\rtl\workitem.o \
$(INTERMEDIATE)\lib\rtl\i386\debug_asm.o \
$(INTERMEDIATE)\lib\rtl\i386\except_asm.o \
$(INTERMEDIATE)\lib\rtl\i386\except.o \
$(INTERMEDIATE)\lib\rtl\i386\random_asm.o \
$(INTERMEDIATE)\lib\rtl\i386\rtlswap.o \
$(INTERMEDIATE)\lib\rtl\i386\rtlmem.o \
$(INTERMEDIATE)\lib\rtl\i386\res_asm.o \
$(INTERMEDIATE)\lib\rtl\i386\thread.o \
Using this order rtl will compile and ntoskrnl can be linked without
problems but If the order is changed to ASMs on top (the order present in
rtl.rbuild):
rtl_OBJS := \
$(INTERMEDIATE)\lib\rtl\i386\debug_asm.o \
$(INTERMEDIATE)\lib\rtl\i386\except_asm.o \
$(INTERMEDIATE)\lib\rtl\i386\except.o \
$(INTERMEDIATE)\lib\rtl\i386\random_asm.o \
$(INTERMEDIATE)\lib\rtl\i386\rtlswap.o \
$(INTERMEDIATE)\lib\rtl\i386\rtlmem.o \
$(INTERMEDIATE)\lib\rtl\i386\res_asm.o \
$(INTERMEDIATE)\lib\rtl\i386\thread.o \
$(INTERMEDIATE)\lib\rtl\austin\avl.o \
$(INTERMEDIATE)\lib\rtl\austin\tree.o \
$(INTERMEDIATE)\lib\rtl\access.o \
$(INTERMEDIATE)\lib\rtl\acl.o \
$(INTERMEDIATE)\lib\rtl\atom.o \
$(INTERMEDIATE)\lib\rtl\bitmap.o \
$(INTERMEDIATE)\lib\rtl\bootdata.o \
$(INTERMEDIATE)\lib\rtl\compress.o \
$(INTERMEDIATE)\lib\rtl\condvar.o \
$(INTERMEDIATE)\lib\rtl\crc32.o \
$(INTERMEDIATE)\lib\rtl\critical.o \
$(INTERMEDIATE)\lib\rtl\dbgbuffer.o \
$(INTERMEDIATE)\lib\rtl\debug.o \
$(INTERMEDIATE)\lib\rtl\dos8dot3.o \
$(INTERMEDIATE)\lib\rtl\encode.o \
$(INTERMEDIATE)\lib\rtl\env.o \
$(INTERMEDIATE)\lib\rtl\error.o \
$(INTERMEDIATE)\lib\rtl\exception.o \
$(INTERMEDIATE)\lib\rtl\generictable.o \
$(INTERMEDIATE)\lib\rtl\handle.o \
$(INTERMEDIATE)\lib\rtl\heap.o \
$(INTERMEDIATE)\lib\rtl\image.o \
$(INTERMEDIATE)\lib\rtl\message.o \
$(INTERMEDIATE)\lib\rtl\largeint.o \
$(INTERMEDIATE)\lib\rtl\luid.o \
$(INTERMEDIATE)\lib\rtl\network.o \
$(INTERMEDIATE)\lib\rtl\nls.o \
$(INTERMEDIATE)\lib\rtl\path.o \
$(INTERMEDIATE)\lib\rtl\ppb.o \
$(INTERMEDIATE)\lib\rtl\process.o \
$(INTERMEDIATE)\lib\rtl\propvar.o \
$(INTERMEDIATE)\lib\rtl\qsort.o \
$(INTERMEDIATE)\lib\rtl\random.o \
$(INTERMEDIATE)\lib\rtl\rangelist.o \
$(INTERMEDIATE)\lib\rtl\registry.o \
$(INTERMEDIATE)\lib\rtl\res.o \
$(INTERMEDIATE)\lib\rtl\resource.o \
$(INTERMEDIATE)\lib\rtl\sd.o \
$(INTERMEDIATE)\lib\rtl\security.o \
$(INTERMEDIATE)\lib\rtl\sid.o \
$(INTERMEDIATE)\lib\rtl\sprintf.o \
$(INTERMEDIATE)\lib\rtl\srw.o \
$(INTERMEDIATE)\lib\rtl\swprintf.o \
$(INTERMEDIATE)\lib\rtl\splaytree.o \
$(INTERMEDIATE)\lib\rtl\thread.o \
$(INTERMEDIATE)\lib\rtl\time.o \
$(INTERMEDIATE)\lib\rtl\timezone.o \
$(INTERMEDIATE)\lib\rtl\timerqueue.o \
$(INTERMEDIATE)\lib\rtl\unicode.o \
$(INTERMEDIATE)\lib\rtl\unicodeprefix.o \
$(INTERMEDIATE)\lib\rtl\vectoreh.o \
$(INTERMEDIATE)\lib\rtl\version.o \
$(INTERMEDIATE)\lib\rtl\workitem.o \
[LD] C:\Ros\clean\reactos\output-i386\ntoskrnl\ntoskrnl.exe
C:\Ros\clean\reactos\obj-i386\lib\rtl\rtl.a(random.o): In function
`RtlUniform@4':
C:/Ros/clean/reactos/lib/rtl/random.c:137: multiple definition of
`_RtlUniform@4'
C:\Ros\clean\reactos\obj-i386\lib\rtl\rtl.a(random_asm.o):C:\Ros\clean\react
os\lib\rtl\i386\random_asm.S:161: first defined here
C:\Ros\clean\reactos\obj-i386\lib\rtl\rtl.a(random.o): In function
`RtlRandom@4':
C:/Ros/clean/reactos/lib/rtl/random.c:69: multiple definition of
`_RtlRandom@4'
C:\Ros\clean\reactos\obj-i386\lib\rtl\rtl.a(random_asm.o):C:\Ros\clean\react
os\lib\rtl\i386\random_asm.S:23: first defined here
collect2: ld returned 1 exit status
mingw32-make: *** [C:\Ros\clean\reactos\output-i386\ntoskrnl\ntoskrnl.exe]
Error 1
Total Build Time: 00:03:09
You will get linking errors , this error looks wired to me . In the rbuild
generated file the .asm files generating this problem will be added to the
end of the list because they are inside an If condition (ARCH=i386) so this
¿bug? does not appear even when exists
Am I missing something here? How can It be solved, any clues?
Friends,
A two day international conference (ICIST2007) is planned at
Thrissur(Kerala, India)
during 14,15 December 2007 with Free Software as the principal theme.
RMS has agreed to engage the participants in a virtual session and
clarify online to any subsequent queries.
Papers are solicited for ICIST2007.
Details are at http://mesengg.ac.in/icist2007.htm
Regards,
Raghesh
Hello.
The attached patch fixes the italian translation of MSCONFIG.
Sincerely,
Carlo Bramini.
------------------------------------------------------
Leggi GRATIS le tue mail con il telefonino i-mode di Wind
http://i-mode.wind.it/
Hi
Here are some ideas for optimizing our gdi object code:
1.) When allocating, locking and deleting a gdi object, we pass the
global variable GdiHandleTable to GDIOBJ_AllocObj(). Do we really need
this? Is there a case where we pass something else? We would only save
few cycles here, but if we don't need it...
2.) When allocating a gdi object, we first need to search the list of
LookasideLists. My suggestion is to give each gdi object type a constant
index in the list and pass that index instead of the object type value.
That would require that the table for the object types/sizes/CleanupProc
is in sync with the index definitions. This could be achieved by
initializing that table on win32k load:
InitGdiObjectType(UINT Index, LONG GdiType, ULONG_PTR ObjectSize,
GDICLEANUPPROC CleanupProc);
Then we only need to make sure, that every index is only there once and
add one line for each object in GDIOBJ_iAllocHandleTable to initialize
the object type.
3.) ROS makes massive use of gdi object handles. It uses a lot more
handles than windows does. That is because every object we use is always
inserted into the handle table. This is slow and wastes handle entries,
wich are a limited resource. Whenever we need a (temporary) object, we
allocate it (find lookaside list, allocate mem, find free entry, lock
entry, do some stuff, unlock entry), then in a second call lock it (do
some checks, lock entry, return pointer) and at the end unlock it and
then delete it.
I think we should rewrite the code a little, so that we only create
handles, when the object reaches usermode and use pointers to mem
objects instead if the objects are kernel mode / temporary only.
XXXOBJ_AllocObj(UINT Index) -> allocate an entry from the LookasideList
and initialize it. Don't create a handle.
XXXOBJ_FreeObj(PVOID pObjBody) -> free the entry from the LookasideList
GDIOBJ_CreateHandle(PVOID pObjBody, UINT Index, LONG GdiType) -> create
a handle for a given mem object
rewrite some XXXOBJ_Xxx apis to deal with pointers to the mem objects
instead of handles (see REGION_Xxx apis)
Imo this should result in a big speed increase for several ntgdi/ntuser apis
Regards,
Timo
Hello.
No, I didn't see the creation of a DLL from the log file.
Perhaps I had understood that zlib was compiled as a static library (eh eh), but in my opinion this isn't the best way for using a robust, thread safe library like this one.
I also agree that I could explain my idea wrongly.
Searching into the online english dictionary... and I found a better word, perhaps "redundant" sounds better than "unuseful".
Sincerely,
Carlo Bramini.
---------- Initial Header -----------
>From : ros-dev-bounces(a)reactos.org
To : "ReactOS Development List" ros-dev(a)reactos.org
Cc :
Date : Wed, 05 Sep 2007 11:21:07 -0400
Subject : Re: [ros-dev] Build with zlib
> Um, because it's a static library? Do you see it in the "dll" directory or
> in the "lib" directory?
>
> -----Original Message-----
> From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] On
> Behalf Of carlo.bramix
> Sent: September-04-07 5:19 AM
> To: ros-dev
> Subject: [ros-dev] Build with zlib
>
> Hello,
> from the compilation log you can read:
>
> [CC] lib\3rdparty\zlib\adler32.c
> [CC] lib\3rdparty\zlib\compress.c
> [CC] lib\3rdparty\zlib\crc32.c
> [CC] lib\3rdparty\zlib\gzio.c
> [CC] lib\3rdparty\zlib\uncompr.c
> [CC] lib\3rdparty\zlib\deflate.c
> [CC] lib\3rdparty\zlib\trees.c
> [CC] lib\3rdparty\zlib\zutil.c
> [CC] lib\3rdparty\zlib\inflate.c
> [CC] lib\3rdparty\zlib\infback.c
> [CC] lib\3rdparty\zlib\inftrees.c
> [CC] lib\3rdparty\zlib\inffast.c
> [AR] obj-i386\lib\3rdparty\zlib\zlib.a
>
> why does it compile zlib.a (absolutely unuseful in my opinion) instead of
> zlib1.dll with its libz.a?
> This log has been taken from the compilation of ReactOS and *not* from the
> "make bootcd" session.
>
> Sincerely,
>
> Carlo Bramini.
>
>
>
> ------------------------------------------------------
> Leggi GRATIS le tue mail con il telefonino i-modeT di Wind
> http://i-mode.wind.it/
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
------------------------------------------------------
Leggi GRATIS le tue mail con il telefonino i-mode di Wind
http://i-mode.wind.it/
Hello,
from the compilation log you can read:
[CC] lib\3rdparty\zlib\adler32.c
[CC] lib\3rdparty\zlib\compress.c
[CC] lib\3rdparty\zlib\crc32.c
[CC] lib\3rdparty\zlib\gzio.c
[CC] lib\3rdparty\zlib\uncompr.c
[CC] lib\3rdparty\zlib\deflate.c
[CC] lib\3rdparty\zlib\trees.c
[CC] lib\3rdparty\zlib\zutil.c
[CC] lib\3rdparty\zlib\inflate.c
[CC] lib\3rdparty\zlib\infback.c
[CC] lib\3rdparty\zlib\inftrees.c
[CC] lib\3rdparty\zlib\inffast.c
[AR] obj-i386\lib\3rdparty\zlib\zlib.a
why does it compile zlib.a (absolutely unuseful in my opinion) instead of zlib1.dll with its libz.a?
This log has been taken from the compilation of ReactOS and *not* from the "make bootcd" session.
Sincerely,
Carlo Bramini.
------------------------------------------------------
Leggi GRATIS le tue mail con il telefonino i-mode di Wind
http://i-mode.wind.it/
