Error Message and Office 2000
Hi, I'm in Southern California. I did a search for the event when my Office 2000 Professional gave me an error message. It won't setup. The event was 1000 and the fault address is the same as a read out of your computer that you posted online. http://www.winehq.org/pipermail/wine-devel/2003-July/018313.html Did you ever figure out how to get it to work? Thanks! Ciao! Connie
Re: [Wine] Re: Windows Kernel Executive implementation
On Wed, Feb 27, 2008 at 8:26 AM, Stefan Dösinger [EMAIL PROTECTED] wrote: Am Mittwoch, 27. Februar 2008 01:52:32 schrieb [EMAIL PROTECTED]: With regard to the other things in this thread, if the sysInternals group at Microsoft is willing to share the interface between their application and driver, wine could easily implement it (ultimately far more secure than the Windows solution), then the tools could run on wine. Unless you're expecting filemon running in wine to magically start showing all file access even from applications not using the Win32 API. What is the use of just running those tools? Aren't there Linux equivalents for it? I don't know. Certainly procmon is lightyears ahead of strace in terms of usability, plus isn't limited to a single process. A google found that KDE will be providing a GUI app named inspektor but I couldn't find very much on it. What is your preferred utility for filling that niche (logging I/O calls)? If it was a test case for better driver support, then yeah, it is useful, but just running those apps by cloning parts of them seems wasted effort to me Those particular apps are useful to the point that every competent Windows sysadmin knows of them.
Re: [Wine] Re: Windows Kernel Executive implementation
On Sat, Feb 23, 2008 at 2:00 AM, Steven Edwards [EMAIL PROTECTED] wrote: On Fri, Feb 22, 2008 at 7:00 PM, Volodymyr Shcherbyna [EMAIL PROTECTED] wrote: I am not sure that ReacOS is a good example. Quite a big amount of code in ReactOS contains leaked code of Windows (from Windows 2k). Recently I did a research, since I have access to Windows code(code premium subscription), I am able to compare things. I was the project cordinator for ReactOS for a while and still have a pretty good relationship with a lot of the active developers. Can you provide me a list of all code (just a list of offending functions would be fine) that is in ReactOS that you know to be from leaked windows sources and I will work with them to remove all offending code. Thanks Steven Essentially the same claims were made (I believe by the same party) on the microsoft public newsgroups about a month ago, with the same offer to expunge the offending code, and AFAICT, no action taken. With regard to the other things in this thread, if the sysInternals group at Microsoft is willing to share the interface between their application and driver, wine could easily implement it (ultimately far more secure than the Windows solution), then the tools could run on wine. Unless you're expecting filemon running in wine to magically start showing all file access even from applications not using the Win32 API. The goal should not be to run Windows kernel drivers in Linux kernel mode, that's insanity, but to implement the userspace/kernel interface API with Linux device drivers behind. Yes, that means people will be limited to hardware supported by Linux, but those drivers have far better minimum reliability than even the Windows ones carrying that joke called WHQL certification. Ben Voigt C++ MVP https://mvp.support.microsoft.com/Profile/voigt (and MS has removed all the information on my public profile since they changed the format...)
Re: [10/10] WineD3D: Implement blits from the active render target to swapchains
Hi, this patch caused some rendering issues to NFS PRO STREET too. Mirek Slugen Stefan Dösinger napsal(a): Am Montag, 17. Dezember 2007 21:04:46 schrieb Stefan Dösinger: Do not apply this patch yet, it has some problems
Re: WineD3D patch submission
I tried this patch, everything works like before, can't find any
regression in apps like ET: QW, Oblivion, all nvidia D3D SDK tests,
3DMarks and others. Titan Quest looks beter, but there are still some
issues in menu, game is not working because of gdi32.dll functionality.
I create patch for actual git.
Mirek
Mitchell Wheeler napsal(a):
Hi all,
A week or so ago I tried to get a game working in WINE (Titan Quest),
however it seems it really needs a proper DIB engine before it'll be
playable.
Anyways, in my attempt to get it working I fixed up some issues w/
IWineD3DDeviceImpl_UpdateSurface.c in dlls/wined3d, not entirely sure
how you guys do things around here so I thought i'd just post my changes
to the function in this mailing list and you can do with it what you
want. (Note: it actually has a few different methods of doing one
thing, enclosed in macro blocks to toggle between them. Technically the
first one should work (i think :\) once you guys properly implement
surface locking/unlocking, and it's 'simplest', but the last one is the
only one that actually works properly (using standard OpenGL calls).
You'll probably have to clean up the code to meet your coding standards
/ etc, maybe remove the custom byte size calculation of compressed
images, and some other things - but the functionality is there... i
also fixed the existing code that didn't actually do what it was
supposed to, heh.
Regards,
Mitchell Wheeler
static HRESULT WINAPI IWineD3DDeviceImpl_UpdateSurface(IWineD3DDevice
*iface, IWineD3DSurface *pSourceSurface, CONST RECT* pSourceRect,
IWineD3DSurface *pDestinationSurface, CONST POINT* pDestPoint) {
IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *) iface;
/** TODO: remove casts to IWineD3DSurfaceImpl
* NOTE: move code to surface to accomplish this
/
IWineD3DSurfaceImpl *pSrcSurface = (IWineD3DSurfaceImpl
*)pSourceSurface;
IWineD3DSurfaceImpl *pDestSurface =
(IWineD3DSurfaceImpl*)pDestinationSurface;
int srcWidth, srcHeight;
unsigned int srcSurfaceWidth, srcSurfaceHeight, destSurfaceWidth,
destSurfaceHeight;
WINED3DFORMAT destFormat, srcFormat;
int srcLeft, srcTop, destLeft, destTop;
WINED3DPOOL srcPool, destPool;
int offset= 0;
int rowoffset = 0; /* how many bytes to add onto the end of a row to
wraparound to the beginning of the next */
glDescriptor *glDescription = NULL, *glSrcDescription = NULL;
GLenum dummy;
int bpp;
UINT destByteSize = 0, srcByteSize = 0;
int destPixelByteSize = 0, srcPixelByteSize = 0;
CONVERT_TYPES convert = NO_CONVERSION;
WINED3DSURFACE_DESC winedesc;
TRACE((%p) : Source (%p) Rect (%p) Destination (%p) Point(%p)\n,
This, pSourceSurface, pSourceRect, pDestinationSurface, pDestPoint);
memset(winedesc, 0, sizeof(winedesc));
winedesc.Width = srcSurfaceWidth;
winedesc.Height = srcSurfaceHeight;
winedesc.Pool = srcPool;
winedesc.Format = srcFormat;
winedesc.Size = srcByteSize;
IWineD3DSurface_GetDesc(pSourceSurface, winedesc);
winedesc.Width = destSurfaceWidth;
winedesc.Height = destSurfaceHeight;
winedesc.Pool = destPool;
winedesc.Format = destFormat;
winedesc.Size = destByteSize;
IWineD3DSurface_GetDesc(pDestinationSurface, winedesc);
if(srcPool != WINED3DPOOL_SYSTEMMEM || destPool !=
WINED3DPOOL_DEFAULT){
WARN(source %p must be SYSTEMMEM and dest %p must be DEFAULT,
returning WINED3DERR_INVALIDCALL\n, pSourceSurface, pDestinationSurface);
return WINED3DERR_INVALIDCALL;
}
/* This call loads the opengl surface directly, instead of copying
the surface to the
* destination's sysmem copy. If surface conversion is needed, use
BltFast instead to
* copy in sysmem and use regular surface loading.
*/
d3dfmt_get_conv((IWineD3DSurfaceImpl *) pDestinationSurface, FALSE,
TRUE,
dummy, dummy, dummy, convert, bpp, FALSE);
if(convert != NO_CONVERSION) {
return IWineD3DSurface_BltFast(pDestinationSurface,
pDestPoint ? pDestPoint-x : 0,
pDestPoint ? pDestPoint-y : 0,
pSourceSurface, (RECT *)
pSourceRect, 0);
}
if (destFormat == WINED3DFMT_UNKNOWN) {
TRACE((%p) : Converting destination surface from
WINED3DFMT_UNKNOWN to the source format\n, This);
IWineD3DSurface_SetFormat(pDestinationSurface, srcFormat);
/* Get the update surface description */
IWineD3DSurface_GetDesc(pDestinationSurface, winedesc);
}
ActivateContext(This, This-lastActiveRenderTarget,
CTXUSAGE_RESOURCELOAD);
ENTER_GL();
if (GL_SUPPORT(ARB_MULTITEXTURE)) {
GL_EXTCALL(glActiveTextureARB(GL_TEXTURE0_ARB));
checkGLcall(glActiveTextureARB);
}
/* Make sure the
Re: Making the wiki FAQ live
On 6/21/07, Ben Hodgetts (Enverex) [EMAIL PROTECTED] wrote: I've done some heavy modifications and additions to the Wiki FAQ and it's now the YOU MUST READ THIS NOW! document pointed to by the #winehq IRC channel so I agree. It's also impossible to edit the old FAQ easily anyway. Some users have been confused though finding two FAQs on the site, so the quicker the old one can be taken down the better. Ben H. In the interest of not breaking existing links, can the static FAQ be replaced with a redirect to the wiki version?
Re: Alarming number of users getting hardlocks with Wine
On 5/24/07, Scott Ritchie [EMAIL PROTECTED] wrote: Reading the Ubuntu forums, I've noticed quite a few reports from users complaining about Wine deadlocking their system - keyboard unresponsive, with no solution but to restart the entire computer. I've had the keyboard stop responding... often... with a particular game. I have to go find the link to it. Sometimes users report this problem after running ANY Wine process - even winecfg. I'm not sure what's causing the issue. At first I thought it was a hardware thing (perhaps ATI's infamously terribly drivers), but would But I have a PCI Geforce 6200. that still prevent winecfg from working? Wine is a user-level process, it shouldn't be able to cause a hardlock under any circumstances, right? Definitely agreeing with that. Trying to convince my management that the blue screen of death triggered by my Windows program is also not my bug for the same reason. Anyone else seen these kinds of reports? Thanks, Scott Ritchie
Re: Alarming number of users getting hardlocks with Wine
On 5/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On 5/24/07, Scott Ritchie [EMAIL PROTECTED] wrote: Reading the Ubuntu forums, I've noticed quite a few reports from users complaining about Wine deadlocking their system - keyboard unresponsive, with no solution but to restart the entire computer. I've had the keyboard stop responding... often... with a particular game. I have to go find the link to it. It's Galactic Dream: Rage of War demo/preview. Free download, make it easy(-ier) to reproduce. http://www.rageofwar.net/ Sometimes users report this problem after running ANY Wine process - even winecfg. I'm not sure what's causing the issue. At first I thought it was a hardware thing (perhaps ATI's infamously terribly drivers), but would But I have a PCI Geforce 6200. that still prevent winecfg from working? Wine is a user-level process, it shouldn't be able to cause a hardlock under any circumstances, right? Definitely agreeing with that. Trying to convince my management that the blue screen of death triggered by my Windows program is also not my bug for the same reason. Anyone else seen these kinds of reports? Thanks, Scott Ritchie
Re: Install fail on 64bit syst Q
configure:2404: checking for C compiler default output file name configure:2431: gcc -m32conftest.c 5 /usr/bin/ld: skipping incompatible /usr/bin/../lib/libc.so when searching for -lc /usr/bin/ld: skipping incompatible /usr/bin/../lib/libc.a when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc /usr/bin/ld: cannot find -lc collect2: ld returned 1 exit status This is your problem... you don't have a 32-bit version of glibc, so although your compiler can compile 32-bit programs such as wine just fine, the library functions are missing. As noted in a previous response, your distro can give you instructions for installing a 32-bit glibc, either a pre-built binary or compiling it yourself.
Re: Internet explorer not detected
On 5/11/07, James Hawkins [EMAIL PROTECTED] wrote: On 5/11/07, Louis Lenders [EMAIL PROTECTED] wrote: Hi, i tried help this dude on IRC channel getting an application to run called MegaSpoof. Even after creating fake registry key it kept complaining about missing Internet Explorer. After looking through the +relay log i found this: 000d:Call KERNEL32.CreateProcessW(,0034f428 Lc:\\Program Files\\Internet Explorer\\iexplore.exe -Embedding,000 0,,,,,,0034f7d8,0034f828) ret=77f1d75f 000d:Ret KERNEL32.CreateProcessW() retval= ret=77f1d75f In current wine a simple wine c:\Program Files\Internet Explorer\iexplore.exe just fails , because we don't have that directory. After manually creating it , and copy iexplore.exe.so to /Program Files/Internet Explorer/iexplore.exe, the application didn't complain anymore, and got further. Question: do we need to mimic windows behaviour, and create that directory + put wine's iexplore in it, or is the policy that in this case we just have to download MS ie6, and install that (as the application suggested) c:\Program Files\Internet Explorer is where iexplore.exe is put in XP, so I think we should mimic that. It wouldn't be hard to add that to wine.inf:[FakeDllsSection]. really %SYSTEMDRIVE%\Program Files\Internet Explorer, right? I don't really feel sorry for apps that assume everything is running from C: -- James Hawkins
Re: [PATCH 3/3] winex11: Use TINN algorithm to speed up colour lookups. (try 2)
But I'm open to any ideas you may have as to how we could avoid using floats, yet not run into the overflow situations so easily. We could probably use division somewhere but I don't think that's actually any better performance-wise. It is, when implemented via bit-shifts (very cheap). I know wine is written in pure C, but with a little C++ template magic you should be able to have fixed-point math that acts like floating, only having the compiler take care of the binary point at compile-time using the type system, and emitting only integer operations. Still wouldn't be as efficient as hand-designed fixed-point pumped through the optimizing compiler. I'm pretty sure ints are still much better performance-wise. That article you cited is not telling the whole story; no operation on a modern CPU is executed in a single cycle. The aggregate throughput when considering optimal pipelining may be one float instruction per cycle... but integer operations routinely achieve several (on a Core 2 I believe up to four instructions can be started into the pipelines per cycle, per core). There's also pipeline stalls and flushes to consider, where I believe further investigation will again show much bigger performance hits on floating-point. And no mention of SIMD was made whatsoever, which is capable of the highest performance in every discussion I've seen. Furthermore SIMD has built-in support for things like integer-multiply-keeping-only-the-most-significant-half and multiply-add, at least on x86 architecture, which if I'm not mistaken is still a wine requirement for running x86 PE files. And when you try to save space by using 32-bit float, you lose everywhere. 32-bit floating-point store involves rounding and is slow. As a result, compilers maintain high precision as long as possible, which means you lose repeatability (integer expressions tend to give the same results with or without optimizations, float -- do not). If you go to 64-bit floats, then you should compare against the range of 64-bit integers, which modern CPUs also support at full speed for basic operations.
Re: -ansi, -pedantic warnings and errors on
On 2/18/07, Robert Shearman [EMAIL PROTECTED] wrote: Joris Huizer wrote: Though the keyword inline implies the code should get inlined, and if it shouldn't, the implementation copy should be removed from the unicode.h file No, it's a hint to the compiler. static inline says to the compiler try to inline this function if it is worth it, or otherwise include a copy of this function in the object file. extern inline says to the compiler try to inline this function if it is worth it, or otherwise link to shared copy of this function (in our case, implemented in the libwine shared object). I believe just inline by itself has that effect. One doesn't ordinarily put extern on the function definition (unless it's 'extern C'). -- Rob Shearman
Re: 1/4 NtCreateMailslotFile tests
Microsoft appears to be pushing people away from NtClose. I'd suggest you to find a reason why. That particular documentation happens to be part of the API released under court order. They didn't want to give it out to begin with, and they don't want people using it now. Perhaps someone should determine if there are any applications statically linking to any of those functions, which would disprove the claim There is no import library, you must use GetProcAddress and leave MS in violation of said order.
Re: Resend 1/4 NtCreateMailslotFile tests
On 2/17/07, Eric Pouech [EMAIL PROTECTED] wrote: Jeff L a écrit : Eric Pouech wrote: Jeff Latimer a écrit : Establish the framework for testing NtCreateMailslotFile. Have fixed issues with NTSTATUS return codes etc. those tests belong to dlls/ntdll, not dlls/kernel32 also, if the test is for ntdll functions, it shouldn't use kernel32 ones... hence, NtClose should be used instead of CloseHandle I put the proposition a while ago about putting the tests in kernel32 as, although they are ntdll functions, they related to mailslot functions and relating the tests would be easier on the tester. I take it that that is not the case? my call would be to put the tests for functions sitting in DLL X in the directory X/tests, even if we need to rewrite some code (or bother some code from some other tests) but as the API are different, we need in the end the both sets of test perhaps split out ntdll tests, as in ntdll/tests/kernel32.c ?
Re: DIB Engine, some summarization
On 2/12/07, Daniel Remenak [EMAIL PROTECTED] wrote: On 2/12/07, Stefan Dösinger [EMAIL PROTECTED] wrote: Am Montag 12 Februar 2007 19:54 schrieb Daniel Remenak: On 2/11/07, Damjan Jovanovic [EMAIL PROTECTED] wrote: What about the case where you draw with GDI, then render with OpenGL on top of that, then draw on top of that with GDI, then swap buffers? If you draw only client-side, you have to copy to the server, then copy back, then copy to the server *again*. You have to upload or download the image *every time* you go between OpenGL and GDI drawing, whereas when you draw with X11, there is no uploads/downloads unless you use DIB sections and draw directly. Not that it's relevant to this conversation (since wine needs to support legacy apps), but just so you know, even Microsoft no longer supports this sample scenario. Drawing with GDI over OpenGL (or DX), and reading from the GDI buffer on a hardware-accelerated window, are both undefined (officially not supported) operations on Windows Vista. Caused a ton of problems for my company's product So IDirect3DSurface9::GetDC does not work any longer? (Or IDirectDrawSurface7::GetDC) /me parties! Unfortunately, no; it looks like you can still render GDI onto a DX surface, just not directly onto a window which is also being rendered to by DX. From the linked blog article: Note that there is an alternative that can often work for an application -- DirectX is capable of handing back a DC to a DirectX surface, and applications can perform GDI rendering to that DC. From the DWM's perspective, that DirectX surface remains purely rendered by DirectX, and all is well. --Daniel Remenak This sounds like a really simple way to support client-side and server-side drawing without the mixing that causes repeated network transfers: gdi32.dll GetDC, GetClientDC, and CreateCompatibleDC would all be done client-size, while IDirectWhatever::GetDC would return a device context that is strictly server-side. Does that seem reasonable?
Re: wineboot: Start items in StartUp folder on boot, includes security measures.
On 2/12/07, James Hawkins [EMAIL PROTECTED] wrote: On 2/12/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: You advocated that wine aim for working exactly like Windows, no less and no more, rather than deviating in user-configurable ways to enhance the user's control over his own system. Right. That's the purpose of Wine. You'd know that if you were a developer on this project. You'll get there a lot faster by contributing to colinux (www.colinux.org) instead. Maybe while we're at it, wine should have the bug which allows certain software to prevent screen grabs. I don't know of any apps that depend on this behavior, so that's not likely to happen. Any DRM-enabled media player... which you would have understood if you looked at my next comment! No, I think defeating DRM to enable fair use is perfectly reasonable, and there are some bugs which should be fixed. Should wine try to patch remote exploits at the exact same rate as windowsupdate.com? Since we have completely different code bases, I don't see how we can fix their code in our tree. You misunderstood me completely, I'm beginning to wonder if you're doing so intentionally. To maintain bug for bug compatibility, then when an exploit is discovered, wine won't be able to release a patch until after Microsoft has done so, because to do so earlier would be to implement functionality that doesn't match WIndows, breaking compatibility. That would be also be required for true bug-for-bug compatibility. After all, someone properly authorized might be using that backdoor to reboot their webfarm remotely -- not! There are things that are wrong in a theoretical sense (i.e. the Pentium floating-point bug), or misclassification of Unicode characters, which some programs might reasonably depend on. And then there are things that are wrong from a practical engineering perspective, like software taking away the user's choice to not run it, which the mere fact that a program depends on it makes it malware. Are you a software engineer? From a practical engineering perspective, adding this option adds unnecessary complication to the code base and increases the chances for bugs. This is exactly what I consider this sort of thing quite necessary, I would implement that function on Windows if it was possible without totally replacing all the security code (processing of Start menu/Programs/Startup and HKLM/Software/.../Run can be turned off, but group policy start items can't be disabled in any way that I'm aware of). UAC does, and no competent engineer thinks UAC is a good thing, or that it adds any amount of security. This malware that you're so UAC does add security, but the interface is horrid. It's really the same idea as Linux's don't-login-as-root, except that with linux you don't necessarily have to use sudo and type a password for every process you want to run elevated, there's suid, sudo remembers your credentials for a short while, you can open an elevated shell, etc. I think UAC has some of the same capability between signed manifests in place of suid and you can probably run an elevated shell there as well. afraid of can just write over that registry entry. I don't run Vista, but my understanding is that you can't permanently approve a particular program to run elevated, the question reappears every single time. Giving the user a per-program Remember my answer option improves the user experience so much it's not even comparable. And I have never advocated for putting this in the registry, my suggestion has always been to store these settings in a file outside the .wine/drive_c jail area that is accessbile via wine's Win32 API. If this entry defaults to Always or Never, then the users won't even know that the option exists, and that's one more piece of information that we'll have to broadcast and answer questions about. So the best thing would be to set Ask as the installation default, and in addition to the Yes/No/Always/Never buttons on the prompt, provide a link to the winecfg page where the default is configured. Reduced privileges do little or nothing to prevent network abuse (open spam relay and the like). If you're running executables that are going to add themselves to AutoStart, the fact that they might run again is the least of your concerns. While I agree 100%, stopping the malware from running itself after a reboot is still a very good thing. How useful would chroot be if the chrooted programs could set up autostart items or cron jobs without the admin's approval? Not nearly as much as it is now.
Re: wineboot: Start items in StartUp folder on boot, includes security measures.
On 2/12/07, James Hawkins [EMAIL PROTECTED] wrote: On 2/11/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On 2/11/07, Misha Koshelev [EMAIL PROTECTED] wrote: Hi everybody, Thanks for your suggestions. I just posted a new patch on wine-patches where I tried to incorporate these and now it does the following (in addition to my previous patch which just started items in the StartUp folder): - When wineboot finds a file that it wants to start in the StartUp folder, it asks the user whether he wants to run the program. His options are: Always, Yes, No (default), and Never. - If he selects Yes the program is run, if he select No it is not. - If he selects Always or Never, I create a registry key in: HKEY_CURRENT_USER\Software\Wine\StartupItems with the full pathname of the program and the value always or never. When wineboot sees this program in the StartUp folder it checks this key, and if it is set it performs the appropriate action. What do you guys think? If you like the system, it would be pretty easy to incorporate this into the run key running as well (which are currently just run without any user confirmation)? This sounds almost perfect. I think the counterpoint raised by James Hawkins would be adequately addressed by adding a winecfg option as follows: Startup items behavior: (*) Silently allow -- This is bug-for-bug compatibility ( ) Ask-- Most computer-savvy folks would want this ( ) Silently block ( ) Block and notify me This is unnecessarily complicated, and i really doubt anything like this would ever make it into the Wine tree. Perhaps this should be independently set for each kind of startup item (startmenu\programs\startup, registry run key, profile settings, etc), but I think that's not really necessary. Also, I would suggest that the list of approved start items be stored outside of winespace, so that malware can't bypass the protection by setting the key. Of course, really nasty stuff could still call into Linux, but that would require some hybrid system that was aware of the ELF dynamic loader in order to not fall afoul of address space randomization. Ultimately I think wine is about more than just running Windows-compatible programs without the Microsoft tax. It's about running those programs without ceding control of your computer to an untrustworthy party. We don't want the limitations that Windows imposes... true bug-for-bug compatibility would mean only being able to access files on a FAT or NTFS partition, but I don't hear anyone advocating for that kind of crippling behavior. What? Wine has nothing to do with which file system your files reside on. You advocated that wine aim for working exactly like Windows, no less and no more, rather than deviating in user-configurable ways to enhance the user's control over his own system. Maybe while we're at it, wine should have the bug which allows certain software to prevent screen grabs. No, I think defeating DRM to enable fair use is perfectly reasonable, and there are some bugs which should be fixed. Should wine try to patch remote exploits at the exact same rate as windowsupdate.com? That would be also be required for true bug-for-bug compatibility. After all, someone properly authorized might be using that backdoor to reboot their webfarm remotely -- not! There are things that are wrong in a theoretical sense (i.e. the Pentium floating-point bug), or misclassification of Unicode characters, which some programs might reasonably depend on. And then there are things that are wrong from a practical engineering perspective, like software taking away the user's choice to not run it, which the mere fact that a program depends on it makes it malware. Asking if you want to run every file set for startup in wineboot every single time is crippling behavior, not to mention annoying. UAC anyone? If you're so worried about this malware, create a reduced privileges account just for Wine. That's the point of a remember my choice or Yes/No/Always/Never option on the prompt which appears when the winecfg option is ask... Reduced privileges do little or nothing to prevent network abuse (open spam relay and the like). Thanks Misha p.s. please please please anyone who is familiar with IShellFolder if you could look over those parts and just say yes it looks good that would make me feel better. I think it is correct but really an expert's opinion would be great. -- James Hawkins
Re: wineboot: Start items in StartUp folder on boot, includes security measures.
On 2/11/07, Misha Koshelev [EMAIL PROTECTED] wrote: Hi everybody, Thanks for your suggestions. I just posted a new patch on wine-patches where I tried to incorporate these and now it does the following (in addition to my previous patch which just started items in the StartUp folder): - When wineboot finds a file that it wants to start in the StartUp folder, it asks the user whether he wants to run the program. His options are: Always, Yes, No (default), and Never. - If he selects Yes the program is run, if he select No it is not. - If he selects Always or Never, I create a registry key in: HKEY_CURRENT_USER\Software\Wine\StartupItems with the full pathname of the program and the value always or never. When wineboot sees this program in the StartUp folder it checks this key, and if it is set it performs the appropriate action. What do you guys think? If you like the system, it would be pretty easy to incorporate this into the run key running as well (which are currently just run without any user confirmation)? This sounds almost perfect. I think the counterpoint raised by James Hawkins would be adequately addressed by adding a winecfg option as follows: Startup items behavior: (*) Silently allow -- This is bug-for-bug compatibility ( ) Ask-- Most computer-savvy folks would want this ( ) Silently block ( ) Block and notify me Perhaps this should be independently set for each kind of startup item (startmenu\programs\startup, registry run key, profile settings, etc), but I think that's not really necessary. Also, I would suggest that the list of approved start items be stored outside of winespace, so that malware can't bypass the protection by setting the key. Of course, really nasty stuff could still call into Linux, but that would require some hybrid system that was aware of the ELF dynamic loader in order to not fall afoul of address space randomization. Ultimately I think wine is about more than just running Windows-compatible programs without the Microsoft tax. It's about running those programs without ceding control of your computer to an untrustworthy party. We don't want the limitations that Windows imposes... true bug-for-bug compatibility would mean only being able to access files on a FAT or NTFS partition, but I don't hear anyone advocating for that kind of crippling behavior. Thanks Misha p.s. please please please anyone who is familiar with IShellFolder if you could look over those parts and just say yes it looks good that would make me feel better. I think it is correct but really an expert's opinion would be great.
Re: wineboot: Start items in StartUp folder on boot.
On 2/10/07, David Lichterman [EMAIL PROTECTED] wrote: Stefan Dösinger wrote: Am Samstag 10 Februar 2007 05:20 schrieb Vitaliy Margolen: Misha Koshelev wrote: Hi, As you all may have noticed, I have been making quite a few patches within the last two weeks (or at least quite a few when compared to zero before then) because I had figured out that the Vector NTI program that is quite important in molecular biologThis patch makes sure that wine will start items in the StartUp folder IMHO this should not be fixed. I've seen lots and lots of malicious programs using this mechanism to start themselves. And even worse if installer uses this to restart itself. That means this installer might not work most of the time on windows. Malicious programs can also write themselves to HKLM/Software/Microsoft/Windows/Run, a key that wineboot reads. So I do not see any advantage in implementing the Run key, but not the autostart folder. I second that opinion. I do computer tech support (ie getting viruses and spy/malware off of windows) at my university and if there's a case for not implementing one of those two run at boot features, disabling the Run key would be the stronger since most, if not all malicious programs now use the run registry location as opposed to the Startup folder. It really comes down to the amount of power a user should have. Maybe require a gksu whenever an app tries to write something to that folder or that registry location? What a gksu? How about prompting the user during startup? e.g., Start title using command line program + args? Yes/No ([x] Don't ask again Don't ask again items could either be stored as hash codes in a configuration file outside the wine filesystem, or else by deleting command/moving to a usual Unixy autostart location. This should be done for all startup programs, whether start menu or registry. It would be the best of both worlds, it works as expected for the user without requiring them to give up control of their system. There could even be a winecfg option whether to prompt the user, silently allow, automatically+loudly deny, or silently deny.
Re: wineboot: Start items in StartUp folder on boot.
On 2/10/07, Jacob Alberty [EMAIL PROTECTED] wrote: Why not integrate this functionality into wineboot? That way if a user wants to completely deny the start-up folder they can just not add wineboot to the list of programs to be started on login, but if they want that functionality they can simply add wineboot to the list of programs for start up when they login? It would allow similar functionality to windows whilst still keeping it a separate system. I think everyone agrees that wineboot is where this functionality should be, if it's implemented at all? Well, part of my idea was that even if the configuration option is set to silently deny, any option that was previously accepted with the don't ask again option checked (or Always in case wine has buttons for Never, Not This Time, Run This Time, Always) would still execute, which is rather different from totally disabling wineboot. Then you could presumably run wineboot explicitly or some helper program, in order to manage the entries. On 2/10/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On 2/10/07, David Lichterman [EMAIL PROTECTED] wrote: Stefan Dösinger wrote: Am Samstag 10 Februar 2007 05:20 schrieb Vitaliy Margolen: Misha Koshelev wrote: Hi, As you all may have noticed, I have been making quite a few patches within the last two weeks (or at least quite a few when compared to zero before then) because I had figured out that the Vector NTI program that is quite important in molecular biologThis patch makes sure that wine will start items in the StartUp folder IMHO this should not be fixed. I've seen lots and lots of malicious programs using this mechanism to start themselves. And even worse if installer uses this to restart itself. That means this installer might not work most of the time on windows. Malicious programs can also write themselves to HKLM/Software/Microsoft/Windows/Run, a key that wineboot reads. So I do not see any advantage in implementing the Run key, but not the autostart folder. I second that opinion. I do computer tech support (ie getting viruses and spy/malware off of windows) at my university and if there's a case for not implementing one of those two run at boot features, disabling the Run key would be the stronger since most, if not all malicious programs now use the run registry location as opposed to the Startup folder. It really comes down to the amount of power a user should have. Maybe require a gksu whenever an app tries to write something to that folder or that registry location? What a gksu? How about prompting the user during startup? e.g., Start title using command line program + args? Yes/No ([x] Don't ask again Don't ask again items could either be stored as hash codes in a configuration file outside the wine filesystem, or else by deleting command/moving to a usual Unixy autostart location. This should be done for all startup programs, whether start menu or registry. It would be the best of both worlds, it works as expected for the user without requiring them to give up control of their system. There could even be a winecfg option whether to prompt the user, silently allow, automatically+loudly deny, or silently deny.
Re: winegcc: sign-compare fixes
memmove(arr-base[i], arr-base[i + 1],
(arr-size - i - 1) *
sizeof(arr-base[0]));
arr-size--;
}
If the element size could be greater than one byte,
the multiplication
here should be checked for overflow (actually, this
is more necessary
when the array is created or expanded).
Well, the base field in the structure is defined as
const char** base so sizeof(base[0]) == sizeof(const
char *), should be 4 or so.
How do you mean overflow in this case? sorry for
asking dumb questions...
One desires that the argument is the size of memory which holds
numelems = (arr-size - i - 1) elements of each = sizeof
(arr-base[0]) bytes each. As you say each = 4 bytes on 32-bit
systems.
Then the value is numelems * each = numelems * 4 = numelems 2.
Thus if either of the two most significant bits in numelems are set,
they will be lost as a result of the shift (multiplication). In this
case the correct value is larger than addressable virtual memory,
which should be illegal. Actually though, the limit should be placed
on arr-size in the allocation function.
The essential problem here is that this can be used to remove sanity
checking in the case where the inputs are supplied by a client with
lesser permissions. Imagine, for example, a kernel function being
invoked via an ioctl... though the problem is equally valid for any
network-facing service.
Say a client is allowed to create and access buffer for exchange with
a device (USB printer or the like), and that the client can allocate
the buffer by providing the number of buffer elements, and the element
size is fixed and non-unity, we'll use 4 in this example. If the
privileged service does something like the following:
handle createbuffer(int buflen)
{
if (buflen = 0) return NULL
int bytecount = 4 * buflen;
if (bytecount quota) return NULL;
int* p = malloc(bytecount);
if (!p) return NULL;
return createbufferhandle(buflen, p);
}
and lets the client read from the buffer:
int readbufferatindex(handle buffer, int index)
{
int size = buffersizefromhandle(buffer);
if (index 0 || index = size) return 0;
return bufferptrfromhandle(buffer)[index];
}
Seems safe enough, right? Each client is allowed only a limited
buffer, maybe elsewhere the number of buffers is limited, so the
client can't execute a DOS attack. malloc guarantees that the buffer
doesn't overlap any other buffer, and the bounds checking in
readbufferatindex prevents clients from reading outside their buffer.
Until I do this:
buffer = createbuffer(0x4010);
Uh-oh. I passed the quota check, because bytecount was calculated at
64 bytes. malloc easily allocated 64 bytes not overlapping with any
other user. But the stored buffersize is set so large that the bounds
check is worthless; I can read any memory I want.
Re: winegcc: sign-compare fixes
On 2/7/07, Joris Huizer [EMAIL PROTECTED] wrote:
I believe this one causes problems -- please do not commit yet
Joris Huizer [EMAIL PROTECTED] wrote:
Need Mail bonding?
Go to the Yahoo! Mail QA for great tips from Yahoo! Answers users.From
8686a200bd1f1cbd934d761013c487a9ddc195c9 Mon Sep 17
00:00:00 2001
From: Joris Huizer
Date: Wed, 7 Feb 2007 15:19:25 +0100
Subject: [PATCH] winegcc sign-compare fixes
To: wine-patches
---
tools/winegcc/utils.c | 13 +++--
tools/winegcc/winegcc.c | 11 ++-
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/tools/winegcc/utils.c b/tools/winegcc/utils.c
index 1af91e9..c144077 100644
--- a/tools/winegcc/utils.c
+++ b/tools/winegcc/utils.c
@@ -120,14 +120,14 @@ void strarray_add(strarray* arr, const c
void strarray_del(strarray* arr, int i)
{
- if (i 0 || i = arr-size) error(Invalid index i=%d, i);
+ if (i 0 || (unsigned int)i = arr-size) error(Invalid index i=%d, i);
The unsigned int comparison here makes the negative check superfluous.
Perhaps the argument should even be changed to unsigned as well, to
match the range of arr-size (if the element is one byte).
memmove(arr-base[i], arr-base[i + 1], (arr-size - i - 1) *
sizeof(arr-base[0]));
arr-size--;
}
If the element size could be greater than one byte, the multiplication
here should be checked for overflow (actually, this is more necessary
when the array is created or expanded).
Re: winedump: sign-compare fixes
On 2/7/07, Dmitry Timoshkov [EMAIL PROTECTED] wrote: Joris Huizer [EMAIL PROTECTED] wrote: -static const MINIDUMP_DIRECTORY* get_mdmp_dir(const MINIDUMP_HEADER* hdr, int str_idx) +static const MINIDUMP_DIRECTORY* get_mdmp_dir(const MINIDUMP_HEADER* hdr,unsigned long int str_idx) Please keep white space unchanged. -while (ptr - (const unsigned char*)table len) +while ((unsigned long)(ptr - (const unsigned char*)table) len) -int i, length; +unsigned long int i, length; -while (file - (const char*)symbols sizeof(PDB_SYMBOLS) + symbols-module_size) +while ((unsigned long int)(file - (const char*)symbols) sizeof(PDB_SYMBOLS) + symbols-module_size) Your changes are inconsistent: sometimes you change 'int' to 'unsigned long int', sometimes to 'unsigned long'. Why not change 'int' simply to 'unsigned'? Seeing int extended to unsigned long like this makes me question whether the correct type wouldn't be size_t especially as it is compared to sizeof(...) -- Dmitry.
Re: It's that time again - time to start thinking about WineConf 2007!
On 2/5/07, Kai Blin [EMAIL PROTECTED] wrote: On Monday 05 February 2007 23:26, Jeremy White wrote: So we can ask, once again: when will 1.0 ship!?!?! [...] p.s. I think Wine will go 1.0 in the same year that is the year of Linux on the Desktop evil grin. Oooh, can we make Duke Nukem Forever runs a 1.0 release requirement? Then we could bundle Wine 1.0 with DNF. ;) That would change the critical path... how do you put that requirement on a Gantt chart? :) Cheers, Kai -- Kai Blin, kai Dot blin At gmail Dot com WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.
Re: It's that time again - time to start thinking about WineConf 2007!
On 2/5/07, John Smith [EMAIL PROTECTED] wrote: Yeah, I can no longer find them on MSDN. Laying the blame on MS all I can say is nice!. On 2/5/07, Tom Wickline [EMAIL PROTECTED] wrote: On 2/5/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: That would change the critical path... how do you put that requirement on a Gantt chart? Have a list of requirements that DNF depends on? :D Tom :)
Re: OpenGL in child windows
I have to ask, is there a reason each thread uses its own display connection (which are all different from gdi_display), and leaves the window data to only be available from the thread the window was created in? Besides the aforementioned problem with the GL context, I'd imagine it would be problematic even in current Wine.. for example, if something creates a window in one thread, passes it to another, then kills the thread it was originally created in while still using the window. In MS Windows, windows die if the creating thread exits for any reason.
winhlp32 implementation
Hi, all! I intend to implement winhlp32 utility looks like native one (font size changing, GID and CNT files support, etc...). Please, share your opinion, has this idea any sense, or *.hlp died long ago and only few persons need it? Inspired by bug http://bugs.winehq.org/show_bug.cgi?id=5926 Thanks.
Re: wine notepad.exe: Segmentation fault
Molle Bestefich wrote: Been running 0.9.15 for a while without problems. Since a week ago (or so) when I updated to HEAD, all I get from Wine is this: wine-git # notepad Segmentation fault Nuking ~/.wine doesn't help: Just to confirm, I get the same problem, segmentation fault when running 0.9.18. I don't routinely run notepad so I don't know when it broke. I'm running Suse9.3. Sorry I can't be of more help. Nick
Continuum patch
Hi, There is a patch in the AppDB entry for the game Continuum. (sorry I don't have AppDB playing nice with DNS here yet so no link.) What needs to be done to have this considered? Regards, -jan
Re: wine autorun utility
William Knop wrote: On Jun 29, 2006, at 8:59 PM, Vitaliy Margolen wrote: Thursday, June 29, 2006, 12:02:38 PM, William Knop wrote: Having the ability to autorun cds is most definitely not a misfeature. Of course it's not. It's the perfect means of distributing trojans, backdoors, rootkits and other very useful software an every CD, including DVDs and music CDs. If your assuming said media is compromised in such a way, requiring the user to manually run the executable will not protect him. The fact is, most media is not compromised. Software publishers ensure they are not. Most windows users can trust their software publishers. For those who cannot, they can simply click No when the dialog pops up. Or they can set it to never autorun. Or they could set it to virus-scan before autorunning. Everybody's happy. One thing I'm sure of: If regular guy Joe Schmo has to run executables from CDs manually, he will either say CDs don't work in wine or say that wine is a PITA to use. I totally agree, autorun is a must (ok put in all the checks) but wine is being put together for the average user isn't it, that means if they put in a CD they expect it to do something, and don't care whether it's 100% secure, (that's the job of the virus/spyware detection software). Now wouldn't that be something wine with AVG/Spybot/Adaware buildin. Although I heard today Microsoft has just done that, a security suite for windows of course you have to pay a subscription otherwise they can't guarantee windows will be secure, mmm ... However, seeing as you can't even install a multi CD game in wine without the game complaining about the fact it can't find CD 2, perhaps priorities need to be sorted. What's the point of autorun when the app throws a wobbly when it gets to CD2
WoW broken for wine 0.9.16 Nvidia cards
Hi, Just a quick question, WoW ( World of Warcraft ) was broken (for Nvidia cards) with there latest software update. Is anybody working on fixing Wow (with Nvidia Cards) ( working fine with ATI ). I just wondered if there was an opengl guru working on fixing this broken application ?. Or whether I should invest some time in learning more about the intricacies of wine and openg and NVidia !.. and fix it myself ( my background is C and assembler (not Intel, but RT11 Perkin Elmer) ? One of the users was asking about progress on fixing this app. I would like to respond back with some progress but suspect nobody is working on it :-( Regards Nick Law * Now where's that Learn opengl/wine/graphics in 21 days book ..*
Re: WoW broken for wine 0.9.16 Nvidia cards
Nick wrote: Hi, Just a quick question, WoW ( World of Warcraft ) was broken (for Nvidia cards) with there latest software update. Is anybody working on fixing Wow (with Nvidia Cards) ( working fine with ATI ). I just wondered if there was an opengl guru working on fixing this broken application ?. Or whether I should invest some time in learning more about the intricacies of wine and openg and NVidia !.. and fix it myself ( my background is C and assembler (not Intel, but RT11 Perkin Elmer) ? One of the users was asking about progress on fixing this app. I would like to respond back with some progress but suspect nobody is working on it :-( Regards Nick Law * Now where's that Learn opengl/wine/graphics in 21 days book ..* maybe I spoke too soon, a fix may have just become available ( we'll see after more tests ) :-)
Adobe Photoshop
When I´ve installed Abobe Photoshop CS2 it was closed without any error
Logs:
fixme:msi:MsiGetProductInfoA {236BB7C4-4419-42FD-0409-1E257A25E34D}
PackageCode 0x406fdbc8 0x406fdc38
fixme:msi:MsiGetProductInfoW L{236BB7C4-4419-42FD-0409-1E257A25E34D}
LPackageCode 0x403e3f38 0x406fdc38
err:dc:DCE_FreeWindowDCE [0x10026] GetDC() without ReleaseDC()!
fixme:msi:MsiInstallProductW LZ:\\soft\\win\\Photoshop CS2\\Photoshop
CS2\\Adobe(R) Photoshop(R) CS2\\Adobe Photoshop CS2.msi L SETUPEXEDIR=\Z:
\\soft\\win\\Photoshop CS2\\Photoshop CS2\\Adobe(R) Photoshop(R) CS2\
fixme:msi:ACTION_AppSearchReg AppSearch unimplemented for RegLocator (key path
LSOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\{786C5747-1033--B58E-0001})
fixme:msi:ACTION_AppSearchReg AppSearch unimplemented for RegLocator (key path
LSOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\{B74D4E10-1033---0001})
fixme:msi:ACTION_AppSearchReg AppSearch unimplemented for RegLocator (key path
LSOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\{ECA57BE9-1E11-4F5F-807D-950BD40DA776})
fixme:msi:ACTION_AppSearchReg AppSearch unimplemented for RegLocator (key path
LSOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\{E9787678-1033--8E67-0001})
fixme:msi:ACTION_AppSearchReg AppSearch unimplemented for RegLocator (key path
LSOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\[ProductCode])
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LFindRelatedProducts
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LValidateProductID
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LIsolateComponents
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LMigrateFeatureStates
fixme:msi:ACTION_PerformUIAction UNHANDLED MSI ACTION LInstallWelcome
fixme:msi:ACTION_PerformUIAction UNHANDLED MSI ACTION LSetupProgress
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LExecuteAction
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LRemoveExistingProducts
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LAllocateRegistrySpace
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LUnpublishComponents
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LMsiUnpublishAssemblies
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LUnpublishFeatures
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LStopServices
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LDeleteServices
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LUnregisterComPlus
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LSelfUnregModules
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LUnregisterTypeLibraries
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action LRemoveODBC
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LUnregisterFonts
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LRemoveRegistryValues
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LUnregisterClassInfo
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LUnregisterExtensionInfo
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LUnregisterProgIdInfo
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LUnregisterMIMEInfo
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LRemoveIniValues
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LRemoveShortcuts
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LRemoveEnvironmentStrings
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LRemoveDuplicateFiles
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action LRemoveFiles
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LRemoveFolders
fixme:msi:ACTION_CustomAction Rollback only action... rollbacks not supported
yet
--
Linux forever
pgp1SLuU4PLmj.pgp
Description: PGP signature
Adobe Photoshop
When I´ve installed Abobe Photoshop CS2 it was closed without any error
Logs:
fixme:msi:MsiGetProductInfoA {236BB7C4-4419-42FD-0409-1E257A25E34D}
PackageCode 0x406fdbc8 0x406fdc38
fixme:msi:MsiGetProductInfoW L{236BB7C4-4419-42FD-0409-1E257A25E34D}
LPackageCode 0x403e3f38 0x406fdc38
err:dc:DCE_FreeWindowDCE [0x10026] GetDC() without ReleaseDC()!
fixme:msi:MsiInstallProductW LZ:\\soft\\win\\Photoshop CS2\\Photoshop
CS2\\Adobe(R) Photoshop(R) CS2\\Adobe Photoshop CS2.msi L SETUPEXEDIR=\Z:
\\soft\\win\\Photoshop CS2\\Photoshop CS2\\Adobe(R) Photoshop(R) CS2\
fixme:msi:ACTION_AppSearchReg AppSearch unimplemented for RegLocator (key path
LSOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\{786C5747-1033--B58E-0001})
fixme:msi:ACTION_AppSearchReg AppSearch unimplemented for RegLocator (key path
LSOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\{B74D4E10-1033---0001})
fixme:msi:ACTION_AppSearchReg AppSearch unimplemented for RegLocator (key path
LSOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\{ECA57BE9-1E11-4F5F-807D-950BD40DA776})
fixme:msi:ACTION_AppSearchReg AppSearch unimplemented for RegLocator (key path
LSOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\{E9787678-1033--8E67-0001})
fixme:msi:ACTION_AppSearchReg AppSearch unimplemented for RegLocator (key path
LSOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\[ProductCode])
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LFindRelatedProducts
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LValidateProductID
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LIsolateComponents
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LMigrateFeatureStates
fixme:msi:ACTION_PerformUIAction UNHANDLED MSI ACTION LInstallWelcome
fixme:msi:ACTION_PerformUIAction UNHANDLED MSI ACTION LSetupProgress
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LExecuteAction
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LRemoveExistingProducts
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LAllocateRegistrySpace
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LUnpublishComponents
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LMsiUnpublishAssemblies
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LUnpublishFeatures
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LStopServices
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LDeleteServices
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LUnregisterComPlus
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LSelfUnregModules
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LUnregisterTypeLibraries
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action LRemoveODBC
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LUnregisterFonts
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LRemoveRegistryValues
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LUnregisterClassInfo
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LUnregisterExtensionInfo
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LUnregisterProgIdInfo
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LUnregisterMIMEInfo
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LRemoveIniValues
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LRemoveShortcuts
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LRemoveEnvironmentStrings
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LRemoveDuplicateFiles
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action LRemoveFiles
fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action
LRemoveFolders
fixme:msi:ACTION_CustomAction Rollback only action... rollbacks not supported
yet
err:msi:ACTION_ProcessExecSequence Execution halted due to error (1603)
--
Linux forever
pgplRLg5mYWhH.pgp
Description: PGP signature
Calc
I've ported M$ Calc using winelib. Is this program needed for wine? -- Linux forever pgpxYWp9IWSlR.pgp Description: PGP signature
Jumbo Mail - fireworks
Ciao, questa è una Jumbo Mail, che [EMAIL PROTECTED] ti ha inviato per condividere con te * video.zip (119256515 byte) e questo messaggio: Greetings and Happy New Year from the Sorrento Peninsular. I've just finished taking this film of the New Year firework celebrations still going on all around. I took this film from our terrace, I hope you enjoy it. The file is big, 113MBs, so I don't recommend downloading it if you don't have broadband. The download link will expire in 7 days. Happy New year to all, Ivan. Per scaricare questi files fai click sul seguente link: http://webmail.inwind.it/r.php?d=inwind.itwr=_unreg_4eh3943vws=3850nl9te=inwind.itc=3pGApbCikowzSQbPn6oV25TAD9NNag721146 Ti ricordiamo che questo link sarà valido fino al 08.01.2005 alle 07:23. Jumbo Mail è il servizio di Libero Mail che permette di condividere file di grandi dimensioni fino a 1GB, senza problemi di superamento dei limiti delle caselle e-mail. Scopri come è semplice e veloce inviare una Jumbo Mail! Fai click su http://liberomail.libero.it/jumbomail.phtml Lo staff di Libero
Stack blowout in _w95_dump_dke
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
_w95_dump_dke has code in it that processes sibling keys in the registry
recursively. This results in a stack blowout for large registries (in my case
in the Software\CLASSES key).
It's trivial to stop the stack blowing out by changing this not to be
recursive, but processing siblings recursively is such an unusual thing to do
that I suspect it must have been done for a reason. Attached is the way I've
fixed it, but this causes the keys to be output in the opposite order to
the way they are output with the CVS code.
Is there a reason this needs to be done in the order the CVS code is doing
it?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA8bbd2IoBoXB5Q0kRAoJEAJ9IbtBVxkly+8t8LPL2ZmD/RVwq6wCdHG2t
QxlBYcbU/VVdeXLx0QVgQlo=
=ZSKw
-END PGP SIGNATURE-
Index: misc/registry.c
===
RCS file: /home/wine/wine/misc/registry.c,v
retrieving revision 1.144
diff -u -r1.144 registry.c
--- misc/registry.c 14 Jun 2004 17:04:34 - 1.144
+++ misc/registry.c 10 Jul 2004 22:55:22 -
@@ -688,10 +688,24 @@
return TRUE;
}
+static int _w95_dump_one_dke(LPCSTR key_name,_w95creg *creg,_w95rgkn *rgkn,_w95dke *dke,FILE *f,int level);
+
+static int _w95_dump_dke(LPCSTR key_name,_w95creg *creg,_w95rgkn *rgkn,_w95dke *dke,FILE *f,int level)
+{
+while (1)
+{
+ if (!_w95_dump_one_dke(key_name, creg, rgkn, dke, f, level))
+ return FALSE;
+ if (dke-next == 0x)
+ return TRUE;
+ dke = (_w95dke*)((char*)rgkn+dke-next);
+}
+}
+
/**
* _w95_dump_dke [Internal]
*/
-static int _w95_dump_dke(LPCSTR key_name,_w95creg *creg,_w95rgkn *rgkn,_w95dke *dke,FILE *f,int level)
+static int _w95_dump_one_dke(LPCSTR key_name,_w95creg *creg,_w95rgkn *rgkn,_w95dke *dke,FILE *f,int level)
{
_w95dkh * dkh;
LPSTR new_key_name = NULL;
@@ -720,6 +734,7 @@
memcpy( new_key_name + len, dkh-name, dkh-keynamelen );
new_key_name[len + dkh-keynamelen] = 0;
+#if 0
/* walk sibling keys */
if (dke-next != 0x ) {
if (!_w95_dump_dke(key_name, creg, rgkn, (_w95dke*)((char*)rgkn+dke-next),f,level)) {
@@ -727,6 +742,7 @@
return FALSE;
}
}
+#endif
/* write the key path (something like [Software\\Microsoft\\..]) only if:
1) key has some values
probs w/ make and make install
cd `dirname dlls/__install-lib__` make install-lib rm -f libdxerr8.a ln -s dxerr8/libdxerr8.a libdxerr8.a rm -f libdxerr9.a ln -s dxerr9/libdxerr9.a libdxerr9.a rm -f libdxguid.a ln -s dxguid/libdxguid.a libdxguid.a rm -f libuuid.a ln -s uuid/libuuid.a libuuid.a cd `dirname advapi32/__install__` make install ../../tools/mkinstalldirs -m 755 /usr/local/lib/wine /usr/bin/install -c advapi32.dll.so /usr/local/lib/wine/advapi32.dll.so cd `dirname amstream/__install__` make install ../../tools/mkinstalldirs -m 755 /usr/local/lib/wine /usr/bin/install -c amstream.dll.so /usr/local/lib/wine/amstream.dll.so cd `dirname avicap32/__install__` make install ../../tools/mkinstalldirs -m 755 /usr/local/lib/wine /usr/bin/install -c avicap32.dll.so /usr/local/lib/wine/avicap32.dll.so cd `dirname avifil32/__install__` make install ../../tools/mkinstalldirs -m 755 /usr/local/lib/wine /usr/bin/install -c avifil32.dll.so /usr/local/lib/wine/avifil32.dll.so make: don't know how to make _install_/avifile.dll.so. Stop *** Error code 2 Stop in /usr/home/vertigo/wine-20040505/dlls. *** Error code 1 Stop in /usr/home/vertigo/wine-20040505. - this is the 2nd stop that occured... during make, towards the end, it couldn't open /home/vertigo/wine-20040505/programs/winetest/advapi32_test.exe... i checked in that dir, and the files were still *_test.exe.so. seemingly, the previous step that copied these files here also stripped them, but did not change their names (remove the .so). i did this manually, and retried make, which finished. the above stop happens almost immediatly from make install. this is on freebsd4.9, and this is basically the same that has always happened for me with all versions of wine i've tried. can someone either help me get this to work, or atleast stop the spreading of the lie that wine works on bsd (have never heard someone say that they had it running on bsd). i've been kicking this horse for months, is it dead? -shaun
Re: Fix toolbar get style
[EMAIL PROTECTED] 04/29/04 22:59 PM When a toolbar receives a TB_GETSTYLE message with wParam=0, the application expects to get the toolbar style and not the first button style. This patch fixes eMule 0.42e, now the toolbar is visible. ChangeLog * Fix TB_GETSTYLE to return the style of the toolbar when wParam is 0 Good catch, but I think the original author of the TB_GETSTYLE code got a bit confused. I think it should always return the style of the toolbar (according to MSDN) and should print an ERR or FIXME if wParam != 0, as it is reserved. Could you resubmit with that change? Rob Hello I will perform some tests under win xp to check this behaviour because even if the author may have been confused. I think it is worth testing that. I will then send another patch. a+ Max Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34/mn) ; tél : 08 92 68 13 50 (0,34/mn)
Wine bug with MFC/C++?
It appears that Wine cannot use tmpfs... so far my testing only works using swap :o( which I do have enabled at home and it crashes. At work I have a 500MB swap space and the same exact program does not crash there. It's not convenient for me to run swap at home, so does anyone know a fix for this? The code seems to require approx 500MB free memory. Since I only have 500MB RAM, I setup tmpfs on /tmp. But wine doesn't seem to use any of it. Shaun
Can't load/print with a 16 bit app, wine 20040408
I can't load a 16 bit app...The problem is correlated to the printing system: i get an run-time Error 482: Printer Error. These are the logs: Log WINEDEBUG=warn+all . warn:dosfs:DOSFS_FindUnixName Ltest\\WINEPS16.dll not found in '/home/franzo/. wine/dosdevices/e:' warn:file:CreateFileW Unable to get full filename from Le:\\test\\WINEPS16.dll (GLE 2) warn:dosfs:DOSFS_FindUnixName LWINEPS16.dll not found in '/home/franzo/.wine/d osdevices/f:' warn:file:CreateFileW Unable to get full filename from Lf:\\WINEPS16.dll (GLE 2) warn:module:load_dll Failed to load module LWINEPS16; status=c135 err:dc:CreateDCW no driver found for LWINEPS16 Log WINEDEBUG=psdrv . trace:psdrv:PSDRV_FindPrinterInfo No 'Paper Size' for printer 'HP' trace:psdrv:PSDRV_ExtDeviceMode (Driver=(null), hwnd=(nil), devOut=(nil), Device ='HP', Port='LPT1:', devIn=(nil), Profile='(null)', Mode=) trace:psdrv:PSDRV_FindPrinterInfo 'HP' trace:psdrv:PSDRV_ExtDeviceMode (Driver=(null), hwnd=(nil), devOut=0x41b6ce42, D evice='HP', Port='LPT1:', devIn=(nil), Profile='(null)', Mode=0002) err:dc:CreateDCW no driver found for LWINEPS16 In /usr/local/lib/wine/ i created this situation: -rwxr-xr-x1 root root 1851820 Apr 12 15:47 wineps.dll.so lrwxrwxrwx1 root root 13 Apr 12 19:52 wineps.drv.so - wineps.dll.so lrwxrwxrwx1 root root 13 Apr 12 17:46 wineps16.dll.so - wineps.dll.so lrwxrwxrwx1 root root 13 Apr 12 15:47 wineps16.drv.so - wineps.dll.so My configuration: In the registry: [System\\CurrentControlSet\\Control\\Print\\Environments\\Windows 4.0\\Drivers\\PS Driver] 1081792881 Configuration File=wineps16 Data File=datafile? Datatype=RAW Dependent Files=str(7): Driver=wineps16 Help File=helpfile? Monitor=monitor name? Version=dword:0400 [System\\CurrentControlSet\\Control\\Print\\Printers\\HP] 1081784615 Attributes=dword: Default Devmode=hex:48,50,00,65,20,50,6f,73,74,53,63,72,69,70,74,20,44,72,69,\ 76,65,72,00,00,00,00,00,00,00,00,00,00,0a,03,01,00,9c,00,08,00,13,6b,00,00,\ 01,00,01,00,ea,0a,6f,08,64,00,01,00,07,00,00,00,02,00,01,00,00,00,03,00,00,\ 00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\ 00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\ 00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\ 00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00 Name=HP Port=LPT1: Print Processor=WinPrint Printer Driver=PS Driver Priority=dword: Start Time=dword: Status=dword: Until Time=dword: [System\\CurrentControlSet\\Control\\Print\\Printers\\HP\\PrinterDriverData] 1081784392 PPD File=/usr/local/share/wine/generic.ppd [System\\CurrentControlSet\\Control\\Print\\Printers\\HP\\PrinterDriverData\\FontSubTable] 1081784392 Arial=Helvetica Courier New=Courier Helv=Helvetica Times New Roman=Times In win.ini: [windows] device=HP,WINEPS16,LPT1: [devices] HP=WINEPS16,LPT1: [PrinterPorts] HP=WINEPS16,LPT1:,15,45 In config [spooler] FILE: = tmp.ps LPT1: = |lpr LPT2: = |gs -sDEVICE=bj200 -sOutputFile=/tmp/fred -q - LPT3: = /dev/lp3 Wine version is the last: 20040408. I can provide more information if needed. Thanks! Francesco Pretto P.S.: a last time WINEDEBUG=+all log (using gentoo ebuild wine, differently than the ones before, taked using wine source unmodified), this identify the last activity before the loading of the error pop-up: trace:psdrv:PSDRV_ParsePPD INPUTSLOTS 'Tray3' Name 'Tray 3' (259) Invocation '/ManualFeed false /MediaPosition 1setpagedevice' trace:psdrv:PSDRV_ParsePPD INPUTSLOTS 'Manual' Name 'Manual Feed' (260) Invocation '/ManualFeed true /Media Position 3setpagedevice' trace:reg:RegQueryValueExA (0x14c,Paper Size,(nil),(nil),0x41584b84,0x41584b9c=4) trace:reg:RegQueryInfoKeyW (0x14c,(nil),0,(nil),(nil),(nil),0x41584adc,0x41584ae0,0x41584ae4,(nil),(nil)) trace:reg:RegEnumValueW (0x14c,0,0x415b7ad8,0x41584ad4,(nil),(nil),0x415b7b00,0x41584ad8) trace:reg:RegEnumValueW (0x14c,1,0x415b7ad8,0x41584ad4,(nil),(nil),0x415b7b00,0x41584ad8) trace:reg:RegEnumValueW (0x14c,2,0x415b7ad8,0x41584ad4,(nil),(nil),0x415b7b00,0x41584ad8) trace:reg:RegEnumValueW (0x14c,3,0x415b7ad8,0x41584ad4,(nil),(nil),0x415b7b00,0x41584ad8) trace:reg:RegQueryInfoKeyW (0x14c,(nil),0,(nil),(nil),(nil),0x41584adc,0x41584ae0,0x41584ae4,(nil),(nil)) trace:reg:RegEnumValueW (0x14c,0,0x415b7ad8,0x41584ad4,(nil),(nil),0x415b7b00,0x41584ad8) trace:reg:RegEnumValueW (0x14c,1,0x415b7ad8,0x41584ad4,(nil),(nil),0x415b7b00,0x41584ad8) trace:reg:RegEnumValueW (0x14c,2,0x415b7ad8,0x41584ad4,(nil),(nil),0x415b7b00,0x41584ad8) trace:reg:RegEnumValueW (0x14c,3,0x415b7ad8,0x41584ad4,(nil),(nil),0x415b7b00,0x41584ad8) trace:reg:RegEnumValueW (0x14c,0,0x415b7ad8,0x41584ad4,(nil),0x41584ad0,0x415b7b00,0x41584ad8) trace:reg:RegEnumValueW (0x14c,1,0x415b7ad8,0x41584ad4,(nil),0x41584ad0,0x415b7b00,0x41584ad8) trace:reg:RegEnumValueW
Wine-20040408 Results (so far) for MFC App
Now it works very nicely... I spent Easter debugging most of the crashes I was having due to the GUI menus (even in winders), from variables not freed, etc and now I cannot get it to crash...yet. I'm using MSVC6 for all the development under VMware 4.5.1. The GUI code is completely MFC with 16 color bitmaps for resources and all underlying solver code, etc is C++/C. This code puts a P4 laptop and memory under moderate load when run... so it's a good test. Below are the ONLY messages I get from Wine-20040408 when I run it from the command-line; wine sokoban.exe (then it opens the GUI) and then do many things with it; data file I/O, parsing many text files, GUI menus, clicks, etc. As you can see below the help file opens fine, but does not display text properly. I used Shalom Help (free) for winders (it works fine on winxp as I've tested). Any ideas why these messages appear and how to prevent them? I can send app screenshots and provide code snippets. Below these is my entire wine config. fixme:dc:LockWindowUpdate (0x10029), partial stub! fixme:dc:LockWindowUpdate ((nil)), partial stub! fixme:dc:LockWindowUpdate (0x10029), partial stub! fixme:dc:LockWindowUpdate ((nil)), partial stub! fixme:dc:LockWindowUpdate (0x10029), partial stub! fixme:dc:LockWindowUpdate ((nil)), partial stub! fixme:winhelp:HLPFILE_UncompressRLE Null length 2, next is 0 fixme:winhelp:HLPFILE_UncompressRLE Null length 2, next is 140 fixme:winhelp:HLPFILE_UncompressRLE Buffer X-flow: d(108628) instead of d(108640) fixme:dc:LockWindowUpdate (0x10029), partial stub! fixme:dc:LockWindowUpdate ((nil)), partial stub! fixme:dc:LockWindowUpdate (0x10029), partial stub! fixme:dc:LockWindowUpdate ((nil)), partial stub! fixme:dc:LockWindowUpdate (0x10029), partial stub! fixme:dc:LockWindowUpdate ((nil)), partial stub! fixme:dc:LockWindowUpdate (0x10029), partial stub! fixme:dc:LockWindowUpdate ((nil)), partial stub! ~/.wine/config: [Drive C] Path = /home/greensh/.wine/c Type = hd [Drive D] Path = /mnt/cdrw Type = cdrom ; make sure that device is correct and has proper permissions ! Device = /dev/scd0 [Drive E] Path = /tmp Type = hd [Drive F] Path = /home/greensh Type = hd [Drive Z] Path = / Type = hd [wine] Windows = c:\\windows System = c:\\windows\\system Temp = e:\\ Path = c:\\windows;c:\\windows\\system;e:\\;e:\\test;f:\\ Profile = c:\\windows\\Profiles\\Administrator GraphicsDriver = x11drv ;ShowDirSymlinks = 1 ;ShowDotFiles = 1 ShellLinker = wineshelllink # [wineconf] [Version] ; Windows version to imitate (win95,win98,winme,nt351,nt40,win2k,winxp, win2k3,win20,win30,win31) ;Windows = win98 ; DOS version to imitate ;DOS = 6.22 ; Be careful here, wrong DllOverrides settings have the potential ; to pretty much kill your setup. [DllOverrides] ; some dlls you may want to change oleaut32 = builtin, native ole32= builtin, native comdlg32 = builtin, native shell32 = builtin, native shfolder = builtin, native shlwapi = builtin, native shdocvw = builtin, native advapi32 = builtin, native msvcrt = native, builtin mciavi.drv = native, builtin mcianim.drv = native, builtin msi = native, builtin ; you can specify applications too ; this one will apply for all notepad.exe ;*notepad.exe = native, builtin ; this one will apply only for a particular file ;C:\\windows\\regedit.exe = native, builtin ; default for all other dlls * = builtin, native [x11drv] ; Number of colors to allocate from the system palette AllocSystemColors = 100 ; Use a private color map PrivateColorMap = N ; Favor correctness over speed in some graphics operations PerfectGraphics = N ; Color depth to use on multi-depth screens ;;ScreenDepth = 16 ; Allow the window manager to manage created windows Managed = Y ; Use a desktop window of 640x480 for Wine ;Desktop = 640x480 ; Use XFree86 DGA extension if present ; (make sure /dev/mem is accessible by you !) UseDGA = Y ; Use XVidMode extension if present UseXVidMode = Y ; Use XRandR extension if present UseXRandR = Y ; Use the take focus protocol UseTakeFocus = Y ; Enable DirectX mouse grab DXGrab = N ; Create the desktop window with a double-buffered visual ; (useful to play OpenGL games) DesktopDoubleBuffered = N ; Run in synchronous mode (useful for debugging X11 problems) ;;Synchronous = Y ; ; Use the Render extension to render client side fonts (default Y) ;;ClientSideWithRender = Y ; Fallback on X core requests to render client side fonts (default Y) ;;ClientSideWithCore = Y ; Set both of the previous two to N in order to force X11 server side fonts ; ; Anti-alias fonts if using the Render extension (default Y) ;;ClientSideAntiAliasWithRender = Y ; Anti-alias fonts if using core requests fallback (default Y) ;;ClientSideAntiAliasWithCore = Y ; [fonts] ;Read the Fonts topic in the Wine User Guide before adding aliases ;See a couple of examples for russian users below Resolution = 96 Default = -adobe-helvetica- DefaultFixed = fixed DefaultSerif =
Wine-20040408 Compile Bug
Had a problem compiling this latest version on my Dell Latitude laptop...
here is the exact make error;
gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include
-D__WINESRC__ -DBINDIR=\/usr/local/bin\ -D_REENTRANT -fPIC -Wall -pipe
-mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith
-g -O2 -o keyboard.o keyboard.c
keyboard.c: In function `X11DRV_ToUnicodeEx':
keyboard.c:2128: error: `XK_EuroSign' undeclared (first use in this
function)
keyboard.c:2128: error: (Each undeclared identifier is reported only once
keyboard.c:2128: error: for each function it appears in.)
make[2]: *** [keyboard.o] Error 1
make[2]: Leaving directory `/data/0MD2/wine-20040408/dlls/x11drv'
make[1]: *** [x11drv] Error 2
make[1]: Leaving directory `/data/0MD2/wine-20040408/dlls'
make: *** [dlls] Error 2
Compilation failed, aborting install.
Looks like it's wrong in detecting the keyboard. A fix was to comment out
the if statement entirely;
if (keysym == XK_EuroSign)
{
bufW[0] = 0x20AC;
ret = 1;
goto found;
}
---
/*
if (keysym == XK_EuroSign)
{
bufW[0] = 0x20AC;
ret = 1;
goto found;
}
/*
Then it compiled/installed fine.
Shaun
Re: Developer's path to Windows/*NIX multi-platform?
integration. Ideally, we will have a GTK theme and a QT theme that just calls the respective toolkit's theming code, so a Wine app will look native both in GNOME and in KDE. I 100% agree that native integration is paramount, and this is why we will have it. This sounds very good. Maybe someday. Since you've mentioned the toolkits, a small comment on that. Of the two only QT is a serious option for cross-platform development. It's a good option, but it's not perfect because your application will not be native in GNOME, Well not to start a KDE vs Gnome debate, but Gnome is way behind KDE development... it doesn't even support Superkaramba (last I checked). Gnome users typically do not prefer KDE or Qt, and part of that stems from that KDE was developed using Qt and it's integration is woven throughout. you will not be using the native toolkits in Windows, you have to pay a lot of licensing fees, etc. You only pay licensing if your Qt app is commercial. The free version is perfect for opensource (ie GPL software) hence why it's included in almost all linux distros and you can D/L the same version for winders. Maybe wxWindows is a better option... It requires too many code changes (at least in Python) for easy cross-compiling. In Qt you simply generate a .pro file for the platform. Shaun -- Dimi.
MFC app compile problems with AFX
Since I was told the winlib docs are out of date, I'll try posting this problem. winemaker --interactive seems to have worked and converted the 'winders' source .cpp and .h files and made the backups fine. It only created one file; Makefile When I type 'make' it produced a bunch of afx errors needing only five afx*. h files, so I copied these over from the VS6 directory, ran 'make clean', but hen it needed a ton more, so I copied them all afx*.h and afx*.inl. Then 'make' gets all the way down to the first errors; /usr/local/include/wine/windows/rpcndr.h:383: error: non-local function ` anonymous struct* NDRSContextUnmarshall2(void*, void*, long unsigned int, void*, long unsigned int)' uses anonymous type In file included from afxdtctl.h:19, from StdAfx.h:18, from ArbreNiv.cpp:2: afxdisp.h:75: warning: malformed '#pragma pack(push[, id], n)' - ignored afxdisp.h:1182: error: friend declaration requires class-key, i.e. `friend struct COleDateTimeSpan' afxdisp.h:1259: error: friend declaration requires class-key, i.e. `friend class COleDateTime' afxdisp.h:1408: warning: #pragma pack (pop) encountered without matching #pragma pack (push, n) In file included from afxdisp.h:1413, from afxdtctl.h:19, from StdAfx.h:18, from ArbreNiv.cpp:2: afxole.inl: In constructor `COleVariant::COleVariant(const CHAR*)': afxole.inl:97: error: `vt' undeclared (first use this function) afxole.inl:97: error: (Each undeclared identifier is reported only once for each function it appears in.) afxole.inl: In constructor `COleVariant::COleVariant(unsigned char)': afxole.inl:101: error: `bVal' undeclared (first use this function) afxole.inl: In constructor `COleVariant::COleVariant(const COleCurrency)': afxole.inl:103: error: `cyVal' undeclared (first use this function) afxole.inl: In constructor `COleVariant::COleVariant(float)': afxole.inl:105: error: `fltVal' undeclared (first use this function) afxole.inl: In constructor `COleVariant::COleVariant(double)': afxole.inl:107: error: `dblVal' undeclared (first use this function) afxole.inl: In constructor `COleVariant::COleVariant(const COleDateTime)': afxole.inl:109: error: `date' undeclared (first use this function) afxole.inl: In member function `DWORD COleSafeArray::GetDim()': afxole.inl:283: error: `parray' undeclared (first use this function) Can anyone help? Any ideas for me to try? I can run the winders executable with wine, but it's very buggy and will crash easily, so I wanted to use winelib. Shaun
Re: Developer's path to Windows/*NIX multi-platform?
At work we write A LOT of 3D graphics code that has requirements to run on winders/linux/macintosh. Qt has definitely proved the way to go (5 years now) with only minor changes required and then it worked on ALL platforms. Java and Python were too slow and required too many code changes for each platform, whereas Qt worked with our existing C/C++ code nicely. BTW, a real good book that's out now is C++ GUI Programming with Qt 3 by Jasmin Blanchette and Mark Summerfield. It starts very basic from Hello World. It's worth the $30. I'd have to say, so far from what I've seen Wine still has a long way to go before it's ready for production, and reliable use... it's getting there but just not there yet. It's great for porting apps, but too poorly documented for actual development. I mean this forum is about it and you're lucky if you can get answers. But thanks to all the helpful people here, maybe it will grow. Shaun On Thu, 1 Apr 2004 17:39:14 -0500 (EST), Dimitrie O. Paun [EMAIL PROTECTED] wrote : You ask: I am willing to re-write my best Windows software from scratch, but I insist that the result is native or almost on Linux so there are not any weird GUI glitches. Do you think Wine is the way to go for me, or am I better off writing individual versions and keeping the Windows software native and then producing QT or GTK versions for *NIX? I'm at a cross-roads here, since I'll be dedicating years of work in whatever direction I take. IMO Wine is the perfect tool for you. We know, it's not perfect. But the best use of your time (and the most efficient) would be to: 1. Fix any problems in your apps (like reliance on strange Windows corner cases, use of very obscure features) 2. Help out fix Wine so that your apps run properly. This will not only help us a lot, but it will help you make good use of your time, and it will allow you to do cross platform development (even for Windows) from your Linux box. Please direct questions to [EMAIL PROTECTED], where people can help you out. -- Dimi.
Winelib Test Drive problem
Hi, I'm starting to use the latest winelib (wine-20040309 release) to try eventually compiling an windows MFC app I wrote. Before attempting this however, I'm following all directions in the winelib user guide, but the Test Drive fails and so it tells me to post to this mailing list. I named my directory winemine2 and copied the source files to this. Then ran winemaker, but it did NOT create a configure script. So I tried make, but it fails with; winebuild -o winemine2.exe.dbg.c --debug -C. dialog.c main.c winegcc -c -mno-cygwin -I. -o winemine2.exe.dbg.o winemine2.exe.dbg.c winegcc -c -mno-cygwin -I. -o dialog.o dialog.c winegcc -c -mno-cygwin -I. -o main.o main.c wrc -I. -foEn.res En.rc En.rc:23:22: Error: syntax error make: *** [En.res] Error 1 I guess if this doesn't work, nothing else might not.
Wineps.drv not a fully windows compliant printer driver?
1 week ago, i posted a msg (subject: 16bit app calls wineps.drv, but wine has wineps.dll) in the ml reporting a run-time error 482: Printer Error with a 16 bit app. Weel, that report is not rappresentative of the problem, it seems more complicated than i tought. At MSDN, i found: Printer error (Error 482) There is some problem that prevents printing. This error has the following causes and solutions: * You don't have a printer installed from the Windows Control Panel. Open the Control Panel, double-click the Printers icon, and choose Add Printer to install a printer. * Your printer isn't online. Physically switch the printer online. * Your printer is jammed or out of paper. Physically correct the problem. * You tried to print a form to a printer that can accept only text. Switch to an installed printer that can print graphics. In windows, all is OK with all type of printer. After 2 weeks of attempts, i understood i'm unable to find the origin of the problem and a possible resolution. So, hoping you can help me, i did a snapshot of my wine configuration including the non-working app and the natives dll needed to run it (no problem of dependences: they should be ok). The snapshot is not very big (~7mb), and it's a simple copy of .wine dir with a testapp script (cd ..., WINEDLLOVERRIDES=... wine app.exe) to immediately run the fucking/non-working app. So, a backup of your .wine dir is needed. Weel, there's also the problem of trust: a new non-root user is OK =) My interest in this stupid business app is only to convert my father to linux, but if you can help me, a donation to the wine project is CERTAIN! Here the easy instruction: NB: Use a new non-root user for trust, or at least # mv .wine winebak 1 - Download to your home http://digilander.libero.it/ceztko/testapp.tar.gz 3 - # tar xvzf testapp.tar.gz 4 - # ./testapp The error message i get is this: run-time error '482': Printer Error ( http://digilander.libero.it/ceztko/snapshot-err.png ) Instead, it should be like this http://digilander.libero.it/ceztko/screenshot-ok.png . I'm unable to understand if is a my mis-configuration or a bug in wine (and maybe this snapshot is not weel configured anyway). But, after 2 weeks of attempts without results, using different printer configurations FROM SCRATCH (cups, file, original windows printer driver, ..), i'm almost sure this is a bug, or a sort of... Thanks for your help!
Re: 16bit app calls wineps.drv, but wine has wineps.dll (missing alias?)
Alexandre Julliard [EMAIL PROTECTED] writes: Ok, but the cups autoconfiguration set wineps in win.ini, and it seems impossible to ovveride this settings... Maybe a synlinks wineps.drv.so -- wineps16.drv.so in /etc/lib/wine/lib/wine can help? No, you can't really fix that with symlinks, the dll names are built into the dlls themselves. If the win.ini entry is set by the cups code then it should be fairly easy to change it to store wineps16 instead. This may break something else, but I guess we'll see... -- Alexandre Julliard [EMAIL PROTECTED] As i touhgt a symlinks is not enough... No chance for alias? Isn't there a mechanism to make wine to use different dll if required to do so? Anyway, i'll be very happy If you'll change cups code a bit: is very frustrating this impossibility of edit the autodetect configuration, and the fact it removes any other printer configured in the [windows] section in win.ini (is it a bug?)! ...forgive me if i forwarded the previous mail only to you. I was at university and i did a mistake with the web-mail. Francesco Pretto [EMAIL PROTECTED]
Re: Running Wine under MS SFU under Wine ... ?
My real point is - SFU is yet another set of windows programs we can use to test wine, may as well grab a copy while they're 'free'. SFU3 contains also the POSIX personality for NT/2k. Does Wine run native NT apps yet?
