Re: Wine Ma os X port
On Thu, 29 Aug 2002, Lionel Ulmer wrote: > On Wed, Aug 28, 2002 at 04:51:29PM -0700, Francois Gouget wrote: > > Not necessarily. What you propose to do for Wine can be done for the C > > and X11 libraries. Then you get an emulator that lets you run x86 Linux > > applications on a PPC machine... including Wine. > > Well, yes... But if you have a system that creates for you a 'translation' > layer for all the libraries used by Wine, why not use it directly on Wine > itself ? You cannot have a tool that is going to write the translation layer automatically. I guess it is simpler to write it by hand for the Unix APIs (maybe a couple thousands at most?), rather than for the Windows APIs >> 10 thousands, plus tons of messages, plus tons of callbacks, plus poor documentation, etc. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm
Re: RFC: 'test' bugzilla keyword
Francois Gouget wrote: >On Tue, 27 Aug 2002, Paul Millar wrote: >[...] > > >>>Maybe 'conformance' would work? >>> >>> >>Personally, I prefer "regression" to "conformance", although both are >>applicable names. >> >> > >The problem is we already have a 'regression' keyword with a reasonable >meaning: 'bugs relating to programs that were working at one time but >stoped working for some reason'. But this does not specifically cover >the 'conformance test suite'. > >If a conformance test used to work and no longer does, then I think it >would be reasonable to tag it as 'conformance, regression'. > >But I have also found that some tests do not pass on Windows. IIRC, >there's a test having to do with TEMP that fails if it is set to >'c:\Windows\Temp' rather than 'c:\'. I would like to be able to make a >bug report and tag it with a keyword to indicate it is related to the >'conformance test suite' (or whatever we want to call it). Similarly, >there would be reports to be made about the conformance tests as run on >FreeBSD and Solaris. And note that none of these are regressions. > > > > You have sold me on "conformance" . The real proplem is that we have been calling the conformance test suite by the wrong name if you ask me. The thing is that this is exactly what the suite is for (to be able to track where wine and windows differ in thier behavior.) To be able to have a bug report where the source is available is indispensible. Mr Newman can we please, please, please have this. Tony Lambregts
trying to draw off-screen
Does anyone know who constrains a window to be on the screen? Our application, in order to minimise flicker, does the hard work with a container application deliberately positioned well off-screen (enormous negative coordinates I think). This works under Windows. However under WINE the initial window appears in the top right corner of my screen (I think I've seen it appear in other corners too on other computers). It then resizes , keeping the same top left corner (with parts of the window off-screen) before correctly repositioning itself into the middle of the screen. Does anyone know which code is doing the initial positioning in the top right corner? Is this deliberate? Bill
RE: Added H_SRCS (used by msvcmaker)
> Patrik Stridvall <[EMAIL PROTECTED]> writes:
>
> > Perhaps files such as include/winuser.h should be included
> > for USER32 for example?
> >
> > Anyway what do you think about adding H_SRCS to
> > every Makefile.in file?
>
> I don't think we want that, especially if you want to add all relevant
> includes it's going to be a nightmare to maintain.
Yes, I'm a little worried about that myself, but then the C_SRCS
doesn't change that often and the H_SRCS are likely to change
MUCH less.
Futhermore it doesn't really matter if it out out sync either.
If somebody developing in MSVC misses a file he can add it.
It not like Wine won't build correctly.
> And make depend (or
> some perl equivalent) can easily determine that information for you.
Well, if you just want all .h files the DLL depends on MSVC already have
that
in a automatically generated "folder" called External dependencies.
The H_SRCS is mostly for the .h files that you are likely to want to look at
or
modify while developing the DLL under MSVC.
But it is not strictly nessary. It is more a convenience sort of thing.
Another reason that I proposed it is that maybe H_SRCS could be used fo
something else though I can't think of anything right now...
But sure I can search for the .h files in the director{y,ies} of each DLL.
However for a DLL like ntdll files like include/wine/exception.h is very
much relevent and won't be included is such a case. Not that it really
matters that much but still...
Re: Added H_SRCS (used by msvcmaker)
Patrik Stridvall <[EMAIL PROTECTED]> writes: > Perhaps files such as include/winuser.h should be included > for USER32 for example? > > Anyway what do you think about adding H_SRCS to > every Makefile.in file? I don't think we want that, especially if you want to add all relevant includes it's going to be a nightmare to maintain. And make depend (or some perl equivalent) can easily determine that information for you. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Wine Ma os X port
On Wed, Aug 28, 2002 at 04:51:29PM -0700, Francois Gouget wrote: > Not necessarily. What you propose to do for Wine can be done for the C > and X11 libraries. Then you get an emulator that lets you run x86 Linux > applications on a PPC machine... including Wine. Well, yes... But if you have a system that creates for you a 'translation' layer for all the libraries used by Wine, why not use it directly on Wine itself ? I do not see why it would so much more difficult for Wine than for libc or X11 libs (the only additionnal problem I see would be endianness problems for ressource loading, but a part from that, I see none). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: DOSFS_FindUnixName and "unix" filesystem (was: Re: (HELP) ...)
Andreas Mohr wrote: > On Thu, Aug 29, 2002 at 09:37:13AM -0700, Duane Clark wrote: > >>Martin Wilck wrote: >> >>>In any case this is relatively minor and we can live without. If we >>>don't patch, we need to be prepared that other people stumble into the >>>problem I had, though. I am still feeling dumb - my wine development was >>>practically stuck for 2 months because of that "wine" file. >> >>Since I also was stumbled for a long period on a similar problem, due to >>specifying a "unix" filesystem, perhaps it would be appropriate in the >>documentation to put some large warnings on that option. > > Well, uh, where have you been recently ? ;-) > That's exactly what we've been doing in several docu places for two years now. > OK, it may not be specified in every relevant docu, but I'd say that at least > 40% of all docs tell this story. > Obviously I should have actually looked at the docs before posting that. It is clearly spelled out in the important spots. Oh well, now that I think about it, it was more than two years ago that I had created the config file that had caused the problem for me.
Re: DOSFS_FindUnixName and "unix" filesystem (was: Re: (HELP) ...)
On Thu, Aug 29, 2002 at 09:37:13AM -0700, Duane Clark wrote: > Martin Wilck wrote: > > > > In any case this is relatively minor and we can live without. If we > > don't patch, we need to be prepared that other people stumble into the > > problem I had, though. I am still feeling dumb - my wine development was > > practically stuck for 2 months because of that "wine" file. > > Since I also was stumbled for a long period on a similar problem, due to > specifying a "unix" filesystem, perhaps it would be appropriate in the > documentation to put some large warnings on that option. Well, uh, where have you been recently ? ;-) That's exactly what we've been doing in several docu places for two years now. OK, it may not be specified in every relevant docu, but I'd say that at least 40% of all docs tell this story. -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php
Re: WineDbg and sources
Fabian Cenedese a écrit : > > Hello > > If WineDbg stops it tries to show the actual source line. With my files it > always says "Unable to open file X" Looking into debugger/source.c I found > that it always bails out after stat (returns -1). This seems like it can't find > the file. But if I use wine wcmd I can go there without a problem. My guess > is that stat is a Unix tool and therefore case sensitive so this could arise > a problem. But still after trying out different cases it could never find my > source files. The code looks good as does the (windows-) path it is looking > for the file. The only reason is the failing return value of stat. > Is it important if the files are Dos/Unix style? (Kate says it's Unix). > Does anybody have any ideas? the point is rather that under windows, file names are case insensitive (even if they are stored with lower/upper cases) since the debugger doesn't open files with the Windows interface but with the unix interface, name lookup likely fails we should rewrite it using windows API (or link winedbg with msvcrt instead of glibc) the DOS/Unix style (if you mean the \r\n vs \n issues) shouldn't matter I'll try to give a try later on A+
Re: DOSFS_FindUnixName and "unix" filesystem (was: Re: (HELP) ...)
Martin Wilck wrote: > > In any case this is relatively minor and we can live without. If we > don't patch, we need to be prepared that other people stumble into the > problem I had, though. I am still feeling dumb - my wine development was > practically stuck for 2 months because of that "wine" file. Since I also was stumbled for a long period on a similar problem, due to specifying a "unix" filesystem, perhaps it would be appropriate in the documentation to put some large warnings on that option.
Keyboard Switching
Hi I made Thai keyboard layout and compiled but I can't switch to thai char.. I use th in X but it not support X thai key input.. Help me.. Serious..! MrChoke -- == Supphachoke Suntiwichaya WWW:http://jedi.links.nectec.or.th/~mrchoke UIN:10509387 TEL:+66-1-5408959 Love Me Love Linux ===
Re: Wine Status
BiDi - 5% done. me tom wrote: > Hello , > > The Wine Status page located here : > http://www.winehq.com/about/index.php?status > Has gone for about one year now with out updates and I > have volunteer'd to work on bringing this page up to date. > I am new to the Wine Project and I am in need of some assistance to make > sure all changes are corrct and accurate. > Over the next week or so I plan to read over the change log's for the > last year > so I will have a feel of the changes that have been made. > > If current Users/Developers could send me changes that they are aware of > I will start a log of changes against the current page. > > If anyone is willing to help me with this I would be most appreciative . > > Thomas Wickline > > >
Re: Wine Status
I also keep track on individual control status, do you want to integrate that too? -- Dimi.
Re: Wine Status
[skipped] > I am new to the Wine Project and I am in need of some > assistance to make > sure all changes are corrct and accurate. > Over the next week or so I plan to read over the change > log's for the > last year > so I will have a feel of the changes that have been > made. A couple of good sources of information about changes in Wine: 1) Wine Weekly News articles http://www.winehq.com 2) Notes in the release ANNOUNCE file http://cvs.winehq.com/cvsweb/wine/ANNOUNCE Good luck, Andriy Boston, MA, USA __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com
WineDbg and sources
Hello If WineDbg stops it tries to show the actual source line. With my files it always says "Unable to open file X" Looking into debugger/source.c I found that it always bails out after stat (returns -1). This seems like it can't find the file. But if I use wine wcmd I can go there without a problem. My guess is that stat is a Unix tool and therefore case sensitive so this could arise a problem. But still after trying out different cases it could never find my source files. The code looks good as does the (windows-) path it is looking for the file. The only reason is the failing return value of stat. Is it important if the files are Dos/Unix style? (Kate says it's Unix). Does anybody have any ideas? Thanks Fabi
Re: Menu patch breakage
On Thu, Aug 29, 2002 at 01:03:38PM +0200, Rein Klazes wrote: > Hi, > > Yesterday's destroymenu patch broke a number of applications, among > them Forte Agent. Because I don't quite understand the issues yet, I > have uploaded a +relay,+menu log to > www.xs4all.nl/~rklazes/temp/ag.log.bz2 if anyone wants to have a look. ARGL ! ;) Hah, but I guess I understand it, fortunately ! :-) The program first creates a window: 0806eae8:Call user32.CreateWindowExA(,005c4183 "ForteAgent:Main",417123b 0 "Agent",1acf,8000,,8000,,,008c,004 0,) ret=00598ea1 trace:menu:MENU_GetSysMenu loading system menu, hWnd 10025, hPopupMenu trace:menu:CreateMenu return 00c8 trace:menu:MENU_GetSysMenu hWnd 10025 (hMenu 00c8) then it assigns a menu to this window: trace:menu:SetMenu (10025, 008c); later it does: 0806eae8:Call window proc 0x406fc3dc (hwnd=00010026,msg=WM_MDISETMENU,wp=010 4,lp=053c) trace:menu:GetMenu for 10025 returning 008c trace:menu:SetMenu (10025, 0104); 0806eae8:Ret window proc 0x406fc3dc (hwnd=00010026,msg=WM_MDISETMENU,wp=010 4,lp=053c) retval=008c And since hmenu 0x008c isn't used any more, it does: 0806eae8:Call user32.DestroyMenu(008c) ret=004dd671 trace:menu:DestroyMenu (008c) 0806eae8:Ret user32.DestroyMenu() retval=0001 ret=004dd671 and thus WIPING OUT the hMenu member of the window, since 0x008c's hWnd member *still* points to the hWnd now owning the 0x0104 hMenu, and thus lets DestroyMenu() wipe out the *old*, wrong hWnd's hMenu member ! So either: a) DestroyMenu should check whether the hMenu's "owner" window still contains the very same menu handle and set it to 0 in this case *only* (i.e.: not eliminate "foreign" hMenu values) or b) a SetMenu should unregister the hWnd member of the hMenu previously assigned to the window (i.e.: set hMenu->hWnd to 0). I'll do some testing to find out which path to take ASAP. For now, I'd assume that b) is the correct answer. Thank you very much for this report ! -- Microsoft Licensing 6.0: "Pay us now in advance, so that we can own you later."
Re: GetObject with empty buffer
> "Fabian" == Fabian Cenedese <[EMAIL PROTECTED]> writes: ... Fabian> If the lpvObject parameter is NULL, the function return Fabian> value is the number of bytes required to store the information Fabian> it writes to the buffer for the specified graphics object. Fabian> Fabian> But I couldn't find this anywhere, not in the general function Fabian> in gdiobj.c nor in the subtypes FONT_GetObject or Fabian> BRUSH_GetObject (sure others neither). As my app uses this Fabian> feature Wine tries to memcpy to a NULL pointer and jumps out of Fabian> the window... literally :) FONT_GetObject sure checks: if(buffer) memcpy( buffer, &lfA, count ); return count; BRUSH_GetObject does not: if (count > sizeof(brush->logbrush)) count = sizeof(brush->logbrush); memcpy( buffer, &brush->logbrush, count ); return count; Someone has to carefully check all subtypes... Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
GetObject with empty buffer
Hello I think I found my (or better a :) problem with fonts. The function GetObject int GetObject( HGDIOBJ hgdiobj, // handle to graphics object int cbBuffer, // size of buffer for object information LPVOID lpvObject // buffer for object information ); should either return the info in the object buffer or, if this pointer is zero, just the size the required info would need. If the lpvObject parameter is NULL, the function return value is the number of bytes required to store the information it writes to the buffer for the specified graphics object. But I couldn't find this anywhere, not in the general function in gdiobj.c nor in the subtypes FONT_GetObject or BRUSH_GetObject (sure others neither). As my app uses this feature Wine tries to memcpy to a NULL pointer and jumps out of the window... literally :) bye Fabi
Menu patch breakage
Hi, Yesterday's destroymenu patch broke a number of applications, among them Forte Agent. Because I don't quite understand the issues yet, I have uploaded a +relay,+menu log to www.xs4all.nl/~rklazes/temp/ag.log.bz2 if anyone wants to have a look. Thanks, Rein. -- Rein Klazes [EMAIL PROTECTED]
Re: Return value GetStockObject
> > In my app I try to get a handle to a system font with following call: > > HGDIOBJ hobj=GetStockObject(ANSI_FIXED_FONT); > > If the call succeeds it should return a handle to the requested object, > > otherwise zero. In Windows I get something like 0x018A000E (looks ok), > > but in Wine I get 0x009E. Even not zero I can't imagine that this is > > a valid handle (address). ANSI_FIXED_FONT is never really used in Wine, > > only SYSTEM_FONT. > > Is this an error or am I barking up the wrong tree? > >In Wine, handles are not (yet) all void * (see bug #90). Even then, it >doesn't mean a handle is a valid heap address; I know there are a couple >places in Wine where they are used as an index in an array locating all >objects of a kind. It doesn't exactly follow the Windows convention, but >I think handles are supposed to be passed back to APIs, not handled >(dereferenced) directly by apps. > >So 0x009E doesn't strike me as bad. If you use it in calls to font >APIs, does it work correctly? With this returned handle I try to fill a structure with GetObject: HGDIOBJ hobj=GetStockObject(ANSI_FIXED_FONT); LOGFONT lfSys; int ret=GetObject(hobj, sizeof(lfSys), &lfSys); (Windows returns 36) After that lfSys has all the info about this font. In Windows the members are filled nicely, lfSys.lfFaceName is "Courier". In Wine GetObject returns 60 (for whatever reason), and lfSys.lfFaceName is empty. Now this could mean that the handles are invalid or that there is something wrong with my fonts. Thanks Fabi
heise online: Tumultuous Response to Alleged Change in MP3 Licensing Conditions
>From a huge german computer magazin, you can found it under: http://www.heise.de/english/newsticker/data/jk-28.08.02-008/ Tumultuous Response to Alleged Change in MP3 Licensing Conditions Ever since the early morning heise online has been receiving a swelling stream of disapproving comment on alleged changes to MP3 licenses: According to a posting at Slashdot[1] Thomson Multimedia, the exclusive licensor of MP3, is said to have erased a passage from its licensing conditions according to which no licensing fees were due for non-commercial free MP3 decoders. In doing so the company was said to be referring to the official table of fees[2], according to which a fee of 75 US cents per MP3 decoder or a one-off payment of 60,000 US dollars (for patent and software; 50,000 US dollars for the patent only) was due. As a matter of fact this rule has been in force for about eighteen months now[3]. At that time not only was the web design of MP3licensing.com modified, in the course of the creation of the then new MP3Pro the licensing conditions were also adjusted. Another decisive passage was also scrapped at that time: "No license fee is expected for desktop software mp3 decoders/players that are distributed free-of-charge via the Internet for personal use of end-users". By inquiring with the Fraunhofer Institute for Integrated Circuits (IIS[4]) and MP3Pro developer Coding Technologies[5] heise online was able to verify the existence of this link -- the tumult has hence been pretty late in coming. Given that Thomson Multimedia has since then not taken any legal steps against developers or distributors of non-commercial MP3 decoders, it does not appear that the future of free MP3 decoders is in jeopardy. As it is, for Thomson to take drastic legal measures in this matter would not make much sense: There is not much money to be had from freeware and open source developers who have created their own MP3 decoders. This is probably the reason why the licensor has refrained to date from taking the appropriate steps. The situation appears to be different with regard to encoders for the creation of MP3 files, however: As a rule in these cases the Fraunhofer Institute as well as Thomson insist that the licensing conditions be met; an open source packet called lame does, however, exist (whether, in the event, its self-referential Gödelian acronym reading LAME Ain't a Mp3 Encoder has enough protective charm is a moot point). It is also not to be feared that such popular players as Winamp or the Musicmatch Jukebox will in future be distributed free-of-charge only without an MP3 decoder: Nullsoft as well as Musicmatch are among the official licensees of MP3(Pro), in the case of Musicmatch this statement also applies to its integrated encoder. Whatever the merits, if any, of the changes in licensing conditions, Mr. Emmett Plant, CEO by profession of Xiph.org Foundation has expressed his considerable delight at the turn of events. In an open letter[6] he thanked Thomson Multimedia. "Thank you for the huge amount of free advertising to our benefit created by your announcement that licensing conditions had changed," Mr. Plant wrote. The letter closes with: "We support all actions on the part of Thomson that make it plain that MP3 costs money. Once again thank you and good luck." Unlike MP3, Ogg Vorbis, recently published in its version 1.0 (according to its developers' statements), is free of patent protection and subject to the GNU Public License; hence, even in future no license fees of any sort would be due for this compression process. It is not a good idea as yet to rely exclusively on Ogg Vorbis, however: Even if Ogg Vorbis manages to close the quality gap between it and MP3 or even manages to get ahead of the latter, it will still take some time before Ogg-capable portable players make their appearance as hardware. (Robert W. Smith) / (jk[7]/c't) URL of this article: http://www.heise.de/english/newsticker/data/jk-28.08.02-008/ Links in this article: [1] http://www.slashdot.org [2] http://www.mp3licensing.com/royalty/software.html [3] http://web.archive.org/web/20010331223305/www.mp3licensing.com/royalty/swdec.html [4] http://www.iis.fhg.de/ [5] http://www.codingtechnologies.com/ [6] http://www.xiph.org/ogg/vorbis/openletter.html [7] mailto:[EMAIL PROTECTED] Copyright 2002 by Verlag Heinz Heise
Re: removing mp3 code
> "Marcus" == Marcus Meissner <[EMAIL PROTECTED]> writes: Marcus> Hi, Apparently distributing even mp3 decoders is not royaltee Marcus> free anymore, according to the slashdot thread and the Thomson Marcus> MultiMedia pages. http://www.heise.de/newsticker/data/vza-29.08.02-000/ (german) tell about a Thompson Statement that free decoders are still royalty free. The Thompson statement in in english. Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
RE: removing mp3 code
> Apparently distributing even mp3 decoders is not royaltee > free anymore, > according to the slashdot thread and the Thomson MultiMedia pages. > > So we probably should remove the msacm mp3 decoder we include. :( At the very least we should make it compile option that is by default disabled. I don't think we need to go that far as to remove it. IIRC LAME an mp3 ENCODER (that was non royalty free even before) got around it by only distributing source code and so can we. BTW: Why do we include a mp3 decoder in the Wine tree? Why not just link to an external library? I can't see maintaining a mp3 decoder being in the best intrest of Wine anyway patents or not...
Re: removing mp3 code
On Thu, Aug 29, 2002 at 11:03:26AM +0200, Michael Stefaniuc wrote: > Hello, > > On Thu, Aug 29, 2002 at 10:52:34AM +0200, Marcus Meissner wrote: > > Apparently distributing even mp3 decoders is not royaltee free anymore, > > according to the slashdot thread and the Thomson MultiMedia pages. > > > > So we probably should remove the msacm mp3 decoder we include. :( > I would wait with that, because every day you get an other information. > Have a look at http://www.heise.de/newsticker/data/vza-29.08.02-000/ Hmm, ok. Ignore my last mail then ;) Ciao, Marcus
Re: removing mp3 code
Hello, On Thu, Aug 29, 2002 at 10:52:34AM +0200, Marcus Meissner wrote: > Apparently distributing even mp3 decoders is not royaltee free anymore, > according to the slashdot thread and the Thomson MultiMedia pages. > > So we probably should remove the msacm mp3 decoder we include. :( I would wait with that, because every day you get an other information. Have a look at http://www.heise.de/newsticker/data/vza-29.08.02-000/ bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg11416/pgp0.pgp Description: PGP signature
Re: DOSFS_FindUnixName and "unix" filesystem (was: Re: (HELP) ...)
Am Don, 2002-08-29 um 03.25 schrieb Alexandre Julliard:
> I'd say that DOSFS_ToDosFCBFormat should fail when the file contains
> upper-case chars on a case-sensitive file system. This will probably
> make it impossible to access some files in certain cases though. I'm
> afraid it's not possible to support case-sensitive file systems 100%
> right given that Windows apps don't preserve case correctly.
I propose another patch with is is IMO the least intrusive:
- changes nothing for non-"unix" filesystems
- for "unix", searches the whole directory for exact matches first,
then again for DOS matches; i.e. DOS matches will be used, but only
if there are no exact ones.
Sorry the patch is difficult to read - you'll see the point if you
compare the patched an non-patched versions visually.
In any case this is relatively minor and we can live without. If we
don't patch, we need to be prepared that other people stumble into the
problem I had, though. I am still feeling dumb - my wine development was
practically stuck for 2 months because of that "wine" file.
Martin
Index: dos_fs.c
===
RCS file: /home/wine/wine/files/dos_fs.c,v
retrieving revision 1.117
diff -u -r1.117 dos_fs.c
--- dos_fs.c27 Aug 2002 01:13:59 - 1.117
+++ dos_fs.c29 Aug 2002 08:34:51 -
@@ -746,31 +746,53 @@
return FALSE;
}
-while ((ret = DOSFS_ReadDir( dir, &long_name, &short_name )))
+if (ignore_case)
{
-/* Check against Unix name */
-if (len == strlenW(long_name))
+while ((ret = DOSFS_ReadDir( dir, &long_name, &short_name )))
{
-if (!ignore_case)
+/* Check against Unix name */
+if (len == strlenW(long_name) && !strncmpiW( long_name, name, len ))
+goto found;
+
+if (dos_name[0])
{
-if (!strncmpW( long_name, name, len )) break;
-}
-else
-{
-if (!strncmpiW( long_name, name, len )) break;
+/* Check against hashed DOS name */
+if (!short_name)
+{
+DOSFS_Hash( long_name, tmp_buf, TRUE, ignore_case );
+short_name = tmp_buf;
+}
+if (!strcmpW( dos_name, short_name )) goto found;
}
}
-if (dos_name[0])
+}
+else /* ignore_case ("unix" file system): try to find exact match first */
+{
+while ((ret = DOSFS_ReadDir( dir, &long_name, &short_name )))
+if (len == strlenW(long_name) && !strncmpW( long_name, name, len ))
+goto found;
+
+DOSFS_CloseDir( dir );
+dir = DOSFS_OpenDir( DRIVE_GetCodepage(path->drive), path->long_name );
+
+while ((ret = DOSFS_ReadDir( dir, &long_name, &short_name )))
{
-/* Check against hashed DOS name */
-if (!short_name)
+if (dos_name[0])
{
-DOSFS_Hash( long_name, tmp_buf, TRUE, ignore_case );
-short_name = tmp_buf;
+/* Check against hashed DOS name */
+if (!short_name)
+{
+DOSFS_Hash( long_name, tmp_buf, TRUE, ignore_case );
+short_name = tmp_buf;
+}
+if (!strcmpW( dos_name, short_name )) goto found;
}
-if (!strcmpW( dos_name, short_name )) break;
}
}
+
+found:
+DOSFS_CloseDir( dir );
+
if (ret)
{
if (long_buf) WideCharToMultiByte(DRIVE_GetCodepage(path->drive), 0,
@@ -787,7 +809,6 @@
}
else
WARN("%s not found in '%s'\n", debugstr_w(name), path->long_name);
-DOSFS_CloseDir( dir );
return ret;
}
--
Martin WilckPhone: +49 5251 8 15113
Fujitsu Siemens Computers Fax: +49 5251 8 20409
Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED]
D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
removing mp3 code
Hi, Apparently distributing even mp3 decoders is not royaltee free anymore, according to the slashdot thread and the Thomson MultiMedia pages. So we probably should remove the msacm mp3 decoder we include. :( Ciao, Marcus
