mounting versioning filesystems
Everybody hi there, this may be a bit un(cor)related to Wine development, but I am stuck with choosing a way to mount some file versioning repository as a local FS. I've found on the net following projects of that vein: CvsFs [1] (CvsFS-FUSE) Wayback [2] CopyFS [3] GitFS [4] cvsfs and wayback was tested on my box, though I was unable to mount my simple CVS repository correctly even for reading. wayback had some another issues. Now I've hit two more projects: copyfs and gitfs. Well, I know I should test them myself but if anyone was toying around such stuff, it would be interesting to hear a response about it. My aim is to update a file in the repository every time my editor changes that file. So far only copyfs does reads/writes, IMHO, and gitfs is still only for a reads. :-( Is there any more FS layers which do r/w? There is another related project that might be interesting for someone who debugs changes on binary files - that's LoggedFS [5]. TIA [1] http://sf.net/projects/cvsfs [2] http://sf.net/projects/wayback [3] http://n0x.org/copyfs/ [4] http://www.sfgoth.com/~mitch/linux/gitfs/ [5] http://sf.net/projects/loggedfs
winecfg: add options to switch between installed directx versions
Hi all. I wanted to install Need for Speed - Most wanted under wine and the setup told me, that directx is not installed. So i think we need a way to set installed/used directx version in winecfg. Do you think its worth to start developing a patch in this direction? Thanks -- Christian Gmeiner - student of computer science http://dxr3plugin.sf.net http://itb04.ath.cx
Re: resend: [d3d] rearrange switch statement to have FIXMEs for unhalded query types
Christoph Frick [EMAIL PROTECTED] writes: hiho this is a resend of a patch i sent some time ago, which was not applied. There's already a FIXME being printed, I don't think we need two of them. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Check some return values of fwrite()
Vincent Béron [EMAIL PROTECTED] writes: Suppress some warnings. This is the first in a serie of patches, checking the return values of a couple functions. Changelog: Check some return values of fwrite(). If you absolutely want to do that, please write a wrapper function, don't add checks all over the place. Though it really doesn't seem worth the trouble, especially in something like winedump. -- Alexandre Julliard [EMAIL PROTECTED]
Re: winecfg: add options to switch between installed directx versions
On Wed, Dec 07, 2005 at 12:38:46PM +, Christian Gmeiner wrote: I wanted to install Need for Speed - Most wanted under wine and the setup told me, that directx is not installed. So i think we need a way to set installed/used directx version in winecfg. Do you think its worth to start developing a patch in this direction? you should first found out (e.g. using WINEDEBUG=+reg) what the app really wants. i had the case, that a game wanted a very current directx-version and i just had to set a new number in wine.inf and everything worked fine then. imho faking the most current version is the best thing to do - i doubt that there are many apps out there that really ask for a certain (lower) version number? -- cu pgpu7szzqcgXS.pgp Description: PGP signature
Re: resend: [d3d] rearrange switch statement to have FIXMEs for unhalded query types
Christoph Frick [EMAIL PROTECTED] writes: the fixme in the current CVS version is not executed for the unhandled defines (hence the break before default:) There's another FIXME just after the switch that's executed in all cases. -- Alexandre Julliard [EMAIL PROTECTED]
Re: winecfg: add options to switch between installed directx versions
On 12/7/05, Christian Gmeiner [EMAIL PROTECTED] wrote: Hi all. I wanted to install Need for Speed - Most wanted under wine and the setup told me, that directx is not installed. So i think we need a way to set installed/used directx version in winecfg. Do you think its worth to start developing a patch in this direction? Thanks -- Christian Gmeiner - student of computer science A quick and easy work around is to edit AutoRun/autorun.cfg and remove DirectXVersion=9.0c Tom
josystick driver layer and support of multiple devices of one kind
hiho i did recently some patches to mostly make joystick_linuxdinput.c handle things more like joystick_linux.c. the main thing, that i dont like on this work, is the fact, that i am just copy-and-paste code from one end to another. i assume someone started back then the joystick_linuxdinput part and if there where changes at either one of them they where not done (or not all the time) also in the other file. also if i have understood this correctly there is no support for multiple joysticks of one kind at least in the joystick_linuxdinput part (i can not confirm this, because i had for now a js-joystick and a event-wheel - but a event-joystick is on the way). for many game-types it is much likely, that the users want to use more than one input-device (e.g. use the wheel and the pedals from two different manufactures, use the pedals from your wheel with your flight stick, use two gamepads, ...) and its most likely that such a device is nowadays a usb device poping up in /dev/input. if the current implementation works fine with more than one js/event-driven joystick - so let me know; my windows/dinput knowledge ist zero and i have not the hardware to test it yet. so my point: i want to make the joystick_... interface to be more abstract. so to bring the code, that is common for the js and event into one common part and then utilize implementations of a interface for each js and event based joysticks. with this step it would make sense to also allow the driver (i call it that way now) to report the joysticks that are available and so have support for multiple joysticks. a split like this would also allow an easier integration of e.g. joystick support for OSX or other opteration systems that handle joysticks in another way then unix/linux does. so my questions: - i this an approach, that would be acceptablefor wine? so if i start on something like this, is there a chance it would be submitted to the tree - or is there a problem in terms of wine does not work like this and we would ignore such an approach - is the sound-system of wine with its lots of implementations a place to get ideas for such a change; or is this totally off, because the user only chooses one driver to use (instead of: only build the driver if appropriate and then let each driver search for hardware) -- cu pgpJZcdQunKnI.pgp Description: PGP signature
Re: resend: [d3d] rearrange switch statement to have FIXMEs for unhalded query types - d3d guru help requested
On Wed, Dec 07, 2005 at 01:10:49PM +0100, Alexandre Julliard wrote:
the fixme in the current CVS version is not executed for the unhandled
defines (hence the break before default:)
There's another FIXME just after the switch that's executed in all
cases.
yeah right - i just checked against my cvs-tree and saw, that this is
still open. the problem here (and some d3d guru might jump in here) is
that i think, that the comment about the lieing and the last fixme is
misleading/wrong?
first of all we no longer lie (only occlusion-query is handled the rest
not). second this is no stub - it works like advertised (ppQuery==NULL
is for checking only). following now a patch that hopefully fixes the
whole thing and give reasonable messages for user/developer.
--
cu
Index: dlls/wined3d/device.c
===
RCS file: /home/wine/wine/dlls/wined3d/device.c,v
retrieving revision 1.103
diff -u -r1.103 device.c
--- dlls/wined3d/device.c 3 Dec 2005 18:34:46 - 1.103
+++ dlls/wined3d/device.c 7 Dec 2005 12:48:23 -
@@ -1094,8 +1094,14 @@
if (NULL == ppQuery) {
/* Just a check to see if we support this type of query */
HRESULT hr = D3DERR_NOTAVAILABLE;
-/* Lie and say everything is good (we can return ok fake data from a
stub) */
switch(Type) {
+case WINED3DQUERYTYPE_OCCLUSION:
+TRACE((%p) occlusion query\n, This);
+if (GL_SUPPORT(ARB_OCCLUSION_QUERY) ||
GL_SUPPORT(NV_OCCLUSION_QUERY))
+hr = D3D_OK;
+else
+WARN(Unsupported in local OpenGL implementation:
ARB_OCCLUSION_QUERY/NV_OCCLUSION_QUERY\n);
+break;
case WINED3DQUERYTYPE_VCACHE:
case WINED3DQUERYTYPE_RESOURCEMANAGER:
case WINED3DQUERYTYPE_VERTEXSTATS:
@@ -1109,16 +1115,11 @@
case WINED3DQUERYTYPE_PIXELTIMINGS:
case WINED3DQUERYTYPE_BANDWIDTHTIMINGS:
case WINED3DQUERYTYPE_CACHEUTILIZATION:
-break;
-case WINED3DQUERYTYPE_OCCLUSION:
-TRACE((%p) occlusion query\n, This);
-if (GL_SUPPORT(ARB_OCCLUSION_QUERY) ||
GL_SUPPORT(NV_OCCLUSION_QUERY))
-hr = D3D_OK;
-break;
+FIXME((%p) Unsupported query type %d\n, This, Type);
+break;
default:
-FIXME((%p) Unhandled query type %d\n,This , Type);
+FIXME((%p) Unhandled query type %d\n, This, Type);
}
-FIXME((%p) : Stub request for query type %d returned %ld\n, This,
Type, hr);
return hr;
}
pgpDDHdip1xnk.pgp
Description: PGP signature
Re: resend: [d3d] rearrange switch statement to have FIXMEs for unhalded query types
On Wed, Dec 07, 2005 at 12:26:17PM +0100, Alexandre Julliard wrote: this is a resend of a patch i sent some time ago, which was not applied. There's already a FIXME being printed, I don't think we need two of them. the fixme in the current CVS version is not executed for the unhandled defines (hence the break before default:) imho this queries are also not handled by wine, but they are known to wine. -- cu pgpaElnLJg2VD.pgp Description: PGP signature
RpcServerListen and RpcMgmtWaitServerListen
Hi, I have a program that basically does: RpcServerUseProtseqEp RpcServerRegisterIf RpcServerListen(DontWait=FALSE) On Windows this will block until another thread calls RpcMgmtStopServerListening. This does not appear to be the case with Wine's implementation. Before I start to dig in and investigate, I was wondering if this is already a well-known problem. Thanks, Phil
Re: Fix dll_count in mis.c
Christian Gmeiner wrote: I think that we need to init dll_count with 0 to get DllCanUnloadNow working correctly. -static LONG dll_count; +static LONG dll_count = 0; Static variables should be initialized to zero by default. Mike
Re: Shell32 File Property Dialog
Johannes Anderwald wrote:
@@ -1185,6 +1185,7 @@ BOOL SHELL_execute( LPSHELLEXECUTEINFOW
static const WCHAR wFile[] = {'f','i','l','e',0};
static const WCHAR wHttp[] = {'h','t','t','p',':','/','/',0};
static const WCHAR wExplorer[] =
{'e','x','p','l','o','r','e','r','.','e','x','e',0};
+static const WCHAR wProperties[] =
{'p','r','o','p','e','r','t','i','e','s',0};
static const DWORD unsupportedFlags =
SEE_MASK_INVOKEIDLIST | SEE_MASK_ICON | SEE_MASK_HOTKEY |
SEE_MASK_CONNECTNETDRV | SEE_MASK_FLAG_DDEWAIT | SEE_MASK_FLAG_NO_UI |
@@ -1275,7 +1276,11 @@ BOOL SHELL_execute( LPSHELLEXECUTEINFOW
sei-hInstApp = (HINSTANCE) 33;
return TRUE;
}
-
+if (sei_tmp.lpVerb)
+{
+if (!strcmpW(sei_tmp.lpVerb,wProperties))
+return SH_ShowPropertiesDialog(sei_tmp.lpFile);
+}
I should have pointed out earlier that this is not the right way to
activate a properties dialog. This will show the same properties dialog
for all shell objects, which is wrong.
You should create a handler for the properties verb in the IContextMenu
interface of the shell object that you're showing the dialog for. You
need to modify both -QueryContextMenu and -InvokeCommand.
I have implement IContextMenu for the ShellLink object (shelllink.c).
Perhaps try extending that code to make a properties dialog for the
ShellLink object first.
The rest looks better though.
Mike
Re: RpcServerListen and RpcMgmtWaitServerListen
Phil Lodwick wrote: Hi, I have a program that basically does: RpcServerUseProtseqEp RpcServerRegisterIf RpcServerListen(DontWait=FALSE) On Windows this will block until another thread calls RpcMgmtStopServerListening. This does not appear to be the case with Wine's implementation. Before I start to dig in and investigate, I was wondering if this is already a well-known problem. This was a known problem to me, but not one I was intending to fix any time soon. The bug is in RpcMgmtWaitServerListen. It should wait on some synchronisation object, which RpcMgmtStopServerListening should signal. -- Rob Shearman
Re: tests for LoadLibraryA [resend, 2nd]
Stefan Leichter [EMAIL PROTECTED] writes: Hello, this tests exhibit a problem of Wiso Sparbuch 2006 (german tax program). The tests are verified against Win2k ChangeLog --- test loading an executable with LoadLibraryA It doesn't really test that; and actually loading an executable works fine. winhlp32 is a special case because it's a symlink to a different executable, and that doesn't quite work. I don't think it warrants a regression test, because it's not really supposed to work that way. What we need is to provide a real winhlp32.exe. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Robert Reif : winecfg: Added support for auto detecting all drivers by attempting to
I do think all the recent changes to winecfg are going into the wrong direction. First of all, allowing the devices to be opened more than once without having the devices ready for that is a ready bad idea. Basically, windows drivers come in two flavors: - single instance (they can be loaded only once in memory) - multiple instance (they can be loaded several times in memory) For the second type, a specific init string (gotten from the registry, and usually dealing with the HZ resources involved) is passed to the driver. In the wine implementation, we don't get anything from the registry, we just let the device (from the unix interface it uses) return as many audio/midi... ports it finds. This is typically the behavior expected from single instance drivers. Among the issues we'll face here are dual open of the same unix resource (contention) for several instances, overwriting of internal data and structures (they are not prepared for that). Therefore, the multiple open patch has to be reverted. Secondly, I do think it's a bad idea to reconstruct in winecfg most the driver management. It's not done correctly (the DRV_INIT, DRV_ENABLE and DRV_LOAD messages are not correctly passed). If it works today, it's by chance as the configure message is never handled (we just put out a message box), but it doesn't access the internal structures. To do it, we need the DRV_ messages sent. Finally, I'm not sure that presenting all the drivers, and the ports available is really meaningful for most users. Some drivers return just potential entries (esound for example). Even with the caps, most users won't tell the difference between alsa and oss entries. Lately, the available drivers button is not really useful. We shouldn't present non available drivers to the users, and just let him/her choose among the available ones (or just to mark the ones which are not available). -- Eric Pouech
Re: josystick driver layer and support of multiple devices of one kind
so my questions: - i this an approach, that would be acceptablefor wine? so if i start on something like this, is there a chance it would be submitted to the tree - or is there a problem in terms of wine does not work like this and we would ignore such an approach - is the sound-system of wine with its lots of implementations a place to get ideas for such a change; or is this totally off, because the user only chooses one driver to use (instead of: only build the driver if appropriate and then let each driver search for hardware) there are several questions: - share as much as possible code between dinput and winmm (you have to choose which one could call the other) - how to abstract the interfaces: ddk is your friend. for the winmm part, check the include/mmddk.h, and dlls/winmm/joystick (the joystick driver). there's in it all what you need (google will help too). - from the MM experience, don't recreate a separate driver for each known HW or interface, but rather stick everything in a single driver, and handle the complexity here A+ -- Eric Pouech
Re: Robert Reif : winecfg: Added support for auto detecting all drivers by attempting to
Eric Pouech wrote: I do think all the recent changes to winecfg are going into the wrong direction. First of all, allowing the devices to be opened more than once without having the devices ready for that is a ready bad idea. Basically, windows drivers come in two flavors: - single instance (they can be loaded only once in memory) - multiple instance (they can be loaded several times in memory) For the second type, a specific init string (gotten from the registry, and usually dealing with the HZ resources involved) is passed to the driver. In the wine implementation, we don't get anything from the registry, we just let the device (from the unix interface it uses) return as many audio/midi... ports it finds. This is typically the behavior expected from single instance drivers. Among the issues we'll face here are dual open of the same unix resource (contention) for several instances, overwriting of internal data and structures (they are not prepared for that). Therefore, the multiple open patch has to be reverted. We never load a driver more than once. Winecfg calls winmm OpenDriver which will only ever load a single instance of the driver into memory. Subsequent OpenDriver calls will reference the existing in memory driver. Wine models the single instance device driver that supports multiple physical devices. I work with highend multichannel sound cards in windows that show up as a single 8 channel device (with one card or 16 channels with two cards) and as 4 (8) stereo devices. Secondly, I do think it's a bad idea to reconstruct in winecfg most the driver management. It's not done correctly (the DRV_INIT, DRV_ENABLE and DRV_LOAD messages are not correctly passed). If it works today, it's by chance as the configure message is never handled (we just put out a message box), but it doesn't access the internal structures. To do it, we need the DRV_ messages sent. It is true that winecfg is not calling each sub system driver (WaveIn, WaveOut, ...) like windows but device probing is done at main driver load in most drivers (and I am fixing the ones that don't) because device configuration is dynamic rather than read from the registry so opening the sub drivers individually to query static data is not a problem. I have a version of the alsa driver that can change registry entries from the configure dialog. Finally, I'm not sure that presenting all the drivers, and the ports available is really meaningful for most users. Some drivers return just potential entries (esound for example). Even with the caps, most users won't tell the difference between alsa and oss entries. Jack and esound are fundamentally flawed because they create 10 virtual sound cards that all reference a single physical device. This doesn't take into account multiple devices. The proper way to implement this is to allow multiple opens of the same device (just like windows). That way two or more programs can open one card and other programs can open another card and none of the programs are aware or even care about the others. I have multiple sound cards and headsets in a single computer for music and VoIP and I need a way for individual programs to work with specific devices (just like in windows). Lately, the available drivers button is not really useful. We shouldn't present non available drivers to the users, and just let him/her choose among the available ones (or just to mark the ones which are not available). It would be trivial to only show the drivers that opened properly so missing drivers or non-functioning drivers would not be displayed. You can infer that from the device tree now if no physical devices show up under a driver. I could add icons to broken or disabled drivers (just like windows) to show driver/hardware state. I also plan to add device and driver management to the device tree in future versions. This is really just wine's version of the audio portion of windows device manager. Hiding stuff in the registry without giving the user an easy way (GUI rather than reading the source and using regedit) of configuring the sound system is not good. The direction I am trying to take the winecfg it to allow specific driver configuration through the windows DRV_CONFIGURE mechanism which displays a driver specific dialog box for changing driver specific registry entries. This is the only time there is potential contention problems between programs but only if configuration is performed immediately while the other programs are accessing the driver. This can be avoided by doing the reconfiguration at wine reboot time (winmm.dll unload/load) or by checking for open drivers and using locking to prevent modifications by other programs. You could also move the sound drivers into the server but that won't happen.
Re: wglGetPixelFormatAttribivARB unexpected RenderType(100)
On Monday 05 December 2005 23:53, Toan T Nguyen wrote: Hi, thanks for the clarification. Everything is fine then. Thank you for the patch. was Nothing BTW, do you know how to improve OpenGL performance in wine? I get about 10-30% drop in FPS compared to the Windows version (the card is overclocked about 10% both in CPU and memory frequencies in windows, so that might explains some of the performance drop). I set UseDGA to Y in wine regedit but that doesn't seem to help at all. 10-30% is not wine overhead (as wine overhead for opengl is very small) i think it's a driver problem: no linux graphic drivers have the maturity andd performances of windows drivers :( Thanks again, Toan Regards, Raphael pgpgfHZNoWnKf.pgp Description: PGP signature
how do I find where wine itself is segfaulting?
Background. I am trying to figure out why a program that I thought ran OK on 25 October no longer runs and no longer runs when I recompile from that code too. So the program accesses invalid memory down inside the WNDPROC stuff (winproc.c line 418, it says, so I guess it means line 416) So I turn on WINDEBUG=+relay to see what is being passed. And wine segfaults. Even export WINEDEBUG=+relay wine --version which yields 0009:Call kernel32.__wine_kernel_init() ret=77ed4e4d Segmentation fault I can't use gdb and I can't use winedbg. Anyone know what is going on? -- Bill Medland mailto:[EMAIL PROTECTED] http://webhome.idirect.com/~kbmed
OLE without TLS libraries
Hi, having a Xen system my Linux tls library path is not in place (renamed to /lib/tls.disabled). When I run a program that uses OLE/DCOM (with native ole libraries) it crashes immediately. Using LD_LIBRARY_PATH=/lib/tls.disabled wine program makes it work again. I am not sure if this is true for all OLE apps. Is this known/expected behaviour or a bug? Cheers, Cihan
Re: Hungarian keyboard detection problem
Wallner Ádám [EMAIL PROTECTED] wrote:
+/*** Hungarian keyboard layout (setxkbmap hu) | modified by Adam Wallner*/
+static const char main_key_HU_new[MAIN_LEN][4] =
+{
+ 0§,1',2\,3+,4!,5%°,6/,7=,8(,9),AsA-,AzAo,AlA,
+ qQ,wW,eE,rR,tT,zZ,uU,iI,oOA¸,pP,AlA.,AsAs,
+ aA,sS,dD,fF,gG,hH,jJ,kK,lL,ASA?,AAA,AtA,
+ yY,xX,cC,vV,bB,nN,mM,,?,.:,-_,
+ AA
+};
+
/*** Polish (programmer's) keyboard layout ***/
static const char main_key_PL[MAIN_LEN][4] =
{
@@ -921,7 +931,7 @@
{0x040a, Spanish keyboard layout, main_key_ES, main_key_scan_qwerty,
main_key_vkey_qwerty},
{0x0410, Italian keyboard layout, main_key_IT, main_key_scan_qwerty,
main_key_vkey_qwerty},
{0x040f, Icelandic keyboard layout, main_key_IS, main_key_scan_qwerty,
main_key_vkey_qwerty},
- {0x040e, Hungarian keyboard layout, main_key_HU, main_key_scan_qwerty,
main_key_vkey_qwertz},
+ {0x040e, Hungarian keyboard layout, main_key_HU_new, main_key_scan_qwerty,
main_key_vkey_qwertz},
I'd suggest instead of creating a new keyboard layout to patch an existing one.
--
Dmitry.
Re: how do I find where wine itself is segfaulting?
Hi, I'm running into the same problem. File on the resulting core tells me it was generated from wine-preloader. I'm using wine 0.9.2 for Fedora Core 3 from winehq (the i686 version I believe). I'm running an x86_64, if that matters. -- Keith --- Bill Medland [EMAIL PROTECTED] wrote: Background. I am trying to figure out why a program that I thought ran OK on 25 October no longer runs and no longer runs when I recompile from that code too. So the program accesses invalid memory down inside the WNDPROC stuff (winproc.c line 418, it says, so I guess it means line 416) So I turn on WINDEBUG=+relay to see what is being passed. And wine segfaults. Even export WINEDEBUG=+relay wine --version which yields 0009:Call kernel32.__wine_kernel_init() ret=77ed4e4d Segmentation fault I can't use gdb and I can't use winedbg. Anyone know what is going on? -- Bill Medland mailto:[EMAIL PROTECTED] http://webhome.idirect.com/~kbmed __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: OLE without TLS libraries
On Thu, Dec 08, 2005 at 12:35:32PM +1000, Cihan Altinay wrote: Hi, having a Xen system my Linux tls library path is not in place (renamed to /lib/tls.disabled). When I run a program that uses OLE/DCOM (with native ole libraries) it crashes immediately. Using LD_LIBRARY_PATH=/lib/tls.disabled wine program makes it work again. I am not sure if this is true for all OLE apps. Is this known/expected behaviour or a bug? Do you have a backtrace of the crash or similar? Ciao, Marcus
