.
You'll need to re-run ./configure after applying.
Cheers,
Jon
License: X11
ChangeLog:
Jon Griffiths [EMAIL PROTECTED]
+dlls/msvcrt/tests/cpp.c dlls/msvcrt/tests/Makefile.in
dlls/msvcrt/tests/.cvsignore
Tests for static RTTI and dynamic casting of cpp
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
Hi,
disclaimer I havent read the wine-user posts
1. The winebuild manpage only mentions ptr, str, wstr, long and
double
as valid Win32 function argument size information - is the amount
and
kind of symbols really important, or is it just the amount of used
stack
space?
the type is used for
Hi Bob,
We currently support production build processes using both FreeBSD
snip
We're currently using some in-house tools that drive Visual Studio
using a COM interface, vs using command-line compilers and nmake.
Does it make sense to try to run these builds using Wine?
Not unless you have
Hiya,
Why do you keep $(SRCDIR) after pwd? man bash and man pwd both say
nothing about giving pwd a path...
you're right, theres no need for it, it just gets swallowed by the
backticks so i didn't notice.
What's really needed is either use our own db2html (but that was
struck
down already
Hiya,
Is there any reason for stripping out the parameter names from this
file?
They can be quite useful as a reminder for what each parameter is.
Consistency and ease of reading, mostly. Before the patch only some
of the calls have parameter names, and (e.g.) the variant calls
aren't
Hi,
--- Ove Kaaven [EMAIL PROTECTED] wrote:
A new parameter to write_type/write_typedef which inhibits writing
anything to the header but still sets written, for example...
would that work?
Err, probably, but I'm not convinced its a better solution without
going back through the code again
Hi,
This is wrong; if you link with msvcrt you have to use msvcrt
headers, and then everything works fine, including references to
stdout. If you mix glibc and msvcrt you are in trouble.
Understood and noted here too - wrong but occasionally useful ;-)
Can you apply the rest of the patch (ie
Hi,
For base 0 it accepts: {whitespace} [+|-] [0[x|o|b]] {digits}
For bases 2, 8, 10 and 16 it accepts: {whitespace} [+|-] {digits}
I'll resend with this difference added, for what its worth.
So: Feel free to reformat the comments of my functions,
but do not remove information.
Far be it
Hi,
--- Eric Pouech [EMAIL PROTECTED] wrote:
any reason why not use DllMain instead of patching winebuild ?
If you mean the DllMain of msvcrt, there is no way for the it to know
what type of app is calling it AFAICS. Only the generated main knows,
and should inform msvcrt when it starts. Also
Hi,
--- Ove Kaaven [EMAIL PROTECTED] wrote:
Could you explain the reason behind the last line, Don't dump
full struct/enum definitions in prototypes, since this shouldn't
happen in any case.
The following idl file, foo.idl, cut down from my oleidl.idl for
example purposes:
Hi,
but i can't without use of DPRINTF ...
but if you have a better solution ?
I suggest creating functions to print your types into a string, and
then dump the created string. Then, if no trace is defined, make
those functions macros that compile to nothing.
Cheers,
Jon
=
Don't wait
This way we can eliminate the DPRINTF macro which is
rarely used, and thus confusing. Alexandre?
Hence my suggestion to only use MESSAGE and DPRINTF inside dumping
functions that can be elimated with macros. But as far as cosmetics
go, i don't see how TMSG and TMS2 are any more ugly than
I'll see If I can work out the hash table for that locale, might take
a little while to get out though...
Cheers,
Jon
--- Marcus Meissner [EMAIL PROTECTED] wrote:
Hi,
I have an app here, which uses locale 407, for which we do not
implement LHashValOfNameSys yet...
It reports:
Hi,
Conversely, I think it's quite reasonable to ask the few developers
that need to change configure to install the latest autoconf,
Sounds fair enough. I only got bitten by it when testing the update
to winedump for the changes to the build system, I'd never use
autoconf normally.
Cheers,
--- [EMAIL PROTECTED] wrote:
The LoadLibrary call comes from the implementation of DelayLoad
Ah,
In that case I can see why doing it manually is a waste of time ;-)
Cheers,
Jon
=
Don't wait for the seas to part, or messiahs to come;
Don't you sit around and waste this chance... - Live
Have a look at the following two messages from Marcus Meissner to
wine-devel and wine-patches:
Hmm, those links dont work for me, however I remember:
The header files for stdio have macro versions of putc/getc so your
implementation must use the FILE structure fields in a binary
compatable way
Hiya,
Thanks for your prompt responses. Based on yourfeedback I'll:
1. Create internal functions with meaningful names and call them
when ordinal calls are used within the DLL (A plus to this is
that the ordinal functions can stay in ordinal.c, and
the implementation can go into the
Hi,
I've been hacking on SHLWAPI.dll for a couple of months now while
holidaying around Thailand, using a beaten up laptop. Since I just
obtained free use of a real machine with a good net connection, I
want to start submitting my work but I thought I'd clear up a few
style issues beforehand:
Hi,
You should _really_ use register functions instead of inline
assembly. Then you can do setjmp/longjmp 100% in C.
I can't get this to build cleanly. Changing the type to register in the
.spec, and adding a CONTEXT86 * as the last parameter in the prototype gave
me an unresolved
Hi,
If you have the wine sources, or browse them from www.winehq.com, checkout
tools/specmaker/README. Also see the Winelib developer guide for details on
Winelib in general.
Note that if all you want is the string routines, thats a lot of overhead for
a few routines. You might find they are
You should _really_ use register functions instead of inline
assembly. Then you can do setjmp/longjmp 100% in C.
OK, new patch coming up shortly. I hadn't grokked register functions at all.
On a related note, going forward we should really support __thiscall in the
spec files too, and pass
Hi,
Hmm, glad to see everyone is alive and well again.
:-) Its been a slow week, no?
Firstup, on copyright, I think I was misunderstood. When I say they are not
copyrighted, I mean the author(s) have _given up_ their copyright explicitly.
Each original header file carries the following
On Monday 12 February 2001 15:33, Patrik Stridvall wrote:
So perhaps we should debate whether we should use alloca or not.
It seems this has been decided. I haven't examined or used alloca in years,
so its possible that my personal objections don't apply in todays
implementations ( a quick
Hi,
Regedit has an annoying refresh problem due to a lack of a
DrawAnimatedRects implementation... so, the next time you need a break and
have nothing better to do... ;)
Hmm, Ive played with regedit from 98 OSR2, and I cant make it call
DrawAnimatedRects. What action specifically makes it
Yes, LocalAlloc is for 16 bit source code compabillity and shouldn't be
used by Win32 code.
Oops, ok, HeapAlloc then :-)
So perhaps we should debate whether we should use alloca or not.
I'll throw my reasons in:
-alloca with unknown length argument resolves to a function call, so isn't as
Why is wine-dev so quiet lately? This sad thread is almost the only
one today. would it be that everyone is waiting for the return of
Alexandre?
I sure am!
I've been working on shlwapi specmaker instead of msvcrt because I don't
want to get tied up resubmitting patches, I need the ones
i know it was already at least mentioned here - how to provide config
file that works without change for more than one application. what do
you think about this concept?
The problem here is the server. I notice that if you start one application
with --managed, all applications started
Hi,
I don't know anything about the Win32 print API, but style wise I tend to
stay away from alloca(). It screws up exception handling because it messes
with the stack, and is machine dependant. Maybe LocalAlloc() would be a
better choice?
Cheers,
Jon
--
"Don't wait for the seas to part,
I know this comes from from someone who just forgot to put a trailing
'\0'. But still.
Sounds like a job for winapi_check ;-)
BTW, Is Alexandre away? I haven't seen any cvs commits for a week...
Jon
--
"Don't wait for the seas to part, or messiahs to come,
Dont you sit around and waste
Hi,
Perhaps it'd be nice to tie up all these memory issues with some kind
of kernel patch... a way to read/write and generally mess with another
process's memory that was broader and more efficient that p-trace.
Something like that would be great for Linux, not sure how it could work with
So, does anyone have a hint on how to go about supporting
VirualProtectEx/VirtualQueryEx on other provesses?
Looking into this, the VirtualEx functions work within the address space of
the target process. At user level I can't see any way to support this from
the sever or any other process
Hi,
debugger starts all right and I can go to a breakpoint using the dll name
in uppercase.api trick.
On a somewhat related note, I'm trying to get the debuggers from lcc and
visual studio to work. VC is my preference since it will let you bring up a
release build executable (i.e. any old
Hi,
Actually I suspect there's another problem with your patch. since you
cast the return values to void*, WINE_UNICODE_TEXT("abc")+1 will very
likely be wrong. Also I believe void* arithmetic is a gcc extension.
I haven't checked, but youre probably right. However Ive never come across
Hi,
type WCHAR* and since sizeof(WCHAR)==2, it just adds two.
Sounds likely. A cast back to WCHAR fixes it, anyhow, but isn't
especially nice.
Which means you get warnings too. I'm not too convinced about this
patch especially because it does not return the proper type.
On the
other
Hi Dror,
if this sounds really idiotic, just delete this post, and forget you ever
saw it.. :)
Its not a stupid idea, but anyone who has the wine source can generate a list
of unimplemented calls with
find wine-src-path/dlls -name "*.spec" -exec grep stub {} \; -print
So it seems overkill
Whoops,
Due to underzealous diff checking on my part, the patch will cause a
regression on toupper/tolower; the following tiny patch needs to be applied
after it:
Cheers,
Jon
Content-Type: application/x-bzip2; charset="iso-8859-1";
wsprintfW() in user32 is not the same as swprintf(), it only supports
a small subset of the possible format strings. We need a complete
Unicode printf implementation in ntdll (or maybe in libwine.so).
wsprintfW supports the formats I need at present, so implementing it in ntdll
would just
Why the app does _nothing_ with dllonexit stubbed is a mystery
to me, but I am never surprised by any stupid thing a windows programmer
might do.
:-)
Are you sure its dllonexit thats causing the problem? It shouldn't have an
effect until the dll that called it is unloaded...
Have you got
If you do get some docs written, by all means submit it to one of the
Wine guides (the Winelib User Guide?). If you don't feel like writing
it in DocBook, you can just send me the plain ASCII text, and I'd be
happy to convert it and find a good place for it.
big grin
I was hoping someone
Hi,
Use gcc 2.97 with -fshort-wchar.
Well, this was for VWCL, and I wanted to make the price of entry as low as
possible for the existing win programmers, so I've gone for another solution;
since its a C++ framework its sufficient to use
#define VTEXTW(str) wine_unicode_text(L##str)
and
Hi,
Of course the name is a bit long (and it's WINE specific) so you
could do:
#define VTEXTW(x) WINE_UNICODE_TEXT(x)
In this case the macro is only used in c++, so I used what WINE_UNICODE_TEXT
expands to in this context; this works for single chars and strings. I think
to be
Actually it helps a little in that you can use the standard C library
headers (e.g. to get wcslen) and then link with crtdll or msvcrt.
This is what I was wondering; given that they expect wchar_t* and Winelib
uses WCHAR* I assumed the headers would be useless.
But the libc C still
On Friday 12 January 2001 02:58, Gerald Pfeifer wrote:
The following patch should fix the bug.
snip
Aargh. All that cutting and pasting, I was bound to screw a couple up ;-(
I have a couple of other minor fixes after testing crt vs msvcrt to come...
Thanks,
Jon
--
"Once you realise you're
OK, I'll try and find a cleaner way to implement this.
Cheers,
Jon
On Thursday 11 January 2001 00:19, Alexandre Julliard wrote:
First, as already mentioned here, you cannot access %esp from inline
assembly and hope to have it point to something specific, gcc is free
to manage the stack
My objection was about local_unwind2, where you were using %esp to
reference local variables. This cannot work, even if you don't modify
%esp in the inline assembly.
Got it, chaining the exception frame using esp is only valid if gcc pushes
the registration struct onto the stack (not a safe
On Thursday 04 January 2001 05:52, Shane Nifong wrote:
I am new to open source so forgive me. How do I know if someone is
working on (or in) the sections that I want to work on? Where I work
we can look into our source management tool and see who is working on
which files. Also, if that
On Wednesday 03 January 2001 06:42, Shane Nifong wrote:
I am starting to work on the advapi32 functions. I was wondering if I
make changes to the stub files that are there how often to I create
patches or update using CVS?
Should I create patches first?
I normally work in one or more
Hi,
It seems win32 programs that link with msvcrt get a load of calls inserted
into their pre main/WinMain startup code to initialise the run time. Just to
get a simple program running (well, crashing _after_ main()) required
implementing a load of init stuff. I was catering for Winelib
Hi,
Im getting a build error since I upgraded to Mandrake 7.2:
gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall
-fno-strength-reduce -mpreferred-stack-boundary=2 -fPIC -D__WINE__
-D_REENTRANT -I/usr/X11R6/include -o d3ddevice/mesa.o d3ddevice/mesa.c
d3ddevice/mesa.c:37:
On Monday 01 January 2001 05:24, Ove Kaaven wrote:
(But from what I found in my mailbox, it seems you were right about the
martini glass issue, at least, it's just that the WineHQ logo isn't really
a wine glass either)
It may not be a Wine glass, but it looks a lot better than the existing
Hi,
Definitely, I am not sure how to go about this now though. Should we just
say the hell with it and forward to CRTDLL since our CRTDLL is working
better or should we just move code out of CRTDLL and into MSVCRT a function
at a time (or several at a time)? I would prefer sticking with
On Sunday 31 December 2000 2:15 am, Andreas Mohr wrote:
You could always make Wine use the *native* version of the file as default
loadorder. What's the problem ?
Well, of course if people start forcing the loadorder to builtin, then
we're outta luck...
Thats what I did (wanting to run a
Hi all,
While updating my crt test harness, I found a call returning strange
values using the native DLL. The call is "ldiv", which returns an
ldiv_t struct _by value_. ldiv_t is defined the same under linux and
windows. The spec entry is:
@ cdecl ldiv(long long) ldiv
i.e it uses the libc
OK, I've been investigating (couldn't wait), heres what I've got so
far:
Recap: Using GetProcAddress to get a pointer (p_ldiv)to CRTDLL's
"ldiv" function, and calling through that pointer produces
errors in some cases. This is because ldiv returns a struct.
The problem occurs for any dll
../../include/wine/obj_base.h:493: duplicate argument name `tj' in
`#define'
make: *** [regapi.o] Error 1
Hi,
The patch I sent earlier, "small fixes", fixes this.
Cheers,
Jon
=
"May their negative actions ripen upon me. And may all my virtues ripen upon
them."-Nagarjuna, on
Heres the Changelog:
* dlls/crtdll: crtdll_main.c, crtdll.h, crtdll.spec, Makefile.in,
mbstring.c, wcstring.c, +crtdll_file.c, +crtdll_str.c,
+crtdll_mem.c, +crtdll_exit.c, +crtdll_spawn.c, +crtdll_dir.c,
+crtdll_time.c
Jon Griffiths [EMAIL PROTECTED]
- Implement
If it does, then I'll write a script to generate wrappers and
publish the full API in a .so
When you have the headers available, a script that could parse out
the prototypes and generate a spec src file would be a godsend. I
had in mind something that would parse the output of an export
listing
58 matches
Mail list logo
