Contributing
Hi, I would like to help contribute to WINE because I use it so much yet I've never actually contributed to it. I was wondering if there are any simple bugs or other tasks that someone new to WINE development could undertake. Thanks. -- From: Travis Athougies 2 + 2 = 4
Re: gdi32-related commit between 0.9.57<->0.9.58broken .NET2/Systems.Windows.Forms
"Vitaliy Margolen" <[EMAIL PROTECTED]> wrote: > Looks like a time to start blacklisting fonts then. If the font is invalid > and does not work even on windows yet it is available in the system - that's > the only thing Wine can do. Or just contact all distros to remove it. Or > request packagers to refuse installing Wine if said font found in the system. Black listing the fonts is not an appropriate fix/workaround. There is already a fixed version of ukai.ttf, and a broken one was causing problems in a lot of native programs besides Wine. -- Dmitry.
Wine 1.0 status: T minus 72 days. 74 open bugs.
44 days to code freeze. Four bugs fixed in the last two days: 9104 comdlg32 2 Pdf-xchange viewer crashes 10040 crypt32 2 Steam crashes during the startup 10111 comctl32 2 WINEDEBUG=warn+heap "make test" has heap error in comdlg32/tests/printdlg.c 11884 winex11. 1 Copy and paste garbage on end History: 3/22: 87 bugs, 76 days to go 3/23: 82 bugs, 75 days to go 3/24: 78 bugs, 74 days to go 3/26: 74 bugs, 72 days to go Here's a list of the currently open 1.0 bugs, sorted by component, with votes: 5948-unknown1 Star Trek: Armada does not install 4971-unknown3 Corel Draw 12 demo install fails 5024-unknown4 Thief: Deadly Shadows crashes:page fault on read access to 0x040c 5055-unknown5 Deleting files from a window in wine doesn't send them to the Trash 5061-unknown6 Copying from Windows Firefox in Wine and pasting to Linux OpenOffice pastes metadata as data 5402-unknown0 Trying to run PhotoStitch 3.1 5844-unknown10 tray minimize 7404-unknown2 ShowWindow(SW_MINIMIZE) should not generate a WM_PAINT message 7477-unknown1 Uplink demo crashes 8125-unknown0 Marratech 6.1 crashes on start 9178-unknown7 "hello world" dos program hangs 9459-unknown8 FIFA 2007 crashes with the recent versions 9916-unknown6 "make test" usually fails 9959-unknown8 Make wine updates work even if the registry changed 10147 -unknown1 Word Viewer 2003 - Tab behavior differs from Windows 10815 -unknown2 Cannot drag images into Adobe Photoshop 7 from the web / desktop 11281 -unknown2 CJK input many issues 12097 -unknown2 Wine 1.0 should not ship out-of-sync resource translations 556 build-en2 Reconcile the Windows and Wine spec files 1114comctl322 Winrar2.90/3.00: Comboex doesn't trigger a event when you mouse-click in some value of it 2493comctl322 Multi-select listview: Shift-arrow up only selects top two items 5955directx-7 DirectDrawCreate crash on non-OpenGL desktop 9030directx-0 army men hangs on black screen 11681 directx-14 Add support for video overlay 82 document2 Stabilize Winelib User Guide Table of Contents 638 document8 Document Wine debugging channels 12217 document0 Documentation should be in XML and not SGML format 3270gdi32 14 Problem with minimized top-level windows 6519gdi32 7 Wine blacks out rotated font bitmap 7571gdi32 1 Accented character glyphs are mixed up with TrueType fonts (affects e.g. Lotus Notes R5) 9771gdi32 38 Steam Friends doesn't work (fails to render correctly or refresh) 9926gdi32 5 gdi32.dll should not have exported function pointers 4733kernel325 Get optimized/compressed/packed executables (non-upx) working 5351kernel329 Windows Installer 3.1 cannot install because of non-standard drive labeling 5541kernel320 WriteConsole can't write to stdout; affects e.g. wsh's cscript's usage message 9039kernel320 GS-Auftrag Professional SQL aborts on startup 9484kernel3217 Program refuses to run because of ProtectCD/ProtectDISC copy-protection 7098mscoree 1 RufzXP crashes on startup, needs mscoree.dll.CorBindToRuntimeEx 5163msi 12 Office XP 2002 crashes on installation 8783ntdll 11 USB serial ports do not work 9356ntdll 6 Serial communication not working since wine-0.9.33 2539ole 3 XDND (Drag and drop for X Windows) doesn't copy text 4770ole 3 BlackBerry Device Manager fails to install under wine 6607ole 8 Drag and Drop not working 8095ole 0 PQ Teaching toy crashes 9942ole 2 Powerpoint Viewer 2007 crashes opening .pptx files 5926programs0 Wine does not provide an implementation of winhlp32.exe 6254richedit4 Installer infinite loop from rich text error 3546shdocvw 2 CLSID_InternetShortcut not available... 6095shdocvw 12 MOTD in counter-strike 1.6 and counter-strike source does not render 8898shdocvw 0 Run Time Error "445": Object doesn't support this action in Europa Knowledgebase 9304shdocvw 3 Temple of Elemental Evil demo doesn't start - gui irresponsive 8439shell32 7 Visual Studio .NET (7) install fails 9809shell32 4 Autodesk Revit Architecture 2008 install fails 10905 shell32 0 thinstall firefox demo requires native msvcrt 11742 shlwapi 8 Small
Re: [PATCH 1/2] user32: Properly translate keyboard left/right-shift, alt, ctrl keys hardware messages.
Vitaliy Margolen wrote: > --- > dlls/user32/message.c | 15 +++ > 1 files changed, 15 insertions(+), 0 deletions(-) > > > [PATCH 2/2] winex11drv: Distinguish left and right keys for shift, ctrl and > alt. (try 5) Alexandre, what was wrong with these patches? I moved the remapping of messages as you suggested. Vitaliy.
Re: gdi32-related commit between 0.9.57<->0.9.58 broken .NET2/Systems.Windows.Forms
Hin-Tak Leung wrote: > --- On Wed, 26/3/08, Huw Davies <[EMAIL PROTECTED]> wrote: > >>> If ukai is affected, I would suspect uming (also from >> Arphic) >>> would be the same? and how many non-english fonts one >> want to >>> "work-around" like this? >> I've not seen any problems with uming. Most >> 'non-english' fonts will >> work fine. There's something very specific about ukai >> that causes >> native gdiplis to have problems. >> Actually I've just attached a hack to the >> bug, try that instead. >>> Thanks - but I also have uming, and a a fair number of >> other fonts >>> shipped from fedora for non-english. (over 100). >> Please try the patch and report back. > > Yes, your patch works alright - it is just ukai and nothing else. I'll put it > on the bug report as well. Ukai (or rather, the original Arphic kai font) was > the first > commercial quality chinese font released under an open license, so you are > going to > have a lot of people - 20% of the world is Chinese, and also linux is rather > more officially popular in China due to licensing/cost/idealological reasons > and some > non-chinese will install "everything" - being affected by this. I don't know > if it > is ukai-specific or any Arphic kai derivatives, but if it affects any Arphic > kai derivatives, filtering by font name as your patch did won't be effective. > Looks like a time to start blacklisting fonts then. If the font is invalid and does not work even on windows yet it is available in the system - that's the only thing Wine can do. Or just contact all distros to remove it. Or request packagers to refuse installing Wine if said font found in the system. Vitaliy.
Re: [GSoC][RFC] Case Insensitive Filesystem
Austin English wrote: > On Wed, Mar 26, 2008 at 6:39 PM, Cesar Izurieta <[EMAIL PROTECTED]> wrote: >> > Alexandre Julliard wrote: >> > > Yes, and that's precisely because Wine wants to preserve case, so that >> > > tools that look at the filesystem directly see the right thing. If you >> > > are going to store everything lowercase in the filesystem, then we >> could >> > > just as well do that inside Wine, without a FUSE module. >> >> We could do this for the drive_c directory but what about /? you >> cannot enforce that there. Maybe this part project should be divided >> into two different problems. 1. How to achieve that for drive_c, and >> 2. how to mount a proxy filesystem for / and apply some rules when >> conflicting files exist, as keep the newest conflicting file with the >> original name and rename other files like it was proposed on another >> thread on this list. > > We could do this in wine itself for drive_c, which is where most of > the problem seems to lie (assuming no one links their program files to > a different mount point). Most performance issues/problem are with > patches or with installers searching for lots of files (within > drive_c). While it would be ideal to do this for the entire FS, doing > it for drive_c should resolve most issues. > You're very right that doing this for just drive_c solves most issues (as we can always fall back on Wine's existing behavior if we're outside of C), however unless we have some Wine process always running there's no way we can guarantee preserving the case integrity of drive_c just inside Wine. Thanks, Scott Ritchie
Re: [GSoC][RFC] Case Insensitive Filesystem
On Wed, Mar 26, 2008 at 6:39 PM, Cesar Izurieta <[EMAIL PROTECTED]> wrote: > > Alexandre Julliard wrote: > > > Yes, and that's precisely because Wine wants to preserve case, so that > > > tools that look at the filesystem directly see the right thing. If you > > > are going to store everything lowercase in the filesystem, then we could > > > just as well do that inside Wine, without a FUSE module. > > We could do this for the drive_c directory but what about /? you > cannot enforce that there. Maybe this part project should be divided > into two different problems. 1. How to achieve that for drive_c, and > 2. how to mount a proxy filesystem for / and apply some rules when > conflicting files exist, as keep the newest conflicting file with the > original name and rename other files like it was proposed on another > thread on this list. We could do this in wine itself for drive_c, which is where most of the problem seems to lie (assuming no one links their program files to a different mount point). Most performance issues/problem are with patches or with installers searching for lots of files (within drive_c). While it would be ideal to do this for the entire FS, doing it for drive_c should resolve most issues.
Re: dlls/user32/tests/cursoricon.c - test succeeded inside todo block
On 26/03/2008, Lei Zhang <[EMAIL PROTECTED]> wrote: > Anyone else seeing this? > > ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p > user32_test.exe.so cursoricon.c && touch cursoricon.ok > cursoricon.c:656: Test succeeded inside todo block: No hbmColor! > make: *** [cursoricon.ok] Error 1 http://test.winehq.org/data/200803211000/#group_Wine:user32:cursoricon user32:cursoricon start dlls/user32/tests/cursoricon.c 1.11 cursoricon.c:655: Test succeeded inside todo block: yHotspot is 1. cursoricon: 5 tests executed (2 marked as todo, 0 failures), 0 skipped. cursoricon: 357 tests executed (10 marked as todo, 1 failure), 0 skipped. user32:cursoricon done (1) or user32:cursoricon start dlls/user32/tests/cursoricon.c 1.11 cursoricon.c:655: Test succeeded inside todo block: yHotspot is 1. cursoricon.c:656: Test succeeded inside todo block: No hbmColor! cursoricon: 5 tests executed (2 marked as todo, 0 failures), 0 skipped. cursoricon: 357 tests executed (9 marked as todo, 2 failures), 0 skipped. user32:cursoricon done (2) so yes. - Reece
Re: [RFC] Improving the summary results on test.winehq.org
On Wed, 19 Mar 2008, Reece Dunn wrote: > Hi, > > Looking at the results from a test run (e.g. > http://test.winehq.org/data/200803181000/), it would be nice to have: > > 1. A summary of a dlls overall results (i.e. the summation of all > its unit test results), preferably before the individual tests, but > could live with them at the bottom. I'm not sure this one is worth it. It would add quite a lot of lines too. > 2. A summary of the entire test results (i.e. the summation of > all unit test results for all dlls). This would be best at the top > where it is easily visible. I've sent a patch doing just that, with the percentage of unit tests that have errors too. > 3. Possibly display the number of tests run in a given pass (e.g. > 0/12 or 1+3/27). This is to give an idea of how many tests have been > run easily (especially for the dll and overall summaries). As mentioned before you get the number of individual checks that where run in the per-test tooltip. The 'statistics' patch also provides the total number of unit tests in a tooltip. -- Francois Gouget <[EMAIL PROTECTED]> http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0
Re: Tests marked as todo are not displayed on the web results.
On Wed, 19 Mar 2008, Reece Dunn wrote: [...] > For example, using the above, it results in: > > gdiplus:graphicspath start dlls/gdiplus/tests/graphicspath.c 1.13 > graphicspath: 198 tests executed (5 marked as todo, 0 failures), 0 skipped. > gdiplus:graphicspath done (0) > > ...so does not tell me which of the 5 tests are todo and which are ok. > > I haven't checked to see if this is also an issue with the `make test` output. Yep, that's because make test does not print the todo tests. Maybe they should be printed but with 'Test failed' replaced with 'Todo test' or something like that. Maybe it should depend on WINETEST_DEBUG. -- Francois Gouget <[EMAIL PROTECTED]> http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science.
Re: [GSoC][RFC] Case Insensitive Filesystem
On Wed, Mar 26, 2008 at 6:17 PM, Scott Ritchie <[EMAIL PROTECTED]> wrote: > > Alexandre Julliard wrote: > > Marc Andre Tanner <[EMAIL PROTECTED]> writes: > > > >> Yes that's true the case information is lost but is it really needed? > >> If you create the files with the original mixed case you will have to > >> scan the whole directory in order to match it to a given filename. > >> And if i am not mistaken this is exactly what wine does. > > > > Yes, and that's precisely because Wine wants to preserve case, so that > > tools that look at the filesystem directly see the right thing. If you > > are going to store everything lowercase in the filesystem, then we could > > just as well do that inside Wine, without a FUSE module. > > > > It seems like we have a few goals: > > * Prevent having to read the whole directory when looking for a > case-insensitive file > * Allow non-Wine programs to work with the cased filenames > * Prevent the creation of conflicting files We could do this for the drive_c directory but what about /? you cannot enforce that there. Maybe this part project should be divided into two different problems. 1. How to achieve that for drive_c, and 2. how to mount a proxy filesystem for / and apply some rules when conflicting files exist, as keep the newest conflicting file with the original name and rename other files like it was proposed on another thread on this list. > > The last one is important, as we need to have a 1:1 correspondence > between cased and uncased files in the .wine folder to prevent breakages > when someone, say, installs a patch with different casing from a zip file. > > I don't see any reason why it would be bad to have the FUSE module > mounted at login rather than when Wine starts. This would make your > Wine folder no different to other apps than, say, a vfat disk mounted > there. I should be able to extract a zip with file-roller containing > "foo.txt" and have it overwrite "Foo.txt" even if Wine isn't running. > > Thanks, > Scott Ritchie > > >
Re: Fw: Re: Google Summer of Code 2008 - joined openprinting+wine project?
Hi Hin-Tak, to sum it up, I was the one working on that project and I hit some ehh.. problems ;) Anyways, my final result was that I got something out of the printer drivers I tried with, but useful results depended on something that is referred to as the ominous 'DIB engine'. Coincidently, there was another SoC project done by Jesse Allen which started implementing that. That code ended up at http://repo.or.cz/w/wine/dibdrv.git, and just as mine, general+AJ's consensus was to start merging it post-1.0. Now I didn't have time to look again at it up to now (uni!) but I still want to finish this, just not as part of a SoC project. Also I wouldn't recommend that to anyone, except he REEEAAALLY does grok all those mysterious inner-GDI concepts (DIB DDB DDI...) that this project touches. I myself have not fully reached insight of how best to merge the current winex11drv, wined3d and Jesse's dib engine, but I'll have a thorough look at it in the next few days. Another unsolved issue is whether to teach wine's internal GDI functions to speak DDI or rather to build a wineddi.drv bridge thing. I tried both approaches but there was no clear decision whether to use one or the other, with Alexandre's stance being 'once something actually works we can talk about that'. Also my code to make printer drivers work depends on some stuff within the localspooler code, I have to investigate how far Detlef got it to work regarding installation of drivers. Oh yeah and that printer proxy was only a DLL to see how native windows communicates with the drivers without getting into disassembling stuff.. the results scared me, astonishing levels of redundancy.. Anyways, even though all the bits and pieces of how to make native drivers actually work with wine are lying around, this is neither a fun nor a beginner's task (I know that now *g). That said, I'm going to look into it and hope to come up with something in the next few days. regards marcel. Hin-Tak Leung wrote: > Hi, anybody on wine-devel want to take this on and make this more concrete? > > --- On Wed, 26/3/08, Till Kamppeter <[EMAIL PROTECTED]> wrote: > >> From: Till Kamppeter <[EMAIL PROTECTED]> >> Subject: Re: Google Summer of Code 2008 - Some general instructions for >> reviewing the student's applications >> To: "Hin-Tak Leung" <[EMAIL PROTECTED]> >> Cc: "Casey Schaufler" <[EMAIL PROTECTED]>, "'Glen Petrie'" <[EMAIL >> PROTECTED]>, "Rik van Riel" <[EMAIL PROTECTED]>, "Jeff Licquia" <[EMAIL >> PROTECTED]>, "Jon Masters" <[EMAIL PROTECTED]>, "Jonathan Riddell" <[EMAIL >> PROTECTED]>, "Josef Spillner" <[EMAIL PROTECTED]>, [EMAIL PROTECTED], "Pekka >> Enberg" <[EMAIL PROTECTED]> >> Date: Wednesday, 26 March, 2008, 4:34 PM >> Hin-Tak Leung wrote: >>> Hi Till and the rest of the gang. >>> >>> Two people had got in touch with with about the >> IJS+PDF workflow, and I replied. >>> (sorry I don't check the "other" e-mail >> often - I probably should set up re-direction). >> Great! >> >>> I thought I should also mentioned that it has just >> came to my attention in some unrelated discussion on >> wine-devel - been doing some non-printing wine-related >> stuff lately - that there *was* a google summer of code >> 2007 project for a >>> wine-based native printer driver proxy - this is the >> sort of thing I have had in mind >>> for a while and I thought it would be interesting to >> do but I don't have in-depth >>> windows knowledge to make it happen, but the wine >> people already did! >>> http://google-summer-of-code-2007-wine.googlecode.com/ >>> >>> I just downloaded the gsoc 2007 printerproxy code. It >> seems that it is just for use >>> from within wine, but it just might be interesting to >> make it more general - via opvp >>> or IJS. We should follow up on this. >> If this project still requires coding, it is not too late >> to add it as >> project idea to the ideas pages of both the Linux >> Foundation and WINE >> (having it presented at two mentoring organizations raises >> the chances >> to find a student). >> >> Our ideas page is a Wiki and you can simply edit it: >> >> https://www.linux-foundation.org/en/Google_Summer_of_Code >> >> Till > > > __ > Sent from Yahoo! Mail. > More Ways to Keep in Touch. http://uk.docs.yahoo.com/nowyoucan.html > -- "Obstacles are those frightful things you see when you take your eyes off your goal." -- Henry Ford (1863-1947) Change the world! Vote revolution: http://hfopi.org/vote-future
Re: [GSoC][RFC] Case Insensitive Filesystem
Alexandre Julliard wrote: > Marc Andre Tanner <[EMAIL PROTECTED]> writes: > >> Yes that's true the case information is lost but is it really needed? >> If you create the files with the original mixed case you will have to >> scan the whole directory in order to match it to a given filename. >> And if i am not mistaken this is exactly what wine does. > > Yes, and that's precisely because Wine wants to preserve case, so that > tools that look at the filesystem directly see the right thing. If you > are going to store everything lowercase in the filesystem, then we could > just as well do that inside Wine, without a FUSE module. > It seems like we have a few goals: * Prevent having to read the whole directory when looking for a case-insensitive file * Allow non-Wine programs to work with the cased filenames * Prevent the creation of conflicting files The last one is important, as we need to have a 1:1 correspondence between cased and uncased files in the .wine folder to prevent breakages when someone, say, installs a patch with different casing from a zip file. I don't see any reason why it would be bad to have the FUSE module mounted at login rather than when Wine starts. This would make your Wine folder no different to other apps than, say, a vfat disk mounted there. I should be able to extract a zip with file-roller containing "foo.txt" and have it overwrite "Foo.txt" even if Wine isn't running. Thanks, Scott Ritchie
Re: gdi32: PlgBlt implementation
One more comment on your patch:
> BOOL WINAPI PlgBlt( HDC hdcDest, const POINT *lpPoint,
> -HDC hdcSrc, INT nXDest, INT nYDest, INT nWidth,
> +HDC hdcSrc, INT nXSrc, INT nYSrc, INT nWidth,
> INT nHeight, HBITMAP hbmMask, INT xMask, INT yMask)
> {
> -FIXME("PlgBlt, stub\n");
> -return 1;
> +//save actual mode, set GM_ADVANCED
> +int oldgMode = SetGraphicsMode(hdcDest,GM_ADVANCED);
> +if (oldgMode == 0)
> +return FALSE;
> +
> +//parallelogram coords
> +POINT plg[3];
Variables must be declared at the beginning of the function. We
require strict ANSI C.
--Juan
Re: GSOC proposal - control panel
On Wed, Mar 26, 2008 at 5:57 PM, Owen Rudge <[EMAIL PROTECTED]> wrote: > This sounds like a pretty decent way of going about things. Number 2 was > something I hadn't particularly considered doing initially, but I'll have a > look for the patch that was posted recently and see what I think about it > and how much work is likely to be involved. I think the existing wine/programs/control should display the enumerated applets but I've never really played with it. In ReactOS we wrote a version of control.exe more enhanced version that did as you suggested, creating a listview with item description and name and I think it was rejected before because Alexandre preferred implementing the namespace properly. As for embedding the pseudo-control panel window in the X11 window, here is the patch in question http://www.winehq.org/pipermail/wine-patches/2008-February/050117.html I don't know how Alexandre feels about this either as he did not merge it in to Winehq. Perhaps he wants to do it some other way... -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: [GSoC][RFC] Case Insensitive Filesystem
On Wed, Mar 26, 2008 at 06:10:16PM +0100, Alexandre Julliard wrote: > Marc Andre Tanner <[EMAIL PROTECTED]> writes: > > > Yes that's true the case information is lost but is it really needed? > > If you create the files with the original mixed case you will have to > > scan the whole directory in order to match it to a given filename. > > And if i am not mistaken this is exactly what wine does. > > Yes, and that's precisely because Wine wants to preserve case, so that > tools that look at the filesystem directly see the right thing. If you > are going to store everything lowercase in the filesystem, then we could > just as well do that inside Wine, without a FUSE module. I am not quite sure whether i understand what you mean. Let's say we mount the case insensitive filesystem at ~/.wine/drive_c this will then preserve the case of the filenames the actual data which is all lowercase is in ~/.wine/.drive_c. So as long as the applications are looking for the files in ~/.wine/drive_c everything is fine. Now when you unmount the filesystem or simply look into ~/.wine/.drive_c the case information is 'lost' (it's still there in the extended attributes but no one cares about it). If this is all wrong, then what is the FUSE module supposed to do? Thanks, Marc -- Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
Re: GSOC proposal - control panel
Hi Steven, > I don't really know if we want to just focus on applets or if we > should not aim for having this project provide better integration with > the native desktop. As far as I understand there is some > infrastructure work that will need to be done in shell32 as I don't > think we fully implement the entire Control Panel shellname space. I > expect implementing this properly will take a good bit of time. What > would be cool would be if we fully supported the namespace so that > when you called control.exe it loaded the control panel window and > that could be embedded in a GTK or QT window for use by native > applications. There was a patch floating around on wine-patches a few > months back to allow for embedding a Win32 Wine window inside of an > existing X window that should do the trick. Implementing the proper Control Panel namespace would certainly make the control panel section of the project a much longer one. My initial thoughts were that it may be an easier task to implement the Control Panel in a more old-fashioned style of simply having a list view into which the control panel icons were placed - this would certainly provide a sufficient interface for accessing the control panel. However, it probably would be better in the long run to implement things "properly", and at the very least getting Control Panel integrated with the shell namespace. Integration with native applications certainly looks as though it would provide an added challenge to that project, but is an interesting idea that could work quite nicely. > As far as migration of the stuff in winecfg and other programs go, I > think starting with the Add/Remove applet is a good. I don't think it > would be too hard to take all of the current logic in > wine/programs/uninstall and wrap it in a proper applet. We want to > make sure that we don't introduce any sort of regression when we make > the switch over so reusing that code would be a good place to start. Indeed, my plan was to make use of appropriate Wine tools where they existed, such as in the case of the uninstaller, and flesh them out into fully-featured control panel applets. > So to recap, (this just goes for for me) I think the project should be > laid out as follows > > 1. A fully working Control Panel Namespace > 2. The ability to embed the Control Panel window in a native window > 3. Have a collection of applets to configure wine This sounds like a pretty decent way of going about things. Number 2 was something I hadn't particularly considered doing initially, but I'll have a look for the patch that was posted recently and see what I think about it and how much work is likely to be involved. Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: gdi32: PlgBlt implementation
Hello Nikolay,
thanks for the patch.
Nikolay Sivov wrote:
> Changelog:
> gdi32: initial implementation using coord transformation and MaskBlt
> patch is made in Windows using TortoiseCVS functionality (all that
> I can use at this moment, shouldn't be a problem I hope)
No that's not a problem as long as you do the cvs diff from the top
level wine directory.
Please do not use C++ style comments but the traditional /* */.
bye
michael
>
> Index: bitblt.c
> ===
> RCS file: /home/wine/wine/dlls/gdi32/bitblt.c,v
> retrieving revision 1.4
> diff -u -r1.4 bitblt.c
> --- bitblt.c18 Sep 2007 10:32:56 -1.4
> +++ bitblt.c26 Mar 2008 21:19:31 -
> @@ -26,6 +26,9 @@
> #include "gdi_private.h"
> #include "wine/debug.h"
>
> +#include
> +#include
> +
> WINE_DEFAULT_DEBUG_CHANNEL(bitblt);
>
>
> @@ -522,9 +525,72 @@
> *
> */
> BOOL WINAPI PlgBlt( HDC hdcDest, const POINT *lpPoint,
> -HDC hdcSrc, INT nXDest, INT nYDest, INT nWidth,
> +HDC hdcSrc, INT nXSrc, INT nYSrc, INT nWidth,
> INT nHeight, HBITMAP hbmMask, INT xMask, INT yMask)
> {
> -FIXME("PlgBlt, stub\n");
> -return 1;
> +//save actual mode, set GM_ADVANCED
> +int oldgMode = SetGraphicsMode(hdcDest,GM_ADVANCED);
> +if (oldgMode == 0)
> +return FALSE;
> +
> +//parallelogram coords
> +POINT plg[3];
> +memcpy(plg,lpPoint,sizeof(POINT)*3);
> +//rect coords
> +POINT rect[3];
> +rect[0].x = nXSrc;
> +rect[0].y = nYSrc;
> +rect[1].x = nXSrc + nWidth;
> +rect[1].y = nYSrc;
> +rect[2].x = nXSrc;
> +rect[2].y = nYSrc + nHeight;
> +//calc XFORM matrix to transform hdcDest -> hdcSrc (parallelogram
> to rectangle)
> +XFORM xf;
> +//determinant
> +FLOAT det = (FLOAT)(rect[1].x*(rect[2].y - rect[0].y) -
> rect[2].x*(rect[1].y - rect[0].y) - rect[0].x*(rect[2].y - rect[1].y));
> +
> +if (fabs(det) < FLT_EPSILON)
> +{
> +SetGraphicsMode(hdcDest,oldgMode);
> +return FALSE;
> +}
> +
> +TRACE("hdcSrc=%p %d,%d,%dx%d -> hdcDest=%p %d,%d,%d,%d,%d,%d\n",
> +hdcSrc, nXSrc, nYSrc, nWidth, nHeight, hdcDest, plg[0].x,
> plg[0].y, plg[1].x, plg[1].y, plg[2].x, plg[2].y);
> +
> +//X components
> +xf.eM11 = (plg[1].x*(rect[2].y - rect[0].y) - plg[2].x*(rect[1].y -
> rect[0].y) - plg[0].x*(rect[2].y - rect[1].y)) / det;
> +xf.eM21 = (rect[1].x*(plg[2].x - plg[0].x) - rect[2].x*(plg[1].x -
> plg[0].x) - rect[0].x*(plg[2].x - plg[1].x)) / det;
> +xf.eDx = (rect[0].x*(rect[1].y*plg[2].x - rect[2].y*plg[1].x) -
> + rect[1].x*(rect[0].y*plg[2].x - rect[2].y*plg[0].x) +
> + rect[2].x*(rect[0].y*plg[1].x - rect[1].y*plg[0].x)
> + ) / det;
> +
> +//Y components
> +xf.eM12 = (plg[1].y*(rect[2].y - rect[0].y) - plg[2].y*(rect[1].y -
> rect[0].y) - plg[0].y*(rect[2].y - rect[1].y)) / det;
> +xf.eM22 = (plg[1].x*(rect[2].y - rect[0].y) - plg[2].x*(rect[1].y -
> rect[0].y) - plg[0].x*(rect[2].y - rect[1].y)) / det;
> +xf.eDy = (rect[0].x*(rect[1].y*plg[2].y - rect[2].y*plg[1].y) -
> + rect[1].x*(rect[0].y*plg[2].y - rect[2].y*plg[0].y) +
> + rect[2].x*(rect[0].y*plg[1].y - rect[1].y*plg[0].y)
> + ) / det;
> +
> +XFORM SrcXf;
> +GetWorldTransform(hdcSrc,&SrcXf);
> +CombineTransform(&xf,&xf,&SrcXf);
> +
> +//save actual dest transform
> +XFORM oldDestXf;
> +GetWorldTransform(hdcDest,&oldDestXf);
> +//
> +SetWorldTransform(hdcDest,&xf);
> +//now destination and source DCs use same coords
> +MaskBlt(hdcDest,nXSrc,nYSrc,nWidth,nHeight,
> +hdcSrc, nXSrc,nYSrc,
> +hbmMask,xMask,yMask,
> +SRCCOPY);
> +//restore dest DC
> +SetWorldTransform(hdcDest,&oldDestXf);
> +SetGraphicsMode(hdcDest,oldgMode);
> +
> +return TRUE;
> }
>
>
>
Re: GSOC proposal - control panel
Hi Owen, On Wed, Mar 26, 2008 at 5:27 PM, Owen Rudge <[EMAIL PROTECTED]> wrote: > interested in working on some other applets, such as an Add/Remove Programs > applet, or a Multimedia applet. Obviously, there wouldn't necessarily be > time to implement all of these, so my intention would be to get the main > control panel and basic Wine control panel applets from winecfg working well > first, and then look at other applets that could be implemented. > > I've developed applications and, indeed, Control Panel applets for Windows > for many years now (I started programming using the Windows API when I was > 12!), so I feel confident that this is a task I would be able to handle. I > believe that a good configuration interface for Wine that supports > third-party control panels is something that would be very useful for > end-users. > > If anyone has any comments or suggestions regarding my proposal, I'd very > much appreciate any feedback. I don't really know if we want to just focus on applets or if we should not aim for having this project provide better integration with the native desktop. As far as I understand there is some infrastructure work that will need to be done in shell32 as I don't think we fully implement the entire Control Panel shellname space. I expect implementing this properly will take a good bit of time. What would be cool would be if we fully supported the namespace so that when you called control.exe it loaded the control panel window and that could be embedded in a GTK or QT window for use by native applications. There was a patch floating around on wine-patches a few months back to allow for embedding a Win32 Wine window inside of an existing X window that should do the trick. As far as migration of the stuff in winecfg and other programs go, I think starting with the Add/Remove applet is a good. I don't think it would be too hard to take all of the current logic in wine/programs/uninstall and wrap it in a proper applet. We want to make sure that we don't introduce any sort of regression when we make the switch over so reusing that code would be a good place to start. So to recap, (this just goes for for me) I think the project should be laid out as follows 1. A fully working Control Panel Namespace 2. The ability to embed the Control Panel window in a native window 3. Have a collection of applets to configure wine I don't know who is mentoring this project so I think we should get their thoughts on it. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
GSOC proposal - control panel
Hi everyone, I'm intending to apply for a Google Summer of Code placement working on the Wine control panel support. My main intention is to work on a proper Control Panel application for Wine that accepts standard .cpl files, and turn winecfg's configuration sections into appropriate control panels. (I notice that pure_evil @ mail.bg has been doing some work on this - if I were to get accepted to work on this, then I would like to continue his line of work, or assist him with it.) However, as I don't believe that project alone would necessarily take up an entire summer, my intention would also be to work on some new control panel applets for Wine. The examples given on the GSOC wiki pages (basic desktop/screen resizing, general network information, and font details) would be good applets for me to implement, but I would also be interested in working on some other applets, such as an Add/Remove Programs applet, or a Multimedia applet. Obviously, there wouldn't necessarily be time to implement all of these, so my intention would be to get the main control panel and basic Wine control panel applets from winecfg working well first, and then look at other applets that could be implemented. I've developed applications and, indeed, Control Panel applets for Windows for many years now (I started programming using the Windows API when I was 12!), so I feel confident that this is a task I would be able to handle. I believe that a good configuration interface for Wine that supports third-party control panels is something that would be very useful for end-users. If anyone has any comments or suggestions regarding my proposal, I'd very much appreciate any feedback. Regards, -- Owen Rudge http://www.owenrudge.net/
Re: gdi32-related commit between 0.9.57<->0.9.58 broken .NET2/Systems.Windows.Forms
--- On Wed, 26/3/08, Huw Davies <[EMAIL PROTECTED]> wrote: > > If ukai is affected, I would suspect uming (also from > Arphic) > > would be the same? and how many non-english fonts one > want to > > "work-around" like this? > > I've not seen any problems with uming. Most > 'non-english' fonts will > work fine. There's something very specific about ukai > that causes > native gdiplis to have problems. > > > > Actually I've just attached a hack to the > bug, try that > > > instead. > > > > Thanks - but I also have uming, and a a fair number of > other fonts > > shipped from fedora for non-english. (over 100). > > Please try the patch and report back. Yes, your patch works alright - it is just ukai and nothing else. I'll put it on the bug report as well. Ukai (or rather, the original Arphic kai font) was the first commercial quality chinese font released under an open license, so you are going to have a lot of people - 20% of the world is Chinese, and also linux is rather more officially popular in China due to licensing/cost/idealological reasons and some non-chinese will install "everything" - being affected by this. I don't know if it is ukai-specific or any Arphic kai derivatives, but if it affects any Arphic kai derivatives, filtering by font name as your patch did won't be effective. __ Sent from Yahoo! Mail. More Ways to Keep in Touch. http://uk.docs.yahoo.com/nowyoucan.html
Re: MinGW cross compilation fails for d3dx9_36/tests
James Hawkins wrote: > On Tue, Mar 25, 2008 at 4:27 AM, Paul Vriens <[EMAIL PROTECTED]> wrote: >> James Hawkins wrote: >> > On Tue, Mar 25, 2008 at 4:08 AM, Paul Vriens <[EMAIL PROTECTED]> wrote: >> >> Hi, >> >> >> >> We didn't have a new winetest executable for the last few days. MinGW >> doesn't >> >> know anything about a d3dx9 dll (yet) that's imported in the d3dx9_36 >> tests. >> >> >> >> Especially while in the process of getting ready for 1.0 we should have >> winetest >> >> run as much as possible. >> >> >> >> My main focus will be adding tests btw until 1.0 is out. These will be >> both >> >> tests to proof the correctness of the current implementation as well as >> tests to >> >> show missing stuff. There are loads of functions for which we have no >> tests yet >> >> and with the 1.0 in sight I think it becomes very important to have >> tests for >> >> virtually every function we (have) implement(ed). >> >> >> > >> > While that's a worthy goal, I think a better short-term goal for the >> > run up to 1.0 is to fix the current failing tests in Windows. >> > >> But either way we need an up-to-date winetest executable ;-) >> > > Are you currently working on this? Is it a problem that needs to be > fixed on the mingw side? > It's indeed a mingw issue and has to be fixed on that side. I've never touched mingw so I'm relying on either Hans Leidekker, Stefan Leichter or Paul Millar to take this up. Cheers, Paul (Vriens).
Re: MinGW cross compilation fails for d3dx9_36/tests
On Tue, Mar 25, 2008 at 4:27 AM, Paul Vriens <[EMAIL PROTECTED]> wrote: > > James Hawkins wrote: > > On Tue, Mar 25, 2008 at 4:08 AM, Paul Vriens <[EMAIL PROTECTED]> wrote: > >> Hi, > >> > >> We didn't have a new winetest executable for the last few days. MinGW > doesn't > >> know anything about a d3dx9 dll (yet) that's imported in the d3dx9_36 > tests. > >> > >> Especially while in the process of getting ready for 1.0 we should have > winetest > >> run as much as possible. > >> > >> My main focus will be adding tests btw until 1.0 is out. These will be > both > >> tests to proof the correctness of the current implementation as well as > tests to > >> show missing stuff. There are loads of functions for which we have no > tests yet > >> and with the 1.0 in sight I think it becomes very important to have > tests for > >> virtually every function we (have) implement(ed). > >> > > > > While that's a worthy goal, I think a better short-term goal for the > > run up to 1.0 is to fix the current failing tests in Windows. > > > But either way we need an up-to-date winetest executable ;-) > Are you currently working on this? Is it a problem that needs to be fixed on the mingw side? -- James Hawkins
dlls/user32/tests/cursoricon.c - test succeeded inside todo block
Anyone else seeing this? ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p user32_test.exe.so cursoricon.c && touch cursoricon.ok cursoricon.c:656: Test succeeded inside todo block: No hbmColor! make: *** [cursoricon.ok] Error 1
Re: Trouble in compiling Wine 0.9.57 and 0.9.58 on Solaris 10 08/07
Am Mittwoch, 26. März 2008 10:57:56 schrieb Новиков Роман Константинович: > After 40 minutes of the compilation the process halted with messages: > wined3d_private.h: In function `float_32_to_16': > wined3d_private.h:159: warning: implicit declaration of function `isinf' > wined3d_main.c: At top level: > wined3d_main.c:271: warning: visibility attribute not supported in this > configuration; ignored > (the last string repeated for many times) > I suppose the situation is connected with Solaris 'isinf' but I am too > far from programming under UNIX... isinf is a function / macro which returns wether or not a float is positive infinite or negative infinite. I think it is a standard C function. Maybe solaris declares it in some header that needs to be included, like math.h?
Re: [GSoC][RFC] Case Insensitive Filesystem
Marc Andre Tanner <[EMAIL PROTECTED]> writes: > Yes that's true the case information is lost but is it really needed? > If you create the files with the original mixed case you will have to > scan the whole directory in order to match it to a given filename. > And if i am not mistaken this is exactly what wine does. Yes, and that's precisely because Wine wants to preserve case, so that tools that look at the filesystem directly see the right thing. If you are going to store everything lowercase in the filesystem, then we could just as well do that inside Wine, without a FUSE module. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [GSoC][RFC] Case Insensitive Filesystem
On Wed, Mar 26, 2008 at 12:49:16PM +0100, Francois Gouget wrote: > On Tue, 25 Mar 2008, Marc Andre Tanner wrote: > [...] > > The filesystem converts every path to lower case before further > > operations take place. On file creation the original filename is > > stored in an extended attribute and later returned upon request. > > Shouldn't it be the other way around? I guess the way you've done it is > simpler because you can simply rely on the standard kernel code to > ensure filename uniqueness, but it also means that anyone accessing the > underlying files directly will lose the case information. Yes that's true the case information is lost but is it really needed? If you create the files with the original mixed case you will have to scan the whole directory in order to match it to a given filename. And if i am not mistaken this is exactly what wine does. Note also that in the current form having files with upper case letters in the underlying directory will cause problems (i will probably just ignore them in readdir for now). Another quite crazy idea is to transform the whole directory to lowercase on mount and then on unmount back to the original mixed case representation. That would preserve the case information, but the mount/unmount will be quite expensive and probably cause some problems if someone is messing around with de underlying directory directly. By the way there is now a git repository available for those who want to play with it. git clone git://repo.or.cz/ciopfs.git Regards, Marc -- Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
Re: gdi32-related commit between 0.9.57<->0.9.58 broken .NET2/Systems.Windows.Forms
On Wed, Mar 26, 2008 at 04:38:26PM +, Hin-Tak Leung wrote: > --- On Wed, 26/3/08, Huw Davies <[EMAIL PROTECTED]> wrote: > But, OTOH, should one expose the whole of fontconfig-available > fonts to wine? A lot of them may be dubious to various extent. Well we already did that anyway. It was just the native gdiplus apps didn't see them because of a bug that this commit fixed. > If ukai is affected, I would suspect uming (also from Arphic) > would be the same? and how many non-english fonts one want to > "work-around" like this? I've not seen any problems with uming. Most 'non-english' fonts will work fine. There's something very specific about ukai that causes native gdiplis to have problems. > > Actually I've just attached a hack to the bug, try that > > instead. > > Thanks - but I also have uming, and a a fair number of other fonts > shipped from fedora for non-english. (over 100). Please try the patch and report back. Huw. -- Huw Davies [EMAIL PROTECTED]
Fw: Re: Google Summer of Code 2008 - joined openprinting+wine project?
Hi, anybody on wine-devel want to take this on and make this more concrete? --- On Wed, 26/3/08, Till Kamppeter <[EMAIL PROTECTED]> wrote: > From: Till Kamppeter <[EMAIL PROTECTED]> > Subject: Re: Google Summer of Code 2008 - Some general instructions for > reviewing the student's applications > To: "Hin-Tak Leung" <[EMAIL PROTECTED]> > Cc: "Casey Schaufler" <[EMAIL PROTECTED]>, "'Glen Petrie'" <[EMAIL > PROTECTED]>, "Rik van Riel" <[EMAIL PROTECTED]>, "Jeff Licquia" <[EMAIL > PROTECTED]>, "Jon Masters" <[EMAIL PROTECTED]>, "Jonathan Riddell" <[EMAIL > PROTECTED]>, "Josef Spillner" <[EMAIL PROTECTED]>, [EMAIL PROTECTED], "Pekka > Enberg" <[EMAIL PROTECTED]> > Date: Wednesday, 26 March, 2008, 4:34 PM > Hin-Tak Leung wrote: > > Hi Till and the rest of the gang. > > > > Two people had got in touch with with about the > IJS+PDF workflow, and I replied. > > (sorry I don't check the "other" e-mail > often - I probably should set up re-direction). > > > > Great! > > > I thought I should also mentioned that it has just > came to my attention in some unrelated discussion on > wine-devel - been doing some non-printing wine-related > stuff lately - that there *was* a google summer of code > 2007 project for a > > wine-based native printer driver proxy - this is the > sort of thing I have had in mind > > for a while and I thought it would be interesting to > do but I don't have in-depth > > windows knowledge to make it happen, but the wine > people already did! > > http://google-summer-of-code-2007-wine.googlecode.com/ > > > > I just downloaded the gsoc 2007 printerproxy code. It > seems that it is just for use > > from within wine, but it just might be interesting to > make it more general - via opvp > > or IJS. We should follow up on this. > > If this project still requires coding, it is not too late > to add it as > project idea to the ideas pages of both the Linux > Foundation and WINE > (having it presented at two mentoring organizations raises > the chances > to find a student). > > Our ideas page is a Wiki and you can simply edit it: > > https://www.linux-foundation.org/en/Google_Summer_of_Code > > Till __ Sent from Yahoo! Mail. More Ways to Keep in Touch. http://uk.docs.yahoo.com/nowyoucan.html
Re: Can't determine disk space, install fails
Ahoj Vito / Hi Vit, many thanks for your valuable help! In our case, it depends on the partition size, not on the free space remaining. We've found that on every partition bigger than 64G, the installation fails. Now we are performing an experimental installation in /var/tmp, where /var has only 15G in our case, and it works like a charm. What debugging options could we set to collect symptoms of the problem ? With regards, Pavel Troller > Hi Pavel, > I've ran into similar issues when, for example, I've got more than 64GB > free space on the partition, and the old Win installers just told me > there was -1 bytes free. I'd vote for some Wine (or 3rd party tool) > functionality that would decrease the reported bytes available per > user's request. > > As a temporary solution for such problems, I've used a small partition > for installation with just 2GBs free and it worked for me. I've then > moved the wineprefix into the target partition. > Regards > Vit Hrachovy > > Pavel Troller wrote: > > Hi! > > We have a long-persisting problem there. It persists for many wine > > versions > > and prevents some programs from installing. > > As an example, today my son complained about impossibility to install WoW. > > The installer was not able to determine the free space on the disk (there > > was > > a dash instead of a number in the box) and the Continue button was greyed > > out, > > so it was not possible to proceed. > > There are other cases, in which the installers say that there is not > > enough > > space on the disk and fail. Of course there is enough space, but the > > installer > > is not able to find it. > > Especially WoW has Gold rating and these problems are not mentioned, so I > > don't think that this is a common wine problem, thus I'm not going to open > > a bug for it. I'm begging for a hint instead, what to try to find the cause > > of the problem. > > Wine is always manually compiled and it runs on a "generic Linux system", > > not on any particular, publicly known distro. > > > > With regards, Pavel Troller > > > > > >
Re: MinGW cross compilation fails for d3dx9_36/tests
On Tue, Mar 25, 2008 at 4:08 AM, Paul Vriens <[EMAIL PROTECTED]> wrote: > Hi, > > We didn't have a new winetest executable for the last few days. MinGW doesn't > know anything about a d3dx9 dll (yet) that's imported in the d3dx9_36 tests. > > Especially while in the process of getting ready for 1.0 we should have > winetest > run as much as possible. > > My main focus will be adding tests btw until 1.0 is out. These will be both > tests to proof the correctness of the current implementation as well as > tests to > show missing stuff. There are loads of functions for which we have no tests > yet > and with the 1.0 in sight I think it becomes very important to have tests for > virtually every function we (have) implement(ed). Might make a good SoC project?
Re: gdi32-related commit between 0.9.57<->0.9.58 broken .NET2/Systems.Windows.Forms
--- On Wed, 26/3/08, Huw Davies <[EMAIL PROTECTED]> wrote: > I think it's a bug in *native* gdiplus. If you install > ukai.ttf on > Windows then apps that use gdiplus will crash too. oh. I suppose it is fair enough that installing any fonts on windows can have bad effects. But, OTOH, should one expose the whole of fontconfig-available fonts to wine? A lot of them may be dubious to various extent. If ukai is affected, I would suspect uming (also from Arphic) would be the same? and how many non-english fonts one want to "work-around" like this? > > > > Do you by any chance have the font > 'ukai.ttf' > > > installed? If so could > > > you try removing it from your fontconfig path and > see if > > > that helps? > > > > Yes, I have ukai.ttf on my system (and others came > with Fedora 8), > > but I am running wine in LANG=en_US.UTF-8 . I'll > give your suggestion a > > try. > > Actually I've just attached a hack to the bug, try that > instead. Thanks - but I also have uming, and a a fair number of other fonts shipped from fedora for non-english. (over 100). __ Sent from Yahoo! Mail. More Ways to Keep in Touch. http://uk.docs.yahoo.com/nowyoucan.html
Re: DLL exports... HELP?!
Wow :-). I have almost wanted to suggest such a native wine-based printer driver as a linux foundation/openprinting GOSC project (I am one of the mentors under the openprinting umbrella https://www.linux-foundation.org/en/Google_Summer_of_Code). I am glad I didn't :-). I suppose under the terms of the license you don't mind we do some work based on your work? I'll let "the other printing folks" know. --- On Wed, 26/3/08, Marcel Partap <[EMAIL PROTECTED]> wrote: > From: Marcel Partap <[EMAIL PROTECTED]> > Subject: Re: DLL exports... HELP?! > To: [EMAIL PROTECTED] > Cc: wine-devel@winehq.org > Date: Wednesday, 26 March, 2008, 11:51 AM > Hi Stefanov, > attached is the code of a standalone proxy DLL I developed > last year during SoC, have a look > especially at the makefile for cross-compilation... > regards marcel. > > -- > >"Obstacles are those frightful things you see when > you take your eyes off your goal." > >-- Henry Ford (1863-1947) >Change the world! Vote revolution: > http://hfopi.org/vote-future > ___ Rise to the challenge for Sport Relief with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/
Re: [PATCH 1 of 2] explorer: add /startfile switch for starting files from file managers
On Wed, Mar 26, 2008 at 10:04 AM, Alexandre Julliard <[EMAIL PROTECTED]> wrote: > "Vincent Povirk" <[EMAIL PROTECTED]> writes: > > > > My understanding is that start.exe will not work because it must be > > compatible with the windows version of start. In any case, I don't > > think I could usefully share code with the rest of start. > > It has to be compatible, but adding new options that don't exist on > Windows shouldn't be a problem. That's what you'd have to do in explorer > too anyway. > Ok, I'll have to look at this in more detail when I am at home. > > I would like to keep the distinction between .exe and other files so > > that bug 5368 can be fixed. > > I'm not sure I understand why you need that for 5368. > It's more the combination of 5224 and 5368. 5224 requires quotes around the exe filename in the command line, even if the filename contains no spaces. ShellExecuteEx does not let me put in the quotes. I think I tested start.exe on windows and it also did not let me add quotes, but I will check again. 5368 isn't very clear (someone apparently wants to make windows file associations somehow work like those on Linux), but it seems like it could be partially solved by having something that users can open non-exe files with in nautilus to start it with the file association in wine. I think it makes sense from a user perspective to do this by starting them with "wine". For that to work, nautilus needs to be able to start them with the same method as exe files. I don't think starting non-exe files should be considered a separate feature. wine.desktop really should do what windows explorer would do, and that's the problem I want to solve here. -- Vincent Povirk
Re: gdi32-related commit between 0.9.57<->0.9.58 broken .NET2/Systems.Windows.Forms
On Wed, Mar 26, 2008 at 03:33:27PM +, Hin-Tak Leung wrote: > --- On Wed, 26/3/08, Huw Davies <[EMAIL PROTECTED]> wrote: > > Well yes, but that doesn't actually mean the patch is > > incorrect. > > Well, it is certainly doing something that the .NET framework doesn't like - > or, maybe exposing a bug elsewhere which wasn't reached due to incompleteness > before. > Can you explain the purpose of your patch? I think it's a bug in *native* gdiplus. If you install ukai.ttf on Windows then apps that use gdiplus will crash too. > > Do you by any chance have the font 'ukai.ttf' > > installed? If so could > > you try removing it from your fontconfig path and see if > > that helps? > > Yes, I have ukai.ttf on my system (and others came with Fedora 8), > but I am running wine in LANG=en_US.UTF-8 . I'll give your suggestion a > try. Actually I've just attached a hack to the bug, try that instead. Thanks, Huw. -- Huw Davies [EMAIL PROTECTED]
Trouble in compiling Wine 0.9.57 and 0.9.58 on Solaris 10 08/07
Hi guys! I've got some trouble with compiling Wine 0.9.57 & 0.9.58 on Solaris 10 08/07 After 40 minutes of the compilation the process halted with messages: wined3d_private.h: In function `float_32_to_16': wined3d_private.h:159: warning: implicit declaration of function `isinf' wined3d_main.c: At top level: wined3d_main.c:271: warning: visibility attribute not supported in this configuration; ignored (the last string repeated for many times) I suppose the situation is connected with Solaris 'isinf' but I am too far from programming under UNIX... My version of gcc is 3.4.3 (Solaris native): bash-3.00# gcc -v Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/specs Configured with: /builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) My configure string is: ./configure --enable-win64 --with-x --x-includes=/usr --x-libraries=/usr I built successfully Wine 0.9.56 and earlier.. What can I do with this? Thanks in advance. Rome
Re: [1/2] shlwapi: added tests for SHCreateStreamOnFile IStream_Read.
On 25/03/2008, Reece Dunn <[EMAIL PROTECTED]> wrote: > This patch adds some basic tests for the Read method of the various > SHCreateStreamOnFile APIs, while making it possible to add other > IStream method tests. > > At the moment, these tests are being skipped on Wine because it is not > returning a valid stream object in the tests. Alexandre: please ignore these patches for now. I am working on a more comprehensive series of tests for the various IStream methods. Thanks, - Reece
Re: prevents WM_DISPLAYCHANGE message being sent when a call to ChangeDisplaySettingsEx fails due to the requested change to the display not occurring.
On 24/03/2008, chris morgan <[EMAIL PROTECTED]> wrote:
> test code run on windows nt4 sp6, messages checked using ms spk++:
>
> DEVMODE dev_mode;
> memset(&dev_mode,0,sizeof(DEVMODE));
> dev_mode.dmSize = sizeof(DEVMODE);
>
> // Get the current display settings
> if (!EnumDisplaySettings(NULL,ENUM_CURRENT_SETTINGS,&dev_mode))
> {
> printf("Could not EnumDisplaySettings, giving up.\n");
> return 0;
> }
>
> // Call ChangeDisplaySettings with the current settings,
> // No WM_DISPLAYCHANGE message sent
> ChangeDisplaySettings(&dev_mode, 0);
>
> // Change something (that works)
> dev_mode.dmBitsPerPel = 32;
>
> // WM_DISPLAYCHANGE message sent
> ChangeDisplaySettings(&dev_mode, 0);
>
> // Change something to an impossible value
> dev_mode.dmBitsPerPel = 999;
>
> // No WM_DISPLAYCHANGE message sent
> ChangeDisplaySettings(&dev_mode, 0);
This should be incorporated into a conformance/regression test. That
way, this bug will not reappear and can also be verified as the
correct behaviour on different versions of Windows.
> +if (width == screen_width && height == screen_height)
> +{
> + return;
> +}
w.r.t. the implementation:
* ChangeDisplaySettings returns a long
(http://msdn2.microsoft.com/en-us/library/ms533260(VS.85).aspx), so
the correct value must be returned on error;
* the fix does not match the test cases (screen size vs colour depth).
In addition, your tests should:
* check that changing the screen resolution causes a
WM_DISPLAYCHANGE message to be sent;
* if there are no other tests, ChangeDisplaySettings should be
checked to see what happens with invalid arguments (for completeness);
* the return value is not checked for expected values (see
http://msdn2.microsoft.com/en-us/library/ms533260(VS.85).aspx);
* GetLastError() is not checked to see what it is set to (see other
tests for examples);
* restore the display settings back to what they were before the tests.
Thanks for improving Wine,
- Reece
Re: gdi32-related commit between 0.9.57<->0.9.58 broken .NET2/Systems.Windows.Forms
--- On Wed, 26/3/08, Huw Davies <[EMAIL PROTECTED]> wrote: > From: Huw Davies <[EMAIL PROTECTED]> > Subject: Re: gdi32-related commit between 0.9.57<->0.9.58 broken > .NET2/Systems.Windows.Forms > To: "Hin-Tak Leung" <[EMAIL PROTECTED]> > Cc: wine-devel@winehq.org > Date: Wednesday, 26 March, 2008, 3:21 PM > On Wed, Mar 26, 2008 at 02:55:07PM +, Hin-Tak Leung > wrote: > > --- On Wed, 26/3/08, Huw Davies > <[EMAIL PROTECTED]> wrote: > > > > > > The error message I got was 'attempt to > read or > > > write protected memory. This is often > > > > an indication that other memory is > corrupt'. > > > > > > Hi, > > > > > > Could you explain how this breaks .NET2, I > can't see > > > why it should at the moment? > > > The purpose of the commit is to do what Windows > does. > > > > I am not entirely sure myself - all I know is I did a > git bisect to find what was > > the problematic commit, and reverting this particular > commit on top of 0.9.58 fixes my problem. > > > > My understanding is that the .NET framework uses the > windows registry font > > entries for font look-ups, according to the discussion > in http://bugs.winehq.org/show_bug.cgi?id=10467#c2, and it > loads fonts directly based on the registry font list and > does its own rendering thing with the font files directly; > > So changing font registry entries break things. > > Well yes, but that doesn't actually mean the patch is > incorrect. Well, it is certainly doing something that the .NET framework doesn't like - or, maybe exposing a bug elsewhere which wasn't reached due to incompleteness before. Can you explain the purpose of your patch? > Do you by any chance have the font 'ukai.ttf' > installed? If so could > you try removing it from your fontconfig path and see if > that helps? Yes, I have ukai.ttf on my system (and others came with Fedora 8), but I am running wine in LANG=en_US.UTF-8 . I'll give your suggestion a try. __ Sent from Yahoo! Mail. More Ways to Keep in Touch. http://uk.docs.yahoo.com/nowyoucan.html
Re: gdi32-related commit between 0.9.57<->0.9.58 broken .NET2/Systems.Windows.Forms
On Wed, Mar 26, 2008 at 02:05:25PM +, Hin-Tak Leung wrote: > I found a .NET2/System.Windows.Forms application which was running alright > in 0.9.56/0.9.57 with the appdb adaptations broke in 0.9.58. So I did a git > bisect > and found that it is a commit to gdi32/freetype.c from Huw Davies which broke > it. > It is known that .NET does some strange things with fonts and font-related > part of > the registry (See http://bugs.winehq.org/show_bug.cgi?id=10467#c2 for > discussion) and > the commit apparently breaks that... I believe I see what that specific > commit does > and how it breaks .NET2, but I am not sure I understand *why* the commit was > accepted > in the first place and what was its purpose... Can somebody explain, and > possibly > either back-out the commit or at least modify it to make it not break stuff? > > commit 0436a5d14abf22af6ec10640496f9e0298a65f69 > Author: Huw Davies <[EMAIL PROTECTED]> > Date: Mon Mar 10 12:31:43 2008 + > > gdi32: Store the Windows path (if it's available) in the font registry > entries. > > The error message I got was 'attempt to read or write protected memory. This > is often > an indication that other memory is corrupt'. Hi, Could you explain how this breaks .NET2, I can't see why it should at the moment? The purpose of the commit is to do what Windows does. Thanks, Huw. -- Huw Davies [EMAIL PROTECTED]
Re: gdi32-related commit between 0.9.57<->0.9.58 broken .NET2/Systems.Windows.Forms
On Wed, Mar 26, 2008 at 02:55:07PM +, Hin-Tak Leung wrote: > --- On Wed, 26/3/08, Huw Davies <[EMAIL PROTECTED]> wrote: > > > > The error message I got was 'attempt to read or > > write protected memory. This is often > > > an indication that other memory is corrupt'. > > > > Hi, > > > > Could you explain how this breaks .NET2, I can't see > > why it should at the moment? > > The purpose of the commit is to do what Windows does. > > I am not entirely sure myself - all I know is I did a git bisect to find what > was > the problematic commit, and reverting this particular commit on top of 0.9.58 > fixes my problem. > > My understanding is that the .NET framework uses the windows registry font > entries for font look-ups, according to the discussion in > http://bugs.winehq.org/show_bug.cgi?id=10467#c2, and it loads fonts directly > based on the registry font list and does its own rendering thing with the > font files directly; > So changing font registry entries break things. Well yes, but that doesn't actually mean the patch is incorrect. Do you by any chance have the font 'ukai.ttf' installed? If so could you try removing it from your fontconfig path and see if that helps? Huw. -- Huw Davies [EMAIL PROTECTED]
Re: gdi32-related commit between 0.9.57<->0.9.58 broken .NET2/Systems.Windows.Forms
--- On Wed, 26/3/08, Huw Davies <[EMAIL PROTECTED]> wrote: > > The error message I got was 'attempt to read or > write protected memory. This is often > > an indication that other memory is corrupt'. > > Hi, > > Could you explain how this breaks .NET2, I can't see > why it should at the moment? > The purpose of the commit is to do what Windows does. I am not entirely sure myself - all I know is I did a git bisect to find what was the problematic commit, and reverting this particular commit on top of 0.9.58 fixes my problem. My understanding is that the .NET framework uses the windows registry font entries for font look-ups, according to the discussion in http://bugs.winehq.org/show_bug.cgi?id=10467#c2, and it loads fonts directly based on the registry font list and does its own rendering thing with the font files directly; So changing font registry entries break things. ___ Rise to the challenge for Sport Relief with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/
Re: kernel32: WideCharToMultiByte: return error on negative dest len (take 2)
"Dan Kegel" <[EMAIL PROTECTED]> writes: >> I don't want to claim ownership for the patch you wrote. > > Don't worry, Alexandre usually gets that right. Maybe, but I don't like it. I really prefer for people to send their own patches instead of having others do it for them. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [2/2] comctl32: tab.c The Item Interior should use HotTracking color not Hilight color (resend).
Alexandre Julliard wrote: >> @@ -1633,7 +1633,7 @@ TAB_DrawItemInterior(const TAB_INFO *inf >>SetTextColor(hdc, (((lStyle & TCS_HOTTRACK) && (iItem == >> infoPtr->iHotTracked) >>&& !(lStyle & TCS_FLATBUTTONS)) >> | (TAB_GetItem(infoPtr, iItem)->dwState & >> TCIS_HIGHLIGHTED)) ? >> -comctl32_color.clrHighlight : >> comctl32_color.clrBtnText); >> +comctl32_color.clrHotTrackingColor : >> comctl32_color.clrBtnText); >> > > Shouldn't you distinguish between TCS_HOTTRACK and TCIS_HIGHLIGHTED > here? I could not find anywhere documentation about TCIS_HIGHLIGHTED... I just changed the registry value "HotTrackingColor" in Windows and after that I have seen that the tab flashes HotTracking color not Hilight. Please tell me right way to fix this mistake. -- Best regards Anatoly Lyutin.
Re: Google Summer of Code - Case Insensitive Filenames
On Tue, Mar 25, 2008 at 9:43 PM, Cesar Izurieta <[EMAIL PROTECTED]> wrote: > > On Tue, Mar 25, 2008 at 12:02 PM, Kai Blin <[EMAIL PROTECTED]> wrote: > > On Tuesday 25 March 2008 17:21:20 Austin English wrote: > > > > > An option yes, but it should not be the default course of action. As > > > Rahyen said, a predictable order should be used, and when there are > > > conflicts, pick the first in that order for presentation through the > > > FUSE system. User can then rename files/delete files to get the one > > > they want (or if possible, have a configuration menu to adjust chosen > > > file order/allow exceptions, etc.). > > Wouldn't it make the most sense to use whichever one was modified last? In most cases. that gives you the right response, eg. you put in a modified executable via patch or similar, and want it to use that version. [snip]
Re: Can't determine disk space, install fails
On Wed, Mar 26, 2008 at 6:49 AM, Pavel Troller <[EMAIL PROTECTED]> wrote: > Hi! > We have a long-persisting problem there. It persists for many wine versions > and prevents some programs from installing. > As an example, today my son complained about impossibility to install WoW. > The installer was not able to determine the free space on the disk (there was > a dash instead of a number in the box) and the Continue button was greyed > out, > so it was not possible to proceed. > There are other cases, in which the installers say that there is not enough > space on the disk and fail. Of course there is enough space, but the > installer > is not able to find it. > Especially WoW has Gold rating and these problems are not mentioned, so I > don't think that this is a common wine problem, thus I'm not going to open > a bug for it. I'm begging for a hint instead, what to try to find the cause > of the problem. > Wine is always manually compiled and it runs on a "generic Linux system", > not on any particular, publicly known distro. > > With regards, Pavel Troller > > > Can you file a bug for this on Wine's bugzilla? [1] I'm really surprised WoW does not install for you, considering it's probably one of the most popular apps out there. [1] http://bugs.winehq.org/
gdi32-related commit between 0.9.57<->0.9.58 broken .NET2/Systems.Windows.Forms
I found a .NET2/System.Windows.Forms application which was running alright in 0.9.56/0.9.57 with the appdb adaptations broke in 0.9.58. So I did a git bisect and found that it is a commit to gdi32/freetype.c from Huw Davies which broke it. It is known that .NET does some strange things with fonts and font-related part of the registry (See http://bugs.winehq.org/show_bug.cgi?id=10467#c2 for discussion) and the commit apparently breaks that... I believe I see what that specific commit does and how it breaks .NET2, but I am not sure I understand *why* the commit was accepted in the first place and what was its purpose... Can somebody explain, and possibly either back-out the commit or at least modify it to make it not break stuff? commit 0436a5d14abf22af6ec10640496f9e0298a65f69 Author: Huw Davies <[EMAIL PROTECTED]> Date: Mon Mar 10 12:31:43 2008 + gdi32: Store the Windows path (if it's available) in the font registry entries. The error message I got was 'attempt to read or write protected memory. This is often an indication that other memory is corrupt'. __ Sent from Yahoo! Mail. More Ways to Keep in Touch. http://uk.docs.yahoo.com/nowyoucan.html
Re: [PATCH 1 of 2] explorer: add /startfile switch for starting files from file managers
"Vincent Povirk" <[EMAIL PROTECTED]> writes: > My understanding is that start.exe will not work because it must be > compatible with the windows version of start. In any case, I don't > think I could usefully share code with the rest of start. It has to be compatible, but adding new options that don't exist on Windows shouldn't be a problem. That's what you'd have to do in explorer too anyway. > I would like to keep the distinction between .exe and other files so > that bug 5368 can be fixed. I'm not sure I understand why you need that for 5368. -- Alexandre Julliard [EMAIL PROTECTED]
Re: wininet: Implement chunked reads.
Hans Leidekker wrote:
> static DWORD HTTPREQ_ReadFile(WININETHANDLEHEADER *hdr, void *buffer, DWORD
> size, DWORD *read)
> {
> WININETHTTPREQW *req = (WININETHTTPREQW*)hdr;
> +static WCHAR encoding[20];
> +DWORD buflen = sizeof(encoding);
> +static const WCHAR szChunked[] = {'c','h','u','n','k','e','d',0};
>
encoding shouldn't be static.
--
Rob Shearman
Re: Can't determine disk space, install fails
Hi Pavel, I've ran into similar issues when, for example, I've got more than 64GB free space on the partition, and the old Win installers just told me there was -1 bytes free. I'd vote for some Wine (or 3rd party tool) functionality that would decrease the reported bytes available per user's request. As a temporary solution for such problems, I've used a small partition for installation with just 2GBs free and it worked for me. I've then moved the wineprefix into the target partition. Regards Vit Hrachovy Pavel Troller wrote: > Hi! > We have a long-persisting problem there. It persists for many wine versions > and prevents some programs from installing. > As an example, today my son complained about impossibility to install WoW. > The installer was not able to determine the free space on the disk (there was > a dash instead of a number in the box) and the Continue button was greyed out, > so it was not possible to proceed. > There are other cases, in which the installers say that there is not enough > space on the disk and fail. Of course there is enough space, but the installer > is not able to find it. > Especially WoW has Gold rating and these problems are not mentioned, so I > don't think that this is a common wine problem, thus I'm not going to open > a bug for it. I'm begging for a hint instead, what to try to find the cause > of the problem. > Wine is always manually compiled and it runs on a "generic Linux system", > not on any particular, publicly known distro. > > With regards, Pavel Troller > >
Re: [1/2] reg: Implement basic 'reg add'. [try 2]
"Andrew Riedi" <[EMAIL PROTECTED]> writes:
> +{
> +LPCTSTR lpSubKey;
Please don't use TCHAR types.
> +static const WCHAR hkcrW[] = {'h','k','c','r',0};
> +static const WCHAR hkcuW[] = {'h','k','c','u',0};
> +static const WCHAR hklmW[] = {'h','k','l','m',0};
> +static const WCHAR hkuW[] = {'h','k','u',0};
> +static const WCHAR hkpdW[] = {'h','k','p','d',0};
> +static const WCHAR hkccW[] = {'h','k','c','c',0};
> +static const WCHAR hkddW[] = {'h','k','d','d',0};
> +
> +/* Determine key type. */
> +if (CompareString(LOCALE_NEUTRAL, NORM_IGNORECASE, key_name, 4, hkcrW,
> 4) == CSTR_EQUAL)
> +*hKey = HKEY_CLASSES_ROOT;
> +else if (CompareString(LOCALE_NEUTRAL, NORM_IGNORECASE, key_name, 4,
> hkcuW, 4) == CSTR_EQUAL)
> +*hKey = HKEY_CURRENT_USER;
> +else if (CompareString(LOCALE_NEUTRAL, NORM_IGNORECASE, key_name, 4,
> hklmW, 4) == CSTR_EQUAL)
> +*hKey = HKEY_LOCAL_MACHINE;
> +else if (CompareString(LOCALE_NEUTRAL, NORM_IGNORECASE, key_name, 3,
> hkuW, 3) == CSTR_EQUAL)
> +*hKey = HKEY_USERS;
> +else if (CompareString(LOCALE_NEUTRAL, NORM_IGNORECASE, key_name, 4,
> hkpdW, 4) == CSTR_EQUAL)
> +*hKey = HKEY_PERFORMANCE_DATA;
> +else if (CompareString(LOCALE_NEUTRAL, NORM_IGNORECASE, key_name, 4,
> hkccW, 4) == CSTR_EQUAL)
> +*hKey = HKEY_CURRENT_CONFIG;
> +else if (CompareString(LOCALE_NEUTRAL, NORM_IGNORECASE, key_name, 4,
> hkddW, 4) == CSTR_EQUAL)
> +*hKey = HKEY_DYN_DATA;
You should use some sort of array instead of duplicating all that code,
and you need to check the next character of the string too.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: kernel32: WideCharToMultiByte: return error on negative dest len (take 2)
On Wed, Mar 26, 2008 at 6:38 AM, Michael Stefaniuc <[EMAIL PROTECTED]> wrote: > > The first step, as Alexandre says, is to add the test with a todo_wine > > around the negative destlen test. > > I would have done it but I'm more than happy to let you run with it. > > Please go ahead and resubmit the patch with todo_wine around it. Done. > I don't want to claim ownership for the patch you wrote. Don't worry, Alexandre usually gets that right.
Can't determine disk space, install fails
Hi! We have a long-persisting problem there. It persists for many wine versions and prevents some programs from installing. As an example, today my son complained about impossibility to install WoW. The installer was not able to determine the free space on the disk (there was a dash instead of a number in the box) and the Continue button was greyed out, so it was not possible to proceed. There are other cases, in which the installers say that there is not enough space on the disk and fail. Of course there is enough space, but the installer is not able to find it. Especially WoW has Gold rating and these problems are not mentioned, so I don't think that this is a common wine problem, thus I'm not going to open a bug for it. I'm begging for a hint instead, what to try to find the cause of the problem. Wine is always manually compiled and it runs on a "generic Linux system", not on any particular, publicly known distro. With regards, Pavel Troller
Re: [PATCH 1 of 2] explorer: add /startfile switch for starting files from file managers
"Vincent Povirk" <[EMAIL PROTECTED]> writes: > My last attempt created a new winelib program; apparently this > functionality fits in explorer. start.exe is probably more appropriate. Either way you are trying to make it too smart; it should take a straight Unix path, and not try to guess anything. -- Alexandre Julliard [EMAIL PROTECTED]
Re: kernel32: WideCharToMultiByte: return error on negative dest len (take 2)
Dan Kegel wrote: > On Wed, Mar 26, 2008 at 4:04 AM, Michael Stefaniuc <[EMAIL PROTECTED]> wrote: >> > This would require reviewing all uses of WideCharToMultiByte in Wine, >> > many places get this wrong. Unless you have an app that requires this >> > fix I'd suggest to leave the test as todo_wine for now. >> >> Would that be a good janitorial work to be done before Wine 1.0? I feel >> like I'm getting tired of translating ... > > Sure. A quick grep finds some obvious ones: > > $ find . -name '*.c' | xargs grep WideCharToMultiByte | grep ' -1, NULL, > NULL)' > The first step, as Alexandre says, is to add the test with a todo_wine > around the negative destlen test. > I would have done it but I'm more than happy to let you run with it. Please go ahead and resubmit the patch with todo_wine around it. I don't want to claim ownership for the patch you wrote. bye michael
Re: kernel32: WideCharToMultiByte: return error on negative dest len (take 2)
On Wed, Mar 26, 2008 at 4:04 AM, Michael Stefaniuc <[EMAIL PROTECTED]> wrote: > > This would require reviewing all uses of WideCharToMultiByte in Wine, > > many places get this wrong. Unless you have an app that requires this > > fix I'd suggest to leave the test as todo_wine for now. > > Would that be a good janitorial work to be done before Wine 1.0? I feel > like I'm getting tired of translating ... Sure. A quick grep finds some obvious ones: $ find . -name '*.c' | xargs grep WideCharToMultiByte | grep ' -1, NULL, NULL)' ./wininet/urlcache.c:WideCharToMultiByte(CP_ACP, 0, lpszLocalFileName, -1, achFile, -1, NULL, NULL); ./mshtml/editor.c:WideCharToMultiByte(CP_ACP, 0, V_BSTR(in), -1, stra, -1, NULL, NULL); ./mshtml/persist.c:WideCharToMultiByte(CP_ACP, 0, headers, -1, data, -1, NULL, NULL); ./mshtml/install.c:WideCharToMultiByte(CP_ACP, 0, file_name, -1, file_name_a, -1, NULL, NULL); ./mshtml/nsio.c:WideCharToMultiByte(CP_ACP, 0, container->doc->mime, -1, This->content, -1, NULL, NULL); ./mshtml/navigate.c:WideCharToMultiByte(CP_ACP, 0, szStatusText, -1, This->nschannel->content, -1, NULL, NULL); ./advapi32/cred.c:string_len = WideCharToMultiByte(CP_ACP, 0, CredentialW->TargetName, -1, CredentialA->TargetName, -1, NULL, NULL); ./advapi32/cred.c:string_len = WideCharToMultiByte(CP_ACP, 0, CredentialW->Comment, -1, CredentialA->Comment, -1, NULL, NULL); ./advapi32/cred.c:string_len = WideCharToMultiByte(CP_ACP, 0, CredentialW->TargetAlias, -1, CredentialA->TargetAlias, -1, NULL, NULL); ./advapi32/cred.c:string_len = WideCharToMultiByte(CP_ACP, 0, CredentialW->UserName, -1, CredentialA->UserName, -1, NULL, NULL); ./urlmon/sec_mgr.c:WideCharToMultiByte(CP_ACP, 0, url, -1, (LPSTR)pbSecurityId, -1, NULL, NULL) (I peeked at that last one. The code is enforcing the length limit itself and then telling WideCharToMultiByte that there's no limit. May as well pass the proper limit to WideCharToMultiByte and let it do the length checking?) The first step, as Alexandre says, is to add the test with a todo_wine around the negative destlen test. I would have done it but I'm more than happy to let you run with it. I haven't quite figured out the fix for bug 9039, this is just something I noticed along the way. - Dan
Re: [PATCH 1 of 2] explorer: add /startfile switch for starting files from file managers
My understanding is that start.exe will not work because it must be compatible with the windows version of start. In any case, I don't think I could usefully share code with the rest of start. Attempting to guess between unix and windows paths is not necessary (I saw no reason not to do it, but I can remove it). I would like to keep the distinction between .exe and other files so that bug 5368 can be fixed. On Wed, Mar 26, 2008 at 8:50 AM, Alexandre Julliard <[EMAIL PROTECTED]> wrote: > "Vincent Povirk" <[EMAIL PROTECTED]> writes: > > > My last attempt created a new winelib program; apparently this > > functionality fits in explorer. > > start.exe is probably more appropriate. Either way you are trying to > make it too smart; it should take a straight Unix path, and not try to > guess anything. > > -- > Alexandre Julliard > [EMAIL PROTECTED] > -- Vincent Povirk
Re: DLL exports... HELP?!
Hi Stefanov, attached is the code of a standalone proxy DLL I developed last year during SoC, have a look especially at the makefile for cross-compilation... regards marcel. -- "Obstacles are those frightful things you see when you take your eyes off your goal." -- Henry Ford (1863-1947) Change the world! Vote revolution: http://hfopi.org/vote-future printerproxydriver.tar.gz Description: application/gzip
Re: [GSoC][RFC] Case Insensitive Filesystem
On Tue, 25 Mar 2008, Marc Andre Tanner wrote: [...] > The filesystem converts every path to lower case before further > operations take place. On file creation the original filename is > stored in an extended attribute and later returned upon request. Shouldn't it be the other way around? I guess the way you've done it is simpler because you can simply rely on the standard kernel code to ensure filename uniqueness, but it also means that anyone accessing the underlying files directly will lose the case information. -- Francois Gouget <[EMAIL PROTECTED]> http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux
Re: DLL exports... HELP?!
On Wednesday 26 March 2008 12:39:39 pm you wrote: > If you build a wine dll inside the wine source tree we use gcc in > combination with some wine magic for compilation. Exporting of functions in > that case happens through a '.spec' file. > > When you want to work outside the wine tree (as it can be more convenient) > you could also use 'winegcc' for building a library. It will handle all the > magic for you. > > Roderick cplskeleton.spec: " 1 stdcall CPlApplet(long long long long) " " libcplskeleton.def ; File generated automatically from ./cplskeleton.spec; do not edit! LIBRARY cplskeleton.dll EXPORTS [EMAIL PROTECTED] @1 "
Re: kernel32: WideCharToMultiByte: return error on negative dest len (take 2)
Michael Stefaniuc <[EMAIL PROTECTED]> writes: > Would that be a good janitorial work to be done before Wine 1.0? I feel > like I'm getting tired of translating ... Sure, if you feel like doing it go ahead. I'm not sure the fix will go in before 1.0, but already fixing as many callers as possible certainly can't hurt. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Wine 1.0 status: T minus 74 days. 78 open bugs.
On Tuesday 25 March 2008 06:50:25 am Dan Kegel wrote: > 3711 wininet 1 Musicmatch fails to install (missing registry > key, HTTP_HttpOpenRequest() problem) > 5625 wininet 3 Wine does not handle internet proxy settings > conveniently I'll look into these two bugs. -Hans
Re: kernel32: WideCharToMultiByte: return error on negative dest len (take 2)
Alexandre Julliard wrote: > "Dan Kegel" <[EMAIL PROTECTED]> writes: > >> While investigating a crash in gs-auftrag in bug 9039, noticed >> WideCharToMultiByte wasn't quite conformant for negative destlen. >> Fixed, with tests. Passes for me in Wine and Win XP. > > This would require reviewing all uses of WideCharToMultiByte in Wine, > many places get this wrong. Unless you have an app that requires this > fix I'd suggest to leave the test as todo_wine for now. Would that be a good janitorial work to be done before Wine 1.0? I feel like I'm getting tired of translating ... bye michael
Re: DLL exports... HELP?!
If you build a wine dll inside the wine source tree we use gcc in combination with some wine magic for compilation. Exporting of functions in that case happens through a '.spec' file. When you want to work outside the wine tree (as it can be more convenient) you could also use 'winegcc' for building a library. It will handle all the magic for you. Roderick > > >Folks, I've been trying to make a bunch of control panel applets > for wine for some time now. > >a CPL is basically a DLL which (the most importnat part) exports a > function called "CPlApplet"; Without it, the cpl isn't worth a thing. > It is the presence of that export which basically identifies it as a > control panel applet. > >Indeed, opening a random .cpl with dllexp yields: > >Function: CPlApplet Address: 0x0041b604 Relative Address: > 0x0041b604 Ordinal 1 (0x1) Filename: intl.cpl > >This one is from the cpl I wrote some time ago in Delphi, and it's > the same with all other 'doze cpls. I'm working on porting it to C and > wine, but that export is really getting the best of me. > >However, dllexp doesn't detect _any_ DLL exports in wine's .dlls, > so I'm stuck without a template :( Am I missing something? (A simple > *hello world* dll source that compiles against wine's source and > exports ANY function would be greatly appreciated) > >Thanks in advance, > >Stefanov. > > - > > Вземи 2 безплатни месеца БТК ADSL! > Поръчай online дo 20 март 2008! > Надежден Високоскоростен Интернет! > http://www.btc.bg/bg/adsl_order.php?residential&action=order&view_pack=1 -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
Re: [2/2] comctl32: tab.c The Item Interior should use HotTracking color not Hilight color (resend).
Anatoly Lyutin <[EMAIL PROTECTED]> writes: > @@ -1633,7 +1633,7 @@ TAB_DrawItemInterior(const TAB_INFO *inf >SetTextColor(hdc, (((lStyle & TCS_HOTTRACK) && (iItem == > infoPtr->iHotTracked) >&& !(lStyle & TCS_FLATBUTTONS)) > | (TAB_GetItem(infoPtr, iItem)->dwState & > TCIS_HIGHLIGHTED)) ? > -comctl32_color.clrHighlight : > comctl32_color.clrBtnText); > +comctl32_color.clrHotTrackingColor : > comctl32_color.clrBtnText); Shouldn't you distinguish between TCS_HOTTRACK and TCIS_HIGHLIGHTED here? -- Alexandre Julliard [EMAIL PROTECTED]
Re: kernel32: WideCharToMultiByte: return error on negative dest len (take 2)
"Dan Kegel" <[EMAIL PROTECTED]> writes: > While investigating a crash in gs-auftrag in bug 9039, noticed > WideCharToMultiByte wasn't quite conformant for negative destlen. > Fixed, with tests. Passes for me in Wine and Win XP. This would require reviewing all uses of WideCharToMultiByte in Wine, many places get this wrong. Unless you have an app that requires this fix I'd suggest to leave the test as todo_wine for now. -- Alexandre Julliard [EMAIL PROTECTED]
DLL exports... HELP?!
Folks, I've been trying to make a bunch of control panel applets for wine for some time now. a CPL is basically a DLL which (the most importnat part) exports a function called "CPlApplet"; Without it, the cpl isn't worth a thing. It is the presence of that export which basically identifies it as a control panel applet. Indeed, opening a random .cpl with dllexp yields: Function: CPlApplet Address: 0x0041b604 Relative Address: 0x0041b604 Ordinal 1 (0x1) Filename: intl.cpl This one is from the cpl I wrote some time ago in Delphi, and it's the same with all other 'doze cpls. I'm working on porting it to C and wine, but that export is really getting the best of me. However, dllexp doesn't detect _any_ DLL exports in wine's .dlls, so I'm stuck without a template :( Am I missing something? (A simple *hello world* dll source that compiles against wine's source and exports ANY function would be greatly appreciated) Thanks in advance, Stefanov. - Вземи 2 безплатни месеца БТК ADSL! Поръчай online дo 20 март 2008! Надежден Високоскоростен Интернет! http://www.btc.bg/bg/adsl_order.php?residential&action=order&view_pack=1 Folks, I've been trying to make a bunch of control panel applets for wine for some time now. a CPL is basically a DLL which (the most importnat part) exports a function called "CPlApplet"; Without it, the cpl isn't worth a thing. It is the presence of that export which basically identifies it as a control panel applet. Indeed, opening a random .cpl with dllexp yields: Function: CPlApplet Address: 0x0041b604 Relative Address: 0x0041b604 Ordinal 1 (0x1) Filename: intl.cpl This one is from the cpl I wrote some time ago in Delphi, and it's the same with all other 'doze cpls. I'm working on porting it to C and wine, but that export is really getting the best of me. However, dllexp doesn't detect _any_ DLL exports in wine's .dlls, so I'm stuck without a template :( Am I missing something? (A simple *hello world* dll source that compiles against wine's source and exports ANY function would be greatly appreciated) Thanks in advance, Stefanov.
Re: fuse-iso and remote named pipes for GSOC
On Wednesday 26 March 2008 02:24:35 Cesar Izurieta wrote: > Besides the FUSE project for GSOC I see two items listed on the > http://wiki.winehq.org/SummerOfCode page: > > # Better ISO FUSE file system integration Steven already took care of this part, so I'll wrap up the next one. > # A FUSE wrapper for remote named pipes using libsmbclient The goal of this is to be able to do RPC via Windows named pipes to remote machines. Of course the best solution would be to just use libsmbclient from Wine directly, but libsmbclient is under the GPL and Wine is under the LGPL, so that's not going to work. So the obvious idea is some solution where we can use libsmbclient for what we need without having to link to libsmbclient. FUSE can provide this abstraction. The idea would be to create a pipe subdirectory of WINEPREFIX and mount our pipefs there. Accessing pipe/server/pipename should connect to \\server\pipe\pipename, if possible. One more thing that needs to be supported is mode switching on the named pipe. I'd suggest to read up on remote named pipes to get a better idea what they're used for. If you've got any more questions, I'm happy to help. Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Scriptable configuration (reg.exe) proposals
Hello potential students, There have been at least 4 people interested in doing the reg.exe project for summer of code, but unfortunately this is not really a good project idea, becuse you can pretty much implement it all in a single day by just calling the right advapi calls. Making winecfg work from the command line is also not hard and you can't fill up 2 or 3 months with this. I'm sorry for not investigating reg.exe further. This should never have been on the ideas list to begin with, and I should be the one to be blamed for not spotting it earlier. I would strongly recommend adding a proposal for another project. It doesn't have to be one from the ideas list, on the contrary: The most succesful applications have been initiatives from people themselves. As long as you work, interact with the community and communicate with your mentor and share your code and ideas you will get paid. I hope that you will have luck in finding other proposals, and that you will be able to participate and complete gsoc succesfully. Regards, Maarten.
