Alexandre Julliard <julliard(a)winehq.com> wrote:
> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes:
>
> > Appended program uses CxxFrameHandler and crashes in wine with builtin
> > msvcrt, but not with native. Compile as Release version and include the
> MFC
> > dll. Can somebody compile for Alexandre? Alexandre, is this a start or do
> > you need something complete?
>
> That's a start, yes, thanks. I'll need a more complete example with
> nested try blocks, destructors all over the place, typed exceptions,
> etc. to make sure I understand all the compiler internal structures;
> but I can at least try to make that simple case not crash...
Although this may duplicate effort, I am familiar with several strange
combinations of exception handling that I know work with Visual C++ 6.0; I
will put them a test program for you. You can never have too many test
programs, right?
Hi,
The first release of the QEMU x86 emulator is available at
http://bellard.org/qemu/. QEMU achieves a fast user space Linux x86
emulation on x86 and PowerPC Linux hosts by using dynamic translation.
Its main goal is to be able to run the Wine project on non-x86
architectures.
Fabrice.
> My app reads the registry to figure out network information, in
> particular it queries the [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
> NT\CurrentVersion\NetworkCards\] key to discover network cards, then
> [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services] to figure out the
> IP address of each one (this program can bind to multiple adaptors).
> ...
> a) In initial setup, ie when you install Wine
> b) At Wine startup
> c) On demand, ie by writing special cases into the registry access code.
Clearly c) because that will work properly even when doing
hotplugging of pcmcia cards and doing interactive dialup
to an isp. Might want to cache it for 10 seconds or something,
and you might need to worry about what happens when programs
are reading the reg entries *while* an interface is changing. (heh.)
BTW there is a system call getifaddrs on many flavors of Unix that
does this kind of query, and there's a library implementation
of it for linux. See
http://www.kegel.com/dkftpbench/dkftpbench-0.45/getifaddrs.chttp://www.kegel.com/dkftpbench/dkftpbench-0.45/getifaddrs.h
The registry code should probably just call this function.
- Dan
--
Dan Kegel
http://www.kegel.comhttp://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Hi guys
For the next part of the work I am doing I am trying to figure out if there is
any way that the DCOM part of one of our products is going to work under Wine
at the server end.
I am not having much success so far and I was wondering if anyone knows
whether this is because I don't have things set up properly or if it is
because of some inherent known lack of functionality.
To start the ball rolling I was working with MSDN's DCOMTST test program pair.
I managed to get that working using the local server (after adding the
definition of IStream to the registry) but am having no luck getting the
client under Wine to talk to the server under Win98. In fact the client side
doesn't even seem to send out a single TCP/IP packet.
(Aside - Nice demonstration of lazy Microsoft code; in their error reporting
they call FormatMessage, ignore the return code and somehow print the
returned error message, even when one hasn't been allocated; I guess it only
works under Windows because the print routine traps the access violation)
I am currently running native ole32 and native rpcrt4.
The builtin rpcrt4 fails on a call to unimplemented
RpcServerInqDefaultPrincName but I don't understand why it is even calling
that; why does it think I have Netware only and why does it think this is a
server process.
Anyone an expert in any of this stuff?
--
Bill Medland
ACCPAC International, Inc.
medbi01(a)accpac.com
Corporate: www.accpac.com
Hosted Services: www.accpaconline.com
I propose the following WineHQ patch to present and clarify Wine's
goals. I'm submitting this to wine-devel first to get a feel of whether
that would be a good addition and whether that sounds reasonable and
accurate enough.
Index: templates/en/about.template
===================================================================
RCS file: /home/wine/lostwages/templates/en/about.template,v
retrieving revision 1.7
diff -u -r1.7 about.template
--- templates/en/about.template 24 Mar 2003 22:49:03 -0000 1.7
+++ templates/en/about.template 30 Mar 2003 02:35:46 -0000
@@ -29,4 +29,70 @@
<a href="mailto:[email protected]">julliard(a)winehq.com</a>. For a list of
current developers, see the <a href="?page=who">Wine Who's Who</a>.</p>
+
+<h1>Wine's Goals</h1>
+
+<p>As mentionned in many places, the primary goal of Wine is to make it
+possible to run Windows applications on x86-based Unix systems. But there is
+often confusion as to what this covers. So let's clarify things a bit:
+
+<ul>
+ <li>Wine does not try to be a better Windows than Windows. What this means
+ is that Wine will not try to extend, improve or 'fix' the Windows API in
+ an attempt to lure developpers into using it. While we think that it is
+ important to provide a way to reuse the legacy Windows applications that
+ are out there, we feel that for new developments there are better APIs
+ than Win32.
+
+ <li>Wine Is Not a (CPU) Emulator. So no, we will not integrate a CPU
+ emulator in Wine any time soon. However we will do what we can to make it
+ possible to integrate Wine into a CPU emulation environment that would
+ provide the regular Unix services that Wine depends on. In such a scheme
+ both Wine and the Windows application would be run in that environment.
+ Two candidates that come to mind are <a
+ href="http://fabrice.bellard.free.fr/qemu/">QEMU</a> and
+ <a href="http://www.transitives.com/tech_overview.htm">Dynamite</a> from
+ <a href="http://www.transitives.com/">Transitives Technologies</a>.
+
+ <li>Wine's goal is to provide replacements for just those DLLs and APIs
+ that are needed to run Windows applications. This means that we will not
+ provide replacements for DLLs that are always shipped together with an
+ application. This also means that implementing an API that no application
+ ever uses is not a priority. Similarly, until there are applications out
+ there that use the Win64 API, it will not be a priority. That being said,
+ we will certainly try to keep our options open and to improve our API
+ coverage as we can.
+
+ <li>Making it possible to use Windows device drivers or VxDs on Unix is not
+ part of Wine's goals. Device drivers don't use the same API that Windows
+ applications do, and run in ring 0 instead or ring 3. To make it possible
+ to use them on Unix, one would have to hack the kernel, implement a
+ completely different API. In other words, this would be a completely
+ separate project. However, if you want to reuse Windows drivers on
+ non-Microsoft operating systems we recommend that you have a look at
+ <a href="http://www.reactos.com/">ReactOS</a>.
+
+ <li>Wine is not an operating system or a desktop environment. So writing
+ device drivers, file or window managers that look like Windows, are not
+ part of Wine's goals. If you are interested in those, the best would be to
+ contribute to the <a href="http://www.kernel.org/">Linux</a>,
+ <a href="http://www.freebsd.org/">FreeBSD</a> or
+ <a href="http://www.reactos.com/">ReactOS</a> kernels, or to the
+ <a href="http://www.gnome.org/">Gnome</a> or
+ <a href="http://www.kde.org/">KDE</a> desktop environments. You will get
+ the added benefit that your contribution will then be usable by everyone,
+ not just by Wine users.
+
+ <li>Wine's focus is on Unix operating systems, and to some extent Linux
+ because that is what most of our developpers are using. However we welcome
+ ports to other architectures such as
+ <a href="http://www.reactos.com/">ReactOS</a> or
+ <a href="http://bewine.beunited.org/">BeWine</a>, and will try to make
+ it possible for them to reuse as much of Wine as possible. After all,
+ reimplementing the Windows API is a big enough task that it is best if we
+ can all work together on it.
+</ul>
+
+
<p> </p>
+
--
Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/
War doesn't determine who's right. War determines who's left.
Hello Everyone,
First I want to thank everyone for the help they have given me in
dealing with my bad spelling, lack of grammer and not following the
rules when working to get most of wine built for mingw. I'm trying to do
a little house keeping with Wine and ReactOS and had a few
changes/questions that could make my and the ReactOS teams life a little
easyer with the port.
1. Can we set --disable-win16 CFLAGS=-DWINE_NOWINSOCK" to be default
when building under Mingw? I tried to write a configure patch for this a
while back but never could get the bastard to work. Once this option is
removed all we will be left with is ./configure to configure wine for
mingw. None of the WINE networking stuff will really work for anyone
working with mingw and I dont expect that to change anytime soon.
Without this flag anything that include winsock.h or winsock2.h will
puke when building on Windows. I know that WINE on linux will need win16
for a while due to older installers that are 16bit but for the mingw
port thats kind of not important.
2. Can we set a conditional option to not build winegcc and winewrap?
These are not needed on Windows as they are only used to port mingw
applications to winelib. Due to the use of Unixisms in these programs
(fork, waitpid, etc) they wont build. Now I know we could stub fork and
wrap waitpid to wait but its kind of pointless and I can see one day
when someone will ask why these dont work on windows even though we
build them. IMHO they just shouldnt get built for us.
winegcc.c: In function `spawn':
winegcc.c:86: warning: implicit declaration of function `fork'
winegcc.c:89: warning: implicit declaration of function `waitpid'
winegcc.c:92: warning: implicit declaration of function `WIFEXITED'
winegcc.c:92: warning: implicit declaration of function `WEXITSTATUS'
gcc -DWINE_NOWINSOCK -Wall -mpreferred-stack-boundary=2 -gstabs+
-Wpointer-arith
-o winegcc winegcc.o -L../libs/port -lwine_port
winegcc.o(.text+0x1a3): In function `spawn':
g:/src/wine-dev/wine/tools/winegcc.c:86: undefined reference to `fork'
winegcc.o(.text+0x1d2):g:/src/wine-dev/wine/tools/winegcc.c:89:
undefined refere
nce to `waitpid'
winegcc.o(.text+0x202):g:/src/wine-dev/wine/tools/winegcc.c:92:
undefined refere
nce to `WIFEXITED'
winegcc.o(.text+0x211):g:/src/wine-dev/wine/tools/winegcc.c:92:
undefined refere
nce to `WEXITSTATUS'
3. Exclude WINEserver. This is a fun one. I took a look at this a while
back a was able to get about 80% of it to compile native on windows.
Before we can even get wineserver to build/link on mingw we still have
the same problem a cygwin port has and that is what to do with the
get/set thread_context stuff. Also from all I have read a mingw port
would require a major redesign because of the signal/pipe usage. I
looked at porting some of the stuff to windows sockets a while back and
decided I still cant program well enough and I have more interesting
things to do like work on ReactOS. =P
4. This may be more a mingw problem rather then something with WINE but
I figured I would ask while I was making noise. When I try to build the
regression tests under mingw with gcc-3.x I am getting this error. If I
dont include wines libmsvcrt.a it goes away. do the exit functions in
wine and mingws source not agree?
gcc registry.o testlist.o -o advapi32_test.exe -L../../../dlls
-ladvapi32 -lke
rnel32 -lntdll -L../../../libs/wine -lwine -L../../../libs/port
-lwine_port -lm
../../../dlls/libmsvcrt.a(ds00443.o)(.text+0x0): multiple definition of
`atexit'
C:/mingw/bin/../lib/gcc-lib/mingw32/3.2.1/../../../crt2.o(.text+0x40):crt1.c:
fi
rst defined here
../../../dlls/libmsvcrt.a(ds00319.o)(.text+0x0): multiple definition of
`_onexit
C:/mingw/bin/../lib/gcc-lib/mingw32/3.2.1/../../../crt2.o(.text+0x60):crt1.c:
fi
rst defined here
make[1]: *** [advapi32_test.exe] Error 1
make[1]: Leaving directory `/g/src/wine-dev/wine/dlls/advapi32/tests'
make: *** [tests] Error 2
At some point I will do documentation for Mingw on MSYS/Cygwin <g>
Thanks
Steven
Gerald Pfeifer <pfeifer(a)dbai.tuwien.ac.at> writes:
> How about the following patch?
>
> It's needed for compilation on FreeBSD; in case it's not correct,
> how should we solve the problem?
I think the code is wrong, we shouldn't store a Linux-only define in a
Windows structure, we should use a Windows define. Any one knows what
the right value should be?
--
Alexandre Julliard
julliard(a)winehq.com
I am currently working on the
EnumSystemLanguageGroups/EnumLanguageGroupLocales functions.
I have finished everything but there is one thing I don't know.
The different language group names are stored in the kernel32.dll
resources in a string table. They are indexed from 1 to 17 in the
win2k/winxp kernel32 dll.
However, in wine it seems these ID are used. So I am wondering how can I
workaround that. I can't change the ID for the groups because they are
defined in winnls.h from 1 to 17.
At the present time I have a version ready to work but with the group
names not stored in the resources (so only one language is possible).
Do I have to change the kernel32 resources ( a lot of work) or does
anyone have an idea ?
Thanks
Max
--
Maxime Bellengé <maxime.bellenge(a)laposte.net>
Hi,
I have troubles with debugging winelib applications.
This is what makes me unhappy:
---
$ gdb wine
(gdb) r notepad
Starting program: /usr/local/bin/wine notepad
XIO: fatal IO error 0 (Success) on X server ":0.0"
after 187 requests (187 known processed) with 0 events remaining.
Program exited with code 01.
---
I'm getting similar results with winedbg (running "winedbg notepad") -
there is just bunch of debug outputs before the error is printed.
However, this happens only when I'm running winedbg from outside wine
directory (checked out from cvs). It works when I'm running winedbg from
wine directory.
I was digging inside wine and problem occurs somewhere in
MODULE_DllProcessAttach() function. This lead me to assumption that
problem is probably caused by incorrect paths to libraries, which
couldn't be found then. I think I should mention that also wineinstall
failed because regedit couldn't find "programs/regedit/regedit.exe.so"
(this file is definitely there) so I had to run regedit to insert
winedefault.reg into registry manualy - I needed to copy winedefault.reg
file to /tmp which is accessible from inside wine system as drive E:\.
My working environment is mdk-9.1 with XFree86 version 4.3.0, native
nvidia driver doesn't work, the same with nvidia driver v. 41.91).
If you have any idea what could be wrong with my linux box, please let
me know. I prefer gdb for debugging since I can use ddd with gdb.
Thanks.
--Juraj
