On Wed, Apr 28, 2010 at 12:48 PM, Alexandre Julliard
wrote:
> Dan Kegel writes:
>
>> Fixes http://bugs.winehq.org/show_bug.cgi?id=22450
>
> There's no reason to do that in configure.
Right then, I'll do something in the registry.
(Although maybe I can live with the existing registry key
if I als
Dan Kegel writes:
> Fixes http://bugs.winehq.org/show_bug.cgi?id=22450
There's no reason to do that in configure.
--
Alexandre Julliard
julli...@winehq.org
Not quite sure about this one. The man page on realpath states that it's
broken by design since some symstems don't have an upper bound on filename
lengths. canonicalize_file_name uses dynamic memory, but isn't available on
non GNU systems. We could provide a realpath based canonicalize_file_nam
Hey Ge,
On Tuesday 17 January 2006 19:55, Ge van Geldorp wrote:
> shfldr_fs and shfldr_unixfs could both inherit from
> a common implementation, we can tack on some internal routines to the
> existing vtable. Redundancy between the two can then be eliminated by
> extracting the common code to the
mport the
shfldr_unixfs.c file because we have no use for it. I haven't really looked
at the unixfs stuff, but I'm wondering if it's perhaps possible to use an
inheritance mechanism? shfldr_fs and shfldr_unixfs could both inherit from a
common implementation, we can tack on some
Hi all,
I guess I'm responsible for a lot of redundant code between the
implementations of filesystem shellfolders in shell32/shlfdr_fs.c and
shfldr_unixfs.c. While I've always tried to re-use as much code as possible,
unixfs by nature has to use posix apis to get hold of the unix
Could you please ignore this patch. I'm experiencing some problems with it.
I'll send a new version soon.
On Tuesday 27 December 2005 16:44, Michael Jung wrote:
> Changelog:
> Store filenames in CP_ACP and WCHAR in the SHITEMIDs
> Removed some wine_todo's for tests that now succeed
>
Hi Troy,
On Monday 18 July 2005 09:37, you wrote:
> I just noticed that your unixfs code appears to be using CP_ACP for all
> conversions between wide characters and multi byte characters. This is OK
> for multi byte display names, but for file names being used in or received
> from t
On Thursday 30 June 2005 21:21, Brian Vincent wrote:
> Does this mean there's no longer a need to map a Z: drive to /?
You still can only access the parts of the filesystem, which are accessible
by a wine drive. You will see the complete unix directory structure, but you
will only be able to sel
On 6/30/05, Michael Jung <[EMAIL PROTECTED]> wrote:
> With the current CVS version, the unixfs shell namespace extension is now
> registered by default at the desktop. So if you do a 'regsvr32 shell32' you
Does this mean there's no longer a need to map a Z: drive to /?
-Brian
won't need the 'regsvr32
shell32'. So for a fresh install, you will end up with unixfs. But if you
already have a '.wine' directory and want unixfs to be registered, you'll
have to do it by hand.
Bye,
--
Michael Jung
[EMAIL PROTECTED]
On Thu, 2005-06-30 at 14:05 +0200, Michael Jung wrote:
> With the current CVS version, the unixfs shell namespace extension is
> now registered by default at the desktop. So if you do a 'regsvr32
> shell32' you will see the unix filesystem in the file dialogs.
This is fantastic
Hi,
With the current CVS version, the unixfs shell namespace extension is now
registered by default at the desktop. So if you do a 'regsvr32 shell32' you
will see the unix filesystem in the file dialogs. It's probably still quite
buggy though. It would be cool if we could
Hi,
What if we map the unixfs extension on the desktop instead of on mycomputer?
So if HKCR\Software\Microsoft\Windows\Current
Version\Explorer\Desktop\Namespace\{UnixDosFolderCLSID} is present, the
desktop folder would forward ParseDisplayName calls to UnixDosFolder instead
of MyComputer
On Thu, Jun 16, 2005 at 11:26:45PM +0200, Alexandre Julliard wrote:
>
> I think the whole canonicalization thing is suspect; you should never
> compare Unix path strings. If you have to compare paths you should use
> stat and compare device/inode.
Except that some FS have difficulty generating un
ery shitemid that is constructed, all
> drives are queried and their paths are canonicalized, which is a lot of disk
> i/o and string copying. Unixfs is really painfully slow. I guess we need some
> caching scheme, but if you don't like the current one, I'll give it some more
> th
On Thursday 16 June 2005 23:11, Dimi Paun wrote:
> Can't we just invalidate the cache if we notice things have changed?
Yes, that should'nt be too hard. Would that be ok, Alexandre?
Bye,
--
Michael Jung
[EMAIL PROTECTED]
From: "Michael Jung" <[EMAIL PROTECTED]>
> In the current implementation, for every shitemid that is constructed, all
> drives are queried and their paths are canonicalized, which is a lot of
disk
> i/o and string copying. Unixfs is really painfully slow. I guess we need
s
that break a lot of
applications, which store filenames in memory during runtime?
In the current implementation, for every shitemid that is constructed, all
drives are queried and their paths are canonicalized, which is a lot of disk
i/o and string copying. Unixfs is really painfully slow. I
Michael Jung <[EMAIL PROTECTED]> writes:
> Changelog:
> Cache the canonicalized unix paths, which correspond to dos devices.
I don't think you want to do that. The goal of the new symlink scheme
is to make it possible to change drive config on the fly, caching it
would defeat that.
--
Ale
On Sat, 2005-05-07 at 09:46 +0200, Michael Jung wrote:
> P.S.: What's the reason for disabling the i18n resources in
> winecfg.rc?
They're out of date and don't reflect the current English GUI.
thanks -mike
On Tuesday 08 March 2005 20:12, Alexandre Julliard wrote:
> I think the extension itself is perfectly reasonable. The thing I'm
> not sure about is creating a brand new dll for it, adding
> Wine-specific dlls should be avoided if possible.
I moved the unixfs stuff from a separate dl
Alexandre Julliard wrote:
I think the extension itself is perfectly reasonable. The thing I'm
not sure about is creating a brand new dll for it, adding
Wine-specific dlls should be avoided if possible.
I agree about dlls that cause un-standard linkage from using code to
private dll. But this is
SF_Desktop_Constructor},
{&CLSID_ShellLink, &IShellLink_Constructor},
{&CLSID_DragDropHelper, &IDropTargetHelper_Constructor},
{&CLSID_ControlPanel, &IControlPanel_Constructor},
{&CLSID_AutoComplete, &IAutoComplete_Constructor},
{NULL,NULL}
};
Would you consider it more reaso
Michael Jung <[EMAIL PROTECTED]> writes:
> Could you please tell me if you consider the unixfs shell namespace
> extension,
> which I've sent to wine-patches last week, a sensible way to go in order to
> access the unix filesystem from winecfg? I know that there is r
Hello,
Could you please tell me if you consider the unixfs shell namespace extension,
which I've sent to wine-patches last week, a sensible way to go in order to
access the unix filesystem from winecfg? I know that there is room for
improvements, and I'm working on it. But if you t
26 matches
Mail list logo
