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/
Hi,
This is for Eric. I couldnt find your Mail Address, so I send this to
ROS ML instead.
I uploaded a picture with the errors in German RC, which are left. Only
one Window makes problems.
http://img407.imageshack.us/img407/7514/errorsbf8.jpg
Bye
Daniel "EmuandCo" Reimer
Hi
I am thinking of doing this adding a header call ntuser.h
and put it in include/reactos/../ that contain all ntuser* syscall prototypes
next thing we need a good test frame work betwin gdi32.dll and win32k.sys
so we can check all param from gdi32 comes down to win32k are correct
or captuers ms gdi32.dll to achive this so easy as posible
I am thinking of adding a new config value or define value for win32k
that will always test the input data is correct.
example
INT
STDCALL
NtGdiExtEscape(HDC hDC,
IN OPTIONAL PWCHAR pDriver,
IN INT nDriver,
INT Escape,
INT InSize,
OPTIONAL LPSTR UnsafeInData,
INT OutSize,
OPTIONAL LPSTR UnsafeOutData)
{
PDC pDC;
LPVOID SafeInData = NULL;
LPVOID SafeOutData = NULL;
NTSTATUS Status = STATUS_SUCCESS;
INT Result;
#if gdi32_testing_on
test_NtGdiExtEscape(...);
#endif
...
...
}
test will testing see if the data should have been sent or not to win32k and vaildate everthing.
and if any error detects it print out a DPRINT1 msg
DPRINT1("Testing start");
DPRINT1("Status : fail");
DPRINT1("Status : why :");
DPRINT1("Testing end");
or
DPRINT1("Testing start");
DPRINT1("Status : Sussess");
DPRINT1("Testing end");
it is like this I want adding to win32k and thuse build in test case.
I hope you all have understanding of good testcase and testframe buildin that can be easy disable and activate.
ofcures the testframe should not be in debug build. we maybe should create a complete new target for it as well
so public can get hold of it easy.
Our current gdi handle and handle table entry code uses a bunch of
macros, masks, bitshifts and even hardcoded values, iirc.
This leads imo to errors, will make the code less portable and cannot
make use of better compiler optimizations.
So I have created a new GDI_TABLE_ENTRY struct and a new type GDIHANDLE.
Both use unions and packed structs to
directly access all fields. GDI_TABLE_ENTRY is completely compatible to
our current one, so all the code would still be valid.
+ the compiler can optimize access of single elements better (movzx,
byte ptr ...)
+ no more need for additional masks, shifts and macros
+ no more messed up code because of wrong hardcoded values
+ better readable code
+ probably easier porting to 64 bits
- must be redefined for big-endian systems
- direct access of stockbit is slightly slower, but could still be
handled by a macro
#pragma pack(push,1)
typedef struct
{
PVOID KernelData; /* Points to the kernel mode structure */
union
{
DWORD ProcessId; /* process id that created the object, 0 for
kernel objects */
struct
{
unsigned ProcessId16: 16;
unsigned Unused: 16;
};
};
union
{
ULONG Type;
struct
{
union
{
unsigned TypeLower: 16;
struct
{
union
{
unsigned HandleTypeStock: 8;
struct
{
unsigned HandleType: 7;
unsigned StockBit: 1;
};
};
unsigned ReuseCount: 8;
};
};
union
{
unsigned TypeUpper: 16;
struct
{
unsigned StorageType: 8; /* PEN uses same value as
BRUSH here, no stock bit */
unsigned Flags: 8;
};
};
};
};
PVOID UserData; /* Points to the user mode structure, usually NULL
though */
} GDI_TABLE_ENTRY, *PGDI_TABLE_ENTRY;;
typedef union
{
HGDIOBJ Handle;
struct
{
unsigned Index: 16;
union
{
unsigned Upper: 16;
struct
{
union
{
unsigned HandleTypeStock: 8;
struct
{
unsigned HandleType: 7;
unsigned StockBit: 1;
};
};
unsigned ReuseCount: 8;
};
};
};
} GDIHANDLE, *PGDIHANDLE;
#pragma pack(pop)
There is still a branch "xen", where some work has been done, however
it's greatly outdated. If someone has a wish, he could make a new
branch. But we don't have any volunteers at the moment.
WBR,
Aleksey Bragin.
On Aug 30, 2007, at 6:32 PM, Brian wrote:
> i was curious as to the status of reactos on xen. does it work(boot
> at all)? i haven't seen anything new about it on the site, and i
> interested.
>
> thanks in advance
> --
> brian
i was curious as to the status of reactos on xen. does it work(boot at all)?
i haven't seen anything new about it on the site, and i interested.
thanks in advance
--
brian
