Hi,
Now the cpp RTTI changes are in, the tests for them can be applied.
this is a slighly updated version of the original patch that fixes a
problem
with asm, register clobbers and optimisation I found when I moved to
gcc
3.2.2, and also works with really ancient, buggy versions of msvcrt
Hi,
Ignore this, it should have gone to wine-patches, and yahooPops seems
to be
truncating my mails. Aargh!
Jon
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Jon Griffiths [EMAIL PROTECTED] writes:
+dlls/msvcrt/cpp.c
Use exception as the base for all exception derived classes.
Implement type_info methods correctly.
Add static RTTI for exported objects.
Throw exceptions when run time casts fail.
Why did you remove all
Jon Griffiths [EMAIL PROTECTED] writes:
+dlls/msvcrt/cppexcept.c
strip dump code when NO_TRACE_MSGS is defined
The compiler should optimize this out, and even if it doesn't that's
no big deal. It certainly doesn't justify adding #ifdefs.
--
Alexandre Julliard
[EMAIL PROTECTED]
Jon Griffiths [EMAIL PROTECTED] writes:
- Functions exported by name only should not be given ordinal numbers
in the .def output, so that link.exe can fill up empy ordinal slots
and create a valid export table. Not doing this leads to an incorrect
export table without any warnings or errors
--- Jon Griffiths [EMAIL PROTECTED] wrote:
This patch addresses most of the existing issues building Wines dlls
as native win32 dlls using msvc, namely:
- We need to export forwards from the .def file.
- We need to export any implemented ordinal functions and mark them
as NONAME.
-
--- Jon Griffiths [EMAIL PROTECTED] wrote:
+tools/winebuild/build.h tools/winebuild/import.c
tools/winebuild/parser.ctools/winebuild/spec16.c
tools/winebuild/spec32.c
Export '@'-functions and forwards
Support PRIVATE and optional ordinal numbers in .def files
Allow
I notice that WINE has a clone of MSVCRT. I also know that MSVCRT exports
some C++ symbols. How does WINE and its clone of MSVCRT and its build
system handle the differences in name mangling between MSVCRT and GCC?
Also, how does it handle the differences between the different class formats
On Wed, 2003-07-16 at 15:00, Jonathan Wilson wrote:
I notice that WINE has a clone of MSVCRT. I also know that MSVCRT exports
some C++ symbols. How does WINE and its clone of MSVCRT and its build
system handle the differences in name mangling between MSVCRT and GCC?
If you look in the spec
Jonathan Wilson wrote:
I notice that WINE has a clone of MSVCRT. I also know that MSVCRT
exports some C++ symbols. How does WINE and its clone of MSVCRT and its
build system handle the differences in name mangling between MSVCRT and
GCC?
MSVCRT is the the C (and C++) run time library for MS
/msvcrt/sys/time.h needs to be added, as
these are the only two ways of avoiding mixture of the MSVCRT sys/types.h
with the native systems sys/time.h.
(Or -I../../include/msvcrt should be removed when compiling
programs/notepad, but I'm afraid that's not right either.)
Gerald
--
Gerald Jerry [EMAIL
/time.h for struct timeval definition.
causes compilation failure of programs/notepad:
/sw/gcc-3.2.2/bin/gcc -c -I. -I. -I../../include -I../../include
-I../../include/msvcrt -D_REENTRANT -fPIC -DNO_LIBWINE_PORT -Wall
-mpreferred-stack-boundary=2 -gstabs+ -Wpointer-arith -g -O2 -o
time.h and simple removing that #include statement
from include/winsock.h solve this problem for me (on FreeBSD 4.8).
My intuition is that either the addition of #include sys/time.h needs
to reverted or a dummy include/msvcrt/sys/time.h needs to be added, as
these are the only two ways
. -I. -I../../include -I../../include
-I../../include/msvcrt -D_REENTRANT -fPIC -DNO_LIBWINE_PORT -Wall
-mpreferred-stack-boundary=2 -gstabs+ -Wpointer-arith -g -O2 -o
License_En.o License_En.c
In file included from ../../include/winsock.h:68,
from ../../include/winsock2.h
Taking _fullpath as a model, I implemented msvcrt._wfullpath (patch
attached).
My unique problem : it makes use of an internal helper called
msvcrt_fln_fix,
which I dont understand.
It seems to work without it, so I think its useful only in specific
cases.
Could someone explain what it does
Hi,
I have changed the macros in the msvcrt headers to static inline functions.
The modified files are: conio.h, ctype.h, direct.h, malloc.h, process.h, search.h,
stdio.h, stdlib.h and string.h (in the include/msvcrt directory).
I have attached a patch for the same.
Thank you.
Madhura
Uwe Bonnes [EMAIL PROTECTED] writes:
+#ifdef P_tmpdir
+ if ( (dir) lstrcpynA(dirname, P_tmpdir,MAX_PATH)
+(GetTempFileNameA(dirname,prefix,0,tmpbuf)))
+goto done;
+#endif
+ if ( (GetEnvironmentVariableA(PWD,dirname,MAX_PATH) )
+
Hi Uwe,
On Sat, 15 Feb 2003, Uwe Bonnes wrote:
Test succeeds with native msvcrt.dll. Patch to msvcrt/file.c comming.
Is it worth marking the tests as todo and removing the todo once wine
passes the tests?
Just a thought ...
Paul Millar
Hi,
the following patch to dlls/msvcrt/locale.c
revision 1.15
date: 2003/02/11 22:11:17; author: julliard; state: Exp; lines: +15 -0
Marcus Meissner [EMAIL PROTECTED]
Implemented __crtLCMapStringA.
causes the following warning on FreeBSD 4.7 using GCC 2.95.4:
locale.c: In function
in the relay output are tons of:
0009:Call kernel32.TlsGetValue() ret=405d833e
0009:Ret kernel32.TlsGetValue() retval=402a7810 ret=405d833e
0009:Call msvcrt.__CxxFrameHandler(403821f0,40592c60,4038226c,40382180)
ret=400c42b7 fs=008f
eax=179c3008 ebx=400f6204 ecx=4010de20 edx
On Sun, Feb 02, 2003 at 09:05:38PM +0100, Marcus Meissner wrote:
On Sun, Feb 02, 2003 at 12:34:53AM +0100, Michael Stefaniuc wrote:
Any tips how to debug this further?
This is usually a missing function in msvcrt. Run with -debugmsg +seh
and check the output directly before
--- Dimitrie O. Paun [EMAIL PROTECTED] wrote:
These are needed by the inline functions in the header.
ChangeLog
Create stubs for chsize, dup, and dup2.
I think chsize and ftruncate do the same thing so is there anyway to forward the call
for chsize
to ftruncate on platforms that have it?
to violent behaviour...
This patch depends on msvcrt: stubs for chsize, dup, dup2
and it obsoletes sys/{stat,types}.h: mode_t, umask (take 2)
since I was difficult to separate them.
Also, I did not know what to do about _open(), and _sopen()
as they take variable number of arguments, so I've left them
Folks,
We have a lot of code in msvcrt headers like so:
#define umask _umask
#define unlink _unlink
#define write _write
This breaks C++ that define a write method in a header,
and then implement it like so:
#include io.h
void MyClass::write(...) { write(...); }
I suggest we turn those
Dimitrie O. Paun wrote:
I suggest we turn those defines into inlines, like this:
inline int write(int fd, const void* ptr, unsigned int size) { return _write(fd, ptr, size); }
Any other solutions?
Sure, there are two:
0. use a linker alias for _write
1. actually have a function write() that
On Thu, 9 Jan 2003, Dimitrie O. Paun wrote:
Folks,
We have a lot of code in msvcrt headers like so:
#define umask _umask
#define unlink _unlink
#define write _write
[...]
I suggest we turn those defines into inlines, like this:
inline int write(int fd, const void* ptr, unsigned int size
Francois Gouget [EMAIL PROTECTED] writes:
The strange thing is that the MSVC headers simply define their
prototype, e.g.:
_CRTIMP int __cdecl umask(int);
Yet these APIs are not exported by the msvcrt library or by any other
dll that I know of. And still applications compile and link!
I
On January 9, 2003 08:38 pm, Alexandre Julliard wrote:
I think you have to link with oldnames.lib for that. We probably have
to provide an oldnames.lib too.
OK, but what do we do now about those defines?
--
Dimi.
On December 14, 2002 02:10 pm, Dimitrie O. Paun wrote:
ChangeLog
Do not explicitly include msvcrt files from msvcrt headers.
Include windef.h instead of winnt.h to get all appropriate types.
Alexandre,
What about this one? Currently {ming,wine}wrap are badly broken.
I hope this one
Dimitrie O. Paun [EMAIL PROTECTED] writes:
What about this one? Currently {ming,wine}wrap are badly broken.
I hope this one is rather uncontroversial, but it does depend on
that bit from crtdll, and I think that is the problem.
I'd prefer that we simply get rid of these includes. This
On December 13, 2002 02:57 pm, Alexandre Julliard wrote:
Do we actually need to include other headers from the msvcrt includes?
My Windows headers don't include anything, but they are from an old
VC++ version. Could someone with a newer VC++ check if this is still
the case?
I don't know, I
On 13 Dec 2002, Alexandre Julliard wrote:
Dimitrie O. Paun [EMAIL PROTECTED] writes:
Here is the problem:
A. The msvcrt files include other msvcrt files, but they should
do so *without* explicitly asking for them. That is, they should
#include stdio.h
instead
Hi guys,
Here's a small test program:
#include windows.h
#include stdio.h
#include stdlib.h
#include assert.h
int main()
{
printf(sizeof(wchar_t)=%d\n, sizeof(wchar_t));
return 0;
}
And I want to compile this with our msvcrt headers.
Look what happens:
[dimi@dimi wine]$ gcc
On November 19, 2002 09:46 am, Dimitrie O. Paun wrote:
[dimi@dimi wine]$ gcc -nostdinc -fshort-wchar -I
/home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include
test.c
Hm, maybe we need the standard headers after all.
Even though this might create confusion
Dimitrie O. Paun wrote:
On November 19, 2002 09:46 am, Dimitrie O. Paun wrote:
[dimi@dimi wine]$ gcc -nostdinc -fshort-wchar -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include test.c
Hm, maybe we need the standard headers after all.
Even though
On November 19, 2002 10:26 am, David Fraser wrote:
So the following C program compiles fine with the above command,
-fshort-wchar or not, and making stdio.h angle-bracketed will take away the
size_t warning:
What I'm waiting for is a solution that does not touch the program
I've posted. My
Am Die, 2002-11-19 um 15.59 schrieb Dimitrie O. Paun:
Nevertheless, they solve only part of the problem:
[dimi@dimi wine]$ gcc -fshort-wchar -I /home/dimi/dev/wine/wine.src/include/msvcrt
-I /home/dimi/dev/wine/wine.src/include test.c
test.c: In function `main':
test.c:8: `wchar_t
On November 19, 2002 10:51 am, Martin Wilck wrote:
Using this line and WCHAR instead of wchar_t, I'm fine. It prints sizeof
(WCHAR) = 2.
I know, but this is not good enough. I want to port some apps over
(eg putty) and that one uses wchar_t. Changing the source is not an
option IMO. In this
Dimitrie O. Paun a écrit:
On November 19, 2002 10:26 am, David Fraser wrote:
So the following C program compiles fine with the above command,
-fshort-wchar or not, and making stdio.h angle-bracketed will take away the
size_t warning:
What I'm waiting for is a solution that does not touch the
On November 19, 2002 10:57 am, Vincent Béron wrote:
Quickly checking in MS's headers (an old version), there's a lot of
typedef to define wchar_t.
I figured that much. I was hoping for a patch... :)
--
Dimi.
, and
msvcrt/wctypes.h), we have the exact opposite: typedef wchar_t WCHAR,
with a default to typedef unsigned short WCHAR if wchar_t is not
defined. So we need to define wchar_t, not WCHAR.
BTW, I believe MS headers have the same order (wchar_t - WCHAR).
Actually, I have similar questions about
On Tuesday 19 November 2002 09:58 am, Dimitrie O. Paun wrote:
On November 19, 2002 10:57 am, Vincent Béron wrote:
Quickly checking in MS's headers (an old version), there's a lot of
typedef to define wchar_t.
I figured that much. I was hoping for a patch... :)
The wine headers are very
/msvcrt/stddef.h
===
RCS file: /var/cvs/wine/include/msvcrt/stddef.h,v
retrieving revision 1.4
diff -u -r1.4 stddef.h
--- include/msvcrt/stddef.h 10 Mar 2002 00:02:38 - 1.4
+++ include/msvcrt/stddef.h 19 Nov 2002 17:09:20
On Tuesday 19 November 2002 12:09 pm, Vincent Béron wrote:
Greg Turner a écrit:
Actually, I have similar questions about the programs and dlls
trees of wine... for example, Alexandre has requested that I remove
#ifdef's from rpcss... but can I safely code against the assumption
that
Hi
Looks like wine is not the only one in need of MS replacements. They're
only at version 0.0.1 but maybe they have something wine could use or
wine sure has something they could use...
http://mingwacr.sourceforge.net/
bye Fabi
Why not cmd.exe only, and hope to find it in the PATH?
I think the PATH in Windows contains windows\system32
in it by default.
Jaco, did you make sure you have the correct link into
C:\windows\system32 created by wineinstall ?
lrwxrwxrwx1 syl wine 31 aoû 3 09:08
On November 3, 2002 12:45 pm, Jaco Greeff wrote:
I have tried this, CreateProcess doesn't find cmd.exe if we don't specify
the full path. (This happend in the test case with the neccessary changes
made to default to cmd.exe). But yes, it would be great.
But the question is whether or not
On Sun, 3 Nov 2002 12:53:15 -0500, Dimitrie O. Paun [EMAIL PROTECTED] wrote :
But the question is whether or not CreateProcess _should_ find it, or not.
If it is, than it's a bug in CreateProcess, and working around it is rather
detrimental. If not, than fine, use the full path. We should
On 3 Nov 2002, Jaco Greeff wrote:
[...]
I however, did look at what the correct behaviour of CreateProcess
should be when I came across this. According to MSDN:
The string can specify the full path and file name of the module to execute
or it can specify a partial name. In the case of a
Francois Gouget wrote:
This is if you specify the lpApplicationName parameter. To have
CreateProcess search the path, leave it as NULL and specify wcmd.exe
... in lpCommandLine.
Very good point. I'll look into it.
Greetings,
Jaco
On Sat, 2 Nov 2002 10:56:02 -0500, Dimitrie O. Paun [EMAIL PROTECTED] wrote :
On November 2, 2002 10:41 am, Jaco Greeff wrote:
+#define POPEN_WCMD_EXEC C:\\Windows\\System32\\cmd.exe /c
Do we need this hardcoded path here?!? What about the COMSPEC
idea that Francois suggested?
I'm
On November 2, 2002 10:41 am, Jaco Greeff wrote:
+#define POPEN_WCMD_EXEC C:\\Windows\\System32\\cmd.exe /c
Do we need this hardcoded path here?!? What about the COMSPEC
idea that Francois suggested?
+#define LPCWSTR_TO_LPSTR(wszIn, nIn, szOut, nOut) \
+*nOut =
On November 2, 2002 11:07 am, Jaco Greeff wrote:
And everybody is a critic ;)
And especially me, lately :(
I would potentially rather more it to it's own header file than doing the
cut-n-paste thing inside a function... Would it be 50% ok with macro abuse
in a seperate header file?
Not
Hallo,
what is the status of winelib compilation of MFC and msvcrt?
Thanks
--
Uwe Bonnes[EMAIL PROTECTED]
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
On Fri, 1 Nov 2002, Uwe Bonnes wrote:
Hallo,
what is the status of winelib compilation of MFC and msvcrt?
I don't think compiling msvcrt with Winelib has ever been attempted.
Concerning compiling the MFC it has been a long time (6 months?) since
I tried. Shouldn't be must worse than before g
On Fri, Nov 01, 2002 at 03:16:58PM +0200, Jaco Greeff wrote:
+/* FIXME: Don't know what this value should be, 10 seems enough as
+ * the maximum number of simultaneous _popen'ed processes
+ */
#define POPEN_MAX_FILES 10
...
+INT POPEN_getOpenFileSlotPos(VOID)
+{
+INT i = 0;
+
Joerg Mayer wrote:
On Fri, Nov 01, 2002 at 03:16:58PM +0200, Jaco Greeff wrote:
Please output an ERR here to ask people to report that POPEN_MAX_FILES
needs to be increased.
Will do that, thanks.
Greetings,
Jaco
Jaco Greeff [EMAIL PROTECTED] writes:
1. Calling the popen function returns a FILE* which needs to be
converted to a MSVCRT_FILE*. The apprach taken here is potentially not
the best route but the only one I could think of. Is it suffiecient?
No, it's wrong. You should be using the Windows API
On 01 Nov 2002 08:40:20 -0800, Alexandre Julliard [EMAIL PROTECTED] wrote :
Jaco Greeff [EMAIL PROTECTED] writes:
1. Calling the popen function returns a FILE* which needs to be
converted to a MSVCRT_FILE*. The apprach taken here is potentially not
the best route but the only one I could
On 01 Nov 2002 08:40:20 -0800, Alexandre Julliard [EMAIL PROTECTED] wrote :
No, it's wrong. You should be using the Windows API (CreateProcess
etc.) not the Unix popen(). Then you can build a proper MSVCRT_FILE.
Sorry, I had a few beers tonight ;) Ok, I just remembered what my concerns
were
On 1 Nov 2002, Jaco Greeff wrote:
[...]
Now wera are faced with a problem in that wcmd is not a pure Windows
application and it doesn't reside in your Windows filesystem, rather it is
in your *nix path.
Try c:\Windows\System\wcmd.exe and I think you will find that it works.
--
Francois
On Fri, 1 Nov 2002 11:21:26 -0800 (PST), Francois Gouget [EMAIL PROTECTED]
wrote :
Try c:\Windows\System\wcmd.exe and I think you will find that it works.
*lol* Like I've said, expect me to be slow tonight :)
Francois == Francois Gouget [EMAIL PROTECTED] writes:
Francois On 1 Nov 2002, Jaco Greeff wrote: [...]
Now wera are faced with a problem in that wcmd is not a pure Windows
application and it doesn't reside in your Windows filesystem, rather
it is in your *nix path.
On Fri, 1 Nov 2002, Uwe Bonnes wrote:
[...]
Giving a fully qualified patch is probably bad advice here. Try wcmd.exe
only and have cmd.exe.so in wine's program directory.
Actually, using COMSPEC or something like that might be even better.
The exact behavior has to be checked on Windows though.
On Fri, 1 Nov 2002 20:50:07 +0100, Uwe Bonnes
[EMAIL PROTECTED] wrote :
Giving a fully qualified patch is probably bad advice here. Try wcmd.exe
only and have cmd.exe.so in wine's program directory. Wine sets on startup
WINEDLLPATH to $topdir/dlls:$topdir/programs and wineapploader there
On November 1, 2002 02:50 pm, Uwe Bonnes wrote:
Probably Alexandre knows more.
Well, yeah, he always does! :)
--
Dimi.
Quoting John K. Hohm [EMAIL PROTECTED]:
No, it's wrong. You should be using the Windows API (CreateProcess
etc.) not the Unix popen(). Then you can build a proper MSVCRT_FILE.
Sorry, I had a few beers tonight ;) Ok, I just remembered what my
concerns
were about using CreateProcess
On Thursday 31 October 2002 10:34 am, Jaco Greeff wrote:
- Tests that will fail with current implementation are temporarily
commented out
Is there a middle ground for tests that are expected to fail? If not,
IMO maybe there should be: It kinda defeats the purpose of a test
framework if we
Jaco == Jaco Greeff [EMAIL PROTECTED] writes:
Jaco ... Tests that will fail
Jaco with current implementation are temporarily commented out
Don't comment them out, matrk them todo. Look at the syntax in
documentation/testing.
And plain inlined patches are preferred against
with a FIXME. I don't want the test sequence to fail
for this issue which is solved by my msvcrt patch. The way I've done it
allows others to verify the new vfprintf patch with minimal work.
And plain inlined patches are preferred against attachments.
I'm doing this via a mail web interface, it has
maybe there should be: It kinda defeats the purpose of a test
framework if we just comment out tests that don't work...
Agreed. It will pass shortly though :) At this point the test will help
anybody wishing to verify my latest msvcrt patch. Plus, it really should
pass. The part that does fail
On Thu Oct 31 20:04:30 2002, Jaco Greeff [EMAIL PROTECTED] wrote :
On Thu, 31 Oct 2002 17:57:12 +0100, Uwe Bonnes
[EMAIL PROTECTED] wrote :
Jaco ... Tests that will fail
Jaco with current implementation are temporarily commented out
Don't comment them out, matrk them todo. Look
On Thursday 31 October 2002 12:04 pm, Jaco Greeff wrote:
On Thu, 31 Oct 2002 17:57:12 +0100, Uwe Bonnes
And plain inlined patches are preferred against attachments.
Just rabble-rousing here, but, until Alexandre stops accepting them, I
plan to attach all my patches. I /am/ willing to mark
On October 31, 2002 01:46 pm, Greg Turner wrote:
In support of attached patches:
Most are irrelevant. The point is not to transport the patch to
Alexandre. If so, you might as well send it directly to him.
Point is to get peer review, and maybe comments. For this purpose,
inlining the patch is
on it.) Anyway, here it is,
comments appreciated:
--[ inline-ish RFC ]
#include config.h
#include wine/port.h
#include stdio.h
#include stdlib.h
#ifdef HAVE_UNISTD_H
# include unistd.h
#endif
#include winbase.h
#include winnls.h
#include wine/unicode.h
#include msvcrt/stdio.h
#include msvcrt
What is wrong with using wcmd and extending it if necessary?
Chris
From: Jaco Greeff [EMAIL PROTECTED]
Date: 2002/10/31 Thu PM 04:27:43 EST
To: [EMAIL PROTECTED]
Subject: RFC: msvcrt _popen/_wpopen/_pclose
Hi,
I want some comments on the possibility of a _popen/_wpopen/_pclose
[EMAIL PROTECTED] wrote:
What is wrong with using wcmd and extending it if necessary?
Nothing. I must admit that I have looked at the wcmd code, but if I
remember correctly it lacks a /C switch. This I assume is the
extending part you are speaking about. Then again, I'm not 100% sure
that it
Jaco Greeff wrote:
[EMAIL PROTECTED] wrote:
What is wrong with using wcmd and extending it if necessary?
Nothing. I must admit that I have looked at the wcmd code, but if I
remember correctly it lacks a /C switch.
Yes it lack a /C switch, but it has the /c switch :) I'm in the
process
Jaco Greeff [EMAIL PROTECTED] wrote:
Ok, try number 3. I've made the changes as requested
* Get result length before allocating and copying with WideCharToMultiByte;
* Make intentions clear on strncat, replaced with strcat
* Removed CHAR castings to get the WCHAR formatting character.
*
Dmitry Timoshkov wrote:
You are still using L prefix and redundant (WCHAR) casts.
I know, it makes it more readable for me at least, telling you exactly
what you are busy with. As I've said previously, it is just semantics
mostly on compile-time. Either way it doesn't make a real difference,
LICENSE: LGPL
If you compile the following code with Visual C++ using the
/MD option (so
that it uses msvcrt.dll)
class CExceptionClass
{
public:
CExceptionClass() {number=0;}
long number;
};
void doSomething()
{
try {
throw CExceptionClass();
} catch(...) {
Patrik Stridvall [EMAIL PROTECTED] wrote:
[1] All tests currenly doesn't compile quite yet, but the
infrastructure is in place. I haven't had much time to look at
it yet. Help would be nice...
Patrik, what kind of help do you need regarding this issue?
I'll gladly help when I have time.
--
Patrik Stridvall [EMAIL PROTECTED] wrote:
[1] All tests currenly doesn't compile quite yet, but the
infrastructure is in place. I haven't had much time to look at
it yet. Help would be nice...
Patrik, what kind of help do you need regarding this issue?
I'll gladly help when I have
Jaco Greeff [EMAIL PROTECTED] writes:
* dlls/msvcrt/file.c Jaco Greeff [EMAIL PROTECTED]
- Allow for the processing of %S and %C format specifiers as per
bug #321
- Code duplicated/shared between dlls/user/wsprintf.c,
dlls/shlwapi/wsprintf.c and now dlls/msvcrt/file.c
That's not correct
Im trying to write regression tests for the sscanf function but ran into
some
problems. First, there were some conflicts with the defines in the headers
with my linux ones, but that was fixed simply by defining USE_MSVCRT_PREFIX.
Whenever I try to run the test it spews out an error: undefind
Im trying to write regression tests for the sscanf function but ran into
some
problems. First, there were some conflicts with the defines in the
headers with my linux ones, but that was fixed simply by defining
USE_MSVCRT_PREFIX. Whenever I try to run the test it spews out an error:
the msvcrt test-framework to the wine source tree. And thanks
for your findings.
Bye
--
Uwe Bonnes[EMAIL PROTECTED]
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
Jukka == Jukka Heinonen [EMAIL PROTECTED] writes:
Jukka Wine msvcrt sscanf and swscanf implementations incorrectly expect
Jukka strings to end with EOF. This crashes some applications which did
Jukka work with older versions of Wine that just forwarded msvcrt
Jukka sscanf
Am Die, 2002-09-17 um 21.47 schrieb [EMAIL PROTECTED]:
In my winelib app, most of the cpp files use MSVCRT
only, and thanks to Martin I've gotten those to compile.
If the small patches I sent make your app _run_ fine, too, please notify
me - I'll submit official. patches to Alexandre
Am Mon, 2002-09-16 um 20.58 schrieb [EMAIL PROTECTED]:
Finally, if I don't use either -nostdinc or -nostdinc++,
gcc complains about types being redefined, such as wint_t
(as an unsigned short int in /usr/include/_G_config.h but
WCHAR in /usr/local/include/wine/msvcrt/wctype.h).
I just
I noticed in regedit's Makefile.in that it lists msvcrt, advapi32, and
kernel32 in it's IMPORTS variable and has no foo_DLLS variable,
whereas Winemaker by default puts most of those in the foo_DLLS
variable.
What's the difference between the DLLS variable and the
IMPORTS variable?
-Steve
Am Die, 2002-09-17 um 16.27 schrieb [EMAIL PROTECTED]:
I noticed in regedit's Makefile.in that it lists msvcrt, advapi32, and
kernel32 in it's IMPORTS variable and has no foo_DLLS variable,
whereas Winemaker by default puts most of those in the foo_DLLS
variable.
What's the difference
In my winelib app, most of the cpp files use MSVCRT
only, and thanks to Martin I've gotten those to compile.
A couple of my source files, however, use a mix of MSVCRT
and standard glibc (fork, exec, etc). When I include unistd.h,
lots of function definitions conflict with msvcrt/io.h. How can
From attempting to run pgm with native msvcrt, w2k scrrun.dll:
fixme:win32:PE_CreateModule Security directory ignored
err:win32:PE_FindExportedFunction function not found for forward
'ntdll._iswalpha' used by 'msvcrt.dll'. If you are using builtin
'msvcrt.dll', try using the native one instead
The following patch to dlls/msvcrt/file.c
revision 1.23
date: 2002/04/26 19:05:16; author: julliard; state: Exp; lines: +4 -0
Better support for configure detection of missing types, added check
for ssize_t.
Removed a couple of no longer used portability functions.
Various
-Original Message-
From: Gerald Pfeifer [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 18, 2002 8:31 AM
To: [EMAIL PROTECTED]
Cc: Martin Faxer
Subject: Linuxism in dlls/msvcrt/msvcrt.spec?
I believe there is a Linuxism in dlls/msvcrt/msvcrt.spec which expects
that _tolower
Hi, I'm trying to compile a simple Win32 console app (
http://luigiwalser.homeip.net:8080/~walser/cosc/450/ex3/ex3.cpp if you want
to see it).
I did:
winemaker --console -I/usr/include/wine/msvcrt -I/usr/include/wine/wine
-imsvcrt.dll --single-target ex3
./configure --with-wine-libraries=/usr
I modified the winemaker command I issued to:
winemaker --console -I/usr/include/wine/msvcrt -I/usr/include/wine/wine
-L/usr/lib/wine -lmsvcrt -lkernel32 --single-target ex3 .
and now:
c++ -shared -Wl,-rpath,/usr/local/lib -Wl,-Bsymbolic -o ex3.so ex3.o
ex3.spec.o -L/usr/lib/wine -lmsvcrt
On Tue, 20 Nov 2001, Uwe Bonnes wrote:
Hallo,
running with builtin msvcrt like
wine --dll msvcrt=b a.exe
[...]
still counts _two_ arguments, as it sees wine a.exe.
Yes, there is a problem. How did I miss it when I looked into the
parameter passing?
For a short test I did
Francois == Francois Gouget [EMAIL PROTECTED] writes:
Francois On Tue, 20 Nov 2001, Uwe Bonnes wrote:
Hallo,
running with builtin msvcrt like
wine --dll msvcrt=b a.exe
Francois [...]
still counts _two_ arguments, as it sees wine a.exe.
Francois
1 - 100 of 142 matches
Mail list logo
