So, the original question was "How to test OpenFile16"?
Here's a more complete answer. First, install OpenWatcom as
previously described. Then create a text file blah.c containing something like
#include
int PASCAL WinMain( HINSTANCE this_inst, HINSTANCE prev_inst, LPSTR cmdline,
On 6/19/07, Dan Kegel <[EMAIL PROTECTED]> wrote:
Unfortuately, Wine doesn't currently run these win16 apps
properly; they hang with
err:ntdll:RtlpWaitForCriticalSection section 0x7b91f300 "syslevel.c:
Win16Mutex" wait timed out in thread 000b, blocked by 000c, retrying
(60 sec)
Filed as http:/
"Anatoly Lyutin" <[EMAIL PROTECTED]> wrote:
+ WCHAR PROG_FILES_DIR[MAX_PATH];
Looks like that this variable is not used anywhere.
static DWORD (WINAPI *pGetLongPathNameA)(LPCSTR,LPSTR,DWORD);
static DWORD (WINAPI *pGetLongPathNameW)(LPWSTR,LPWSTR,DWORD);
+static DWORD (WINAPI *pGetShortPat
Anatoly asked:
How can I write a test for this function or build program use it?
I think writing good win16 tests requires a 16 bit linker.
Fortunately, OpenWatcom has one, and works on Wine.
It's amazingly easy to install it and build one of its demo apps:
$ wget http://ftp.openwatcom.org/ftp/
On 6/19/07, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
No, it should lock the virtual desktop (with a fancy screensaver and
all ;-). That stuff really belongs in explorer though, not in
wineboot.
Don't tempt me =) If I recall Scr's are just exe's anyway so we could
create our own dummy one
"Steven Edwards" <[EMAIL PROTECTED]> writes:
> I'll check this as well. I did not even think about the virtual
> desktop window case. I'll look in to this a bit. Perhaps we should pop
> up a message box or something for that case to warn the user.
No, it should lock the virtual desktop (with a fa
On 6/19/07, Hans Leidekker <[EMAIL PROTECTED]> wrote:
It's your idea so you should get the credit. I was just helping out
with the implementation.
Your code, your copyright =)
There will allways be Linux distributions that don't install the xdg
tools by default, and it's not inconceivable tha
On Tuesday 19 June 2007 20:08:50 Steven Edwards wrote:
> Patch by Hans Leidekker
It's your idea so you should get the credit. I was just helping out
with the implementation.
> This could be expanded for other platforms that use xdg stuff by
> changing the #ifdef. I added the #ifdef to also deal
Hi all!
How can I write a test for this function or build program use it?
I do not understand how I can do this uses Wine?
Thank you for attention!
=)
--
Best regards
Anatoly Lyutin.
Stefan Dösinger <[EMAIL PROTECTED]> writes:
> Obviously there is a little memory requirement for the heap management
> structures that belong to a 0 byte allocation. But extra code to check if
> This->decls is NULL + a HeapAlloc call need a few bytes too...
>
> I can change that to allocate one
Huw Davies wrote:
On Tue, Jun 19, 2007 at 06:06:45PM +0200, Paul Vriens wrote:
Hi,
I'm a total newbie to the 64-bit world (just built a system this weekend)
and now I'm trying to get Wine compiled.
It fails with (the first failure that is):
LD_LIBRARY_PATH="../../libs/wine:$LD_LIBRARY_PATH"
Am Dienstag, 19. Juni 2007 18:46 schrieb H. Verbeet:
> On 19/06/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> > Am Dienstag, 19. Juni 2007 15:44 schrieb H. Verbeet:
> > > Not specific to this patch, but will you remove the fvf field from the
> > > stateblock as well?
> >
> > I am thinking about
Alexandre Julliard escribió:
[EMAIL PROTECTED] writes:
+case WM_SIZE:
+TRACE("WM_SIZE %d %d\n", LOWORD(lParam), HIWORD(lParam));
+SetWindowPos(hwnd, NULL, pVideoRenderer->WindowPos.left,
pVideoRenderer->WindowPos.top, LOWORD(lParam), HIWORD(lParam), SWP_NOZOR
On 19/06/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
Am Dienstag, 19. Juni 2007 15:44 schrieb H. Verbeet:
> Not specific to this patch, but will you remove the fvf field from the
> stateblock as well?
I am thinking about that, but currently it has to be known to wined3d for
reporting the prope
Am Dienstag, 19. Juni 2007 14:05 schrieb H. Verbeet:
> On 19/06/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> > Yeah, HeapReAlloc works on object->decls with 0 bytes allocated, but not
> > on a NULL pointer. It keeps the array growing simpler. I can just use
> > HeapReAlloc unconditionally inste
Am Dienstag, 19. Juni 2007 15:44 schrieb H. Verbeet:
> Not specific to this patch, but will you remove the fvf field from the
> stateblock as well?
I am thinking about that, but currently it has to be known to wined3d for
reporting the proper fvf on GetFVF with state recording. A future patch coul
On Tue, Jun 19, 2007 at 06:06:45PM +0200, Paul Vriens wrote:
> Hi,
>
> I'm a total newbie to the 64-bit world (just built a system this weekend)
> and now I'm trying to get Wine compiled.
>
> It fails with (the first failure that is):
>
> LD_LIBRARY_PATH="../../libs/wine:$LD_LIBRARY_PATH" ../..
On 19.06.2007 18:06, Paul Vriens wrote:
> Hi,
>
> I'm a total newbie to the 64-bit world (just built a system this
> weekend) and now I'm trying to get Wine compiled.
>
> It fails with (the first failure that is):
>
> LD_LIBRARY_PATH="../../libs/wine:$LD_LIBRARY_PATH" ../../tools/wrc/wrc
> --nos
Hi,
I'm a total newbie to the 64-bit world (just built a system this weekend) and
now I'm trying to get Wine compiled.
It fails with (the first failure that is):
LD_LIBRARY_PATH="../../libs/wine:$LD_LIBRARY_PATH" ../../tools/wrc/wrc
--nostdinc -I. -I. -I../../include -I../../include -D__WIN
On 6/18/07, Alex Waite <[EMAIL PROTECTED]> wrote:
Alexander Nicolaysen Sørnes wrote:
> This should make it easier for people to notice the menu options. From 10px
> to 11px.
>
>
> Regards,
>
> Alexander N. Sørnes
>
>
>
>
>
Alexander Nicolaysen Sørnes wrote:
> This should make it easier for people to notice the menu options. From 10px
> to 11px.
>
>
> Regards,
>
> Alexander N. Sørnes
>
>
>
>
>
I agree with increasing text size here, bu
Not specific to this patch, but will you remove the fvf field from the
stateblock as well?
On 19/06/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
+if(!This->stateBlock->vertexShader) {
Testing for a vertex shader like that doesn't take into account the
selected vs mode (ie, could be disabled) or transformed vertices. You
should probably be using use_vs() instead.
I remember discussing this patch, but in retrospect I'm not sure this
fix is completely correct. When a pixel shader is used with fixed
function vertex processing, more than GL_LIMITS(textures) texture
coordinates can be used.
On 19/06/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
Yeah, HeapReAlloc works on object->decls with 0 bytes allocated, but not on a
NULL pointer. It keeps the array growing simpler. I can just use HeapReAlloc
unconditionally instead of something like this
Well yes, but why not simply start wi
Am Dienstag, 19. Juni 2007 12:18 schrieb H. Verbeet:
> On 19/06/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> > +if (hr != S_OK) return NULL;
>
> Any reason for not simply using FAILED(hr) there?
Actually no, except that it was copypasted from existing code. I'll fix that
and resend.
> > +
[EMAIL PROTECTED] writes:
> +case WM_SIZE:
> +TRACE("WM_SIZE %d %d\n", LOWORD(lParam), HIWORD(lParam));
> +SetWindowPos(hwnd, NULL, pVideoRenderer->WindowPos.left,
> pVideoRenderer->WindowPos.top, LOWORD(lParam), HIWORD(lParam), SWP_NOZORDER);
Why do you want to r
Peter Dons Tychsen <[EMAIL PROTECTED]> writes:
> #ifdef HAVE_LIBXXSHM
> -if (descr->image && descr->useShm)
> +
> +if(descr->image && descr->useShm)
> +{
> + XGetGeometry(gdi_display, descr->drawable, &root, &x, &y, &width,
> &height, &border_width, &depth);
> +TRACE("XGet
On 19/06/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
+if (hr != S_OK) return NULL;
Any reason for not simply using FAILED(hr) there?
+object->decls = HeapAlloc(GetProcessHeap(), 0, 0);
Is that useful?
Hi, Tim.
Please, proceed bug #8554.
Thanks,
--
Kirill
"Lei Zhang" <[EMAIL PROTECTED]> wrote:
Just curious, what popular WMs do active a window when users click the
window caption buttons?
I have no idea.
In the case where the WM does the right thing and activates the
window. (It looks like fvwm95 is one such WM.)
That's a WM specific behaviou
On 6/18/07, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote:
"Lei Zhang" <[EMAIL PROTECTED]> wrote:
>> We already send WM_MOUSEACTIVATE message on a take focus X11 event, so
>> I don't see a point in duplicating it. On the other hand if a WM doesn't
>> activate a window when a user clicks on window's
32 matches
Mail list logo
