Re: ntdll/kernel32: #36
Eric Pouech [EMAIL PROTECTED] wrote: but which charset is used when getting the filename (from a directory enum for example). The charset of the mount option, the default charset of the kernel, or the charset of default locale ? Look at the following line, borrowed from my /etc/fstab: /dev/hda1 /mnt/dosc vfat auto,uid=500,gid=500,ro,noexec,codepage=866,iocharset=koi8-r 0 0 It means that the kernel should use cp 866 for short file names on that drive and translate file names to the local koi8-r encoding for file APIs. It's up to user to make correct assumptions and specify valid mount options. I.e. it's quite a fair play to assume that the user has correctly configured the system to work with his/her locale. -- Dmitry.
Force native MSI and MSHTML
On Wed, 2003-09-24 at 16:53, Matthew Davison wrote:
I have recently noticed the large number of Stub DLLs being Added to
wine with minimal functionality, for example Msi, MSHTML (they don't
work for me in any case). These additions have not for the most part
been accompanied with a new native, builtin entry in samples/config.
Annoying isn't it? The config file is not the right place to do this
anyway, better to have it hardcoded into loader/loadorder.c IMHO,
otherwise users will always forget to update their config.
Tracking this stuff in the source probably makes the most sense anyway.
I'm not fully sure of the semantics of this structure. I have a feeling
specifying LOADORDER_DLL here (native) will cause wine to fail with the
standard dll not found error if native isn't present rather than fall
back. Arguably for these two DLLs that's actually what we want - at
least the dll not found error is understandable by most users as
opposed to some random stub crash/hang/whatever caused by missing
functionality.
ChangeLog
Force native MSI and MSHTML in the load order
Index: loader/loadorder.c
===
RCS file: /home/wine/wine/loader/loadorder.c,v
retrieving revision 1.66
diff -u -r1.66 loadorder.c
--- loader/loadorder.c 5 Sep 2003 23:15:43 - 1.66
+++ loader/loadorder.c 25 Sep 2003 10:23:47 -
@@ -67,6 +67,8 @@
{ keyboard, { LOADORDER_BI, 0, 0 } },
{ krnl386.exe, { LOADORDER_BI, 0, 0 } },
{ mmsystem, { LOADORDER_BI, 0, 0 } },
+{ mshhtml, { LOADORDER_DLL,0, 0 } },
+{ msi, { LOADORDER_DLL,0, 0 } },
{ mouse,{ LOADORDER_BI, 0, 0 } },
{ ntdll,{ LOADORDER_BI, 0, 0 } },
{ odbc32, { LOADORDER_BI, 0, 0 } },
Keyboard problems
Hi When running eg. notepad with latest wine cvs, wine doesn't correctly find out my Finnish keyboard. Instead it is using Latin American keyboard because it's getting the highest score when X11DRV_KEYBOARD_DetectLayout is choosing keymap. I've looked in wine/dlls/keyboard.c and noticed that in Latin American keymap there are not many Alt-Gr characters. Every Alt-Gr charater produces an error and lowers the score of even right keymap and that is why wrong keymap is selected. So it seems like there is a problem detecting the keys right. Any thoughts? I've attached a debuglog of wine -debugmsg +keyboard,+key notepad My system is RH 9 and /etc/sysconfig/i18n says: LANG=en_US.iso885915 SUPPORTED=en_US.iso885915:en_US:en SYSFONT=latarcyrheb-sun16 keyblog.tar.gz Description: log
Re: Keyboard problems
Salmela [EMAIL PROTECTED] wrote: When running eg. notepad with latest wine cvs, wine doesn't correctly find out my Finnish keyboard. Instead it is using Latin American keyboard because it's getting the highest score when X11DRV_KEYBOARD_DetectLayout is choosing keymap. Does it really prevents your keyboard to work properly, or it's just that annoying FIXME message which bothers you? P.S. I assume that you are running either latest Wine release or CVS version. -- Dmitry.
How to run program without wine ?
Can i compile my program to executable file that can be run without wine ?
Re: How to run program without wine ?
On Thu, 25 Sep 2003, flyker wrote: Can i compile my program to executable file that can be run without wine ? No. -- Dimi.
Re: Build log from tests built with MSVC 7
Alexandre Julliard [EMAIL PROTECTED] wrote: Steven Edwards [EMAIL PROTECTED] writes: OK so we know the DPA_Create problems are not just in Mingw. Can we do something about this now? You probably need a more recent comctl32.lib. I definitely have these functions in mine. Which is probably from the latest official SDK (I could find February 2003). The original compile was with MSVC 7 (aka Visual C .NET) if I remember correctly and considering that we talk about functions introduced in Win95 (although undocumented at that time) I find it a serious problem that the import libraries from MSVC 7 still do not seem to provide these. I for myself still use VC 6 although I recently downloaded the SDK and installed it, to be able to compile and link some Wine source code. Still can't figure out why I should need .NET ;-) Rolf Kalbermatter
Re: How to run program without wine ?
On Thu, Sep 25, 2003 at 07:24:57PM +0400, flyker wrote: Can i compile my program to executable file that can be run without wine ? No. Hmmm Than i don't see any reason to compile program using winelib. What is the difference between wine program.exe That will run only on i386 and compatibles. and wine program.exe.so This can be compiled and run on PPC, Alpha, S390 whatever ? I think the goal of winelib is to make independent executable. And i don't see any other goal. It's a first step in porting your app to Linux. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart pgp0.pgp Description: PGP signature
Re: ntdll/kernel32: #36
Pouech Eric DMI AEI CAEN [EMAIL PROTECTED] writes: My first (dumb) reaction was if it's in there, it means we need it for some cases. But, I don't want to support this codepage option for no real need, so if no one objects, we could remove it. It's here because we didn't have CP_UNIXCP support then. We could definitely remove it. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Misc bugs found by using valgrind
[EMAIL PROTECTED] (Michael Günnewig) writes: It's a point, so here is the new patch. I don't think we need to check string sizes against MAXINT, that's just a waste of time. Also please don't add memsets to fix valgrind complaints, the bugs need to be fixed properly not just hidden by clearing everything. -- Alexandre Julliard [EMAIL PROTECTED]
Re: shlwapi 405/406
Jon Griffiths [EMAIL PROTECTED] writes: Please don't do that. Internal functions should use standard C calling conventions. We don't care about two bytes of extra code. Can do. Is there any reason why not though? After all, the entire Win32 api does it... Precisely, this way it's obvious which functions are meant to be used by Win32 apps and which are internal to Wine. -- Alexandre Julliard [EMAIL PROTECTED]
Upgrade management
On Thu, 2003-09-25 at 18:21, Alexandre Julliard wrote: No, that hardcoded list is only for dlls that we know will never work as native. We don't want to have to change it every week depending on the progress of some other dll. There are plenty of things that you may have to add in the registry or config when upgrading Wine, that's just one of them; we'll need a general mechanism to do that anyway. OK, so the best way to tackle this then is probably once we moved the config entirely into the registry for packages to remerge the default registry on install/upgrade? Of course people who do make install from CVS are a bit stuck - maybe we can use Makefile rules to do it ?
[Fwd: Wine starts faster without /etc/printcap ...]
I hope this won't be that much OT here ... ---BeginMessage--- Hi all, I've noticed that renaming the /etc/printcap file, (/etc/printcrap may be an option ;) ) so that wine can't find it, makes wine start remarkablly faster than it would with the printcap. Now I'm asking, is there any option in the wine config to disable this printcap parsing thing ? I've tried setting printer = no, and removing printer related stuff from the wine config too with no result. Should I try anything else 'fore I start digging into sources ? Thanks Cheers. ---End Message---
Re: How to run program without wine ?
On Fri, 26 Sep 2003, Shachar Shemesh wrote: A Win32 program needs Win32 environment. Be that a registry, the Win32 APIs, or a forest directory structure and My Documents and Program Files. While you may theoretically get the APIs by statically linking the DLLs into the executable, all of the rest are only available if Wine is installed on the machine. As such, I don't think a Winelib app will be able to ever live without a wine environment. Of course, you will need wine installed. I wasn't clear in my response, but I thought he refered to the fact that now we have to start Winelib apps as: wine myapp.so Ideally, we can just link it to a real executable, without all the wrappers that we have now. Not that it would change much, you will still need the DLLs, etc. but it would be a bit cleaner. Meanwhile, if you use winegcc you are isolated from all these ugly details... -- Dimi.
Re: How to run program without wine ?
On Thu, 2003-09-25 at 23:16, Dimitrie O. Paun wrote: On Fri, 26 Sep 2003, Shachar Shemesh wrote: A Win32 program needs Win32 environment. Be that a registry, the Win32 APIs, or a forest directory structure and My Documents and Program Files. While you may theoretically get the APIs by statically linking the DLLs into the executable, all of the rest are only available if Wine is installed on the machine. As such, I don't think a Winelib app will be able to ever live without a wine environment. I don't agree with this - there are shades of Win32ness. An app that is slowly being ported to be native may well need to be done in chunks. You can remove the registry requirements, teach it the FHS and so on, while still using HeapAlloc. It's true there's little point just recompiling the app and saying that's it, but obviously the value of winelib is not in allowing us to use ld.so instead of wine, it's in the ability to take a port slowly but surely, maybe never being completed but along the way getting sufficient integration for it not to matter. Of course, you will need wine installed. I wasn't clear in my response, but I thought he refered to the fact that now we have to start Winelib apps as: wine myapp.so Ideally, we can just link it to a real executable, without all the wrappers that we have now. Not that it would change much, you will still need the DLLs, etc. but it would be a bit cleaner. Meanwhile, if you use winegcc you are isolated from all these ugly details... Yes, it'd be nice to get it documented somewhere why this is needed (maybe it already is). As I understand it, the problem is that the libc linker would invoke static initializers which might rely on winelib being initialized (especially in c++ code) leading to badness if it isn't? Maybe the threading stuff gets involved too. If it's just static initializers which are the problem, the obvious solution would be to make winelib initialize on demand - of course I say that, but I'm not going to do the work ;) I don't even know how hard it's be. If it's because we need to override pthreads too, then I suppose magic tricks with the ELF GOT might help there. Deep voodoo beyond my skill at present though. thanks -mike
Re: Fix for bug 640 - moving thin frames leaves mess
On September 25, 2003 02:54 pm, Pavel Roskin wrote: We probably need another program to test GDI functions. Ideally, screenshots from Wine an Windows should match to the pixel. That will be a lot of wasted time for no good reason. I don't think we need, or that is advisable to have pixel-for-pixel compatibility of the interface. -- Dimi.
Re: Fix for bug 640 - moving thin frames leaves mess
On Thu, 25 Sep 2003, Alexandre Julliard wrote: Pavel Roskin [EMAIL PROTECTED] writes: OK, drop that part of the patch for now. I think that xoring anything with COLOR_WINDOWTEXT is incorrect, but I need to test possible other solutions. After all, the bug is about the white mess from dragging windows, which is a bigger problem. Well, yes, but it's a bug in XFree86, not in Wine. Confirmed. Accelerated X works correctly with the same hardware and X libraries, while XFree86 4.2.1 exhibits the bug. Nevertheless, I checked how the focus rectangle works on Windows 2000 and found something we may want to fix. Actually, there are two focus rectangles. The one displayed on buttons with keyboard focus is drawn by opaque pen in xor mode using alternating button face and button text colors. This guarantees that the focus is visible if the text on buttons is visible. Usually it's not different from the other focus rectangle. But if the button text is white on lightgray, the focus rectangle is almost a continuous line. If the button text is blue on lightgray, the focus rectangle is drawn by yellow and black dots. The other focus rectangle is displayed by calling DrawFocusRectangle(). In this case, the line is transparent and uses simple inversion. No color scheme settings affect the color. I'm attaching a patch that fixes DrawFocusRectangle() to use inversion. I also removed reference to COLOR_WINDOWTEXT to aesthetic reasons. The pen color is unused, but nobody should think that any color schemes affect this function. This change is also sufficient to work around the XFree86 bug. We don't have to work it around, but we are lucky that it's a side effect of making DrawFocusRect() correct. I also included a patch that removes special treatment for R2_XORPEN with black pen. I don't see such behavior in Windows 2000. I also tested Paintbrush from Windows 3.11 and it has no graphical problems except Pick-Tilt, which is unaffected by this code. It's an old hack that is wrong and unneeded now. -- Regards, Pavel Roskin --- graphics/x11drv/graphics.c +++ graphics/x11drv/graphics.c @@ -207,15 +207,6 @@ BOOL X11DRV_SetupGCForPen( X11DRV_PDEVIC val.foreground = WhitePixel( gdi_display, DefaultScreen(gdi_display) ); val.function = GXcopy; break; -case R2_XORPEN : - val.foreground = physDev-pen.pixel; - /* It is very unlikely someone wants to XOR with 0 */ - /* This fixes the rubber-drawings in paintbrush */ - if (val.foreground == 0) -val.foreground = (WhitePixel( gdi_display, DefaultScreen(gdi_display) ) ^ - BlackPixel( gdi_display, DefaultScreen(gdi_display) )); - val.function = GXxor; - break; default : val.foreground = physDev-pen.pixel; val.function = X11DRV_XROPfunction[rop2-1]; --- windows/painting.c +++ windows/painting.c @@ -1158,9 +1158,9 @@ BOOL WINAPI DrawFocusRect( HDC hdc, cons INT oldDrawMode, oldBkMode; hOldBrush = SelectObject(hdc, GetStockObject(NULL_BRUSH)); -hNewPen = CreatePen(PS_ALTERNATE, 1, GetSysColor(COLOR_WINDOWTEXT)); +hNewPen = CreatePen(PS_ALTERNATE, 1, RGB(255, 255, 255)); hOldPen = SelectObject(hdc, hNewPen); -oldDrawMode = SetROP2(hdc, R2_XORPEN); +oldDrawMode = SetROP2(hdc, R2_NOT); oldBkMode = SetBkMode(hdc, TRANSPARENT); Rectangle(hdc, rc-left, rc-top, rc-right, rc-bottom);
Re: Keyboard problems
On Thu, 25 Sep 2003, Dmitry Timoshkov wrote: Salmela [EMAIL PROTECTED] wrote: When running eg. notepad with latest wine cvs, wine doesn't correctly find out my Finnish keyboard. Instead it is using Latin American keyboard because it's getting the highest score when X11DRV_KEYBOARD_DetectLayout is choosing keymap. Does it really prevents your keyboard to work properly, or it's just that annoying FIXME message which bothers you? Scandinavian characters don't work (äöåÄÖÅ). I thought this might be the problem. P.S. I assume that you are running either latest Wine release or CVS version. I am.
