Multimedia Control Panel question
The proper way to set the default sound card is to use the same registry keys as Windows and either use a native mmsys.cpl or devise a wine specific way of doing the same thing. Creating a builtin mmsys.cpl is one way of accomplishing this and another way is to add this capability to winecfg. You could also have winecfg launch mmsys.cfg (native or builtin). Any ideas on what would be the best way for wine? Here are some of the registry keys and a link to some documentation: http://www.cs.vu.nl/~pboon/md/indexold.htm Index: tools/wine.inf === RCS file: /home/wine/wine/tools/wine.inf,v retrieving revision 1.31 diff -u -p -r1.31 wine.inf --- tools/wine.inf 11 Apr 2005 18:49:28 - 1.31 +++ tools/wine.inf 12 Apr 2005 04:59:23 - @@ -40,6 +40,7 @@ AddReg=\ Fonts,\ MCI,\ Misc,\ +Multimedia,\ Nls,\ OLE,\ Tapi @@ -558,6 +559,11 @@ HKLM,System\CurrentControlSet\Control\Nl [OLE] HKLM,"Software\Microsoft\OLE","EnableDCOM",,"Y" HKLM,"Software\Microsoft\OLE","EnableRemoteConnect",,"N" + +[Multimedia] +HKCU,Software\Microsoft\Multimedia\Sound Mapper,"PreferredOnly",0x10001, +HKCU,Software\Microsoft\Multimedia\Sound Mapper,"Playback",,"" +HKCU,Software\Microsoft\Multimedia\Sound Mapper,"Record",,"" [Tapi] HKLM,%CurrentVersion%\Telephony,"Perf1",0x10001,5045524a
Re: lostwages/templates/en status_ui.template
On Sun, Apr 10, 2005 at 08:43:44PM +0200, Jacek Caban wrote: > I completely disagree. We can do much more than there is done right now. > shdocvw > is more than WebBrowser control and we can inplement those areas, but > WebBrowser > needs a lot of work as well. Mozilla ActiveX Control seems not to be > systematically > developed and the compability we need is not their aim. We need an > implementation > of WebBrowser based on MSHTML, which will be possible when I finish my work > on it. > This way we'll be able to implement shdocvw correctly (eg. it'll be possible > to > implement Internet Explorer OLE Automation), but now it's far, far away from > it > and really far from 100% complete. This is a good discussion for WineConf. But sure, in the meantime feel free to submit a patch for this entry that better reflect your plans. In any event, I think such a significant effort probably deserves a bit bigger space somewhere else, but it will have to wait a bit until we can figure out where exactly. -- Dimi.
Rough Draft
Rough Draft is a useful Windows word processor that natively saves files in .RTF format. Unfortunately, when installing it I got the following errors: fixme:richedit:RichEditANSIWndProc EM_AUTOURLDETECT: stub fixme:richedit:RichEditANSIWndProc WM_SETFONT: stub fixme:richedit:RichEditANSIWndProc EM_LIMITTEXT: stub fixme:richedit:RichEditANSIWndProc EM_EXLIMITTEXT: stub fixme:richedit:ME_ReleaseStyle all style references freed (good!) err:menubuilder:InvokeShellLinker failed to fork and exec wineshelllink err:menubuilder:InvokeShellLinker failed to fork and exec wineshelllink fixme:msvcrt:_setmbcp Unreal codepages (e.g. -3) not implemented fixme:msvcrt:_setmbcp Unreal codepages (e.g. -3) not implemented fixme:ole:SLTG_ProcessDispatch memh.cbExtra is 4320 fixme:ole:SLTG_ProcessDispatch offset 0 0x4a fixme:ole:SLTG_ProcessDispatch memh.cbExtra is 376 fixme:ole:SLTG_ProcessDispatch offset 0 0x4a fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects Anyone know why I get all the fixme's ? -- Andrew Beneath the noble bird Between the proudest words Behind the beauty, cracks appear Once with heads held high They sang out to the sky Why do their shadows bow in fear? Beneath, Between and Behind by Rush (Fly By Night, 1975) ---
Re: shell32, ntdll tests
On Apr 11, 2005 4:34 PM, Aaron Arvey <[EMAIL PROTECTED]> wrote: > More specifically, is it worth the time to write tests for ntdll/loader.c > and ntdll/virtual.c? It seems that these files would be used to load any > program, so if there were any bugs, I'm guessing they would become > apparent immediately and thus having formal tests would be somewhat > pointless. Please correct (or reaffirm) me as I am going to write some > tests in my spare time and I want to make sure that they'd be useful to > the wine project. Regression/conformance tests are almost never pointless even if they just reaffirm what is already obvious. They serve two purposes: to conform to windows behaviour, and to make sure later code changes don't create regressions. It would be well worth all of our time for anyone to write more tests, so please send them in. -- James Hawkins
shell32, ntdll tests
Is anyone currently working (or have feedback) on tests for ntdll/loader.c, ntdll/virtual.c, shell32/folder.c, shell32/shlexec.c, or shell32/shell_main.c? More specifically, is it worth the time to write tests for ntdll/loader.c and ntdll/virtual.c? It seems that these files would be used to load any program, so if there were any bugs, I'm guessing they would become apparent immediately and thus having formal tests would be somewhat pointless. Please correct (or reaffirm) me as I am going to write some tests in my spare time and I want to make sure that they'd be useful to the wine project. I'm looking at these specific files because they have code which is run by google's picasa 2, but not by the wine test suite. Thanks! Aaron
Re: OLEAUT32: Don't crash on divide by zero
IEEE floating point has a special zero value. See http://stevehollasch.com/cgindex/coding/ieeefloat.html in the "Special Values" section. You can compare against this value, and (a - a) = 0.0f. You do lose that precision when you introduce multiplication and division...so you might end up with ((b * a) / b - a) != 0...which is why everyone warns against comparing with zero. Nevertheless, 5.0f / 0.0f will still trigger a divide by zero error, and that can be avoided by checking the denominator against 0 (which is what this patch does). On Apr 11, 2005 1:06 PM, Marcus Meissner <[EMAIL PROTECTED]> wrote: > On Mon, Apr 11, 2005 at 12:47:22PM -0700, Daniel Remenak wrote: > > Changelog: > > Return DISP_E_DIVBYZERO instead of crashing when asked to divide a > > variant by zero. > > You cannot really compare floats against 0 I think. > > Ciao, Marcus > >
Re: OLEAUT32: Don't crash on divide by zero
On Mon, Apr 11, 2005 at 12:47:22PM -0700, Daniel Remenak wrote: > Changelog: > Return DISP_E_DIVBYZERO instead of crashing when asked to divide a > variant by zero. You cannot really compare floats against 0 I think. Ciao, Marcus
CVS Checkout: Wineowner's lock???
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 When I try to checkout wine's cvs I get: ... cvs server: [13:54:51] waiting for wineowner's lock in /home/wine/wine/dlls/shell32 I got no idea about his one...??? Greetings, Jan Schiefer! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCWshmzC00UKXFdVcRAqqeAJsGRLvbeb2Y+IA5DLyeFtqwiAdZXgCgl389 XguDPLoWPG0oHjKPldx1PSA= =8bZH -END PGP SIGNATURE-
[NtQuerySystemInformation #1] Fixes + tests
Hi,
this is a first go at some unit tests and related fixes for
NtQuerySystemInformation.
The ultimate goal is to get SysInternal's Process Explorer running.
I welcome suggestions and remarks. If none I will submit this to
wine-patches and start the further works.
Cheers,
Paul Vriens.
Changelog
Start of unit tests for NtQuerySystemInformation
Return STATUS_INVALID_INFO_CLASS for non-implemented classes
Return len for SystemCpuInformation
Return STATUS_ACCESS_VIOLATION if no buffer given
Index: dlls/ntdll/nt.c
===
RCS file: /home/wine/wine/dlls/ntdll/nt.c,v
retrieving revision 1.75
diff -u -p -r1.75 nt.c
--- dlls/ntdll/nt.c 28 Mar 2005 10:03:57 - 1.75
+++ dlls/ntdll/nt.c 11 Apr 2005 18:54:54 -
@@ -577,6 +577,11 @@ NTSTATUS WINAPI NtQuerySystemInformation
SYSTEM_BASIC_INFORMATION* sbi = (SYSTEM_BASIC_INFORMATION*)SystemInformation;
if (Length >= sizeof(*sbi))
{
+if (!SystemInformation)
+{
+ret = STATUS_ACCESS_VIOLATION;
+break;
+}
sbi->dwUnknown1 = 0;
sbi->uKeMaximumIncrement = 0;
sbi->uPageSize = 1024; /* FIXME */
@@ -605,6 +610,7 @@ NTSTATUS WINAPI NtQuerySystemInformation
sci->Revision = 0;
sci->Reserved = 0;
sci->FeatureSet = 0x1fff;
+len = sizeof(*sci);
}
else ret = STATUS_INFO_LENGTH_MISMATCH;
}
@@ -758,7 +764,6 @@ NTSTATUS WINAPI NtQuerySystemInformation
else ret = STATUS_INFO_LENGTH_MISMATCH;
}
break;
-
case SystemCacheInformation:
{
SYSTEM_CACHE_INFORMATION* sci = (SYSTEM_CACHE_INFORMATION*)SystemInformation;
@@ -790,7 +795,6 @@ NTSTATUS WINAPI NtQuerySystemInformation
else ret = STATUS_INFO_LENGTH_MISMATCH;
}
break;
-
case SystemKernelDebuggerInformation:
{
PSYSTEM_KERNEL_DEBUGGER_INFORMATION pkdi;
@@ -804,11 +808,10 @@ NTSTATUS WINAPI NtQuerySystemInformation
else ret = STATUS_INFO_LENGTH_MISMATCH;
}
break;
-
default:
FIXME("(0x%08x,%p,0x%08lx,%p) stub\n",
SystemInformationClass,SystemInformation,Length,ResultLength);
-ret = STATUS_NOT_IMPLEMENTED;
+ret = STATUS_INVALID_INFO_CLASS;
}
if (ResultLength) *ResultLength = len;
Index: dlls/ntdll/tests/Makefile.in
===
RCS file: /home/wine/wine/dlls/ntdll/tests/Makefile.in,v
retrieving revision 1.12
diff -u -p -r1.12 Makefile.in
--- dlls/ntdll/tests/Makefile.in 14 Feb 2005 21:08:56 - 1.12
+++ dlls/ntdll/tests/Makefile.in 11 Apr 2005 18:55:27 -
@@ -9,6 +9,7 @@ CTESTS = \
env.c \
error.c \
generated.c \
+info.c \
large_int.c \
path.c \
reg.c \
--- /dev/null 2004-02-23 22:02:56.0 +0100
+++ dlls/ntdll/tests/info.c 2005-04-11 20:35:09.0 +0200
@@ -0,0 +1,84 @@
+/* Unit test suite for *Information* Registry API functions
+ *
+ * Copyright 2005 Paul Vriens
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include "ntdll_test.h"
+
+static NTSTATUS (WINAPI * pNtQuerySystemInformation)(SYSTEM_INFORMATION_CLASS, PVOID, ULONG, PULONG);
+
+static HMODULE hntdll = 0;
+
+#define NTDLL_GET_PROC(func) \
+p ## func = (void*)GetProcAddress(hntdll, #func); \
+if(!p ## func) { \
+ trace("GetProcAddress(%s) failed\n", #func); \
+ FreeLibrary(hntdll); \
+ return FALSE; \
+}
+
+static BOOL InitFunctionPtrs(void)
+{
+hntdll = LoadLibraryA("ntdll.dll");
+if(!hntdll) {
+ trace("Could not load ntdll.dll\n");
+ return FALSE;
+}
+if (hntdll)
+{
+ NTDLL_GET_PROC(NtQuerySystemInformation)
+}
+return TRUE;
+}
+
+static void test_params()
+{
+DWORD status;
+SYSTEM_BASIC_INFORMATION* sbi = HeapAlloc(GetProcessHeap(), 0, sizeof(*sbi));
+
+/* Use a non existent info class */
+status = pNtQuerySystemInformation(-1, NULL, 0, NULL);
+ok( status == STATUS_INVALID_INFO_CLASS, "Expected STATUS_INVALID_INFO_CLASS, got %08lx\n", status);
+
+/* Use an existent cl
ntoskrnl and safedisk
I won't have much time to work on this stuff for a while, so I thought I might as well post it here. I've got a ntoskrnl.exe that can load, unload and initialise drivers successfully (Well, I've only tried with a few builds of safedisk but that doesn't matter), it can also dispatch io requests received from DispatchDeviceControl to the driver. However safedisk fails by returning STATUS_UNSUCCESSFUL in the IRP's IoStatus.Status member, I haven't been able to debug this because winedbg refuses to step trough the code properly, however I will try again when I have time to do so. In the mean time you can download and build this stuff yourself, the patch that teaches wine to interact with ntoskrnl is at http://spazioinwind.libero.it/nonsolomicrosoft/public/patch.diff , ntoskrnl itself is here http://spazioinwind.libero.it/nonsolomicrosoft/public/ntoskrnl.tar.bz you'll also need http://spazioinwind.libero.it/nonsolomicrosoft/public/ntoskrnl_protocol.h , put it in include/wine. A full ./configure && make depend && make is needed to build this stuff into wine after patching. Comments/ideas/fixes welcome. Note that ntoskrnl isn't thread safe ATM and probably can't handle more than one driver at any one time. Ivan.
Re: lostwages/templates/en status_ui.template
Mike McCormack wrote: > > Mike Hearn wrote: > >> You're right, but I hope you are not writing a rendering engine from >> scratch! That would be madness. We really need to adapt Gecko to improve >> its MSHTML compatibility here. > I don't touch the engine code! I use Gecko's embedding API. The HTML rendering will never be compatible at all, but that's not important in most cases. What we need is a compatible API, and that can be done using Gecko as HTML engine, everything else we have to implement ourself (eg. my current implementation uses Gecko to download document - that also needs to be changed). > Actually, I'd be interested to see how much of Gecko we'd need to > import/port so that Wine could render HTML. It seems pretty obvious > to me from my experiments with the Mozilla Active X control that > nobody is using it as it is. > > Mike > Soon you'll see - I promise:) If you mean how much of code do we need to port to Wine tree, the answer is that no code excepting creating our headers. Everything else is in a shared library that can be loaded at runtime. My current implementation imports only 6 functions (and 3 of theme are to manipulate strings!). Everything else can be done using interfaces. Jacek
Re: lostwages/templates/en status_ui.template
Mike McCormack wrote: > > Mike Hearn wrote: > >> You're right, but I hope you are not writing a rendering engine from >> scratch! That would be madness. We really need to adapt Gecko to improve >> its MSHTML compatibility here. > I don't touch engine code! I use Gecko's embeding API. The HTML rendering will never be compatibile at all, but that's not important in most cases. What we need is a compatibile API, that can be done using Gecko as HTML engine, everything else we have to implement ourself (eg. my curretnt implementation uses Gecko to download document, what also needs to be changed). > Actually, I'd be interested to see how much of Gecko we'd need to > import/port so that Wine could render HTML. It seems pretty obvious > to me from my experiments with the Mozilla Active X control that > nobody is using it as it is. > > Mike > You'll see this, I promise, but first I need to clean up code, what I do sending patches. If you mean how much of code do we need to port to Wine tree, andswer is that no code excepting creating our headers. Everything else is in shared library that can be loaded in runtime. My current implementation imports only 6 functions (and 3 of theme are to manipulate strings!). Everything else can be done using interfaces. Jacek
Re: lostwages/templates/en status_ui.template
On Mon, 2005-04-11 at 17:37 +0200, Paul van Schayck wrote: > I'm not entirely sure here what kind of compatibility you are talking. > But for actual page rendering gecko will never be mshtml compatible. > MSHTML is an incorrect implantation of the W3 standards and mozilla is > not recreating it. But they already do. For instance, they implement some document.all compatibility. I suspect they'd be willing to accept build-time #ifdef TRIDENT_COMPATIBLE patches. If not, then we'd have to fork it. > This is no problem as long as exact IE replication is not needed (ie. > for simple display inside other applications). But for web designing > where people want to see IE behaviour you will never want a different > engine. Sure, for people doing web pages they'll always want native behaviour. The need to reimplement MSHTML (Trident) is for: - Apps that embed it, like the HTML Help system - Web apps that need IE compatible feature sets thanks -mike
Re: lostwages/templates/en status_ui.template
On Mon, 2005-04-11 at 23:33 +0900, Mike McCormack wrote: > Actually, I'd be interested to see how much of Gecko we'd need to > import/port so that Wine could render HTML. It seems pretty obvious to > me from my experiments with the Mozilla Active X control that nobody is > using it as it is. Yeah. We should probably just fix the mirroring stuff and get it enabled by default in WineHQ. Currently nobody is using it because it doesn't download anything, and then most apps seem to crash ...
Re: Alexandre is back!
Jakob Eriksson wrote: Send in more patches, everybody! :-) lol, poor thing let him get trough his current backlog. Ivan.
Re: dib fixes
Rein Klazes <[EMAIL PROTECTED]> writes: > I tried to do this, you need to clip to the visible region as well. I > could not get it 100% full proof because of races between the clip > calculations and the actual positions on the screen. > > So I get the pixels now from the root window (clipped to the screen) and > everything is rock solid. The code is simpler too. That's ugly, and it will fail miserably if the drawable is a bitmap, you really have to use the specified drawable. Look at how the BitBlt code does it to determine the proper limits. -- Alexandre Julliard [EMAIL PROTECTED]
Alexandre is back!
Send in more patches, everybody! :-)
Re: lostwages/templates/en status_ui.template
On Apr 11, 2005 3:42 PM, Mike Hearn <[EMAIL PROTECTED]> wrote: > On Sun, 10 Apr 2005 20:43:44 +0200, Jacek Caban wrote: > > We need an implementation of WebBrowser based on MSHTML, which will be > > possible when I finish my work on it. This way we'll be able to > > implement shdocvw correctly (eg. it'll be possible to implement Internet > > Explorer OLE Automation), but now it's far, far away from it and really > > far from 100% complete. > > You're right, but I hope you are not writing a rendering engine from > scratch! That would be madness. We really need to adapt Gecko to improve > its MSHTML compatibility here. I'm not entirely sure here what kind of compatibility you are talking. But for actual page rendering gecko will never be mshtml compatible. MSHTML is an incorrect implantation of the W3 standards and mozilla is not recreating it. This is no problem as long as exact IE replication is not needed (ie. for simple display inside other applications). But for web designing where people want to see IE behaviour you will never want a different engine. So we should always allow native shdocvw to keep IE to show the same behaviour. As implanting shdocvw ourselves is not going to work. Paul
Re: lostwages/templates/en status_ui.template
Hi, --- Mike McCormack <[EMAIL PROTECTED]> wrote: > Actually, I'd be interested to see how much of Gecko we'd need to > import/port so that Wine could render HTML. It seems pretty obvious to > me from my experiments with the Mozilla Active X control that nobody is > using it as it is. The ReactOS guys are using the Wine code mostly as is. There is still some issue preventing Mozilla from drawing so Martin Fuchs has made a lightwieght Webbrowser that is a wrapper around the currently implementation that installs the Control. It would be nice to not have to download any additional stuff to have Gecko support but I don't think its worth the massive amount of trouble to import plus I doubt Julliard would ever let it in the Wine tree anyway. Thanks Steven __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/
Re: dib fixes
On Sat, 09 Apr 2005 10:19:36 +0200, you wrote:
> > Are you suggesting more checks then that the pixels are within the
> > dimensions of the drawable?
> you need at least to use the intersection of the bitmap and the drawable (not
> sure both start at (0,0) corner though).
I tried to do this, you need to clip to the visible region as well. I
could not get it 100% full proof because of races between the clip
calculations and the actual positions on the screen.
So I get the pixels now from the root window (clipped to the screen) and
everything is rock solid. The code is simpler too.
> I was also wondering what would happen when stretching is required, but IIRC
> this is done way before (normally)
Funny, in my tests StretchDIBits() with such bitmaps leaves black gaps
(Wine2K and WinME) as long as you do not do a 1:1 stretch. With 1:1
stretches or using SetDIBitsToDevice I see the behavior as you
described.
Changelog:
dlls/x11drv : dib.c
In X11DRV_DIB_SetImageBits avoid BadMatch errors when calling
XGetSubImage.
Rein.
--- wine/dlls/x11drv/dib.c 2005-04-01 13:32:29.0 +0200
+++ mywine/dlls/x11drv/dib.c2005-04-11 15:33:39.0 +0200
@@ -3434,6 +3444,32 @@ static void X11DRV_DIB_GetImageBits_32(
}
/***
+ * X11DRV_DIB_SetImageBits_GetSubImage
+ *
+ * Helper for X11DRV_DIB_SetImageBits
+ */
+static void X11DRV_DIB_SetImageBits_GetSubImage(
+const X11DRV_DIB_IMAGEBITS_DESCR *descr, XImage *bmpImage)
+{
+/* compressed bitmaps may contain gaps in them. So make a copy
+ * of the existing pixels first */
+RECT bmprc = { descr->xDest, descr->yDest,
+descr->xDest + descr->width , descr->yDest + descr->height};
+RECT rc = { 0, 0, screen_width, screen_height};
+
+/* - convert to screen coordinates */
+OffsetRect( &bmprc, descr->physDev->drawable_org.x,
+ descr->physDev->drawable_org.y);
+/* clip to screen rectangle */
+if( IntersectRect( &rc, &rc, &bmprc))
+XGetSubImage( gdi_display, root_window, rc.left, rc.top,
+rc.right - rc.left, rc.bottom - rc.top, AllPlanes,
+ZPixmap, bmpImage,
+descr->xSrc + rc.left - bmprc.left,
+descr->ySrc + rc.top - bmprc.top);
+}
+
+/***
* X11DRV_DIB_SetImageBits
*
* Transfer the bits to an X image.
@@ -3475,10 +3511,7 @@ static int X11DRV_DIB_SetImageBits( cons
break;
case 4:
if (descr->compression) {
- XGetSubImage( gdi_display, descr->drawable, descr->xDest,
descr->yDest,
- descr->width, descr->height, AllPlanes, ZPixmap,
- bmpImage, descr->xSrc, descr->ySrc );
-
+X11DRV_DIB_SetImageBits_GetSubImage( descr, bmpImage);
X11DRV_DIB_SetImageBits_RLE4( descr->lines, descr->bits,
descr->infoWidth, descr->width,
descr->xSrc, (int *)(descr->colorMap),
@@ -3491,9 +3524,7 @@ static int X11DRV_DIB_SetImageBits( cons
break;
case 8:
if (descr->compression) {
- XGetSubImage( gdi_display, descr->drawable, descr->xDest,
descr->yDest,
- descr->width, descr->height, AllPlanes, ZPixmap,
- bmpImage, descr->xSrc, descr->ySrc );
+X11DRV_DIB_SetImageBits_GetSubImage( descr, bmpImage);
X11DRV_DIB_SetImageBits_RLE8( descr->lines, descr->bits,
descr->infoWidth, descr->width,
descr->xSrc, (int *)(descr->colorMap),
Re: Re2: Pushing up data through the stream in quartz
Robert Shearman wrote:
Maarten Lankhorst wrote:
HRESULT Capture_Run(CaptureBox * capBox, FILTER_STATE *state)
{
HRESULT hr;
IMediaSample *pSample = NULL;
LPBYTE pointer;
hr = OutputPin_GetDeliveryBuffer((OutputPin *)capBox->pOut,
&pSample, NULL, NULL, 0);
TRACE("Meat 1: %lx - %p\n", hr, pSample);
hr = IMediaSample_GetPointer(pSample, &pointer);
TRACE("Meat 2\n");
IMediaSample_SetActualDataLength(pSample, 320*240*3);
TRACE("Meat 3\n");
ZeroMemory(pointer, 320*240*3);
TRACE("Meat 4\n");
OutputPin_SendSample((OutputPin *)capBox->pOut, pSample);
FIXME("%p -> (%p) stub\n", capBox, state);
return S_OK;
}
I get E_VFW_NOT_COMMITTED after trying GetDeliveryBuffer, what's the
cause?
This error is due to a memory allocator needing to be committed before
it can be used (see dlls/quartz/memallocator.c). You should call
IMemAllocator_Commit in the Run implementation of your filter and then
push one sample downstream. IIRC, you should also call
IMemAllocator_Decommit in the Stop implementation of your filter, but
this isn't done for the implementation I referred to
(dlls/quartz/transform.c).
Rob
I added this line:
hr = OutputPin_CommitAllocator((OutputPin *)capBox->pOut);
I get this error:
=>1 0x7b50326f StdMemAllocator_Alloc(iface=0x7d29bc80)
[/usr/src/bld/wine-cur/dlls/quartz/memallocator.c:792] in quartz
(0x77a9dee8)
2 0x7b501e56 BaseMemAllocator_Commit+0x186(iface=0x7d29bc80)
[/usr/src/bld/wine-cur/dlls/quartz/memallocator.c:258] in quartz
(0x77a9df18)
3 0x7b5073ca OutputPin_CommitAllocator+0xca(This=0x7d29b928)
[/usr/src/bld/wine-cur/dlls/quartz/pin.c:937] in quartz (0x77a9df44)
...
Unhandled exception: divide by zero in 32-bit code (0x7b50326f).
trace:quartz:BaseMemAllocator_Commit using alloc at 0x7b503230
The offending line:
if ((si.dwPageSize % This->base.pProps->cbAlign) != 0)
Re: lostwages/templates/en status_ui.template
Mike Hearn wrote: You're right, but I hope you are not writing a rendering engine from scratch! That would be madness. We really need to adapt Gecko to improve its MSHTML compatibility here. Actually, I'd be interested to see how much of Gecko we'd need to import/port so that Wine could render HTML. It seems pretty obvious to me from my experiments with the Mozilla Active X control that nobody is using it as it is. Mike
Re: Re2: Pushing up data through the stream in quartz
Maarten Lankhorst wrote:
HRESULT Capture_Run(CaptureBox * capBox, FILTER_STATE *state)
{
HRESULT hr;
IMediaSample *pSample = NULL;
LPBYTE pointer;
hr = OutputPin_GetDeliveryBuffer((OutputPin *)capBox->pOut,
&pSample, NULL, NULL, 0);
TRACE("Meat 1: %lx - %p\n", hr, pSample);
hr = IMediaSample_GetPointer(pSample, &pointer);
TRACE("Meat 2\n");
IMediaSample_SetActualDataLength(pSample, 320*240*3);
TRACE("Meat 3\n");
ZeroMemory(pointer, 320*240*3);
TRACE("Meat 4\n");
OutputPin_SendSample((OutputPin *)capBox->pOut, pSample);
FIXME("%p -> (%p) stub\n", capBox, state);
return S_OK;
}
I get E_VFW_NOT_COMMITTED after trying GetDeliveryBuffer, what's the
cause?
This error is due to a memory allocator needing to be committed before
it can be used (see dlls/quartz/memallocator.c). You should call
IMemAllocator_Commit in the Run implementation of your filter and then
push one sample downstream. IIRC, you should also call
IMemAllocator_Decommit in the Stop implementation of your filter, but
this isn't done for the implementation I referred to
(dlls/quartz/transform.c).
Rob
Re: lostwages/templates/en status_ui.template
On Sun, 10 Apr 2005 20:43:44 +0200, Jacek Caban wrote: > We need an implementation of WebBrowser based on MSHTML, which will be > possible when I finish my work on it. This way we'll be able to > implement shdocvw correctly (eg. it'll be possible to implement Internet > Explorer OLE Automation), but now it's far, far away from it and really > far from 100% complete. You're right, but I hope you are not writing a rendering engine from scratch! That would be madness. We really need to adapt Gecko to improve its MSHTML compatibility here. thanks -mike
Re: real SetProcessClass and SetThreadPriority support
Hi, On Mon, Apr 11, 2005 at 02:07:47PM +0100, Mike Hearn wrote: > On Sun, 2005-04-10 at 19:42 -0500, Robert Shearman wrote: > > You're forgetting the reason why we need the suid root binary - > > because allowing processes to set their priority as realtime (or > > otherwise very high) leaves the system open to a trvial DoS attack. > > Not only do the startup code paths need to be audited, but also the > > priority setting logic too. > > Good point. But I don't think there's any way to avoid this: > fundamentally anyone can write a Win32 app that requests realtime > priority and then goes into an infinite loop. In order to emulate that > faithfully Linux just has to budge. Nope, that's just the main issue of what the CK kernel discussed: how to implement some sort of "realtime" priority *without* DoS capabilities. And the result was SCHED_ISO. See http://bhhdoa.org.au/pipermail/ck/2004-October/001169.html for an overview. But OTOH your point is still valid: even a SCHED_ISO wouldn't emulate this kind of realtime priority correctly, since it *can* be preempted, which would probably violate Win32 realtime prio properties. Still, it's a very acceptable compromise, I'd say. > It's not like it's hard to DoS a desktop Linux box anyway. Just compile > winetest on it ;) Now that's true ;) Andreas
Re: Reduce __attribute__(x) to nothing if __GNUC__ is unset
Vincent Béron <[EMAIL PROTECTED]> writes: > This lets us get rid of various #ifdef __GNUC__, as well as use > DECLSPEC_NORETURN at least everywhere winnt.h is included, without fear > of conflicts. This doesn't really help, because we want the code to build with the Microsoft headers too, so you still can't use __attribute__ without ifdefs. And really the use of __attribute__ should be kept to a minimum, your other patches are adding it in a lot of places where it's not necessary. -- Alexandre Julliard [EMAIL PROTECTED]
Re: real SetProcessClass and SetThreadPriority support
On Sun, 2005-04-10 at 19:42 -0500, Robert Shearman wrote: > You're forgetting the reason why we need the suid root binary - > because allowing processes to set their priority as realtime (or > otherwise very high) leaves the system open to a trvial DoS attack. > Not only do the startup code paths need to be audited, but also the > priority setting logic too. Good point. But I don't think there's any way to avoid this: fundamentally anyone can write a Win32 app that requests realtime priority and then goes into an infinite loop. In order to emulate that faithfully Linux just has to budge. It's not like it's hard to DoS a desktop Linux box anyway. Just compile winetest on it ;)
Re: stubbed powrprof.dll
On Sat, 9 Apr 2005, Benjamin Cutler wrote: [...] Don't include other headers in your header unless the Windows Platform SDK does it (it doesn't in this case). We would like the header dependencies to be the same as the Platform SDK, so programs can compile the same way. Hmm, ok. I'll have to make some changes to the .c file then. Thanks for pointing this out. Let me explain this rule a bit more just for the benefit of the general public: There's one important and slightly counterintuitive property that we want in Wine: we want programs to *fail to compile* in Wine the same way they fail to compile in Windows. The rationale is that programs developped in Wine should have a reasonable chance to compile and link on Windows using the Platform SDK. This is especially important for the conformance tests where typically one developer writes a conformance test using Wine's headers and then another developer compiles it on Windows using the Platform SDK. At some point most conformance tests would just fail to compile on Windows because the Wine headers were more permissive for the #include order, C COM interface declarations, etc. This meant more work for the second developer and conformance tests were not being run much on Windows thus defeating their purpose. But I'm happy to report that now things are much better. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.
Re: [Wine]Turining off Fixme Errors
Le dimanche 10 avril 2005 Ã 23:00 +0200, TimeFX a Ãcrit : > WINEDEBUG=fixme-all wine program.exe > > see http://www.winehq.com/site/docs/wine-user/x1824#AEN1826 This page is outdated concerning the Wine Developer's Guide, and refers to a codeweaver no more existing page. See and the wrong URL: "For more details about debug channels, check out the The Wine Developer's Guide." Nicolas > - Original Message - > From: "Phillip Bruce" <[EMAIL PROTECTED]> > To: "wine-users" <[EMAIL PROTECTED]> > Sent: Sunday, April 10, 2005 10:21 PM > Subject: [Wine]Turining off Fixme Errors > > > > Hi, > > > > I hate asking for this as somone did provide me the answer > > earlier. But what is the winedebug syntax for turning off > > all fixme errors? > > > > Thanks. > > > > Phillip > ___ > wine-users mailing list > [EMAIL PROTECTED] > http://www.winehq.org/mailman/listinfo/wine-users -- Brouard Nicolas <[EMAIL PROTECTED]>
Mismatch in winternl.h for SYSTEM_*_INFORMATION structs
Hi,
I'm busy fixing up NtQuerySystemInformation as this is needed for my
'Get Processor Explorer running' project.
I've found that (at least) 2 structs are wrongly sized:
/* System Information Class 0x03 */
typedef struct _SYSTEM_TIMEOFDAY_INFORMATION {
#ifdef __WINESRC__
LARGE_INTEGER liKeBootTime;
LARGE_INTEGER liKeSystemTime;
LARGE_INTEGER liExpTimeZoneBias;
ULONG uCurrentTimeZoneId;
DWORD dwReserved;
#else
BYTE Reserved1[48];
#endif
} SYSTEM_TIMEOFDAY_INFORMATION, *PSYSTEM_TIMEOFDAY_INFORMATION; /* was
SYSTEM_TIME_INFORMATION */
In the __WINESRC__ case it's 32 bytes and 48 otherwise.
The same is true for the _SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION
struct, where in the __WINESRC__ case it's 48 bytes and 44 bytes
otherwise.
So my questions are:
1. Is there a reason for this, or is it a bug.
2. Why do we have separate structs for the WINE and the NOT-WINE case.
Is this because most of it is undocumented?
Cheers,
Paul Vriens.
