Hello!
While the state of the original code is horrendous, and removing it was a step in the good direction, this simplified implementation omits many of the optimizations and specific VGA tricks that the original "author" of the code had intended to duplicate.
If you'd like, I would be open to talking to eVb (we both have some experience with VGA programming) to create an efficient 4BitBlt routine similar to the original one that has been removed, but one that actually has basis in actual fact and isn't of the nature this original implementation was.
I can see the original code was converting packed data into per-plane (planar) data and had special edge handling, but it looks like the original author did not realize this, and most of the modulo-and-shifts appear as bitwise ANDs (compiler optimizations), which is just plain confusing.
Since the rest of bootvid is probably the same "quality", we could take a good look at it, both from a coding and legal standpoint, if you'd like.
-r
Author: gschneider
Date: Sun May 30 01:54:47 2010
New Revision: 47431
URL: http://svn.reactos.org/svn/reactos?rev=47431&view=rev
Log:
[BOOTVID] Dramatically simplify 4bpp blitting routine
See issue #5103 for more details.
Modified:
trunk/reactos/drivers/base/bootvid/i386/vga.c
Modified: trunk/reactos/drivers/base/bootvid/i386/vga.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/base/bootvid/i386/…
==============================================================================
--- trunk/reactos/drivers/base/bootvid/i386/vga.c [iso-8859-1] (original)
+++ trunk/reactos/drivers/base/bootvid/i386/vga.c [iso-8859-1] Sun May 30 01:54:47 2010
@@ -402,33 +402,20 @@
IN ULONG BitsPerPixel,
IN ULONG Delta)
{
- ULONG LeftAnd, LeftShifted, LeftPlusOne, LeftPos;
- ULONG lMask, rMask;
- UCHAR NotlMask;
- ULONG Distance;
- ULONG DistanceMinusLeftBpp;
- ULONG SomeYesNoFlag, SomeYesNoFlag2;
- PUCHAR PixelPosition, m;
- PUCHAR i, k;
- ULONG j;
- ULONG x;
- ULONG Plane;
- UCHAR LeftArray[84];
- PUCHAR CurrentLeft;
- PUCHAR l;
- ULONG LoopCount;
- UCHAR pMask, PlaneShift;
- BOOLEAN Odd;
- UCHAR Value;
+ ULONG sx, dx, dy;
+ UCHAR color;
+ ULONG offset = 0;
+ const ULONG Bottom = Top + Height;
+ const ULONG Right = Left + Width;
/* Check if the buffer isn't 4bpp */
if (BitsPerPixel != 4)
{
/* FIXME: TODO */
DbgPrint("Unhandled BitBlt\n"
- "%lxx%lx @ (%lx,%lx)\n"
- "Bits Per Pixel %lx\n"
- "Buffer: %p. Delta: %lx\n",
+ "%lux%lu @ (%lu|%lu)\n"
+ "Bits Per Pixel %lu\n"
+ "Buffer: %p. Delta: %lu\n",
Width,
Height,
Left,
@@ -439,181 +426,28 @@
return;
}
- /* Get the masks and other values */
- LeftAnd = Left & 0x7;
- lMask = lMaskTable[LeftAnd];
- Distance = Width + Left;
- rMask = rMaskTable[(Distance - 1) & 0x7];
- Left >>= 3;
-
- /* Set some values */
- SomeYesNoFlag = FALSE;
- SomeYesNoFlag2 = FALSE;
- Distance = (Distance - 1) >> 3;
- DistanceMinusLeftBpp = Distance - Left;
-
- /* Check if the distance is equal to the left position and add the masks */
- if (Left == Distance) lMask += rMask;
-
- /* Check if there's no distance offset */
- if (DistanceMinusLeftBpp)
- {
- /* Set the first flag on */
- SomeYesNoFlag = TRUE;
-
- /* Decrease offset and check if we still have one */
- if (--DistanceMinusLeftBpp)
- {
- /* Still have a distance offset */
- SomeYesNoFlag2 = TRUE;
- }
- }
-
- /* Calculate initial pixel position */
- PixelPosition = (PUCHAR)VgaBase + (Top * 80) + Left;
-
- /* Set loop buffer variable */
- i = Buffer;
-
- /* Switch to mode 0 */
- ReadWriteMode(0);
-
- /* Leave now if the height is 0 */
- if (Height <= 0) return;
-
- /* Set more weird values */
- CurrentLeft = &LeftArray[Left];
- NotlMask = ~(UCHAR)lMask;
- LeftPlusOne = Left + 1;
- LeftShifted = (lMask << 8) | 8;
- j = Height;
-
- /* Start the height loop */
+ /* 4bpp blitting */
+ dy = Top;
do
{
- /* Start the plane loop */
- Plane = 0;
+ sx = 0;
do
{
- /* Clear the current value */
- *CurrentLeft = 0;
- LoopCount = 0;
-
- /* Set the buffer loop variable for this loop */
- k = i;
-
- /* Calculate plane shift and pixel mask */
- PlaneShift = 1 << Plane;
- pMask = PixelMask[LeftAnd];
-
- /* Check if we have a width */
- if (Width > 0)
- {
- /* Loop it */
- l = CurrentLeft;
- x = Width;
- do
- {
- /* Check if we're odd and increase the loop count */
- Odd = LoopCount & 1 ? TRUE : FALSE;
- LoopCount++;
- if (Odd)
- {
- /* Check for the plane shift */
- if (*k & PlaneShift)
- {
- /* Write the pixel mask */
- *l |= pMask;
- }
-
- /* Increase buffer position */
- k++;
- }
- else
- {
- /* Check for plane shift */
- if ((*k >> 4) & PlaneShift)
- {
- /* Write the pixel mask */
- *l |= pMask;
- }
- }
-
- /* Shift the pixel mask */
- pMask >>= 1;
- if (!pMask)
- {
- /* Move to the next current left position and clear it */
- l++;
- *l = 0;
-
- /* Set the pixel mask to 0x80 */
- pMask = 0x80;
- }
- } while (--x);
- }
-
- /* Set the plane value */
- __outpw(0x3C4, (1 << (Plane + 8) | 2));
-
- /* Select the bitmask register and write the mask */
- __outpw(0x3CE, (USHORT)LeftShifted);
-
- /* Read the current Pixel value */
- Value = READ_REGISTER_UCHAR(PixelPosition);
-
- /* Add our mask */
- Value = (Value & NotlMask) | *CurrentLeft;
-
- /* Set current left for the loop, and write new pixel value */
- LeftPos = LeftPlusOne;
- WRITE_REGISTER_UCHAR(PixelPosition, Value);
-
- /* Set loop pixel position and check if we should loop */
- m = PixelPosition + 1;
- if (SomeYesNoFlag2)
- {
- /* Set the bitmask to 0xFF for all 4 planes */
- __outpw(0x3CE, 0xFF08);
-
- /* Check if we have any distance left */
- if (DistanceMinusLeftBpp > 0)
- {
- /* Start looping it */
- x = DistanceMinusLeftBpp;
- do
- {
- /* Write the value */
- WRITE_REGISTER_UCHAR(m, LeftArray[LeftPos]);
-
- /* Go to the next position */
- m++;
- LeftPos++;
- } while (--x);
- }
- }
-
- /* Check if the first flag is on */
- if (SomeYesNoFlag)
- {
- /* Set the mask value */
- __outpw(0x3CE, (rMask << 8) | 8);
-
- /* Read the current Pixel value */
- Value = READ_REGISTER_UCHAR(m);
-
- /* Add our mask */
- Value = (Value & ~(UCHAR)rMask) | LeftArray[LeftPos];
-
- /* Set current left for the loop, and write new pixel value */
- WRITE_REGISTER_UCHAR(m, Value);
- }
- } while (++Plane < 4);
-
- /* Update pixel position, buffer and height */
- PixelPosition += 80;
- i += Delta;
- } while (--j);
+ /* Extract color */
+ color = Buffer[offset + sx];
+
+ /* Calc destination x */
+ dx = Left + (sx << 1);
+
+ /* Set two pixels */
+ SetPixel(dx, dy, color >> 4);
+ SetPixel(dx + 1, dy, color & 0x0F);
+
+ sx++;
+ } while (dx < Right);
+ offset += Delta;
+ dy++;
+ } while (dy < Bottom);
}
VOID
Hi!
It is really funny to see that translators don't seem to understand the
simple meaning of:
/*
* Attention Translators:
* DO NOT TRANSLATE THESE RESOURCES YET!
*/
It means: DO NOT TRANSLATE THESE RESOURCES YET!!!!!!! Got it???
Yes, but why?
Because usrmgr is not finished yet from a programmers point of view.
Most of the underlying infrastructure ist entirely missing. Right now,
usrmgr is completely useless and its look and feel might change without
prior notice.
So please don't waste your precious time by adding more translations!
Please translate other missing texts instead, but leave usrmgr alone. At
least as long as the little note at the top is still in place.
Thank you very much for your attention!
Regards,
Eric
Hi all,
I am new to this mail group and have a question that probably needs
your kind of technical knowledge to answer. I want to use reactos,
however, up to its completion, can I use some libraries on windows to
replace them? In example, wine libraries can be superseded by original
windows libraries if you own them. I want to make the inverse of this
simply for security reasons to use a kernel fully opensource and which
have a documented api. So can I use ntkrnlos.exe and hal.dll or
similar in original windows installations to replace propriety kernel
and libraries for security reasons? If yes, which of them should I
use, and are they complete to replace them?
Also a second question may arise as "the priority of reactos
development can be focused on firstly these parts of the project or
not?"...
Best Regards...
Ahmet Alper Parker
Hi!
That is for bAnsi:1 to set if ansi. Good job over all!
James
On Sat, May 22, 2010 at 7:07 AM, Timo Kreuzer <timo.kreuzer(a)web.de> wrote:
> Aleksey Bragin wrote:
>> Shouldn't the LARGE_UNICODE_STRING be used there instead?
>>
> On Windows the window name is ANSI for an ANSI caller and UNICODE for a
> UNICODE caller.
> The class name is always in UNICODE though.
>
> See also http://www.reactos.org/wiki/Techwiki:Win32k/LARGE_UNICODE_STRING
>
PS: Still on sick leave.
cgutman(a)svn.reactos.org wrote:
> + DbgPrint("%S: %d test executed (0 marked as todo, %d failures),
> %d skipped.\n", TestName, total, failures, skipped);
Nice! Though testman won't parse this if you don't change "test" to
"tests" ;-)
Best regards,
Colin
Shouldn't the LARGE_UNICODE_STRING be used there instead?
WBR,
Aleksey.
On May 22, 2010, at 5:05 AM, tkreuzer(a)svn.reactos.org wrote:
> Author: tkreuzer
> Date: Sat May 22 03:05:31 2010
> New Revision: 47295
>
> URL: http://svn.reactos.org/svn/reactos?rev=47295&view=rev
> Log:
> [WIN32K / USER32]
> Convert the window text string from UNICODE_STRING to LARGE_STRING
> and fix NtUserCreateWindowEx parameters. We currently still pass
> UNICODE only LARGE_STRINGs, as the rest of the code in win32k
> expects this.
> Fixes display of large text windows, like the winzip license.
> See issue #2900 for more details.
>
> Modified:
> trunk/reactos/dll/win32/user32/windows/window.c
> trunk/reactos/include/reactos/win32k/ntuser.h
> trunk/reactos/subsystems/win32/win32k/include/window.h
> trunk/reactos/subsystems/win32/win32k/ntuser/desktop.c
> trunk/reactos/subsystems/win32/win32k/ntuser/message.c
> trunk/reactos/subsystems/win32/win32k/ntuser/painting.c
> trunk/reactos/subsystems/win32/win32k/ntuser/window.c
Hi Michael,
there is no need to hardcode the messagebox output language to english.
In the resource files a string exists for what you're doing:
IDS_FINISHEDFIND (probably already loaded into a string in the code
somewhere).
Thanks,
Gregor
"Jan Blomqvist Kinander" <jan.blomqvist(a)reactos.org> wrote:
> Opening many sessions in windows is really bad idea ... for kernel stuff and another csrss, smss problems ... terminal server blue screen, black screen, printers, etc ... so i have an idea for a workaround ...
>
> Is open a session using createwinstation api ... in that session, create multiples desktops, using createdesktop api, in each desktop will be secure shell replacement, ejecuted using x user credentials (runas) ... the printing is gonna be universal virtual printers that receive the buffer from the win32, and send the emf or pdf to the client ...
>
Hi Jan & Gonzalo,
I'm no expert in this particular area, but don't You think it would be
more logical
to give each remote a winstation, and not just a desktop on a shared
winstation ?
Best Regards
// Love
Hi Developers, I have been aproached by a certain Gonzalo from Colombia, he claims to be a developer who wants to make a Terminal Server Clone, I enclose the mail he sent me, please have a look at it and answer him.
Yours Sincerely,
Jaix Bly
>>>
Hey Jaix, i'm Gonzalo from Colombia (South America) tecnologia(a)slmsistemas.net
I'm a coder, i develop more than 500 utils and apps for terminal server and citrix .... i have a product called Galeon that is a "clon" of terminal server with shell replacement, full duplex sound, universal printer driver, etc ...
I want to develop a Open Source Terminal Server based in something like VNC and OpenVPN
Opening many sessions in windows is really bad idea ... for kernel stuff and another csrss, smss problems ... terminal server blue screen, black screen, printers, etc ... so i have an idea for a workaround ...
Is open a session using createwinstation api ... in that session, create multiples desktops, using createdesktop api, in each desktop will be secure shell replacement, ejecuted using x user credentials (runas) ... the printing is gonna be universal virtual printers that receive the buffer from the win32, and send the emf or pdf to the client ...
Using Virtual Channels is a pain in the ass ... because they all travel using only one tcp socket ... (really bad idea) so, problems with video, audio, performance, etc ...i think we can use openvpn to connect to only one port (443 to ssl vpn) and after the vpn is connected, we can open many socket (each service) between the client and the server desktop ... so we can send printing, sound, video, etc ...
I have many things already developed ... createwinstation, createdesktop, impersonate users, universal printer, openvpn implementation .. etc ... but i need help in other areas, like the video grabber in the desktop (maybe a modified vnc) i can make a printscreen of each desktop, and send the jpg ... and is working, but is a really bad idea ...
This product can merge with ReactOS .. and be the ReactOS terminal server ...
https://sourceforge.net/projects/oswts/
What do you think?
Do you receive this mail?
Thanks,
Gonzalo.
--
Cordialmente:
Ing. Gonzalo Araujo C
MCSE, MCSA, MCSD, ITIL, CISSP, C|EH, LPI
Desarrollo SLM Sistemas Ltda
desarrollo(a)slmsistemas.com
tecnologia(a)slmsistemas.net
http://www.slmsistemas.com
Colombia - Guatemala - Chile - Venezuela
<<<
Hello! I already have almost latest trunk build of ReactOS installed.
Now I want to try
modifying some sources, but recompiling whole system takes about 8 hours
on my
very slow PC. How can I recompile only modified part of the system?
I am using RosBE for Linux version 1.5.
Hello,
as you all know we have quite a lot of regressions recently, and
recently they only add up to one another causing annoyances of
testers and developers. There is a strong need to change this
situation as soon as possible, otherwise the project's future is
undetermined.
I want to propose a step-by-step approach. Our brave testing team has
created a good overview of the most important regressions and bugs we
have so far: http://www.reactos.org/wiki/Buglist .
Now, very important(!):
For the first step I would like ALL developers to drop their current
ReactOS-related work, including all work in branches or wherever else
and focus ONLY on fixing regressions from that list. The goal is to
fix all confirmed regressions that have been introduced, starting
from the most recent and going down to the most ancient. All possible
ways to remove a regression could be used: starting from a proper fix
and finishing with a total revert or commenting out even good code.
Process coordination: feel free to commit proper fixes right away,
however as for reverts, I, and/or comittee of our core devs, would
like to have a final say on whether something should be reverted.
I repeat, all other non-regression related commits to the official
ReactOS SVN repository are forbidden, even to branches. The only
exception may be developers whose access is restricted to branches
only.
Thank you for understanding,
Aleksey Bragin.
Gregor Schneider <grschneider(a)gmail.com> wrote:
> Concerning using an internal format: let's assume we got three 8bpp
> surfaces (source, destination, pattern), which are quite big pending
> for a raster operation. You would convert these three to another
> format like 32bpp, process them and convert back?
No, of course not, Gregor,
You're absolutely right about the 8bpp S/D/P situation.
It would be a terrible idea to convert such a simple format to another
for a tertiary rop.
I think I was thinking about an internal graphic structure for the
display context .. ;-)
Accumulate all rops to an 32bit DIB internally, unless the physical
device is low bpp.
Come to think of it, almost anything but RLE is suitable internally,
depending
on the output color requirements. The graphics primitives for lines,
ellipses, and
so on can be small enough to separate a few specialized implementations for
different bit depths. I guess that's what You do ? (I didn't look yet).
Branching for different bit formats in the primitives would be a bad
idea though..
Wouldn't You agree ?
Best Regards
// Love
PS. I have a slice-line routine that's faster than an oiled lightning,
and it's really
small enough that it'd be worth replicating the code for different bit
depths.
Let me know if you're interested.
Hi guys,
Sorry for barging in on a discussion about code that's not on my desk,
but looking at your code there is something I want to point out.
Graphics code need to be *fast*, that's a primary consideration,
so I'm taken aback when I look at your inner bit expansion loop.
This is horrible from a standpoint of performance.
> length = (*bits++) >> shift;
> if (length)
> {
> c = *bits++;
> while (length--)
> {
> if (x >= width) break;
> temp = UncompressedBits + (((height - y) * Delta) + x);
> x++;
> *temp = c;
> }
> }
You're recomputing the start of the bit-run for every pixel you emit,
when you should move that calculation out of the inner loop to get
high performance. Graphics code is not the arena where you can be lazy
and hope that the optimizer will make your inefficient code faster.
At the very least You ought to write it something like this:
> length = (*bits++) >> shift;
> if (length)
> {
> c = *bits++;
> if (x + length > width) {
> // RLE encoding error - Bit-run exceeds width
> length = width - x;
> }
> temp = UncompressedBits + ((height - y) * Delta);
> x += length; // precompute finishing x
> while (length--)
> {
> *temp++ = c;
> }
> }
As a sideline note I'd like to mention that it's standard practice
in graphics libraries to use one unified bitmap format internally
to make internal processing like alpha-blend or text rendering or
whatever straight forward. The 32bit DIB format is quite suitable,
even if it uses the most memory - Graphics never was cheap on memory.
Just my penny to the pot
Best Regards
// Love
Hello,
This is the second time that work that someone on the ARM Team has worked on has been mostly reverted without any communication with us, and incorrect changes have been added to parts of our work.
The Eng function worked on even clearly stated comments such as "Compressed surfaces don't have scanlines!", yet this new patch restores the old incorrect functionality.
lDelta cannot be anything but != 0 for compressed data such as RLE or JPG/PNG! And creating the DIB should not decompress the bits.
Please read http://www.tech-archive.net/Archive/Development/microsoft.public.developmen… for example.
I do not understand how you can believe that "RLE" has a scan-line. I am not a graphics expert by no means, but even I understand this fact: by definition scan-lines in an RLE are dynamic, and a scan-line offset table contains information about that.
You do not have to take my word for it, as a simple driver test case will also show that Windows does not decompress RLE data or set lDelta to any other value than 0 with an RLE bitmap. You can find more information on RLE at http://www.fileformat.info/mirror/egff/ch09_03.htm.
If you are wondering why there have not been any commits coming lately, recent actions such as these as the cause.
-r
Author: khornicek
Date: Sat May 8 20:09:45 2010
New Revision: 47134
URL: http://svn.reactos.org/svn/reactos?rev=47134&view=rev
Log:
[WIN32K]
- Bring back support for RLE compressed bitmaps.
- Merge the decompress functions for 4bb and 8bpp bitmaps to one generic function.
- Simplify SURFMEM_bCreateDib a bit by not allowing PNG/JPEG compression at all.
See issue #5276 for more details.
Modified:
trunk/reactos/subsystems/win32/win32k/eng/surface.c
Modified: trunk/reactos/subsystems/win32/win32k/eng/surface.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/en…
==============================================================================
--- trunk/reactos/subsystems/win32/win32k/eng/surface.c [iso-8859-1] (original)
+++ trunk/reactos/subsystems/win32/win32k/eng/surface.c [iso-8859-1] Sat May 8 20:09:45 2010
@@ -204,48 +204,59 @@
return NewBitmap;
}
-VOID Decompress4bpp(SIZEL Size, BYTE *CompressedBits, BYTE *UncompressedBits, LONG Delta)
-{
- int x = 0;
- int y = Size.cy - 1;
- int c;
- int length;
- int width = ((Size.cx+1)/2);
- int height = Size.cy - 1;
+BOOL DecompressBitmap(SIZEL Size, BYTE *CompressedBits, BYTE *UncompressedBits, LONG Delta, ULONG Format)
+{
+ INT x = 0;
+ INT y = Size.cy - 1;
+ INT c;
+ INT length;
+ INT width;
+ INT height = Size.cy - 1;
BYTE *begin = CompressedBits;
BYTE *bits = CompressedBits;
BYTE *temp;
- while (y >= 0)
- {
- length = *bits++ / 2;
- if (length)
- {
- c = *bits++;
- while (length--)
- {
- if (x >= width) break;
- temp = UncompressedBits + (((height - y) * Delta) + x);
- x++;
- *temp = c;
- }
- }
- else
- {
- length = *bits++;
- switch (length)
- {
+ INT shift = 0;
+
+ if (Format == BMF_4RLE)
+ shift = 1;
+ else if(Format != BMF_8RLE)
+ return FALSE;
+
+ width = ((Size.cx + shift) >> shift);
+
+ _SEH2_TRY
+ {
+ while (y >= 0)
+ {
+ length = (*bits++) >> shift;
+ if (length)
+ {
+ c = *bits++;
+ while (length--)
+ {
+ if (x >= width) break;
+ temp = UncompressedBits + (((height - y) * Delta) + x);
+ x++;
+ *temp = c;
+ }
+ }
+ else
+ {
+ length = *bits++;
+ switch (length)
+ {
case RLE_EOL:
x = 0;
y--;
break;
case RLE_END:
- return;
+ _SEH2_YIELD(return TRUE);
case RLE_DELTA:
- x += (*bits++)/2;
- y -= (*bits++)/2;
+ x += (*bits++) >> shift;
+ y -= (*bits++) >> shift;
break;
default:
- length /= 2;
+ length = length >> shift;
while (length--)
{
c = *bits++;
@@ -260,69 +271,18 @@
{
bits++;
}
- }
- }
- }
-}
-
-VOID Decompress8bpp(SIZEL Size, BYTE *CompressedBits, BYTE *UncompressedBits, LONG Delta)
-{
- int x = 0;
- int y = Size.cy - 1;
- int c;
- int length;
- int width = Size.cx;
- int height = Size.cy - 1;
- BYTE *begin = CompressedBits;
- BYTE *bits = CompressedBits;
- BYTE *temp;
- while (y >= 0)
- {
- length = *bits++;
- if (length)
- {
- c = *bits++;
- while (length--)
- {
- if (x >= width) break;
- temp = UncompressedBits + (((height - y) * Delta) + x);
- x++;
- *temp = c;
- }
- }
- else
- {
- length = *bits++;
- switch (length)
- {
- case RLE_EOL:
- x = 0;
- y--;
- break;
- case RLE_END:
- return;
- case RLE_DELTA:
- x += *bits++;
- y -= *bits++;
- break;
- default:
- while (length--)
- {
- c = *bits++;
- if (x < width)
- {
- temp = UncompressedBits + (((height - y) * Delta) + x);
- x++;
- *temp = c;
- }
- }
- if ((bits - begin) & 1)
- {
- bits++;
- }
- }
- }
- }
+ }
+ }
+ }
+ }
+ _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER)
+ {
+ DPRINT1("Decoding error\n");
+ _SEH2_YIELD(return FALSE);
+ }
+ _SEH2_END;
+
+ return TRUE;
}
HBITMAP FASTCALL
@@ -362,7 +322,7 @@
pso->cjBits = pso->lDelta * Size.cy;
UncompressedFormat = BMF_4BPP;
UncompressedBits = EngAllocMem(FL_ZERO_MEMORY, pso->cjBits, TAG_DIB);
- Decompress4bpp(Size, (BYTE *)Bits, (BYTE *)UncompressedBits, pso->lDelta);
+ DecompressBitmap(Size, (BYTE *)Bits, (BYTE *)UncompressedBits, pso->lDelta, Format);
}
else if (Format == BMF_8RLE)
{
@@ -370,7 +330,7 @@
pso->cjBits = pso->lDelta * Size.cy;
UncompressedFormat = BMF_8BPP;
UncompressedBits = EngAllocMem(FL_ZERO_MEMORY, pso->cjBits, TAG_DIB);
- Decompress8bpp(Size, (BYTE *)Bits, (BYTE *)UncompressedBits, pso->lDelta);
+ DecompressBitmap(Size, (BYTE *)Bits, (BYTE *)UncompressedBits, pso->lDelta, Format);
}
else
{
@@ -467,6 +427,7 @@
PSURFACE psurf;
SIZEL LocalSize;
BOOLEAN AllocatedLocally = FALSE;
+ PVOID DecompressedBits = NULL;
/*
* First, check the format so we can get the aligned scanline width.
@@ -500,17 +461,29 @@
break;
case BMF_8RLE:
+ ScanLine = (BitmapInfo->Width + 3) & ~3;
+ Compressed = TRUE;
+ break;
case BMF_4RLE:
+ ScanLine = ((BitmapInfo->Width + 7) & ~7) >> 1;
+ Compressed = TRUE;
+ break;
+
case BMF_JPEG:
case BMF_PNG:
- Compressed = TRUE;
- break;
+ ASSERT(FALSE); // ENGDDI shouldn't be creating PNGs for drivers ;-)
+ DPRINT1("No support for JPEG and PNG formats\n");
+ return NULL;
default:
DPRINT1("Invalid bitmap format\n");
return NULL;
}
+ /* Save local bitmap size */
+ LocalSize.cy = BitmapInfo->Height;
+ LocalSize.cx = BitmapInfo->Width;
+
/* Does the device manage its own surface? */
if (!Bits)
{
@@ -519,7 +492,8 @@
{
/* Note: we should not be seeing this scenario from ENGDDI */
ASSERT(FALSE);
- Size = BitmapInfo->Size;
+ DPRINT1("RLE compressed bitmap requested with no valid bitmap bits\n");
+ return NULL;
}
else
{
@@ -551,6 +525,22 @@
{
/* Should not have asked for user memory */
ASSERT((BitmapInfo->Flags & BMF_USERMEM) == 0);
+
+ if (Compressed)
+ {
+ DecompressedBits = EngAllocMem(FL_ZERO_MEMORY, BitmapInfo->Height * ScanLine, TAG_DIB);
+
+ if(!DecompressedBits)
+ return NULL;
+
+ if(!DecompressBitmap(LocalSize, (BYTE *)Bits, (BYTE *)DecompressedBits, ScanLine, BitmapInfo->Format))
+ {
+ EngFreeMem(DecompressedBits);
+ return NULL;
+ }
+
+ BitmapInfo->Format = (BitmapInfo->Format == BMF_4RLE) ? BMF_4BPP : BMF_8BPP;
+ }
}
/* Allocate the actual surface object structure */
@@ -564,6 +554,8 @@
else
EngFreeMem(Bits);
}
+ if (DecompressedBits)
+ EngFreeMem(DecompressedBits);
return NULL;
}
@@ -584,11 +576,9 @@
pso->fjBitmap = BitmapInfo->Flags & (BMF_TOPDOWN | BMF_UMPDMEM | BMF_USERMEM);
/* Save size and type */
- LocalSize.cy = BitmapInfo->Height;
- LocalSize.cx = BitmapInfo->Width;
pso->sizlBitmap = LocalSize;
pso->iType = STYPE_BITMAP;
-
+
/* Device-managed surface, no flags or dimension */
pso->dhsurf = 0;
pso->dhpdev = NULL;
@@ -599,48 +589,28 @@
psurf->hSecure = NULL;
psurf->hDIBSection = NULL;
psurf->flHooks = 0;
-
+
/* Set bits */
- pso->pvBits = Bits;
-
- /* Check for bitmap type */
- if (!Compressed)
- {
- /* Number of bits is based on the height times the scanline */
- pso->cjBits = BitmapInfo->Height * ScanLine;
- if (BitmapInfo->Flags & BMF_TOPDOWN)
- {
- /* For topdown, the base address starts with the bits */
- pso->pvScan0 = pso->pvBits;
- pso->lDelta = ScanLine;
- }
- else
- {
- /* Otherwise we start with the end and go up */
- pso->pvScan0 = (PVOID)((ULONG_PTR)pso->pvBits + pso->cjBits - ScanLine);
- pso->lDelta = -ScanLine;
- }
+ if(Compressed)
+ pso->pvBits = DecompressedBits;
+ else
+ pso->pvBits = Bits;
+
+ /* Number of bits is based on the height times the scanline */
+ pso->cjBits = BitmapInfo->Height * ScanLine;
+ if (BitmapInfo->Flags & BMF_TOPDOWN)
+ {
+ /* For topdown, the base address starts with the bits */
+ pso->pvScan0 = pso->pvBits;
+ pso->lDelta = ScanLine;
}
else
{
- /* Compressed surfaces don't have scanlines! */
- pso->lDelta = 0;
- pso->cjBits = BitmapInfo->Size;
-
- /* Check for JPG or PNG */
- if ((BitmapInfo->Format != BMF_JPEG) && (BitmapInfo->Format != BMF_PNG))
- {
- /* Wherever the bit data is */
- pso->pvScan0 = pso->pvBits;
- }
- else
- {
- /* Fancy formats don't use a base address */
- pso->pvScan0 = NULL;
- ASSERT(FALSE); // ENGDDI shouldn't be creating PNGs for drivers ;-)
- }
- }
-
+ /* Otherwise we start with the end and go up */
+ pso->pvScan0 = (PVOID)((ULONG_PTR)pso->pvBits + pso->cjBits - ScanLine);
+ pso->lDelta = -ScanLine;
+ }
+
/* Finally set the handle and uniq */
pso->hsurf = (HSURF)psurf->BaseObject.hHmgr;
pso->iUniq = 0;
Hello everybody,
We're currently in the process of moving a main server (Buildmaster,
ISO-Storage, etc.) to another location and doing upgrades on the other
servers.
As always, we try to keep the downtime low, but expect short outages in
the next few days.
You'll be notified when the move is over or if there are any major problems.
Best regards,
Colin
ekohl(a)svn.reactos.org wrote:
> PWSTR utf16_wcschr(PWSTR str, WCHAR c)
> +{
> + SIZE_T i;
> +
> + for(i = 0; str[i] && str[i] != c; i++);
> +
> + if(str[i])
> + return &str[i];
> + else
> + return NULL;
> +}
> +
> +PWSTR strchrW(PWSTR str, WCHAR c)
Why do you duplicate the same code for these wide-char string functions
here, just under a different name?
The utf16_* family of functions in this file was particularly designed to
address the issue of different wchar_t lengths on different hosts. It's
meant to be used together with the include/host/wcsfuncs.h header.
If you need an example, cmlib is one library using these functions (see
e.g. "cmlib.h" for the proper header inclusion, "cminit.c" for a use, etc.)
Best regards,
Colin
Hey guys,
Recently<http://source.winehq.org/git/wine.git/?a=history;f=dlls/msvcrt;hb=1ac163316…>wine
has made some improvements to its msvcrt and I've taken the time to
port them to reactos. changes include:
- implement per thread crt locales and many locale functions.
- implement/improve support for vc6, vc7, vc8 exceptions.
- implement/improve language support functions.
- implement/improve many library functions.
- implement many secure functions.
- use spec file for msvcrt.dll
- fix amd64 linking issues.
- add msvcirt.dll, msvcr7.dll ,msvc71.dll, msvc80.dll, msvcr90.dll from
wine (no longer need to install versions of ms runtime for visual c language
apps)
changes are divided into different parts but building has not been tested
with individual parts.
part 1, 2 and 3 include changes to centralize the definition of several key
macros (see reactos/wine/exception.h, reactos/wine/config.h,
crt/include/internal/wine/cppexcept.h)
also on part 2 in scanf.c wcs.c and possibly other files i didn't know what
libcntpr expected so i was quite severe hacking out functions and only
letting in the minimum necesary to build ntoskrnl and everything else that
uses it.
part3 includes changes to baseaddress.rbuild that should be revised, i
didn't know how to calculate a good base address for the msvcr dlls so i
just used the same one and let ntdll reallocate if necesary...
part5 applies to rostests.
and before you say it... msvcrt_winetest file now crashes with this trace:
dll/win32/kernel32/file/create.c:136 (CreateFileW@28) <-- arch didn't check
if lpFileName was valid
lib/sdk/crt/stdio/file.c:1485 (_wsopen)
modules/rostests/winetests/msvcrt/file.c:1179 (test_fopen_fclose_fcloseall)
ros-dev-request(a)reactos.org wrote:
>>> Look at this as a signal warning before the ship hits the reef.......
>>> The ship has turn into the reef!
>>>
>> No need to give false signals here, they often lead to loss of investment
>> (example from stock trading area).
>>
> Trying to make money from ReactOS is a bad idea and thinking about
> money from ReactOS, makes this idea delusional.
>
Sorry for barging into Your discussion guys,
but I think Aleksey meant that allegorically, not literally ??
Best Regards
Love
Michael!
Good work!!!!
Do you think this might be one of the reasons we are reentering
co_UserDestroyWindow? The DCE is cleared and (not cached) at first
then we go back a second time and hit the assert...?
http://www.reactos.org/bugzilla/show_bug.cgi?id=5320