RE: Random Solaris 7 x86 issues
Here are various things I'm seeing. 1) Running anything produces: err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report 2) Solitaire seems to work fine. 3) Running telnet produces: err:win32:do_relocations FATAL: Need to relocate C:ÖWINDOWSÖTELNET.EXE, but no relocation records present (stripped during link). Try to run that file directly The following patch to map_image allows telnet to start up: [snip] OK. mmap on Solaris has slightly different semantics than mmap on Linux if an address is specified and/or MAP_FIXED is specified. The other cases are the same however. I don't remember exactly what the difference is but IIRC on Linux if an address is specified and the address is page aligned it maps on that adress regardless whether MAP_FIXED is specified. Solaris on the other hand uses the address only as a hint regardless of whether it is page aligned or not unless of course MAP_FIXED is specified. So this means that your patch might indead be the correct fix. Ulrich know more about this than I do. Ulrich? PS. BTW does an addition of MAP_FIXED in setup_dos_mem help?
Nonstandard capitilization
Hello,
Working with internationalization i have run into a bug and was
wondering what people though a good approach would be.
The basic problem is that turkish has nonstandard capitalization.
I have been told:
Turkish character set (codepage 1254, ISO8859-9) distinguishes i with a
dot above and i without a dot. So it is correct that toupper('i') returns
0xDD.
uppercase i without a dot: 0x49 (=I)
lowercase i without a dot: 0xFD
uppercase i with a dot:0xDD
lowercase i with a dot:0x69 (=i)
cf. http://czyborra.com/charsets/iso8859.html#ISO-8859-9
But LCMapString(LCMAP_LOWERCASE/UPPERCASE) Windows API ignores those
letters.
LCMapString(lcid, LCMAP_LOWERCASE, "I")- "i"
LCMapString(lcid, LCMAP_UPPERCASE, "i")- "I"
LCMapString(lcid, LCMAP_LOWERCASE, "\xdd") - "\xdd" (no change)
LCMapString(lcid, LCMAP_UPPERCASE, "\xfd") - "\xfd" (no change)
I was looking to see if i could find a global list of what these
exceptions to normal mapping may be. However what i found was
http://srfi.schemers.org/srfi-13/mail-archive/msg00046.html
- Turkish has different case mappings.
Case-mapping functions are sensitive to external environment settings
in ways not defined by this SRFI. E.g., the current $LC locale in Unix.
Note that Turkish is the only language in the Unicode set with this problem.
Unfortunately for turkish this is a big problem. because it means that
the windows directory gets uppercased to W(I with a dot)NDOWS and thus
things fail under wine.
So there are two issues. The first is that our LCMapString is wrong (it
calls straight toupper) and needs to be corrected. This is a simple fix.
However I was unable to find a comprehensive list of where windows is
nonstandard.
second, we directly call toupper and tolower all over in wine code. We
would need to change all those calls to something else which understands
the exceptions windows uses. What function should that be? Should there
be a new WINE_ToUpper function that everything calls, or should
everywhere we call toupper we instead call LCMapStringA() or CharUpper()
?
Also if anyone knows other languages which have nonstandard behavior
under windows it would be good to find out how many things like this we
will have to work on.
-aric
Re: Nonstandard capitilization
On Fri, 10 Nov 2000, Aric Stewart wrote: I was looking to see if i could find a global list of what these exceptions to normal mapping may be. Global list? Case mapping is pretty much locale-dependent by definition. Everyone knows about the German sharp S, too, I guess... uppercase of ß is SS. So there are two issues. The first is that our LCMapString is wrong (it calls straight toupper) and needs to be corrected. This is a simple fix. However I was unable to find a comprehensive list of where windows is nonstandard. Is it really? There's a documented LCMAP_LINGUISTIC_CASING flag - whenever it's not specified, Windows defaults to filesystem-compatible casing. second, we directly call toupper and tolower all over in wine code. We would need to change all those calls to something else which understands the exceptions windows uses. What function should that be? Should there be a new WINE_ToUpper function that everything calls, or should everywhere we call toupper we instead call LCMapStringA() or CharUpper() ? Of course we should use standard routines rather than defining more Wine-internal routines.
just writing EMF files using libwine
Hi wine developers, I'm the developer of pstoedit - a GPLed program that can translate PostScript to a bunch of different vector formats. (www.geocities.com/wglunz/pstoedit/). For Windows platforms I also provide a driver to create EMF files. This driver currently used the Windows-API. More and more I get requests whether I couldn't provide this EMF driver also on non-Windows platforms, e.g. Sun Solaris (Sparc) or HP-UX or Linux (here as native Linux application, not as .exe). Now I tried to use libwine but have the following problems / questions: Without any change, libwine.a doesn't compile on Solaris-Sparc. I needed to comment out some assembler parts. Question: is libwine not intended to be usable also on non Intel platforms ? The libwine.a as produced by "make libwine.a" doesn't contain the needed GDI calls like: Rectangle Polyline SetTextAlign CreateBrushIndirect CreateMetaFileA So I need e.g. also libgdi32.so - right ? How can I "make" this without building whole wine ? Configure doesn't seem to have an option for this (just for the libwine.a/so) Also libgdi32.so doesn't compile under Solaris-Sparc (using gcc) - same problem with assembler code as above. So I searched for the functions that I need and found most of them in the graphics/enhmetafiledrv directory. Unfortunately, these are not exactly the effective Win32 functions, but instead some internal functions that are called via the upper GDI layer. Now it get's a bit frustrating. It seems so that I need to build lot's of wine (and this doesn't work under Solaris-Sparc due to the assebmler code) just to be able to use the GDI functions that write to a Metafile. Question: isn't there a more direct way I can build just the parts that I need to write a Metafile ? I even cannot imagine why the code to write a Metafile is so platform dependent. Is there a way to get a GDI that supports just metafiles and omit all the stuff that isn't needed ? Any help is greatly appreciated. Wolfgang
Re: Windows Installer
On Fri, 10 Nov 2000, Uwe Bonnes wrote: Taral writes: There was a very vague reference to Windows Installer problems on the newsgroup, but nothing concrete. As far as I can tell, msi.dll does NOT like one of the wine dlls. Since this is probably going to become a FAQ, can someone provide an authoritative answer to why msi.dll fails like this? I can provide my own (partial) analysis based on the contents of msi.dll. You are very vague. I think nobody can answer unless you have a concrete bug report... Sorry about that, I thought it was clear. Running instmsi.exe from a microsoft-free system results in an error: "This installation package could not be opened. Contact the application vendor to verify that this is a valid Windows Installer package." NOTE: I just discovered that replacing ole32.dll with native version fixes the problem. I will look into it further. Taral
Re: Random Solaris 7 x86 issues
Patrik Stridvall wrote: OK. mmap on Solaris has slightly different semantics than mmap on Linux if an address is specified and/or MAP_FIXED is specified. The other cases are the same however. I don't remember exactly what the difference is but IIRC on Linux if an address is specified and the address is page aligned it maps on that adress regardless whether MAP_FIXED is specified. Solaris on the other hand uses the address only as a hint regardless of whether it is page aligned or not unless of course MAP_FIXED is specified. So this means that your patch might indead be the correct fix. Ulrich know more about this than I do. Ulrich? The problem is the following: if you pass MAP_FIXED to mmap(), it *will* use this address no matter what. Especially, if there are already *other* mappings in that range, they will just be zapped. This is same for both Linux and Solaris. On the other hand, if you do *not* pass MAP_FIXED, the address passed to mmap() is only a *hint* of where to place the mapping. Both Linux and Solaris are free to chose some other address. In no case will old mappings be affected. Again, the semantics is the same for both Linux and Solaris. However, the *implementation* is quite different: Linux will always try to place the mapping at exactly the address specified, and will only chose a different address if the other is already taken. Solaris, however, will nearly always move the mapping to some other address, apparently due to efficiency considerations. This creates a problem for Wine, because be sometimes *have* to place a mapping at a particular address, e.g. non-relocateable executable images. What we need here is a routine that tries to place the mapping at exactly the specified address, but if this is not possible, does *not* zap any other mappings but returns an error. On top of the Linux mmap(), this is easily done: just call mmap() with the address, and without MAP_FIXED, and check the return value: if the system chose another address, we know that we have failed. On top of the Solaris mmap(), we have a problem: we can't use MAP_FIXED as this might zap other mappings, and we can't *not* use MAP_FIXED, because then the system nearly never choses the address we need, even though it were possible. One possible solution would be to perform ourselves a check whether the target region is free from other mappings, and if so, use mmap() with MAP_FIXED. One way to do this would be to scan the proc file system entry for the current process to find out the current mappings. (Another way would be to check our own reprentation of the address space as list of FILE_VIEW data structures. We need to take care that we don't overlook system mappings in this case ...) There is also a not quite trivial problem of how to avoid race conditions here ... Bye, Ulrich -- Dr. Ulrich Weigand [EMAIL PROTECTED]
Re: Random Solaris 7 x86 issues
Alexandre Julliard wrote: Does anybody know exactly what Solaris does? Does it simply round the address to some nearest boundary, or does it pick a completely random address? If it's just rounding we could allocate a larger area and use the part that we wanted, but if the address is random this won't work. Well, a little test program shows (on Solaris 2.5.1): 1234 -- ef6f -- ef6c 1000 -- ef6b -- ef6a and on Solaris 2.6: 1234 -- ef6f -- ef6d 1000 -- ef6c -- ef6b and on Solaris 2.7: 1234 -- ff39 -- ff37 1000 -- ff36 -- ff35 all on Sparc; always 16K allocations. So it would appear that Solaris completely ignores the passed address, and just sorts all mmaps() nicely together ;-) And no, MAP_FIXED does not work since it will wipe out existing mappings at this address. Yes. Except if we check ourselves in advance ... Bye, Ulrich -- Dr. Ulrich Weigand [EMAIL PROTECTED]
Re: Random Solaris 7 x86 issues
Patrik Stridvall [EMAIL PROTECTED] writes: Solaris on the other hand uses the address only as a hint regardless of whether it is page aligned or not unless of course MAP_FIXED is specified. Does anybody know exactly what Solaris does? Does it simply round the address to some nearest boundary, or does it pick a completely random address? If it's just rounding we could allocate a larger area and use the part that we wanted, but if the address is random this won't work. And no, MAP_FIXED does not work since it will wipe out existing mappings at this address. -- Alexandre Julliard [EMAIL PROTECTED]
Re: GDI object refcount?
Well, if you can implement this, then just go ahead. Just remember that you have to do the refcount increase/decrease in every single SelectObject function. On the other hand I think I know more about that at the moment ;) So if you don't want to do it, then I'll do. Hmm. I think it would be nice if you could do it :) As you said, you seem to know your way around that code way better than me. Nicke -- -[ [EMAIL PROTECTED] ]- Seek simplicity, and distrust it. (A. Whitehead)
Re: Random Solaris 7 x86 issues
The problem is the following: if you pass MAP_FIXED to mmap(), it *will* use this address no matter what. Especially, if there are already *other* mappings in that range, they will just be zapped. Yes. :-( One possible solution would be to perform ourselves a check whether the target region is free from other mappings, and if so, use mmap() with MAP_FIXED. One way to do this would be to scan the proc file system entry for the current process to find out the current mappings. (Another way would be to check our own reprentation of the address space as list of FILE_VIEW data structures. We need to take care that we don't overlook system mappings in this case ...) There is also a not quite trivial problem of how to avoid race conditions here ... I started to code this last night using mincore to check each page in the target region one at a time (which should be somewhat portable), however I didn't see an easy / obvious way to ensure that all other threads are quiescent. -- John - | Feith Systems | Voice: 1-215-646-8000 | Email: [EMAIL PROTECTED] | |John Wehle| Fax: 1-215-540-5495 | | -
Update: MacOSX and WineLib...
Hi everyone, Last week I had sent an email to the devel mailing list asking if anyone knew of any possible issues there would be with porting WineLib to MacOS X. I received a number of potential issues. The main ones, summarized from an email from Patrik Stridvall, are: ===START= - According to the "MacOS X Kernel Environment" book, pg. 37, Mac OSX does not support memory mapped devices through the mmap API. This would affects at least streaming sound playback. But it supports mmap for files? Especially MAP_SHARED? Speaking of mmap. Does MacOS X support sendmsg/recvmsg? If not you can forget about porting Wine unless you can convince Alexandre that the Wineserver should be redesigned. - Must ensure that behaviour of lower level UNIX resources like sockets, threads, files are the way WINE expects it. Wine currently expects that the file API works on socket descriptors. This is not the case on BeOS but I determined that this was a fixable issue. I just never did it. ===FINISH= To test these concerns, I made four test apps and compiled and ran them on Mac OS X. I used the "Mac OS X Public Beta Developer Tools CD" which is downloadable from http://connect.apple.com The first test app used mmap and MAP_SHARED option, the second sent messages between two programs using sendto over a socket, the third used file I/O functions (like read,write) to send messages over a socket, the fourth sent an FD over a socket to another process using sendmsg/recvmsg. I have good news, each of these programs compiled without modification on MacOS X with the standard cc, and ran perfectly!! So, I don't think there are any show stoppers that would keep us from being able to port WineLib to MacOS X. Of course there would be work to do, but at least it is definitely possible. Thanks for all of the help, -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. [EMAIL PROTECTED] ~ http://www.macadamian.com "Nothing is a problem once you debug the code."
Re: GDI object refcount?
On Fri, Nov 10, 2000 at 11:21:39PM +0200, Niclas Karlsson MATE wrote: Well, if you can implement this, then just go ahead. Just remember that you have to do the refcount increase/decrease in every single SelectObject function. On the other hand I think I know more about that at the moment ;) So if you don't want to do it, then I'll do. Hmm. I think it would be nice if you could do it :) oki. I'll try to do it this weekend. Andreas Mohr
Re: Random Solaris 7 x86 issues
Ulrich Weigand [EMAIL PROTECTED] writes: So it would appear that Solaris completely ignores the passed address, and just sorts all mmaps() nicely together ;-) Great :-( And what does the address space look like at startup? Where does it allocate the main exe and the .so libraries? Maybe we can reserve the addresses we need like 0 and 0x0040 with a MAP_FIXED at startup. And no, MAP_FIXED does not work since it will wipe out existing mappings at this address. Yes. Except if we check ourselves in advance ... You'd need to completely freeze all threads first, because you never know if some libc function is not going to change mappings. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Random Solaris 7 x86 issues
John Wehle wrote: I started to code this last night using mincore to check each page in the target region one at a time (which should be somewhat portable), I don't think mincore is appropriate, as we must check whether there *is* a mapping, not just whether some of its pages are actually present in physical memory. Even if a mapping happens to be completely paged out we still must not zap it. Scanning the list of mappings from the proc file system should work, though. however I didn't see an easy / obvious way to ensure that all other threads are quiescent. This is indeed the main problem here ... Bye, Ulrich -- Dr. Ulrich Weigand [EMAIL PROTECTED]
Re: Random Solaris 7 x86 issues
I don't think mincore is appropriate, as we must check whether there *is* a mapping, not just whether some of its pages are actually present in physical memory. Sure it is. The question is did mincore return an *error* for the page being checked (in which case nothing is mapped there) or did it return zero (in which case something is mapped there). Ah, sorry. You're right, of course. Using mincore should be somewhat more portable than digging around /proc. Yes. The /proc format changed even across Solaris versions :-/ Bye, Ulrich -- Dr. Ulrich Weigand [EMAIL PROTECTED]
Re: Random Solaris 7 x86 issues
Alexandre Julliard wrote: Great :-( And what does the address space look like at startup? Where does it allocate the main exe and the .so libraries? Maybe we can reserve the addresses we need like 0 and 0x0040 with a MAP_FIXED at startup. Well, my little test app looks like this: 7499: ./test 0001 8K read/exec /home/inf1/weigand/test 0002 8K read/write/exec /home/inf1/weigand/test FF28656K read/exec /usr/lib/libc.so.1 FF332000 32K read/write/exec /usr/lib/libc.so.1 FF33A000 8K read/write/exec [ anon ] FF35 16K write [ anon ] FF36 16K write [ anon ] FF37 16K write [ anon ] FF38 16K read/exec /usr/platform/sun4u/lib/libc_psr.so.1 FF39 16K write [ anon ] FF3A 8K read/exec /usr/lib/libdl.so.1 FF3B128K read/exec /usr/lib/ld.so.1 FF3DE000 16K read/write/exec /usr/lib/ld.so.1 FFBEC000 16K read/write/exec [ stack ] total 960K So at least the libraries are no problem. The executable base address is not so nice, but there we could probably fiddle around with linker scripts ... Note that this is on Sparc, as I don't have access to a Solaris/x86 box. John, does it look much different there? And no, MAP_FIXED does not work since it will wipe out existing mappings at this address. Yes. Except if we check ourselves in advance ... You'd need to completely freeze all threads first, because you never know if some libc function is not going to change mappings. Yes, that's the problem. :-/ Bye, Ulrich -- Dr. Ulrich Weigand [EMAIL PROTECTED]
Re: Random Solaris 7 x86 issues
Note that this is on Sparc, as I don't have access to a Solaris/x86 box. John, does it look much different there? 14420: ./a 08046000 8K read/write/exec [ stack ] 0805 4K read/exec /tmp/a 0806 4K read/write/exec /tmp/a DFB3F000552K read/exec /usr/lib/libc.so.1 DFBC9000 28K read/write/exec /usr/lib/libc.so.1 DFBD 4K read/write/exec [ anon ] DFBD2000108K read/exec /usr/lib/ld.so.1 DFBF8000 4K read/exec /usr/lib/libdl.so.1 DFBFA000 4K read/write/exec [ anon ] DFBFC000 12K read/write/exec /usr/lib/ld.so.1 total 728K This is on Solaris 7 x86. -- John - | Feith Systems | Voice: 1-215-646-8000 | Email: [EMAIL PROTECTED] | |John Wehle| Fax: 1-215-540-5495 | | -
FindWindow warning
Is the following FIXME correct (and the comment as well)?
Ciao
Jörg
--
Joerg Mayer [EMAIL PROTECTED]
I found out that "pro" means "instead of" (as in proconsul). Now I know
what proactive means.
Index: wine/windows/win.c
===
RCS file: /home/wine/wine/windows/win.c,v
retrieving revision 1.104
diff -u -r1.104 win.c
--- wine/windows/win.c 2000/11/02 20:08:59 1.104
+++ wine/windows/win.c 2000/11/10 21:36:28
@@ -1576,6 +1576,10 @@
}
}
retvalue = 0;
+/* In this case we need to check whether other processes
+ own a window with the given paramters on the Desktop,
+ but we don't, so let's at least warn about it */
+FIXME("Returning 0 without checking other processes\n");
end:
WIN_ReleaseWndPtr(pWnd);
return retvalue;
Re: Another bug (or the return of the (in)famous strength reduce GCC bug)
On Fri, Nov 10, 2000 at 07:50:44PM +, Eric Pouech wrote:
I tried to debug an annoying bug^H^H^Hfeature of the Wine debugger
command history runs havoc after a few commands get entered
this boils down to a... compiler bug (no Ulrich, this ain't a(nother) joke)
---8--
#include stdio.h
int main()
{
int i;
static int L[4] = {0,1,2,3};
for (i = 0; i 4 - 1; i++) L[i] = L[i + 1];
L[i] = 4;
for (i = 0; i 4; i++) printf("[%d] = %d\n", i, L[i]);
}
---8--
This bug seems to be fixed in the current gcc CVS version, at least
judging from their online compile form ;)
Ciao, Marcus
Re: Re: wineserver - linux kernel idea
Hey Juergen, thanks for taking the time to read my mail. By synchronisation, you're talking about event flags, semaphores, message queues, etc, right? For an event flag, i would create a name pipe, and store it's filename, name, and handle in the database. SetEvent would then write a byte to the pipe. ResetEvent would read all the bytes from the pipe. WaitSingleObject would select on the pipe. Processes would use the database to find the pipe's filename using either the event flag's name or handle. i think the other synchronisation events could be handled in a similar fashion. Mike Original message from: "Juergen Schmied" [EMAIL PROTECTED] Did you think about syncronisation? Do you really know what the server is doing beside storing some data? Ciao Juergen -- mailto:[EMAIL PROTECTED] ph +61 2 9427 2196 __ Get your own free web email at http://www.looksmart.com.au LookSmart Australia
Re: FindWindow warning
At 11:40 PM 11/10/00 +0100, you wrote: Is the following FIXME correct (and the comment as well)? snip fixme about FindWindow not working for another process That's a following of the address space separation. Although the Wine processes are separated, the windows handles are still generated by each Wine process through a local mechanism based on memory allocation. The Wine server does not generate them, and as such these handles have no meaning for another process. For example, it can happen that 2 windows of different processes have the same handle. So it does not make sense to do a FindWindow for a window in another process in current Wine. The main problem for fixing that is probably to not having performance going down the drain :-) Gerard
