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
Is there going to be a new release candidate of ReactOS version 0.3.3? I
tested it very shortly and was very impressed with how it looked in
comparison to version 0.3.0. Is there a list of known bugs as feedback
from 0.3.3rc1 testers? Searching through Bugzilla might be a bit too
much :).
Anyway, the issues I experience in VMware 6.00 on WinXP Pro x64 host so
far are:
* diskette drive not visible (and/or working). Ever since 0.2.8 or so?
* shutdown does not close the virtual machine (might be improper
shutdown). Screen goes all black and need to enter VMware menu to
shutdown the ReactOS virtual machine.
Is the AUTORUN.INF by now the only file on the root of the CD? icons and
readme files can go in subdirectories I guess, which makes adding
ReactOS to multi-installation CDs a lot easier (a CD/DVD containing
setup or LiveCD of various operating systems, mostly using the Isolinux
bootloader for a frontend menu and chainloading bootsectors).
I've not extensively tested the RC1 on for example if it still can
complete installation and bootup with 32MB or less RAM installed (VMware
allows anywhere from 4MB to 8GB in increments of 4MB, Bochs/Qemu allow
1MB increases).
A resolved item I noticed in this new release was the ability to enter
digits for the computername, wasnt possible previously in 0.3.0 or 0.3.1.
ReactOS is getting interesting by now..a Win32 operating system with a
size of about 50MB and capable of playing huge games sooner or later.
Looks like a blessing to my limited size (16GB) DRAM based solid state disk.
Hi,
I have it half way done. Run the test program and you can see. Program works in
W2k, XP and Wine. mingw32-gcc -mwindows -Os GetGlyphOutline.c -o ggo.exe
I stopped messing with it two weeks ago, I needed to work on something else.
When testing you can select the alphanumeric character with the keyboard. The
original program had "a" but I changed it to "L" something simple to draw at
first. You will see the problem.
The test program from Dr. Dobb's Journal http://www.ddj.com/184409154?pgno=12
Thanks,
James
Runs and hides~
>Personal preference.
>Wine are nearing to a 1.0 product and are very careful about what code
>enters their repository.
>ReactOS does not currently meet their strict policy.
>
>If you want to get code into Wine, you must submit your patches with test
>cases and if required, relevant links to documentation.
I have also ask the question on the WINE-mailinglist.
The answer at
http://www.winehq.org/pipermail/wine-devel/2007-August/058929.html
looks like, that the test-suites are not the only reason.
Greatings
theuserbl
_________________________________________________________________
Sie suchen E-Mails, Dokumente oder Fotos? Die neue MSN Suche Toolbar mit
Windows-Desktopsuche liefert in sekundenschnelle Ergebnisse. Jetzt neu!
http://desktop.msn.de/ Jetzt gratis downloaden!
As I already said, the difference between ReactOS and WINE, as it's
written in that Wine mailing list, is that ReactOS "is known" [by
some] for reversing MS binaries, and Wine is not known for reversing
MS binaries (though it does not imply ReactOS is always doing it, and
Wine did [does] not reverse engineer).
Also, Wine is not "Open Source community", it is *part* of Open
source community, as are thousands of other projects, which somehow
form the general perception of projects.
WBR,
Aleksey Bragin.
On Aug 29, 2007, at 7:01 PM, Marc Piulachs wrote:
>
> Does it mean ReactOS is not respected/trusted among the Open Source
> community for disassembling Microsoft binaries?
>
> I don't know if this accusation is really true or not but if it's
> not I
> think it's even worse because that means that something is failing
> (probably
> communication) between the project and the OS community. Doing
> nothing about
> that is IMHO a very bad idea.
>
> I think it deserves some deep reflection and a *serious* strategy
> to change
> that general opinion. Earn respect is a KEY thing to do if the
> project wants
> to attract new developers.
>
> My two cents,
> Marc
