Re: SymEnumSymbolsForAddr in dbghelp.dll
Guys, Just a quick status update on the symbol lookup and an explanation of what this question is all about. Basically, I have loaded the dbghelp file successfully and loaded all of the symbols for the module (aka, library, dll, etc) being linked. I then tried to invoke this function SymEnumSymbolsForAddrto enumerate each function's arguments and lo and behold, the damn function is not implemented in Wine.. but where there is a will, there is a way. I recalled that Wine has its own debugger and they implement the backtrace capability so I'm looking to see how they enumerate the arguments. I will let you know more soon. Roger From: Roger Cruz To: "wine-devel@winehq.org" Sent: Monday, April 16, 2012 9:13 PM Subject: SymEnumSymbolsForAddr in dbghelp.dll I wrote a simple piece of code that uses dbghelp.dll's SymEnumSymbolsForAddr() but when I went to search for its code in Wine, it looks to be missing. The dbghelp.spec has that function listed as "stub". What does stub mean in this context? Does it mean the function is not implemented? Are there any plans to? Thanks Roger R. Cruz
New forum software
Can I ask when we'll have the new forum software installed? It's been discussed ages ago and we still using the same old crappy version. Vitaliy.
SymEnumSymbolsForAddr in dbghelp.dll
I wrote a simple piece of code that uses dbghelp.dll's SymEnumSymbolsForAddr() but when I went to search for its code in Wine, it looks to be missing. The dbghelp.spec has that function listed as "stub". What does stub mean in this context? Does it mean the function is not implemented? Are there any plans to? Thanks Roger R. Cruz
Re: winebuild port to ARM?
Hi Andre, I am willing to help as much as my knowledge allows me to port this. The last time I wrote anything in ARM was about 15+ years ago so my knowledge of it is rather limited. I'm also trying to understand what every line of the assembly code is doing in x86. If someone with more knowledge were willing to port this file for us, it would be a great start :-) but failing that, I can fold up my sleeves and take a crack at it. Roger From: André Hentschel To: Wine Devel Sent: Friday, April 13, 2012 11:13 AM Subject: Re: winebuild port to ARM? Am 13.04.2012 08:55, schrieb Roger Cruz: > Is anyone interested in helping me port the x86 specific code in Winebuild to > ARM so I can get the relay tracing working? I am relatively new to ARM so > any help would be appreciate it. > > Thanks > Roger R. Cruz > > *From:* Roger Cruz > *To:* "wine-devel@winehq.org" > *Sent:* Monday, April 9, 2012 11:16 PM > *Subject:* winebuild port to ARM? > > Has anyone worked or is currently working on porting the x86 specific code in > Winebuild to ARM? Specifically the relay.c file? > It's on my todo list: http://wiki.winehq.org/ARM It won't be that easy and not only winebuild is involved, but also ntdll. I'm not that good in understanding x86 asm, but the code is partially commented, still i need to figure out the intention of every single line. How would you imagine "helping you to port"? -- Best Regards, André Hentschel
[shlwapi] Add NULL checks to StrCpyW and StrCatW
Hello friends, according to these results, it looks like the test I added in the patch crashes win2k SP4 but it works on all others. And it does not seem to be a thing that it can be resolved with dynamic library loading. So, what should I do? Do I need to comment them like it has been done (for example) into test_StrChrA()? Do I need to remove interely the test and revive previous patch? Please excuse my inexperience... Sincerely, Carlo Bramini. >Messaggio originale >Da: test...@testbot.winehq.org >Data: 16/04/2012 22.48 >A: >Ogg: TestBot job 17900 results: [shlwapi] Add NULL checks to StrCpyW and StrCatW > >VM StatusNumber of test failures >WINEBUILDcompleted >WNT4WSSP6completed 0 >W2KPROSP4completed 1 >WXPPROSP3completed 0 >W2K3R2SESP2 completed 0 >WVISTAADMcompleted 0 >W2K8SE completed 0 >W7PROcompleted 0 >W7PROX64 completed 0 >TEST64_W7SP1 completed 0 >W7PROX64 completed 0 >TEST64_W7SP1 completed 0 > >=== WINEBUILD (build) === >No build failures found > >=== WNT4WSSP6 (32 bit string) === >No test failures found > >=== W2KPROSP4 (32 bit string) === > >shlwapi: >string: unhandled exception c005 at 77C7F8A8 > >=== WXPPROSP3 (32 bit string) === >No test failures found > >=== W2K3R2SESP2 (32 bit string) === >No test failures found > >=== WVISTAADM (32 bit string) === >No test failures found > >=== W2K8SE (32 bit string) === >No test failures found > >=== W7PRO (32 bit string) === >No test failures found > >=== W7PROX64 (32 bit string) === >No test failures found > >=== TEST64_W7SP1 (32 bit string) === >No test failures found > >=== W7PROX64 (64 bit string) === >No test failures found > >=== TEST64_W7SP1 (64 bit string) === >No test failures found
Re: [shlwapi] Add NULL checks to StrCpyW and StrCatW
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17900 Your paranoid android. === W2KPROSP4 (32 bit string) === string: unhandled exception c005 at 77C7F8A8
Re: [PATCH] winealsa.drv: Init *num to 0 (Coverity)
On Mon, Apr 16, 2012 at 11:53:00AM -0500, Andrew Eikum wrote: > On Mon, Apr 16, 2012 at 09:09:58AM +0200, Marcus Meissner wrote: > > Also initialize a "may be uninitialized" value the compiler sees. > > > > Not sure what this means. *num is initialized at the beginning of > alsa_enum_devices, which is always called from GetEndpointIDs. Seems > like a Coverity oversight. I'd either leave it as-is, or also remove > the *num=0 from alsa_enum_devices. It cannot handle two variables that track the same logic easily. So it cannot see "counter" and "content" variables that belong together. I marked it as FALSE now. Ciao, Marcus
Re: [PATCH] winealsa.drv: Init *num to 0 (Coverity)
On Mon, Apr 16, 2012 at 11:53:00AM -0500, Andrew Eikum wrote:
> On Mon, Apr 16, 2012 at 09:09:58AM +0200, Marcus Meissner wrote:
> > Also initialize a "may be uninitialized" value the compiler sees.
> >
Of course I quoted the wrong section of your mail :)
>
> Not sure what this means. *num is initialized at the beginning of
> alsa_enum_devices, which is always called from GetEndpointIDs. Seems
> like a Coverity oversight. I'd either leave it as-is, or also remove
> the *num=0 from alsa_enum_devices.
>
> Andrew
>
> > Ciao, Marcus
> > ---
> > dlls/winealsa.drv/mmdevdrv.c |3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/dlls/winealsa.drv/mmdevdrv.c b/dlls/winealsa.drv/mmdevdrv.c
> > index e3c1d15..d84bbb2 100644
> > --- a/dlls/winealsa.drv/mmdevdrv.c
> > +++ b/dlls/winealsa.drv/mmdevdrv.c
> > @@ -345,7 +345,7 @@ static WCHAR *construct_device_id(EDataFlow flow, const
> > WCHAR *chunk1, const cha
> > {
> > WCHAR *ret;
> > const WCHAR *prefix;
> > -DWORD len_wchars = 0, chunk1_len, copied = 0, prefix_len;
> > +DWORD len_wchars = 0, chunk1_len = 0, copied = 0, prefix_len;
> >
> > static const WCHAR dashW[] = {' ','-',' ',0};
> > static const size_t dashW_len = (sizeof(dashW) / sizeof(*dashW)) - 1;
> > @@ -583,6 +583,7 @@ HRESULT WINAPI AUDDRV_GetEndpointIDs(EDataFlow flow,
> > WCHAR ***ids, GUID **guids,
> >
> > TRACE("%d %p %p %p %p\n", flow, ids, guids, num, def_index);
> >
> > +*num = 0;
> > *ids = NULL;
> > *guids = NULL;
> >
> > --
> > 1.7.3.4
> >
> >
> >
>
>
Re: [PATCH] winealsa.drv: Init *num to 0 (Coverity)
On Mon, Apr 16, 2012 at 09:09:58AM +0200, Marcus Meissner wrote:
> Also initialize a "may be uninitialized" value the compiler sees.
>
Not sure what this means. *num is initialized at the beginning of
alsa_enum_devices, which is always called from GetEndpointIDs. Seems
like a Coverity oversight. I'd either leave it as-is, or also remove
the *num=0 from alsa_enum_devices.
Andrew
> Ciao, Marcus
> ---
> dlls/winealsa.drv/mmdevdrv.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/dlls/winealsa.drv/mmdevdrv.c b/dlls/winealsa.drv/mmdevdrv.c
> index e3c1d15..d84bbb2 100644
> --- a/dlls/winealsa.drv/mmdevdrv.c
> +++ b/dlls/winealsa.drv/mmdevdrv.c
> @@ -345,7 +345,7 @@ static WCHAR *construct_device_id(EDataFlow flow, const
> WCHAR *chunk1, const cha
> {
> WCHAR *ret;
> const WCHAR *prefix;
> -DWORD len_wchars = 0, chunk1_len, copied = 0, prefix_len;
> +DWORD len_wchars = 0, chunk1_len = 0, copied = 0, prefix_len;
>
> static const WCHAR dashW[] = {' ','-',' ',0};
> static const size_t dashW_len = (sizeof(dashW) / sizeof(*dashW)) - 1;
> @@ -583,6 +583,7 @@ HRESULT WINAPI AUDDRV_GetEndpointIDs(EDataFlow flow,
> WCHAR ***ids, GUID **guids,
>
> TRACE("%d %p %p %p %p\n", flow, ids, guids, num, def_index);
>
> +*num = 0;
> *ids = NULL;
> *guids = NULL;
>
> --
> 1.7.3.4
>
>
>
Re: msvcrt: Added more length modifiers in scanf function
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17893 Your paranoid android. === WNT4WSSP6 (32 bit scanf) === scanf.c:144: Test failed: sprintf retuned 10 scanf.c:145: Test failed: got 1942892530, expected 12345678901234 === W2KPROSP4 (32 bit scanf) === scanf.c:144: Test failed: sprintf retuned 10 scanf.c:145: Test failed: got 1942892530, expected 12345678901234 === WXPPROSP3 (32 bit scanf) === scanf.c:144: Test failed: sprintf retuned 10 scanf.c:145: Test failed: got 1942892530, expected 12345678901234 === W2K3R2SESP2 (32 bit scanf) === scanf.c:144: Test failed: sprintf retuned 10 scanf.c:145: Test failed: got 1942892530, expected 12345678901234
Re: ws2_32: Fix hostent memory allocation
On Mon, Apr 16, 2012 at 10:17, Alexandre Julliard wrote: > ... > That's not a good helper function, with all the optional parameters and > various behaviors. Also if you need a big documentation block like this > for a 5-line function it's a sign that something is wrong. Sorry, I didn't know it was bad to document small functions. So should I duplicate list_size creating list_count to get the number of items or should I simply loop and count the size and item count without using list_size in WS_dup_he? > -- > Alexandre Julliard > julli...@winehq.org Best wishes, Bruno
Re: WASAPI ISimpleAudioVolume::SetMasterVolume appears to not work
Hi Adam, On Sun, Apr 15, 2012 at 12:06:14AM +0100, adam smith wrote: > I've been trying to get WASAPI audio output working for our app as > Directsound output was very glitchy post the new audio stack. > Sorry to hear that. We do have a large sequence of patches just about ready to go into Wine which will improve directsound greatly, but they're not in quite yet. > All seems to work great with WASAPI however I need to able to set the > volume level independently for individual audio sessions / streams for > crossfading however I'm having problems controlling the volume levels of a > shared mode audio session / stream. specifically, > > ISimpleAudioVolume::SetMasterVolume ... returns success but does not > change the volume level though interestingly > Yes, this is a limitation of the ALSA and OSS drivers. You can see that actually doesn't do anything. This is because ALSA and OSS don't support per-stream volume control. For example, if we set the volume on an ALSA device, it will actually affect the volume of _every_ stream that uses that ALSA device, which isn't what we want. > HRESULT hr; > hr=audioClient_->GetService(IID_ISimpleAudioVolume,(void**)&simpleAudioVolume_); > if (SUCCESS(hr)) > hr=simpleAudioVolume_->SetMute(TRUE,NULL); > > does work and mute the volume. > Yes, we have some logic to allow muting to work, by just setting the samples sent to ALSA to silence. Again, this is because muting the ALSA device would result in muting _every_ stream using that device. > Does anyone have any experience of these interfaces or know equivalent > interfaces to use instead > Sorry, Linux's audio systems just don't have the capabilities to let Wine do this. We would need to build a software mixer into Wine to do volume control, and we don't have that (yet). Andrew
Re: ws2_32: Fix hostent memory allocation
Bruno Jesus <00cp...@gmail.com> writes:
> @@ -5546,24 +5546,70 @@ INT WINAPI WSAUnhookBlockingHook(void)
> * pointers (via a template of some kind).
> */
>
> -static int list_size(char** l, int item_size)
> +/***
> + * list_size (INTERNAL)
> + *
> + * Calculate the size of data and number of items from a list based on
> + * a fixed item size or strings by using strlen. The source list must be
> + * NULL terminated.
> + *
> + * PARAMS
> + * l [I] Pointer to array of source items.
> + * item_size [I] Fixed item size or zero if it's a string list.
> + * size_sum [O] Pointer to where the sum of item bytes will be
> + * stored. May be NULL if not required by the caller.
> + * item_count [O] Pointer to where the number of items bytes will be
> + * stored. May be NULL if not required by the caller.
> + *
> + * NOTES
> + * When item_size is zero the byte sum will also count the NULL
> + * terminator for each string.
> + */
> +static void list_size(char** l, int item_size, int *size_sum, int
> *item_count)
> {
> - int i,j = 0;
> - if(l)
> - { for(i=0;l[i];i++)
> - j += (item_size) ? item_size : strlen(l[i]) + 1;
> -j += (i + 1) * sizeof(char*); }
> - return j;
> +int s, c, *sum = (size_sum ? size_sum : &s), *count = (item_count ?
> item_count : &c);
> +*sum = *count = 0;
> +if(l)
> +{
> +for(;l[*count];(*count)++)
> + *sum += (item_size) ? item_size : strlen(l[*count]) + 1;
> +}
That's not a good helper function, with all the optional parameters and
various behaviors. Also if you need a big documentation block like this
for a 5-line function it's a sign that something is wrong.
--
Alexandre Julliard
julli...@winehq.org
Re: jscript: Make sure to jump out of switch before entering implicit default clausule
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17883 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found
Re: Testbot certificate has expired
Hi Morten, On 04/15/12 14:59, Morten Rønne wrote: > Hi > > testbot.winehq.com certificate expired on 13-04-2012. So now the > wininet tests in dlls/wininet/tests/http.c are failing with an error > for me. > I can't determine if the fault are in the test or the function called > should handle the error case. > > The error message is: > err:wininet:NETCON_secure_connect SSL_connect failed: 12037 > http.c:2873: Test failed: HttpSendRequest failed: 12037 > wine: Unhandled page fault on read access to 0x0008 at address > 0x68a876c5 (thread 0009), starting debugger... > Unhandled exception: page fault on read access to 0x0008 in 32-bit > code (0x68a876c5). Ideally we should use https://test.winehq.org/ instead (and generally test.winehq.org for all tests) so that we'd have better control over test infrastructure. I've started moving things in this direction last year, but never had enough time to finish it. Cheers, Jacek
Re: gdi32: Add support for emulating bold faces of bitmap fonts.
Huw Davies wrote: > > > Don't we need to add some bytes if glyph_width % 32 == 0 ? > > > > Well, I didn't see in my tests a need for that. > > That may be because your tests are just looking at the font metrics > and not at the glyphs themselves... I have an application that actually needs that, so I'm "testing" the resulting glyphs by eyes, while font metrics get tested by the tests. -- Dmitry.
Re: msvcp90: Add codecvt ctors and dtors
Hi,
On 04/16/12 02:50, William Panlener wrote:
typedef struct {
+ locale_facet facet;
+ /* FIXME: type definition in standard but var here */
+ enum { ok, partial, error, noconv } result;
+} codecvt_base;
This structure has incorrect size. It should not contain result variable.
+typedef struct {
+ codecvt_base base;
+ /* FIXME: incomplete struct definition */
+} codecvt_char_char_mbstate;
It's better to define whole structure. Also other structures are named
differently, it would be probably better to name it codecvt_char.
+typedef struct {
+ codecvt_base base;
+ /* FIXME: incomplete struct definition */
+} codecvt_short_char_mbstate;
+
+typedef struct {
+ codecvt_base base;
+ /* FIXME: incomplete struct definition */
+} codecvt_wchar_char_mbstate;
There's no reason to define separate structures for unsigned short and
wchar_t variants of the class. Probably the only difference between this
classes is typeinfo structure.
+/* FIXME: Potentially unused */
+/* ?id@?$codecvt@DDH@std@@2V0locale@2@A */
+locale_id codecvt_char_char_mbstate_id = {0};
I don't understand this comment. The id fields will be used by locale class.
+/* ??1codecvt_base@std@@UAE@XZ */
+/* ??1codecvt_base@std@@UEAA@XZ */
+DEFINE_THISCALL_WRAPPER(codecvt_base_dtor, 4)
+void __thiscall codecvt_base_dtor(codecvt_base *this)
+{
+FIXME("(%p)\n stub!", this);
+TRACE("(%p)\n", this);
+}
There's no need to use both FIXME and TRACE.
+/* ??1?$codecvt@DDH@std@@MAE@XZ */
+/* ??1?$codecvt@DDH@std@@MEAA@XZ */
+DEFINE_THISCALL_WRAPPER(codecvt_char_char_mbstate_dtor, 4)
+void __thiscall codecvt_char_char_mbstate_dtor(codecvt_char_char_mbstate *this)
+{
+/*FIXME stub*/
+codecvt_base_dtor(&this->base);
+TRACE("(%p)\n", this);
+}
It's better to print a fixme message here.
+DEFINE_RTTI_DATA(codecvt_char_char_mbstate, 0, 1,&locale_facet_rtti_base_descriptor,
NULL, NULL, " ?AV?$codecvt@DDH@std@@");
+DEFINE_RTTI_DATA(codecvt_short_char_mbstate, 0, 1,&locale_facet_rtti_base_descriptor,
NULL, NULL, " ?AV?$codecvt@GDH@std@@");
+DEFINE_RTTI_DATA(codecvt_wchar_char_mbstate, 0, 1,&locale_facet_rtti_base_descriptor,
NULL, NULL, ".?AV?$codecvt@_WDH@std@@");
The RTTI data for these structures is incorrect.
+__ASM_VTABLE(codecvt_base, ""/*FIXME*/);
+__ASM_VTABLE(codecvt_char_char_mbstate, ""/*FIXME*/);
+__ASM_VTABLE(codecvt_short_char_mbstate, ""/*FIXME*/);
+__ASM_VTABLE(codecvt_wchar_char_mbstate, ""/*FIXME*/);
It's better to create correct virtual functions table. This may lead to
some strange crashes.
Re: Request for help/advice in investigation of one interesting "huge FPS regression" bug
On 4/16/12, Alexey Loukianov wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > 16.04.2012 04:28, Vitaliy Margolen wrote: >> Of course it won't - they are binary blobs from Nvidia. Not much to see >> there. All you really looking for are time spent in that library. >> > > Vitaliy, I don't expect oprofile to find hidden COFF or DWARF 2 debug infos > inside nVIDIA binary blob, it's obvious that there are nothing like that > there > :-). > > What I was expecting to find in oprofile output is a libGL.so subdivision > like > may be seen in "objdump -T /usr/lib/libGL.so.295.40" output. Thinking a bit > more about it makes it clear that my expectations were wrong as the export > table doesn't have all the required info for oprofile to act as a poors man > substitute for real symbols map file (for example, it can't be determined > for > sure from exports table what are the actual proc boundaries for any given > exported symbol). > > What might be useful for profiling in this case is a "proxy" wrapper for > libGL > that sits between Wine and real libGL and collects call timing stats. A > wrapper of such kind wouldn't be as devastating to FPS as apitrace, and it > would provide a fine-grained picture on per-proc timing stats which are > extremely helpful when one is trying to catch a GPU driver bug. I have no > idea > if there's such a wrapper already implemented out in a wild. Something equivalent exists and is in Wine. When compiling wined3d compile it with -DUSE_WIN32_OPENGL to route all GL calls through wine's opengl32.dll. It may give some more clues. About all Nvidia driver calls end up in libGLcore.so where libGL.so is a thin wrapper. You likely won't see that much more, but it is easy to try. Roderick > > - -- > Best regards, > Alexey Loukianov mailto:mooro...@mail.ru > System Engineer,Mob.:+7(926)218-1320 > *nix Specialist > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.16 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJPi20tAAoJEPB9BOdTkBULPo4IAKFYIbPvg0Znv6AOiZt+C2yV > +uiq1+FZcdeMedfGZrA8lelOvUEp9h8/wuDEmZ2YEW28+S/qkMA0EL0MaJY7hqZz > ac3vdt/wVxxDpwAm1Jjl0YjmzhZP4dE8fyB42Clh5+McIG7MvsO7sHfGmQk9Jbye > d+KvoOWbOFaB5fNrXr+lQMGqkNTSMas3TQS3KIVeiCFitDzXwDHoK7dGykeiJ340 > q0MxqRRa7XvGSZNtw9Q043ZeywaNMFD/k6tSUkIXwP/FlZsTBPHhr7M37h+gjt84 > 2w26KE7cncoUKl1l3w7WfUMN9/MgEKmtX5O0nsP0S8EBCdehfVhOlUcUI48Kkgk= > =Kkgh > -END PGP SIGNATURE- > > >
Re: gdi32: Add support for emulating bold faces of bitmap fonts.
On Mon, Apr 16, 2012 at 05:51:20PM +0900, Dmitry Timoshkov wrote: > Huw Davies wrote: > > > Don't we need to add some bytes if glyph_width % 32 == 0 ? > > Well, I didn't see in my tests a need for that. That may be because your tests are just looking at the font metrics and not at the glyphs themselves...
Re: gdi32: Add support for emulating bold faces of bitmap fonts.
Huw Davies wrote: > Don't we need to add some bytes if glyph_width % 32 == 0 ? Well, I didn't see in my tests a need for that. -- Dmitry.
Re: gdi32: Add support for emulating bold faces of bitmap fonts.
On Mon, Apr 16, 2012 at 04:37:39PM +0900, Dmitry Timoshkov wrote:
> diff --git a/dlls/gdi32/freetype.c b/dlls/gdi32/freetype.c
> index 0a5d3c3..eb3f9b5 100644
> --- a/dlls/gdi32/freetype.c
> +++ b/dlls/gdi32/freetype.c
> @@ -5669,12 +5669,27 @@ static inline BYTE get_max_level( UINT format )
> return 255;
> }
>
> -static const BYTE masks[8] = {0x80, 0x40, 0x20, 0x10, 0x08, 0x04, 0x02,
> 0x01};
> +static void emulate_bold_glyph(BYTE *buf, int pitch, int height)
> +{
> +int x, y;
> +BYTE *p = buf;
> +
> +for (y = 0; y < height; y++)
> +{
> +for (x = pitch - 1; x >= 0; x--)
> +{
> +p[x] |= p[x] >> 1;
> +if (x > 0) p[x] |= p[x - 1] << 7;
> +}
> +p += pitch;
> +}
> +}
>
Don't we need to add some bytes if glyph_width % 32 == 0 ?
Huw.
