wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Re: shell32: Some tests for FolderShortcut class
by Alexandre Julliard 19 Aug '05

19 Aug '05

Michael Jung <mjung(a)iss.tu-darmstadt.de> writes: > Changelog: > Added some tests for CLSID_FolderShortcut objects Could you please merge that in one of the existing test files, like shlfolder.c? We don't want to create too many test files. -- Alexandre Julliard julliard(a)winehq.org

1 0

Mouse-buttons swapped after winetest
by Paul Vriens 19 Aug '05

19 Aug '05

Hi, with the latest winetest http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/winetest-200506211000… my mouse-buttons (left and right) are swapped after the test. Any idea?? Cheers, Paul.

4 6

Re: USER32: fix gcc 4.0 warnings
by Alexandre Julliard 19 Aug '05

19 Aug '05

Mike McCormack <mike(a)codeweavers.com> writes: > When switching on a WORD value, case values should also be WORD values > to avoid value out of range warnings. We shouldn't be switching on a WORD, that magic item handling is broken. -- Alexandre Julliard julliard(a)winehq.org

1 0

Weird issue with advapi32 tests on nt 4.0
by Ivan Leo Puoti 19 Aug '05

19 Aug '05

The advapi32 tests save a key, load it and delete the file, and all is fine. But on nt 4.0 sp6 I'm getting a *really* weird, thing, a saved_key.LOG comes out of the blue, it appears to get written to disc after the RegLoadKey call at line 543 of dlls/advapi32/tests/registry.c, however this really shouldn't happen, why should RegLoadKey write this empty file? Has anyone else seen this? I was tempted to send a patch to just delete the file but I'm curious about where this file is coming from and why it gets created, anyone have a clue?. Ivan.

1 0

[Bug 3165] Patch available
by Dripple 19 Aug '05

19 Aug '05

Hi, I tested the patch submitted in http://bugs.winehq.org/show_bug.cgi?id=3165 Bugzilla page with Notes. Seems to fix the issue. Regards. Dripple.

4 3

winspool.drv: Conformance-Tests
by Detlef Riekenberg 18 Aug '05

18 Aug '05

Hi. I wrote a Commandline-Program for testing the Printing-API and found many misterious behaviour. While rewriting the conformance-tests for winspool.drv, how should we handle this bugs / features ? Example for GetPrinterDriverDirectory (W/A): Win98se and WinME do not check the requested level I marked that as todo("windows"). Is this ok? Another Example for GetPrinterDriverDirectory and Enum*: from MSDN: pcbNeeded [out] - Pointer to a value that specifies the number of bytes copied if the function succeeds, - or the number of bytes required if cbBuf is too small. On w2k, the the returned "number of bytes required" in the ANSI-Version is the same as in the Unicode-Version. For GetPrinterDriverDirectory, the rest from the unicode-version of the result is visible in the second part of the buffer. (I Think, w2k fill the buffer with the unicode-version and convert in-place to ANSI. Should we do the same ?) I marked both Versions as valid. (buffersize == (datasize+datasize) and buffersize == datasize) Is this ok? -- By By ... ... Detlef

2 2

Re: Cursor disappears and reappears
by gslink 18 Aug '05

18 Aug '05

I suspect this may not be in Wine at all. There is currently a problem that shows up both in and out of Wine with the cursor vanishing permanently until reboot on some games that block or change the cursor. This appears to be a problem in FC but I have not had time to track it down.

1 0

Re: IStorage* vs. LPSTORAGE vs. winapi_check
by Marcus Meissner 17 Aug '05

17 Aug '05

On Tue, Aug 16, 2005 at 04:33:36PM +0200, Francois Gouget wrote: > > I checked the prototypes of OleDoAutoConvert() and GetConvertStg() and > they use LPSTORAGE rather than IStorage* so I think the 16bit versions > should match. This would avoid introducing ISTorage* in win16.api. > > However one could probably also argue that these functions (which are > currently just stubs) should take a SEGPTR anyway... > > This brings me to OleLoad16() and ReadClassStg16() which were causing > winapi_check to complain because they have comments in their prototypes > that look like documentation to it. I think the right way to handle > those is use the regular documentation to document the real type of > these pointers, i.e. do it as follows: The LPSTORAGE layout is definitely not the same. So LPSTORAGE16 would be more fitting I think. Also when not using "SEGPTR" I get conversion warnings and it clarifies a bit what exactly the type of the argument is. I am fine by the patch, but will have to fix it up regarding LPSTORAGE once we get to the point of implementing those funcs. Ciao, Marcus

2 4

Re: fontforge 20050729 insists on adding .ttf extension
by Huw D M Davies 17 Aug '05

17 Aug '05

On Wed, Aug 17, 2005 at 02:25:29PM -0400, Pavel Roskin wrote: > Hello! > > ChangeLog: > fontforge 20050729 insists on adding .ttf extension even if > the requested output file name ends with a dot. So let's use > names ending with ttf. These are ttf files, and we are not even > installing them. This looks good to me. What seems to have happened was that George Williams gave Rob a workaround to a fontforge regression, that regression has since been fixed and the workaround no longer works. So applying this patch (in affect reversing Rob's) seems like the right thing to do, at the expense of breaking font creation for some versions of fontforger. Ideally we'd detect a broken fontforge, but I don't think it's really worth the effort. Huw.

1 0

Cursor Disappears and reappears
by Kevin DeKorte 17 Aug '05

17 Aug '05

Using Wine 20050725 and Lotus Notes 6.51 when I move my mouse to the database tabs or over the replication window the mouse disappears while I move over the tab or replicated databases and then reappears when I leave the list. The databases are highlighted, but having the mouse completely disappear is a little annoying. I don't remember it doing this with 20041202. Kevin -- Get my public GnuPG key from http://keyserver.veridis.com:11371/export?id=7574690260641978351

2 2

CodeWeavers Installer Challenge - XMLSpy Enterprise Suite
by Vijay Kiran Kamuju 17 Aug '05

17 Aug '05

Hi, I was trying to install Altova XMLSpy Enterprise demo version, on linux with wine-20050725 version. It is hanging and it seems that in the begining there are some stream errors, fixeme: AppSearch must be implemented in ACTION_AppsearchComponents for CmpLocator tab (some thing like it). I wanted to test current msxml implementation as it might use msxml3 parser internally (i dunno really). Thanks, Vijay

1 0

Re: Lostwages: acknowledgement take two.......
by Jonathan Ernst 17 Aug '05

17 Aug '05

I have sent about 310 patches since december 2004, mostly for AppDB, some for lostwages and bugzilla and quite a few translating resources files in french and reimplementing the uninstaller, I really don't know if it makes it worth inclusion and won't be angry if I'm not included. Le mardi 16 août 2005 à 05:50 -0400, Tom Wickline a écrit : > Hello All, > > If your aware of someone missing from this list that should have > inclusion please let me know and ill happily include them in a future > update. > > Also: If I left someone at 2004 and they should be at 2005 let me > know! I updated all the folks that I remember sending in a number of > patches.... > > This patch includes Paul Vriens to the acknowledgment and who pages. > > Tom > > Changelog: > minor fixes, update to 2005 -- Jonathan Ernst <Jonathan(a)ErnstFamily.ch>

2 2

Re: KERNEL/tests: test WideCharToMultiByte
by Alexandre Julliard 17 Aug '05

17 Aug '05

Saulius Krasuckas <saulius2(a)ar.fi.lt> writes: > Log message: > Saulius Krasuckas <saulius.krasuckas(a)ieee.org> > Add a test for WideCharToMultiByte. This should go in codepage.c. -- Alexandre Julliard julliard(a)winehq.org

1 0

WineHQ: Default font
by Christian Britz 17 Aug '05

17 Aug '05

Hi all, I noticed a little possibility to improve www.winehq.org with very little effort: I am talking about the default font for the website. if you look at http://www.winehq.org/winehq_styles.css you will easily see that the default font is "bitstream vera sans", followed by "verdana" and "arial" if vera is not available. Despite the fact that MS might be considered evil by some kids, Verdana and Arial look _much_ better and professional than Vera. I even removed Vera from my system just tomake the homepage look better and mor profesional. I would suggest that the responsible people switch the default font to Arial, which is also available on most Unix systems. No Offence meant! Regards, Christian

2 1

Future Acknowledgement & Who's Who updates
by Tom Wickline 16 Aug '05

16 Aug '05

Hello, I am in the process of updating our "Acknowledgement" & "Who's Who" pages and if anyone here wants to be included and your currently not just send me a mail and ask for inclusion. If you want inclusion on the "Acknowledgement" page let me know what aerie's you have worked on and you will be added in on my next patch. If you believe you will be around for some time to come (a year) and want to be included to the "Who's Who" page let me know this as well. For the "Who's Who" I will need a short description of who you are, where your from, when you started working on wine, and what aerie's you work on. You can look at other entries for a good example.. http://www.winehq.org/site/who http://www.winehq.org/site/acknowledgement This is what I have thus far for my next update. ADD - Jonathan Ernst (Acknowledgement page) ADD - Krzysztof Foltman (Acknowledgement page) ADD - Phil Krylov (Acknowledgement page) Update - Gerald Pfeifer to (2005) Update - Michael Jung to (2005) Update - James Hawkins to (2005) Update - Vitaliy Margolen to (2005) Update - Mike Hearn to (2005) Tom

1 0

Re: Lostwages: developer-cheatsheet.template.diff
by Andreas Mohr 16 Aug '05

16 Aug '05

Hi, On Tue, Aug 16, 2005 at 06:17:27PM +0200, Francois Gouget wrote: > Actually 'dereference' is correct here, although I have no doubt that it > is not in any dictionary. Huh, why? http://dictionary.reference.com/search?q=dereference But OTOH it does mention "well established in jargon", so you might have a point here. Andreas

3 2

Re: DINPUT: Generic FF effect implementation (FF #4)
by Daniel Remenak 16 Aug '05

16 Aug '05

Could I get some feedback on why this has not been applied? I've got several additional patches prepared already that depend on it and if something needs to be changed I'd like to know before I get even more that do. It still applies cleanly to CVS. If it's just not being applied because it's considered dead code I can submit the other patches that actually use it. Thanks, Daniel Remenak On 8/6/05, Daniel Remenak <dtremenak(a)gmail.com> wrote: > The fourth in a series of patches to enable force feedback through > DirectInput on linux event devices. > > Changelog: > Add a generic force feedback effect implementation > > This patch includes a bunch of support code for all DirectInput FF > effects, and adds stubs for a generic FF effect interface. > > Details: > 1. Stubs for a generic implementation of the IDirectInputEvent interface > 2. Debug utility functions to dump common structures > 3. Implementations of necessary object functions (e.g. AddRef, > Release, QueryInterface) > 4. Complete implementations of system-independent SetParameters and > GetParameters > > This patch adds two files, effect.c and effect_private.h, in the > dlls/dinput directory. This patch depends on FF #3 in order to > compile. > > --Daniel Remenak > > <Attachment: ff-4-effect.diff, 20K> >

2 3

Re: Get shlfolder test running with shell32 4.0
by Alexandre Julliard 16 Aug '05

16 Aug '05

Francois Gouget <fgouget(a)codeweavers.com> writes: > Version 4.0 of the shell32 dll does not export StrRetToBufW(). Other shell32 versions don't either, since StrRetToBufW is in shlwapi ;-) -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Report swap file total/free sizes to be the same as physical memory
by Andreas Mohr 16 Aug '05

16 Aug '05

Hi, On Tue, Aug 16, 2005 at 11:49:34PM +0900, Dmitry Timoshkov wrote: + /* Project2k refuses to start if it sees less than 1Mb of free swap */ + if (lpmemex->ullTotalPageFile < lpmemex->ullTotalPhys) + lpmemex->ullTotalPageFile = lpmemex->ullTotalPhys; + if (lpmemex->ullAvailPageFile < lpmemex->ullAvailPhys) + lpmemex->ullAvailPageFile = lpmemex->ullAvailPhys; 1 mega*bit* sounds a "bit" small... Andreas Mohr

1 0

Re: Winecfg and port access
by Christian Schmitz 16 Aug '05

16 Aug '05

HI: Thanks for you answer but i dont know how program these lines for control ioperm(). Yes my system is Suse Linux 9.3 with kde upgraded 3.4.1 I solve the problem (in old wine) of this way: In the old file config i write [ppdev] "378" = "/dev/parport0" [ports] "read" = "0x779,0x378-0x37f,0x280-0x2a0" "write" = "0x779,0x378-0x37f,0x280-0x2a0" I set the attributes crw-rw-rw- 1 me root 99, 0 2005-03-19 16:36 /dev/parport0 crw-rw-rw- 1 lp lp 6, 0 2005-03-19 16:36 /dev/lp0 and add Myuser to the lp group. With all this i get the right of access. Maybe if you sendme a clue maybe i can make the wrapper. Thanks Christian >> I am using TopMax software (a chip programmer) with old wine version (with >> config file). >> >> I try the new wine but i not find where grant the FULL parallel port >> access to the TopMax program >> >> Where is the new config file for touch manually? or >> How i can make for grant port access (standard 378-37f) >If you're using linux, you will most likely have to use a suid-root wrapper >that calls ioperm() and subsequently drops privileges and invokes wine. >That's about 10 lines of C and should be a good exercise ;] I don't know >offhand how portable ioperm() is, and if there is something in /proc that >would be more portable, etc. > >I don't see anything suid-root that comes with wine, so probably wine itself >doesn't have anything of the sort. And I don't know either how wine managed >to pull it off before w/o using suid root executable, unless it did it via >signal catching and some manual forwarding to /dev/lp#. With right ioperms in >place the program should be able to run at full speed. -- En un mundo sin fronteras.... ¿Quién necesita Puertas y Ventanas? EN INGLES: In a world without frontiers, who needs Gates and Windows

1 0

Re: MSHMTL: Added QueryStatus implementation
by Saulius Krasuckas 16 Aug '05

16 Aug '05

* On Tue, 2 Aug 2005, Jacek Caban wrote: > > --- dlls/mshtml/tests/htmldoc.c 26 Jul 2005 10:31:23 -0000 1.5 > +++ dlls/mshtml/tests/htmldoc.c 1 Aug 2005 22:33:37 -0000 > @@ -806,12 +806,76 @@ static void test_Persist() > } > } > > +static OLECMDF expect_cmds[OLECMDID_GETPRINTTEMPLATE+1] = { > + 0, > + OLECMDF_SUPPORTED, /* OLECMDID_OPEN */ > + OLECMDF_SUPPORTED, /* OLECMDID_NEW */ > + OLECMDF_SUPPORTED, /* OLECMDID_SAVE */ ... > + OLECMD cmd[2] = { > + {OLECMDID_OPEN, 0xf0f0}, > + {OLECMDID_GETPRINTTEMPLATE+1, 0xf0f0} > + }; > + > + hres = IOleCommandTarget_QueryStatus(cmdtrg, NULL, 0, NULL, NULL); > + ok(hres == S_OK, "QueryStatus failed: %08lx\n", hres); > + > + hres = IOleCommandTarget_QueryStatus(cmdtrg, NULL, 2, cmd, NULL); > + ok(hres == OLECMDERR_E_NOTSUPPORTED, > + "QueryStatus failed: %08lx, expected OLECMDERR_E_NOTSUPPORTED\n", hres); Jacek, OLECMDID_OPEN (equally as OLECMDID_NEW) isn't supported here on winME, AFAICT. Moreover, calls to IOleCommandTarget_QueryStatus throws an exception of Accesss Violation here. I tested this with OLECMDID_SAVE and it works OK. And we have a typo next, right? > + ok(cmd[1].cmdf == 0, "cmd[0].cmdf=%lx, expected 0\n", cmd[0].cmdf); > + ok(cmd[0].cmdf == OLECMDF_SUPPORTED, > + "cmd[1].cmdf=%lx, expected OLECMDF_SUPPORTED\n", cmd[1].cmdf); Hence, there goes my try: Log message: Saulius Krasuckas <saulius.krasuckas(a)ieee.org> Fix typo in a two checks. WinME fixes: - OLECMDID_OPEN and OLECMDID_NEW aren't supported. - Ignore unsupported OLECMDs as they throws exceptions. Index: dlls/mshtml/tests/htmldoc.c =================================================================== RCS file: /home/wine/wine/dlls/mshtml/tests/htmldoc.c,v retrieving revision 1.7 diff -p -u -r1.7 htmldoc.c --- dlls/mshtml/tests/htmldoc.c 3 Aug 2005 21:26:40 -0000 1.7 +++ dlls/mshtml/tests/htmldoc.c 13 Aug 2005 16:09:15 -0000 @@ -808,8 +808,8 @@ static void test_Persist() static const OLECMDF expect_cmds[OLECMDID_GETPRINTTEMPLATE+1] = { 0, - OLECMDF_SUPPORTED, /* OLECMDID_OPEN */ - OLECMDF_SUPPORTED, /* OLECMDID_NEW */ + 0, /* OLECMDID_OPEN */ + 0, /* OLECMDID_NEW */ OLECMDF_SUPPORTED, /* OLECMDID_SAVE */ OLECMDF_SUPPORTED|OLECMDF_ENABLED, /* OLECMDID_SAVEAS */ OLECMDF_SUPPORTED, /* OLECMDID_SAVECOPYAS */ @@ -842,7 +842,7 @@ static const OLECMDF expect_cmds[OLECMDI OLECMDF_SUPPORTED, /* OLECMDID_SHOWPAGESETUP */ OLECMDF_SUPPORTED, /* OLECMDID_SHOWPRINT */ 0,0, - OLECMDF_SUPPORTED, /* OLECMDID_CLOSE */ + OLECMDF_SUPPORTED, /* OLECMDID_DONTDOWNLOADCSS */ 0,0,0, OLECMDF_SUPPORTED, /* OLECMDID_SETPRINTTEMPLATE */ OLECMDF_SUPPORTED /* OLECMDID_GETPRINTTEMPLATE */ @@ -854,7 +854,10 @@ static void test_OleCommandTarget(IOleCo int i; HRESULT hres; + ZeroMemory(cmds, sizeof(cmds)); + for(i=0; i<OLECMDID_GETPRINTTEMPLATE; i++) { + if(!expect_cmds[i+1]) continue; cmds[i].cmdID = i+1; cmds[i].cmdf = 0xf0f0; } @@ -863,6 +866,7 @@ static void test_OleCommandTarget(IOleCo ok(hres == S_OK, "QueryStatus failed: %08lx\n", hres); for(i=0; i<OLECMDID_GETPRINTTEMPLATE; i++) { + if(!expect_cmds[i+1]) continue; ok(cmds[i].cmdID == i+1, "cmds[%d].cmdID canged to %lx\n", i, cmds[i].cmdID); ok(cmds[i].cmdf == expect_cmds[i+1], "cmds[%d].cmdf=%lx, expected %x\n", i+1, cmds[i].cmdf, expect_cmds[i+1]); @@ -961,7 +965,7 @@ static void test_HTMLDocument(void) int i; OLECMD cmd[2] = { - {OLECMDID_OPEN, 0xf0f0}, + {OLECMDID_SAVE, 0xf0f0}, {OLECMDID_GETPRINTTEMPLATE+1, 0xf0f0} }; @@ -973,9 +977,9 @@ static void test_HTMLDocument(void) "QueryStatus failed: %08lx, expected OLECMDERR_E_NOTSUPPORTED\n", hres); ok(cmd[1].cmdID == OLECMDID_GETPRINTTEMPLATE+1, "cmd[0].cmdID=%ld, expected OLECMDID_GETPRINTTEMPLATE+1\n", cmd[0].cmdID); - ok(cmd[1].cmdf == 0, "cmd[0].cmdf=%lx, expected 0\n", cmd[0].cmdf); + ok(cmd[1].cmdf == 0, "cmd[1].cmdf=%lx, expected 0\n", cmd[1].cmdf); ok(cmd[0].cmdf == OLECMDF_SUPPORTED, - "cmd[1].cmdf=%lx, expected OLECMDF_SUPPORTED\n", cmd[1].cmdf); + "cmd[0].cmdf=%lx, expected OLECMDF_SUPPORTED\n", cmd[0].cmdf); hres = IOleCommandTarget_QueryStatus(cmdtrg, &IID_IHTMLDocument2, 2, cmd, NULL); ok(hres == OLECMDERR_E_UNKNOWNGROUP,

2 9

want to change the behaviour of wine when minimising in kde?
by Fabio Duarte Vilas Boas 16 Aug '05

16 Aug '05

When minimizing, I dont like the icon and would like to know how to change it? __________________________________________________ Converse com seus amigos em tempo real com o Yahoo! Messenger http://br.download.yahoo.com/messenger/

2 1

Lines of code in Wine?
by Tom Wickline 16 Aug '05

16 Aug '05

Hello, I was looking at our line count so I could update the history page and the FAQ with new up to date numbers. And my numbers come no where close to what has been reported in the past. anyone care to generate the current line count ? Here is the numbers I get if anyone is interested. Wine: ansic: 1025534 (96.99%) perl: 18339 (1.73%) yacc: 6503 (0.61%) sh: 4064 (0.38%) lex: 2916 (0.28%) awk: 54 (0.01%) Total = 1,057,410 Lostwages: php: 1469 (100.00%) Total = 1,469 AppDB: php: 9034 (97.78%) perl: 185 (2.00%) sh: 20 (0.22%) Total = 9,239 Tools: perl: 3725 (81.71%) python: 572 (12.55%) exp: 140 (3.07%) php: 115 (2.52%) sh: 7 (0.15%) Total = 4,559 kernel-win32: ansic: 6269 (100.00%) Total = 6,269 Grand Total = 1,078,946 Tom

3 4

Re: [MSXML]xmlnode_get_nodeName Implementation
by Mike McCormack 16 Aug '05

16 Aug '05

Hi Vijay, Vijay Kiran Kamuju wrote: > i think it would be better if we put bstr_from_xmlChar in msxml_private.h > need directions how to implement domdoc_get_nodeName I'll post a patch to move bstr_from_xmlChar and other utility functions somewhere else in the code later. > please comment on the patch For now the basics of msxml3 aren't really decided (eg. how to map xmlNodePtr to IXMLDOMNode, etc), and how to manage the relationship between nodes. The way I'm managing node pointers will probably change again. What I really need is more test cases, so if you have any msxml test cases lying around, then let me know. Mike

2 4

Proposed interface for file operations by the file dialog code (dlls\commdlg\filedlg*.c)
by Troy Rollo 16 Aug '05

16 Aug '05

References: <http://www.winehq.org/hypermail/wine-patches/2005/08/0265.html> <http://www.winehq.org/hypermail/wine-devel/2005/08/0286.html> Background: Work is currently proceeding on a branched version to create additional APIs for WINE that use UNIX path names rather than Windows ones. This is useful for Winelib apps and seeks to make them look more like they are native apps, thereby addressing some of the complaints that Winelib apps are somehow of lesser status than ports using other APIs. After some discussion, it was decided that this would remain a branch until at least such time as the implementation was proven to work in real-world situations. Part of this involves producing file dialog APIs that operate appropriately in this context. That includes taking UNIX path names on input, producing UNIX path names on output and in callbacks to the application, and browsing a heirarchy that does not include windows-isms such as drive letters. To make modifications directly in the existing code would result in a set of differences that would result in significant headaches for branch maintenance and any future merge-back to WineHQ. The objective is to reduce the differences so as to improve compatibility between the branches. The patch referenced above took a minimal-change approach to this problem by implementing an interface that mostly implemented the small operations made by the existing code, without even putting in local stubs (hence the inconsistent calling conventions in the interface). The general principle I have used is that path names should, as far as possible, be opaque so that the file dialog code itself never examines their contents directly, but rather calls functions in the interface to extract or locate particular portions of the path, to modify or concatenate paths or to make use of the paths. The minimalist interface: typedef struct { UINT code_page; WCHAR sep_char; HRESULT WINAPI (*get_top_folder) (IShellFolder **); LPITEMIDLIST (*get_pidl_from_name)(IShellFolder *, LPWSTR); BOOL (*get_display_name) (LPCITEMIDLIST, LPWSTR); IShellFolder* (*get_folder_from_pidl)(LPITEMIDLIST); BOOL WINAPI (*change_directory) (LPCWSTR); UINT WINAPI (*get_directory) (UINT, LPWSTR); void (*qualify_path) (LPWSTR, LPCWSTR); void (*complete_path) (LPWSTR); BOOL (*has_invalid_char) (LPCWSTR); LPWSTR WINAPI (*find_next_component) (LPCWSTR); LPWSTR WINAPI (*find_file_name) (LPCWSTR); LPWSTR WINAPI (*find_extension) (LPCWSTR); BOOL WINAPI (*file_exists) (LPCWSTR); BOOL WINAPI (*is_directory) (LPCWSTR); LPWSTR WINAPI (*add_dir_sep) (LPWSTR); DWORD WINAPI (*get_full_path) (LPCWSTR, DWORD, LPWSTR, LPWSTR*); } FileDlgFileOps; Minimalist interface vs ideal interface: On IRC this morning Alexandre said he would prefer a well-designed interface to the minimalist approach, hence this discussion. Since the interface is entirely internal to commdlg, I will use cdecl calling conventions. Detailed discussion follows. The code_page member was put there because the UNIX file name APIs may not use the same code page as other A entry points. WINE uses CP_ACP (as does Windows - although CP_THREAD_ACP is subject to further investigation) for most purposes, but CP_UNIXCP for UNIX path names when translating them to UTF16. Often CP_UNIXCP will be something like UTF8, or it may be ISO8859-1 in situations where Windows would use CP1252. It may be that a Winelib application should have CP_ACP set to be the UNIX code page, but they may not (and unless they do something special will not. So places where A->W or W->A conversions happen on path names need to make sure they use the right code page in the context. The minimalist approach was to make this a data member, but the ideal approach would be to have functions which performed the appropriate conversions. Looking through the existing code, the conversions are performed in some contexts where the output is allocated, and others where the output is a fixed size buffer. If we want to have just one conversion function for each direction, this would give us: CHAR *filename_wtoa(WCHAR const *in, CHAR *out, int bufrange); WCHAR *filename_atow(CHAR const *in, WCHAR *out, int bufrange); "in" is the input buffer. "out" is the output buffer (NULL if we want the method to allocate). "bufrange" is the number of elements pointed to by "out". The return value is a pointer to the file name on success, and is either the value of "out", or an allocated buffer where "out" is NULL. On failure the return value is NULL. The sep_char is perhaps the rudest part of the minimalist interface since it does not treat the path names as opaque. It is used in the following contexts: The handling of CDM_GETFILEPATH, where it is used to paste the file name and directory name together; and in FILEDLG95_InitControls, where it is used to determine if the input file name has a path component. With an ideal interface the CDM_GETFILEPATH handling would be changed to use a general path qualification function. Determining if the input file name has a path component could be handled in one of two ways: with a method for querying this; or by searching for the start of the file name component and testing if that is the start of the string [ie. find_file_name(input) != input]. I prefer the latter method since it means one less entry in the interface, but if the boolean function were preferred it might appear as: BOOL has_path(char const *filename); get_top_folder exists because the Windows path versions of the dialog use the Desktop folder as their top level, but a UNIX path version should arguably use the UNIX root as its top level. Operations retrieving the top level folder (SHGetDesktopFolder) appear in many places. I would prefer to return the pointer though, hence: IShellFolder *get_top_folder(void); The next three functions in the minimal interface (get_pidl_from_name; get_display_name; and get_folder_from_pidl) are functions that are already implemented for Windows path names and are used to handle conversions between item ID lists and path names. Unless somebody thinks the existing implementations are in need of reworking, I don't see any reason not to include them as is in the interface. The next two functions (change_directory; and get_directory) are currently direct calls to SetCurrentDirectoryW and GetCurrentDirectoryW in the default implementation of the interface. In the UNIX path versions there is some difficulty in how these should be handled for reasons that are too complex to go into here, but by having the interface at least a start can be made on figuring out how to deal with these. GetCurrentDirectoryW is usually called in contexts where the buffer is allocated (albeit wastefully), but in one case is called on a stack buffer. I am inclined to have the stack buffer replaced by an allocated one, hence: BOOL set_directory(WCHAR const *dir); WCHAR *get_directory(void); Next comes qualify_path, which is used to generate a fully qualified and canonical (no '/../' sequences) path name given a directory name and a (possibly already fully qualified) path name. The minimalist declaration is based on the way this operation was implemented in FILEDLG95_OnOpen, but in accordance with my preference for allocating string buffers I would prefer: WCHAR *qualify_path(WCHAR const *path, WCHAR const *dir); It may be that if dir == NULL the function would use the current directory. complete_path is only used in one place - in FILEDLG95_OnOpen where the routine walks through its path elements, and tacks on a trailing backslash to paths like "c:" (which will be the first component of the path for "c: \windows\system.ini"). find_next_component (currently set to PathFindNextComponentW) is only used in that same context, so perhaps the better solution is to combine these two with: WCHAR *next_component(WCHAR const *path, WCHAR const *last); "last" is the most recent return value (or NULL for the first call). "path" is the input path. The return value is an allocated string containing the next path component, so you would get "c:\", "windows", "system.ini" as return values. has_invalid_char is used to test if the path name contains any invalid characters. The current default implementation is wrong, but reflects what was already there. The general rule is that Win32 paths (at least in the file dialog) should not contain '/', ':' (except as a drive letter (*)), '<'. '>', and '|'. IIRC, wild cards are forbidden in file names, but the filedlg code does not treat them as invalid because they are valid for entry into the edit box of the file dialog. Under UNIX, there are no invalid file name characters - any string is a valid file name although it may be a relative file name. I would keep this function but rename it: BOOL *valid_file_name(WCHAR const *filename); (*) can the file dialogs address stream names under NT? Is it meaningful to do the same under Wine since UNIX has no concept of file sub-streams? find_file_name and find_extension find the final path component, and the extension (if any) in the file name. These are fairly pure functions for handling otherwise opaque path names, so they would remain as is but without the WINAPI calling convention: WCHAR *find_file_name(WCHAR *filename); WCHAR *find_extension(WCHAR *filename); Next come file_exists and is_directory. These could be replaced by a single routine that requests the type of the file and returns -1 if the file does not exist: int get_file_type(WCHAR const *filename); Returns (with optional symbolic constants): -1: no such file 0: ordinary file 1: directory This would also simplify some other code where is_directory is called immediately after file_exists. add_dir_sep is used when pasting a path name and a wildcard string. If there are no objections, qualify_path could be used for such situations, thereby avoiding the need for a separate add_dir_sep. get_full_path is currently a call to GetFullPathNameW. It is used in 3 places in FILEDLG95_InitControls. Each time it is used to do three things: 1. Convert any 8.3 filenames to the long path name version, then extract the file name portion (if any) and directory name portion of the resulting long path, storing them in separate locations. I would simplify the call, allocating the result: WCHAR *get_full_path(WCHAR const *path); The file name component would then be discovered by a call to find_file_name. Obvious candidates for changes: 1. find_extension could be implemented using find_file_name in a way that obviates the need for a separate find_extension. 2. Might find_file_name be implemented in terms of next_component? This likely depends on the behaviour or next_component with a path like "f:\windows\" - if it only returns "f:\" and "windows" then it would not be suitable, but if it returns "f:\", "windows" and "" then it would. Proposed interface: typedef struct { CHAR *(*filename_wtoa)(WCHAR const *in, CHAR *out, int bufrange); WCHAR *(*filename_atow)(CHAR const *in, WCHAR *out, int bufrange); IShellFolder *(*get_top_folder)(void); LPITEMIDLIST (*get_pidl_from_name)(IShellFolder *, LPWSTR); BOOL (*get_display_name)(LPCITEMIDLIST, LPWSTR); IShellFolder* (*get_folder_from_pidl)(LPITEMIDLIST); BOOL (*set_directory)(WCHAR const *dir); WCHAR *(*get_directory)(void); int (*get_file_type)(WCHAR const *filename); WCHAR *(*qualify_path)(WCHAR const *path, WCHAR const *dir); WCHAR *(*get_full_path)(WCHAR const *filename); WCHAR *(*next_component)(WCHAR const *path, WCHAR const *last); WCHAR *(*find_file_name)(WCHAR *filename); WCHAR *(*find_extension)(WCHAR *filename); BOOL *(*valid_file_name)(WCHAR const *filename); } FileDlgFileOps;

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel