Hi all,
Thanks to Mike's help, I succeeded in showing a SHBrowseForFolder
thingy, in the winecfg program, so that people can pick a directory they
want to use as virtual C drive.
However, ofcourse, this directory choosing thingy shows the virtual
Windows file system, not the Unix file system.
Marcus Meissner wrote:
Here is a list of the soft dependencies. We suggest packagers
install each and every last of those before building the package.
These libraries are not dependencies in the RPM sense. In DEB packages,
they should appear as Suggests or Recommends, as the case may be.
ICU
Hi,
On Wed, Nov 24, 2004 at 09:58:14AM +0100, Robert van Herk wrote:
Hi all,
Thanks to Mike's help, I succeeded in showing a SHBrowseForFolder
thingy, in the winecfg program, so that people can pick a directory they
want to use as virtual C drive.
However, ofcourse, this directory
Hi,
Is Z:\ always mapped to the root of the unix file system? Because that
would seem to solve it: just let them choose a directory from Z:\ and
then probably modify the returned string by removing Z: and replacing
all /'s bij \'s.
Hopefully it isn't: you may not always want to expose the
Hi,
On Wed, Nov 24, 2004 at 12:45:20PM +0100, Robert van Herk wrote:
Hi,
Is Z:\ always mapped to the root of the unix file system? Because that
would seem to solve it: just let them choose a directory from Z:\ and
then probably modify the returned string by removing Z: and replacing
all
On Wed, 24 Nov 2004, Shachar Shemesh wrote:
Marcus Meissner wrote:
Here is a list of the soft dependencies. We suggest packagers
install each and every last of those before building the package. These
libraries are not dependencies in the RPM sense. In DEB packages, they
should appear as
On Tue, 23 Nov 2004, Hans Leidekker wrote:
On Tuesday 23 November 2004 14:07, Francois Gouget wrote:
What I meant is that we should check for one of these new APIs that we
need, and if we don't find it we should just do as if lcms.h was
missing.
Yes of course, I meant that too, and we should do
Hi,
Is it possible (as in: not too dangerous) to make a special API that
does not exist in Windows, but then does exist in Wine, that would allow
a program to mount the full Unix tree read only, such that only Wine
programs can do that?
I don't think that's a clean solution.
Since NT-based
Hi,
On Wed, Nov 24, 2004 at 02:03:16PM +0100, Robert van Herk wrote:
In fact, the only ways I can think of to make this feature available
just for Wine programs, is
- Calling the Unix api directly from winecfg (I guess that is possible?)
just to read out the directory contents and then put
On Wednesday 24 November 2004 13:13, Francois Gouget wrote:
I do think it's a better solution. Just like it's better to let Wine
compile even if the ALSA development libraries are not installed or
obsolete, eventhough the resulting winealsa is going to be
non-functional.
Agreed again
On Tue, 23 Nov 2004 14:56:43 -0800, Scott Ritchie wrote:
My reason for splitting off libwine and wine is that libwine can be
installed without wine and could someday be used to launch a program
that has been ported with winelib, without having to have wine proper in
it.
I'm afraid that's not
On Wed, 24 Nov 2004 09:58:14 +0100, Robert van Herk wrote:
Thanks to Mike's help, I succeeded in showing a SHBrowseForFolder
thingy, in the winecfg program, so that people can pick a directory they
want to use as virtual C drive.
Cool.
However, ofcourse, this directory choosing thingy
Francois Gouget wrote:
On Wed, 24 Nov 2004, Shachar Shemesh wrote:
Marcus Meissner wrote:
Here is a list of the soft dependencies. We suggest packagers
install each and every last of those before building the package.
These libraries are not dependencies in the RPM sense. In DEB
packages, they
On Tue, 23 Nov 2004 19:48:41 -0500, Vincent Béron wrote:
Then why do we link to them if they simply return not implemented? As
notepad works corectly with the newer glibc, I wonder if we do have a
fallback to the poll branch (I thought it was a compile-time define).
Alexandre seems to feel we
Is Z:\ always mapped to the root of the unix file system? Because that
would seem to solve it: just let them choose a directory from Z:\ and
then probably modify the returned string by removing Z: and replacing
all /'s bij \'s.
No not always, it's not enforced by Wine. It could be any
On Wed, 24 Nov 2004, Andreas Mohr wrote:
On Wed, Nov 24, 2004 at 12:45:20PM +0100, Robert van Herk wrote:
Ofcourse, another solution would be to make a Unix server that
communicates with winecfg and tells it how the Unix directory structure
is, but that would be overkill I guess :-).
Robert van Herk [EMAIL PROTECTED] wrote:
Therefore, I'd say
that using this approach, it is probably nicer to have a magic wine flag
that let the SHBrowseForFolder thingy show the unix directory listing
I wonder whether using a callback in SHBrowseForFolder and reinitializing
dialog with
Mike Hearn [EMAIL PROTECTED] writes:
On Tue, 23 Nov 2004 19:48:41 -0500, Vincent Béron wrote:
Then why do we link to them if they simply return not implemented? As
notepad works corectly with the newer glibc, I wonder if we do have a
fallback to the poll branch (I thought it was a
On Wed, 2004-11-24 at 16:18 +0100, Alexandre Julliard wrote:
We cannot check for a return -ENOSYS function at compile time, so if
the function exists we link to it and check for ENOSYS at run time,
and fall back to poll() in that case.
Right, but why not always use syscalls and never glibc? I
On Wed, 2004-11-24 at 15:53 +0100, Robert van Herk wrote:
Also, we'd have the problem that when other processes are active and
using the disks, these disks will be unmounted :-).
Good point. I was assuming that if you're reconfiguring drives in
winecfg while other apps are running you'd be
Yes that'd work as well. I'd rather have a magic winecfg flag than
copy/paste the code as that way we get bugfixes in shell32
automatically. But Alexandre tends to prefer copy/paste over hacking
code around or using static libraries, so I'm not sure which way he'd
prefer here.
Anyways: the
Robert Shearman a écrit :
mammique wrote:
Hello,
i'm looking for a lightweight way to read the windows regitry. I don't
know windows, so i don't know how it's done. The goal in simply to check
the windows network configuration of a machine from a live-cd, to use
the same parameters on the running
The addition of winecfg/drivedetect.c via
revision 1.1
date: 2004/11/23 13:50:23; author: julliard; state: Exp;
Mike Hearn [EMAIL PROTECTED]
- More heapification.
- Split drive code into core, UI and autodetect.
- Implement drive autodetection.
- Slight redesign of drive tab.
-
On Tue, 23 Nov 2004, Hans Leidekker wrote:
What I meant is that we should check for one of these new APIs that we
need, and if we don't find it we should just do as if lcms.h was
missing.
Yes of course, I meant that too, and we should do that. But you presented
this as a better solution for
Hey folks,
Brian, Alexandre, and I have been talking with some kind folks that
are volunteering to help host Wineconf in Stuttgart; we're thinking
late spring for Stuttgart.
We've also had a generous offer to help set up a meeting in
conjunction with LinuxTag in Karlruhe in mid to late June.
This
Hi,
I want to add support generating .debug files that are linked from .so
files so that we can have one set of binaries, no matter whether a
person is a developer or end-user and yet have no additional disk space
or bandwidth costs.
This is really just a RFC about changes I've made to the DLL
Mike Hearn [EMAIL PROTECTED] writes:
Right, but why not always use syscalls and never glibc? I think that is
what Vincent was getting at. I think you did say that it was a general
principle to always use libc when possible but I don't remember if you
explained why.
There are many reasons,
Mike Hearn [EMAIL PROTECTED] writes:
Yes, this was expected. Just ensure only Z: is mapped during the directory
browser operation. See the code in drive.c to find out how to modify drive
mappings using win32 but to be honest the easiest way would be to make a
copy of the current configuration
On Wed, 24 Nov 2004 11:24:01 -0600, Robert Shearman wrote:
I want to add support generating .debug files that are linked from .so
files so that we can have one set of binaries, no matter whether a
person is a developer or end-user and yet have no additional disk space
or bandwidth costs.
On Wed, 24 Nov 2004 09:26:08 +0100, mammique wrote:
Thank you Rob, i understand this way, it seems quite hard regarding my
missing experience in wine me but i'll try to deal with it. BTW you
suggest to include regedit (.exe), and other stuff present in windows if
i undertand correctly, if
Mike Hearn wrote:
On Wed, 24 Nov 2004 11:24:01 -0600, Robert Shearman wrote:
I want to add support generating .debug files that are linked from .so
files so that we can have one set of binaries, no matter whether a
person is a developer or end-user and yet have no additional disk space
or
On Wed, 2004-11-24 at 12:33 -0600, Robert Shearman wrote:
It is already there. I added support for it a few months ago.
Oops, sorry.
I wasn't very clear about what I wanted with the makefiles. Basically,
this will be an optional post-build step. The way I am leaning towards
at the moment
Mike Hearn wrote:
On Wed, 2004-11-24 at 12:33 -0600, Robert Shearman wrote:
I wasn't very clear about what I wanted with the makefiles. Basically,
this will be an optional post-build step. The way I am leaning towards
at the moment is that make install will install with full debugging
Hello!
I'm trying to run apple iTunes 4.7.0.42 in Winehq CVS and I'm getting this
failure when I try to access the music store. Wine asks me to report this.
err:local:LOCAL_GetBlock not enough space in GDI heap 10bf for 28 bytes
err:region:CombineRgn Invalid rgn=(nil)
err:local:LOCAL_GetBlock
Stefan Dösinger wrote:
Hello!
I'm trying to run apple iTunes 4.7.0.42 in Winehq CVS and I'm getting this
failure when I try to access the music store. Wine asks me to report this.
err:local:LOCAL_GetBlock not enough space in GDI heap 10bf for 28 bytes
err:region:CombineRgn Invalid rgn=(nil)
Stubs declared in .spec files were not generated or exported for PE (MinGW)
builds. The patch below fixes that. It adds a new mode to winebuild, --pedll,
which generates the stubs.
Since it's a global change I'm sending it here for review first.
Ge van Geldorp.
Index: Make.rules.in
On Wed, 24 Nov 2004 10:43:57 -0600, Jeremy White [EMAIL PROTECTED] wrote:
Brian, Alexandre, and I have been talking with some kind folks that
are volunteering to help host Wineconf in Stuttgart; we're thinking
late spring for Stuttgart.
I'll jump the gun here and give some more details.
Alexandre Julliard wrote:
Mike Hearn [EMAIL PROTECTED] writes:
Yes, this was expected. Just ensure only Z: is mapped during the directory
browser operation. See the code in drive.c to find out how to modify drive
mappings using win32 but to be honest the easiest way would be to make a
copy of
I am sending this to wine-devel as I would like a DirectInput hacker to
comment on it. With this patch we are able to run some of the DirectX
sample application using Wine dinput.dll on Windows.
Changelog:
Magnus Olsen [EMAIL PROTECTED]
Add more polling of keyboard and mouse devices under
Robert van Herk [EMAIL PROTECTED] wrote:
Also, I am having some troubles into tricking the SHBrowseForFolder
thingy into using a different root folder, since I guess I need to use
SHParseDisplayName
On Wed, 24 Nov 2004, Gerald Pfeifer wrote:
The addition of winecfg/drivedetect.c via
revision 1.1
date: 2004/11/23 13:50:23; author: julliard; state: Exp;
Mike Hearn [EMAIL PROTECTED]
- More heapification.
- Split drive code into core, UI and autodetect.
- Implement drive
It is already there. I added support for it a few months ago.
I've did debug packages for mdk the day after AJ commited your patch, but is
there any easy way I can test to see if the debug info works with winedbg?
Ivan.
Libero ADSL:
42 matches
Mail list logo
