On Thursday 21 November 2002 01:21 am, Dimitrie O. Paun wrote:
Hmm,
Another header problem. When compiling Putty with Wine's headers,
I get this errors:
In file included from
/home/dimi/dev/wine/wine.src/include/msvcrt/wchar.h:12, from
wcwidth.c:9:
I cant seem to get Office '97 installed. Setup
starts up and when it says "Searching for installed components", It says "Setup
cannot continue". What could be causing that? I can install Office 2000 properly
but '97 wont install? Also after tinkering around with my wine configuration,
[Best
d'oh! I forgot about the resolution thing.
No matter, I can retake the ones I did at 800x600 easily enough. Are
there any that aren't really worth bothering with Brian, or should I
retake them all at the new res? I assume apart from that they were
generally OK.
thanks -mike
On Wed, 2002-11-20
Am Don, 2002-11-21 um 06.05 schrieb Dimitrie O. Paun:
#include winsock.h
#include windows.h
fails miserably in Wine (but apparently works in Windows)
In file included from /home/dimi/dev/wine/wine.src/include/windows.h:62,
from
I think what Dimi was talking about was sending the PuTTY team patches
so they could offer a Linux version on their download site, rather than
actually supplying it with Wine.
A couple of questions - if a program uses Winelib, is it all statically
linked or do you still need a wine installation
Mmmm..
Doesn't sound like a basic windows app.
I do not know any windows program that uses putty
and there are plenty linux/unix alternatives.
but it might be usefull to some people. ( i don't know anyone )
perhaps it is time to seperate all the winelib progs from the main wine
package and
On Thursday 21 November 2002 12:28, you wrote:
I think what Dimi was talking about was sending the PuTTY team patches
so they could offer a Linux version on their download site, rather than
actually supplying it with Wine.
than it might still be a usefull thing to keep all the winelibs in
one
Mark Hannessen wrote:
A couple of questions - if a program uses Winelib, is it all statically
linked or do you still need a wine installation for it to work.
winelib apps need wine dll functions and are not static compiled.
so wine is needed to run wine apps
I started writing this mail,
A couple of questions - if a program uses Winelib, is it all statically
linked or do you still need a wine installation for it to work.
winelib apps need wine dll functions and are not static compiled.
so wine is needed to run wine apps
I started writing this mail, and during
Boris [EMAIL PROTECTED] wrote:
I cant seem to get Office '97 installed. Setup starts up and when it
says Searching for installed components, It says Setup cannot
continue. What could be causing that?
You're trying to install an upgrade-only version of Office '97. This
version will scan your
Steven Edwards wrote:
The problem we have with people making and shipping winelib apps at this point is that with every
release of WINE untill 1.x we will have breakages.
If winelib contains what I think it contains, I don't see why that
should happen. Are you sure about that point?
After
Hi Dimi,
I have been doing some work on OWNERDATA listviews with Outlook and
have found something with my test programs.
Even if i create a Dialog with DialogBoxW to contain the listview,
and return NFR_UNICODE for WM_NOTIFYFORMAT my windows 2000 box still
calls notifies with
On November 21, 2002 10:19 am, Aric Stewart wrote:
I wondered if you had found a counter example in your own tests, or
if you had just assumed that windows would act rationally. If it was an
assumption then I will happily make a patch that mimic the behavior of
my test program. If you have
On November 21, 2002 06:28 am, Mike Hearn wrote:
I think what Dimi was talking about was sending the PuTTY team patches
so they could offer a Linux version on their download site, rather than
actually supplying it with Wine.
Indeed. Sorry, my mistake, I was not clear. I realized that my email
Hi,
As the prospect of having to go back to XP is looming if I can't get the
adobe svg plugin working properly, I'm trying to build my own Wine, and
then point CrossOver to it so stuff like IE will (hopefully) continue to
work well. Unfortunately the compile dies when it tries to build
winetest,
On Wed, Nov 20, 2002 at 06:59:42PM +0800, yf wrote:
ÔÚ 2002-11-20 Èý µÄ 18:13£¬ Patrik Stridvall дµÀ£º
0803 2002-11-20 0605 0
802 15:27050
1 Marcus Meissner
040
70
8080502
On Tue, Nov 19, 2002 at 09:20:40PM +0800, yf wrote:
I'm using a application that using
On November 21, 2002 04:47 am, Martin Wilck wrote:
This is because of the circular include sequence
winsock.h - windows.h - winsock2.h - winsock.h
where the last include doesn't work because _WINSOCKAPI_ is already
set.
The following patch fixes it.
Thank you, this works beautifully.
--
On Fri, 15 Nov 2002, Patrik Stridvall wrote:
Alfred (Cc:ed) verified that these warnings can be eliminated by
o getting rid of the -Wl,-Bsymbolic option (which you probably want
to keep to actually get warnings linking symbols are hosed), or
o explicitly adding -lc.
Would you mind
Mike Hearn a écrit:
Hi,
As the prospect of having to go back to XP is looming if I can't get the
adobe svg plugin working properly, I'm trying to build my own Wine, and
then point CrossOver to it so stuff like IE will (hopefully) continue to
work well. Unfortunately the compile dies when it
On November 21, 2002 11:25 am, Shachar Shemesh wrote:
Performing the communications with the wineserver
from the app itself (rather than from dlls the app is dynamically linked
with) seem to me like asking for trouble, if only because it deviates
significantly from the way Windows apps are
Here is a patch which preserves alot of your structure.
it works to correct my bug in Outlook.
-aric
Dimitrie O. Paun wrote:
On November 21, 2002 10:19 am, Aric Stewart wrote:
I wondered if you had found a counter example in your own tests, or
if you had just assumed that windows would act
Mike Hearn wrote:
Am I missing something here?
Not sure. I was under the impression that Winelib apps used wineserver,
the protocol for which won't be frozen until 1.0 - this might be what he
meant.
I will have to confess utter ignorance here. However, this does not seem
a wise choice
Rick Romero wrote:
...
I don't like being the one to introduce a hack, so FWIW, Pegasus Mail
only requires the patch I attached. If this works for Duane also,
excellent, I assume you'd want to keep the hack to a minimum.
Unfortunately, fpga_editor is still broken with this patch, though it
OK, yeah, it turns out I do seem to have the headers, I was thrown by
the odd location of them.
The actual source of the error is this function in winetest.c (this is
after preprocessing btw)
static void xs_init(void)
{
extern void boot_wine(CV *cv);
Perl_newXS(my_perl,
On November 21, 2002 11:33 am, Aric Stewart wrote:
Here is a patch which preserves alot of your structure.
it works to correct my bug in Outlook.
Wow! It's hard to believe this is the case... WTF is this so?
I mean, did you find a reasonable explanation to this behaviour?
Did you have a chance
On November 21, 2002 11:37 am, Mike Hearn wrote:
static void xs_init(void)
{
extern void boot_wine(CV *cv);
Perl_newXS(my_perl, wine::bootstrap,boot_wine,winetest.c);
}
which causes this output:
gcc -c -I. -I. -I../../include -I../../include `perl -MExtUtils::Embed
-e perl_inc`
*** Warning: the OpenGL version you have installed relies on libpthread
for
*** thread-safety. To prevent crashes, OpenGL support has been disabled.
*** A fix for glibc 2.1.3 that seems to work is included in this version
of Wine,
*** start configure with '--enable-opengl' to force OpenGL support.
Yeah it is sort of amazing.
I have a test program under windows if you would like to see the Visual
studio project. It has _UNICODE defined in the project, I create a main
window with CreateWindowW Inside that window i do a DialogBoxW. That
dialog box has a listview which is OWNERDATA.
I look
I re-ran configure and forced OpenGL, but I would like to know how to
get a non-libpthread version of OpenGL if at all possible..
Well, you can't... It depends on your OpenGL 'vendor'. Some link to pthread,
some don't. But well, this warning is mostly obsolete as we did not have any
bug
On Thu, 2002-11-21 at 11:13, Aric Stewart wrote:
Yeah it is sort of amazing.
I have a test program under windows if you would like to see the Visual
studio project. It has _UNICODE defined in the project, I create a main
window with CreateWindowW Inside that window i do a DialogBoxW. That
On November 21, 2002 06:27 am, Dustin Navea wrote:
Do you think that this patch will fix my treeview problem(s)? Or should
the same sort of thing be done to treeview as a test to see if it will?
Yes, the same sort of patch should be done for treeview. I'll try to
do one soon.
--
Dimi.
Gerald Pfeifer [EMAIL PROTECTED] writes:
How should this be solved (in a portable way)?
Adding -lc seems the right way. In fact I committed that fix last
night ;-)
--
Alexandre Julliard
[EMAIL PROTECTED]
On November 21, 2002 12:13 pm, Aric Stewart wrote:
i tried all sorts of variations on the W and A creations to see if i saw
any difference and I did not.
Also this patch fixes the bug in Outlook...
Yes. And beyond this, it correlates perfectly with the treeview
problems we have been
Gerald Pfeifer [EMAIL PROTECTED] writes:
How should this be solved (in a portable way)?
Adding -lc seems the right way. In fact I committed that fix last
night ;-)
Yes I noticed. :-)
However, it doesn't seem to be the 100% correct fix.
DLLs using pthreads like the ones depending on
Folks,
On windows people link to winspool as such:
-lwinspool
In Wine, we need to do:
-lwinspool.drv
Obviously, this causes problems. Should we create
a winspool - winspool.drv link in dlls/?
--
Dimi.
I have a problem with wine, and everyone says that it is a bug, so I suppose
that it would have some relevance here. Any help or solutions would be helpful.
there's nothing wrong at first sight with the sound on this trace
could you resend it to me with a -debugmsg +winmm,+wave,+dsound
btw,
Winelib apps have no direct dealings with the wineserver.
However, our DLL interface is not that stable yet, that's
why we're pushing to finish the DLL separation (Phase 1).
Check out the 0.9 TODO! :)
This was what I was talking about. It MAY be possible for current
winelib binarys to work
Marcus Meissner a écrit :
Hmm, what is wrong with A for all the first 3 cases?
nothing. but we need a way to let users pick up 2 = B (it doesn't mean
we'll forbid 2 = A for all the wineconsole lovers ;-)
A+
John K. Hohm wrote:
Well, I was hoping some of the COM experts would comment on that. If
I understand it right you are avoiding writing some thunking routines
for older interfaces, at the cost of an extra pointer access in every
function. I'm not convinced it's a good trade-off, but I'd like to
On Thu, 21 Nov 2002, Alexandre Julliard wrote:
Adding -lc seems the right way. In fact I committed that fix last
night ;-)
Thanks a lot! :-)
On Thu, 21 Nov 2002, Patrik Stridvall wrote:
However, it doesn't seem to be the 100% correct fix.
DLLs using pthreads like the ones depending on OpenGL
Grr. Maybe I should go look at last year's ttydrv to see how
to do it properly :-)
most of the curses loading is protected by ifdef:s
(btw curses inclusion is 2 years and 8 months old... perhaps you didn't
have the curse-devel package installed by then)
did you try recompiling wine with
On November 21, 2002 01:55 pm, Eric Pouech wrote:
4. I would love to be able to choose the terminal that's started.
That is, instead of having wineconsole pop up, wouldn't it
be cool if konsole/gnome-terminal/rxvt/xterm/etc would be
fired up depending on
1. If I start a command-line app in a terminal, I want
the app to make use of the terminal, not NOT start a
new one. Unix apps behave like this (eg. Midnight Commander)
and command-line Wine apps should not behave any differently.
that's the 2 = B case (or more exactly,
Sure, that's the initial invocation. But beyond that, what if
I run a a windows app, and that one starts a command line app?
In that case, I don't want wineconsole to pop up, but rather
my console of choice. A common example is winedbg: it starts up
in wineconsole, but I'd rather have it
On November 21, 2002 02:26 pm, Eric Pouech wrote:
this won't be easily possible, because wine has no knowledge on what
currently exists on the terminal
Sorry, I don't understand exactly the issues here, but what don't we
know to exist? I mean, if we start it, can't we assume a blank slate?
--
Gerald Pfeifer [EMAIL PROTECTED] writes:
Bummer. Would it work to *always* use -lc_r on FreeBSD, Patrik/Alfred?
AFAICS libc_r is a user-space thread implementation, it won't do the
right thing for us. I guess we'll need some kind of pthread emulation
like we have on Linux.
--
Alexandre
Dimitrie O. Paun a écrit :
On November 21, 2002 02:26 pm, Eric Pouech wrote:
this won't be easily possible, because wine has no knowledge on what
currently exists on the terminal
Sorry, I don't understand exactly the issues here, but what don't we
know to exist? I mean, if we start it,
On November 21, 2002 02:47 pm, Eric Pouech wrote:
various stuff:
- if another wine console is running on the same terminal
How can it, we're talking about the case when _we_ start up the
console, so there shouldn't be anything on it, no?
- when a console is started, we have to wait until all
On November 21, 2002 01:42 pm, Steven Edwards wrote:
Winelib apps have no direct dealings with the wineserver.
However, our DLL interface is not that stable yet, that's
why we're pushing to finish the DLL separation (Phase 1).
Check out the 0.9 TODO! :)
This was what I was talking about. It
This seems complicated... :)
that's why we need to simplify what we want to do ;-))
But, here's how I look at it:
1. If we start the program in our console, it makes use of it:
xterm -e wine myprog.exe
you say it should work just fine.
2. Now, in the case we start a
Geoff Thorpe a écrit:
On November 21, 2002 01:42 pm, Steven Edwards wrote:
Winelib apps have no direct dealings with the wineserver.
However, our DLL interface is not that stable yet, that's
why we're pushing to finish the DLL separation (Phase 1).
Check out the 0.9 TODO! :)
This was what I
On November 21, 2002 03:25 pm, Eric Pouech wrote:
This seems complicated... :)
that's why we need to simplify what we want to do ;-))
:)
this won't work, because CreateProcess passes from parent to child some
context information the child get it from wineserver using its parent
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On November 21, 2002 12:24, [EMAIL PROTECTED] wrote:
It seems like a simple fix is a test if hwnd is NULL and calling
PostThreadMessage with the right thread ID, but I don't know how
to get the current thread's ID. Any ideas/suggestions?
Folks,
Another problem developing Winelibs app while using your
Wine tree. Say you have the following:
-- a Winelib app you're working on
-- a Wine tree you're working on
-- you compile wine out-of-tree
Now, say you build your myapp.exe.so OK, and you now want
to create a symlink myapp -
Dimitrie O. Paun a écrit :
On November 21, 2002 03:25 pm, Eric Pouech wrote:
This seems complicated... :)
that's why we need to simplify what we want to do ;-))
:)
this won't work, because CreateProcess passes from parent to child some
context information the child get it
On November 21, 2002 04:44 pm, Eric Pouech wrote:
this won't support the case where the app creates it own console after
it has started
Duh! Forgot about that one. This is getting funny :) What about this one:
When we create a console, we start a process (say wconsole, since the
Folks,
Here's a quick status update on PuTTY as a Winelib app:
1. It compiles, links, and runs perfectly (Yay!)
2. I've talked to the PuTTY folks, and they agreed
to add Winelib as one of their targets in their
build process (provided I do the patch :))
3. I've modified they
Dimitrie O. Paun [EMAIL PROTECTED] writes:
Possible solution:
-- have winewrapper somehow in the Wine build tree.
One way to do that is to rename winewrapper to
winewrapper.in, and generate winewrapper at
build time
-- link to the winewrapper in the build tree
--
I contacted David Harris, author of Pegasus Mail, and here's what he had
to say. I am totally lost when it comes to the windowing stuff, I'm not
sure what's X and what's Windows. Hopefully that can help a little.. I
know the patches thread was really self-explanatory, but was centered on
the
On November 21, 2002 03:27 pm, Vincent Béron wrote:
There already is a versioning in the wineserver protocol; I believe the
present version is 68 or 69. The problem lies in using an app compiled
for another version than the installed wine libraries/server, and/or
surviving upgrades in the
On November 21, 2002 05:12 pm, Alexandre Julliard wrote:
You shouldn't use winewrapper, you should copy wineapploader and adapt
it to your situation. This is what winemaker is supposed to do too,
though I think it's somewhat broken right now.
OK, that's better. I don't need winemaker for this,
Alright, I did the new debugmsg and I also tried a few more things:
I installed a directx based game and the sound worked fine for it.
I tried to adjust the volume on the program itself and that didn't work.
I tried changing directories and such, that also didn't work.
Here is the output from
What is missing:
1. The winspool issue I've sent earlier is bugging me.
They link against -lwinspool, we require -lwinspool.drv
This is very awkward to implement, and my patch would
become a lot more intrusive (and maybe unacceptable).
We need to fix this on our end,
On November 21, 2002 05:46 pm, Sylvain Petreolle wrote:
can't this be done by winemaker ?
No, they have a very nonstandard build process, and there is
no way I'm going to send them a patch redefining they entire
process. This is way too invasive, really.
--
Dimi.
bash-2.05a$ wine -debugmsg +winmm,+wave,+dsound Rosetta.exe
trace:winmm:WINMM_LibMain 0x4163 0x1 (nil)
trace:winmm:WINMM_CreateIData Created IData (0x403f0ef8)
trace:winmm:MMDRV_Install ('wineoss.drv', 'wineoss.drv', mapper=N);
trace:winmm:MMDRV_Install Got 32 bit func 'auxMessage'
Dimitrie O. Paun [EMAIL PROTECTED] writes:
Now, what I don't like is to ship them that script. There's no need,
really, all they have to do is link to it. And for it to work right
out of the tree, I can just add a small thingy in wineapploader that
looks at where the symlink is pointing, and
On Thu, 21 Nov 2002, Dimitrie O. Paun wrote:
[...]
Reason is that __int64 is not defined. Now, this happens when I compile
a file that has only one include:
#include wchar.h
As a quick hack, I've added this:
typedef long long __int64;
to include/msvcrt/sys/types.h, but it doesn't
On November 21, 2002 06:05 pm, Alexandre Julliard wrote:
Actually it's a bit more complicated because wineapploader expects a
normal Wine installation, not to run inside the source tree. But I'm
I know, but it can be modified to support running out of the tree without
loss of functionality.
On November 21, 2002 06:34 pm, Francois Gouget wrote:
I'm not sure what the solution to this is. We could make sure that each
and every single Wine header includes (directly or indirectly)
'stddef.h' so that __int64 is always defined. But that seems pretty
ugly. Unfortunately I don't see any
PostMessage fails if you pass in NULL as the HWND argument.
According to the MSDN, a NULL HWND means The function behaves
like a call to PostThreadMessage with the dwThreadId parameter
set to the identifier of the current thread. Currently,
PostMessage tries to get the thread id of the hwnd, which
On Thu, 21 Nov 2002, Dimitrie O. Paun wrote:
On November 21, 2002 06:34 pm, Francois Gouget wrote:
I'm not sure what the solution to this is. We could make sure that each
and every single Wine header includes (directly or indirectly)
'stddef.h' so that __int64 is always defined. But that
Dimitrie O. Paun [EMAIL PROTECTED] writes:
If Wine was a mature, stable project, I'd agree with you. But it's not.
The ability to make a small change in Wine, go back to the Winelib app,
and test it, is invaluable. I would have simply given up debugging PuTTY
f I had to go through a wine
On November 21, 2002 07:08 pm, Francois Gouget wrote:
That would work, but it's worse. I checked with Visual C++ and you need:
-D__int8=char -D__int16=short -D__int32=int -D__int64=long long
Well, that's fine. Is this fix acceptable? In that case, we should get
rid of the #defines from the
On November 21, 2002 07:07 pm, Alexandre Julliard wrote:
Sure, but as Wine developer it's easy for you to write a small wrapper
script to run from inside the source tree.
The discussion got too theoretical. All I am saying is that right
now, working with Winelib is not pleasant. I can talk from
On November 21, 2002 07:54 pm, Alexandre Julliard wrote:
You can just put a few #ifndefs in our headers to avoid
redefinition warnings so that the defines can be added for apps that
require them.
Sounds like a plan. Expect a path soon.
--
Dimi.
Hello Wine-Devel
I have not filled a bug with this a some of you may already know a solution
to this problem.
I've a contributor to the Mono project (http://www.go-mono.com) working on
the System.Windows.Forms namespace. It has been decided to use Wine to
implement this assembly since the S.W.F
Dimitrie O. Paun [EMAIL PROTECTED] writes:
The discussion got too theoretical. All I am saying is that right
now, working with Winelib is not pleasant. I can talk from personal
experience. And I think it's in our best interest to remove any
unnecessary hoops that you have to jump through to
On Thu, 2002-11-21 at 17:46, Alexandre Julliard wrote:
ChangeSet ID: 6362
CVSROOT: /opt/cvs-commit
Module name: wine
Changes by: [EMAIL PROTECTED] 2002/11/21 17:46:06
Modified files:
tools : wineinstall
Log message:
Matthew Davison [EMAIL PROTECTED]
On November 21, 2002 08:20 pm, Alexandre Julliard wrote:
It's very good that you are
looking into it, I'm just trying to encourage you to make it pleasant
the right way, instead of simply hiding the unpleasantness under a few
scripts that won't fix the core issues.
It looks like you have made
Alexandre,
The winspool.drv issue is a lot more serious than the
in-tree execution. This one screws things up badly for
the PuTTY build system. Should we modify winebuild to
try to link with winspool.drv, and if that fails with
winspool.dll when -lwinspool is given? (or the other
way around, I
Dimitrie O. Paun [EMAIL PROTECTED] writes:
I'd love for (1) to get solved, but I don't have the time, and expertise to
do it now. And even if I had, there are other items with higher priority on
my TODO. My focus is on (2). The only reason I looked into compiling Winelib
apps is to gather
François-Denis Gonthier [EMAIL PROTECTED] writes:
François-Denis Gonthier [EMAIL PROTECTED] writes:
boehm_crash.exe.so: boehm_crash.o boehm_crash.exe.spec.o boehm_crash.exe.dbg.o
gcc -shared -Wl,-Bsymbolic -D_REENTRANT -DWINELIB -o boehm_crash.exe.so \
boehm_crash.exe.spec.o \
On November 21, 2002 09:20 pm, Alexandre Julliard wrote:
the main issue is identifying the problems and defining exactly what
we need it to do. And I think the right approach is to have Wine
developers like you try to port apps, because you know how to work
around the problems;
We are on the
Dimitrie O. Paun [EMAIL PROTECTED] writes:
I found out that working out of the tree is very useful. I'm certain
other Wine developers will find the same. Your answer is
Don't do it!.
which I don't think is reasonable given the current state of affairs.
No, I agree it's useful,
Dimitrie O. Paun [EMAIL PROTECTED] writes:
The winspool.drv issue is a lot more serious than the
in-tree execution. This one screws things up badly for
the PuTTY build system. Should we modify winebuild to
try to link with winspool.drv, and if that fails with
winspool.dll when -lwinspool is
-lntdll.dll and -lpthreads were left here from another makefile I've got.
I've removed them but it didn't help. Here is the usual backtrace from gdb:
Starting program: /usr/local/bin/wine boehm_crash.exe.so
[New Thread 16384 (LWP 18946)]
Program received signal SIGSEGV, Segmentation fault.
Hi all, This is my first time on this list.
I've been playing around with Wine with quite a bit of success, but I've
ran into a problem when trying to get an old program that uses IR to
work correctly. I've already post on comp.emulators.ms-windows.wine and
they referred my problem here. Here
Hey now that I got AIM running, (have to copy from a windows install and
force wine to use that winver) I noticed 2 small bugs.. Both are
related to comctl32 AFAICT...
1) When going to sign on, the controls think that the left mouse button
is pushed always, and so when you move the mouse over
Who could know better Wine internals than the author ? :)
Apparently, the problem lies in Boehm GC, but before mailing Hans
Boehm
about this (he can probably provide limited support only), I'd like
to hear
about the people that knows about the internals of Wine.
Hi!
I've got an application, which uses an asynchron file stream library. I uses
ReadFileEx() and alertable wait with SleepEx().
This doesn't work right with wine. It seems to get caught in an endless loop.
Wine and wineserver together use 100 % cpu power.
Does anyone already know, what's
François-Denis Gonthier [EMAIL PROTECTED] writes:
Apparently, the problem lies in Boehm GC, but before mailing Hans Boehm
about this (he can probably provide limited support only), I'd like to hear
about the people that knows about the internals of Wine.
It seems that seg fault is deliberate,
Brian Vincent wrote:
I've been meaning to put something together for a few days here..
shots to Brian isn't the best way to go about it as nobody knows who has
sent what. Have you actually got any yet Brian?
First, take a look at:
http://www.theshell.com/~vinn/ss
[snip]
The following
92 matches
Mail list logo
