> CloseHandle doesn't wait for the thread to finish, so
> this has no effect. In any case there doesn't seem to be any need
> to wait in those tests.
My bad. There was something hokey with the tests, moving the CloseHandle made
them pass consistently. After changing the implementation I can't rep
Hi Dan,
> Not *quite* all. Inquiring minds always want to know what
> app it will help and/or bugzilla entry it will fix.
Fair enough. The bug in question is 2408, for LocoScript (a rather ancient dos
text editor). Note that a couple of other people have reported unrelated bugs
in that bug due
Hi Michael,
> open inputs read as one, so reads without responder return 0xFF.
You're right, testing it on dosbox it does return 0xff for non hercules cards.
As long as bit seven never toggles though, any app reading it will still infer
that a hercules card isn't present. I didn't catch the ass
Andrey,
Thanks for your comments. I've updated and re-sent the patch, please let me
know if you see any problems with it.
I knocked up a quick test and you are correct, native ws2_32 does not allow a 0
handle in WSIoctl. I'll send a patch for that once this set is commited.
Cheers
Jon
Hi,
> should be:
> @ stdcall SymEnumerateSymbols64(long double ptr ptr)
Thanks, I missed that long long changed to double a while ago. I've re-sent the
patch.
Cheers,
Jon
> what about the simpler:
> +dbg_printf(val_int ? "true" : "false");
Works for me. I've re-sent the patch.
Cheers
Jon
> Internal functions should return an error code instead of
> calling SetLastError.
Perhaps in a general sense, but URLCache_CopyEntry already did
SetLastError(ERROR_INSUFFICIENT_BUFFER): setting it there means the
4 places that call it don't need to ^ the logic to set the 2
different errors thems
> Internal functions should return an error code instead of
> calling SetLastError.
Perhaps in a general sense, but URLCache_CopyEntry already did
SetLastError(ERROR_INSUFFICIENT_BUFFER): setting it there means the 4 places
that call it don't need to the logic to set the 2 different errors thems
Hi Dan,
> The last part of your patch, having to do with SysAllocStringByteLen(),
> seems correct to me, offhand. Maybe if you clean up the comment a
> bit more, sprinkle sugar on it, and resend, it'll make it in this time.
I'll polish it and fire in again next week, there doesn't seem much poin
Hi George,
>If I change the size to 18 the plus is drawn correctly
>Does anybody knows anything about this ?
The native controls draw a different kind of cross for large items,
which looks a lot nicer. I added this but the initial threshold for
deciding when to draw the large cross was too small,
Hi Michael,
> With the emulation mode set to "winxp" I can only TlsAlloc 64
> indexes, even though the MSDN docs say there should be at least
> 20 million.
You're misreading that page, the limits are:
Win 2000/2003 & XP - 1088 indexes per process
Win Me/98 - 80 indexes per process
Win NT
> For the varargs and libc-forwarded function in msvcrt, I think all
> that we
> need is already in out spec file. So no need for the MS SDK.
If you want to write the tracing code by hand, yes. If you have the
headers winedump will generate the TRACE() statements for you as
well.
Cheers,
Jon
==
Hi Uwe,
>I think it would be helpfull, if we could generate debug stubs for
>these functions. Can anybody help?
If you have the SDK headers, winedump in spec mode can generate this
for you.
Cheers,
Jon
=
"Don't wait for the seas to part, or messiahs to come;
Don't you sit around and waste
Hi Rob,
>I get a few errors like the following:
>error: ::div has not been declared
>error: ::ldiv has not been declared
div and ldiv may or may not be included in the std namespace. Try
changing the calls to either remove the scope resolution from their
calls or adding std before it.
>And tons
Hi Luke,
>i noticed that Wine has a mapi32.dll.so.
The current MAPI code is very, very far from complete. I have been
implementing it in a bottom up manner (i.e. starting with the lower
level/utility functions and working up toward constructing the higher
order functions/objects). For example, th
Hi,
>>+docA.lpszDocName = WtoA( doc->lpszDocName );
>>+docA.lpszOutput = WtoA( doc->lpszOutput );
>>+docA.lpszDatatype = WtoA( doc->lpszDatatype;
>>
>Isn't there a missing parenthesis?
There sure is, I must have deleted it while removing the cruft from
the diff (since it compiles fine
--- Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> I certainly don't want to add 5000 auto-generated stubs. Now if you
> want to use winedump to help you write stubs for the cases that are
> really necessary (like ordinal exports) sure, but each stub needs
> to
> be reviewed to make sure the retu
Hi,
> The solution is not to start building a .spec.c
> file for MSVC, it's to fix our spec files so that they can work on
> Windows without generating extra code. This means replacing the
> stubs by real functions.
So will you accept patches to do this (add empty stubs)? winedump has
had the cap
Hi,
> Is there anyway we could add some magic to msvcmaker to do this? It
> seems to me that if we need to have the stubs defined in a source
> file on msvc we can have msvcmaker parse the spec files and
> generate a extra source file when its making the makefiles.
If Alexandre will accept patc
Hi,
I had a patch which enabled stub generation for building native dlls
last year
(http://www.winehq.org/hypermail/wine-patches/2003/07/0176.html),
that part was not accepted for the same reasons that are being
mentioned in this thread.
I would like to point out again that the VC linker will not
Hi,
in dlls/kernel/cpu.c, around line 430, is the following code for
NetBSD:
{
int mib[2];
int value[2];
...
if (sysctl(mib, 2, value, value+1, NULL, 0) >= 0)
if (value) PF[PF_FLOATING_POINT_EMULATED] = FALSE;
Hi,
> Well, it's more work for the poor slob who has to review, test, and
> commit the resulting patches
gulp, I guess thats me, ;-)
> (not to mention for people who
> maintain local changes and need to fix merge conflicts after each
> commit).
I wondered about that; the good news is that al
Hi,
> >>Do the patches take into account that a header might only be
> >>included to
> >>check that an exported function matches the declaration in the
> >>header file?
I've extended my script to handle this case.
Cheers,
Jon
=
"Don't wait for the seas to part, or messiahs to come;
Don't
Hi,
> It's the same issue, I took 16-bit headers as example but you can
> have
> the same problem with SDK headers, it's quite possible that a file
> doesn't need winuser.h by itself. So you would first have to move
> the
> includes out of the non-sdk header into the source files, and then
> once
Hi,
> No, I don't think we want to do that in two steps, since we don't
> want to add headers that are only needed to build a private header.
> For instance many private headers still contain 16-bit stuff, and
we
> definitely don't want to start including Win16 headers all over the
> place.
Right
Hi Rob,
> Do the patches take into account that a header might only be
> included to
> check that an exported function matches the declaration in the
> header file?
No, I dont think that case can exist.
Each .c file contains 5-20 or more functions that take flags/structs
etc defined in the head
Hi,
> The problem with that approach is that you remove a lot of headers
> that are included anyway so it doesn't make any difference in build
> time, and many of them will have to be added again once we finish
> the header cleanup. For instance you remove winuser.h everywhere
> win.h is included
Hi Juan,
> winnls.h declares WideCharToMultiByte, and we just saw a
> compilation error
> on some systems because it was missing [1].
winnls.h is included already by wine/unicode.h in url.c, so its not
needed again there. The script I wrote basically comments out the
includes one at a time, and r
Hi,
--- Andreas Mohr <[EMAIL PROTECTED]> wrote:
> Note that some removed include files might be needed for different
> systems,
> so some breakage might/may/will follow this patch.
I deliberately made my script remove only Wines own headers for this
reason. It will not remove system header files.
Hi Oliver,
>I've also got a little patch for oleaut/varient.c to
>allow number-string comparisons. There are a couple of
>undocumented assumptions I've made,like what to return
>for an empty of if the string isn't a number, and the
>only thing I've been able to test with is 1 vb
>application as I
Hi,
>I personally don't think it's really useful without more detailed
>information on each dll, but in any case this belongs to one of the
>sgml documents, not a stand-alone ASCII file.
c2man.pl will generate a blurb for each dll in the source tree when
building API docs, if one of the dlls sour
Hi,
More on this problem ... here what happens under native when the back
window is clicked:
Order of trace below is (msg, hwnd, wparam,lparam)
The app is started, click on the client area of the background window
WM_MOUSEACTIVATE back 001203aa 02010001 (MA_ACTIVATE)
Front window is told i
Hi,
My app gives me a FIXME from dlls/gdi/enhmetafile.c at line 1144
complaining that ExtSelectClipRgn is not implemented (and then
proceeds to draw rather corrupted looking pictures). Looking at the
code there is an implementation, but its been #ifdef'd out. removing
the #if 0 doesn't produce any
Hi Walt,
> Do you know what shift-tab does under such circumstances in
> Windows? If
> it's the same as regular tab, you could just map ISO_Left_Tab onto
> tab, like below.
I'm not sure about native, but your patch fixes my app (i.e. makes
shift-tab move backward through the tabbing order). It a
Hi,
Duly reporting:
err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym
FE20 (ISO_Left_Tab) :
err:keyboard:X11DRV_ToUnicodeEx
(virtKey=9,scanCode=F,keycode=17,state=1)
This happens when I shift-tab in any Wine app. System is mdk
10.0/wine cvs and this message has been there for sev
Hi Francois,
> IMHO it would be better to rely on the WINETEST_INTERACTIVE
> environment variable.
I got the use of VISIBLE from the listview and tab control tests, but
WINETEST_INTERACTIVE does sounds like a better/more consistent
approach. I'll try to get a patch for all 3 tests out in the next
Hi,
> ODS_NOACCEL 0x0100
> ODS_NOFOCUSRECT 0x0200
Thanks for that, I've updated the patch.
Cheers,
Jon
=
"Don't wait for the seas to part, or messiahs to come;
Don't you sit around and waste this chance..." - Live
[EMAIL PROTECTED]
___
Do yo
Hi,
>It would be really nice to separate formatting changes from other
> changes. It's hard to see what's got changed and what not.
Agreed, see my reply to Robert on that.
>>"Only create a scroll control when/if we need one (like native)"
>Nothing got changed. It's being created when needed, and
Hi,
> Nice. While you're at it (and have it fresh in your mind), can you
> please also provide an audit (and a list of TODOs) as per comctl
> 6.0?
It will be a while afraid, I'm really busy with work ATM. My first
priorities when i get some free time are to finish clearing my patch
tree for oleau
Hi,
> There is no point in sending WM_QUERYUISTATE. I believe it is only
> really used for the toolbar control, but the native comctl32 has a
> common framework that means it is sent for all controls.
Sure, it helps when diffing the traces of native and builtin though.
By sending this and creat
Hi,
> I think the original poster wanted to use a closed-source
> third-party DLL
> written in C++ and compiled with MSVC. AFAIK none of your
> suggestions address that case.
If source for the dll isn't available then the only option i can
think of is as follows:
WARNING: Untested, but should w
Hi,
> how can I call a class constructor (which is built form
> another class) in spec file? Can anyone provide me an example?
This is possible, although it is not immediately obvious. Here is the
solution I use (I will document this one day but I'm very busy ATM):
Scenario 1: App uses C++ dll,
> Does that happen often? Should Wine developers start running the
> tests before submitting a patch?
Absolutely, my bad. I didn't actually realise they were any listbox
tests!
Updated patch coming.
Jon
=
"Don't wait for the seas to part, or messiahs to come;
Don't you sit around and was
Hi James,
> Can this patch be broken up into smaller, independent parts? It's
> more likely to be committed if that is the case.
Aside from the tests, what constitutes independent? These are all new
functions so there is no possibility of regressions, which is the
main reason to split up patches
Hi,
I am trying to track down some GDI leaks in a large application I am
porting. To make things easier I added logging to GDI_AllocObject and
GDI_FreeObject in order to find mismatches at program termination,
and hacked a script to find allocations that weren't deallocated. The
patch to dlls/gdi/
Hi,
> Windows XP Professional, in a network with roaming profiles
> served by Samba. I don't know what is relevant.
Strange, I'd have assumed you'd have an extended mapi client
installed by deault. What is your default mail client?
> OK, sending you off-list.
Thanks. I'll have a look at this.
Hi,
> the mapi32 tests call scInitMapiUtil, which pops up an alert
> box saying something like (translating it) "Your default
> mailer application isn't capable of this operation, please
> ensure that Outlook is configured as the default mailer."
This probably means that you don't have a mapi cli
Hi,
I'm experimenting with native vs builtin comctl32 for an app and
whenever I set this dll to native I hit this assert in
init_system_dir():
assert( mod->Flags & LDR_WINE_INTERNAL );
This happens on a 2.6 and a 2.4 system. I suspect its not related to
comctl32 per-se, but merely loading a nat
Hi Eric,
> no, it's normal you get this. In fact, we should simply abort the
> loading.
> Does this work better ?
I can't test it unfortunately, but it looks like the right thing to
do. I asked on [EMAIL PROTECTED] and was told to upgrade to binutils 2.15
to fix the bad stab generation. Sure en
Hi,
I'm having some trouble with the debugger and a large C++ application
I'm trying to debug. This seems unrelated to the recent changes that
were made (the old debugger used to have issues as well).
When my app dies i get the following:
wine: Unhandled exception (thread 0009), starting debugge
Hi,
> But maybe we can introduce a '-i' options instead:
> winebuild: --ignore=x,y,z => -ix -iy -iz
I just checked this, and it actually works already, as multiple -i's
are cumulative on winebuilds command line. Good thought!
Cheers,
Jon
=
"Don't wait for the seas to part, or messiahs to co
Hi,
The -Wb argument to winegcc currently expects a comma separated list
of arguments which it then splits up and passes to winebuild.
This conflicts with the --ignore=x,y,z syntax of winebuilds ignore
argument, since it also uses a comma to delimit the list to ignore.
The easiest way to fix th
> It makes a big difference in code readability.
I disagree, but for two lines of code, who cares. I've sent a new
version to wine-patches.
Cheers,
Jon
=
"Don't wait for the seas to part, or messiahs to come;
Don't you sit around and waste this chance..." - Live
[EMAIL PROTECTED]
Hi,
> That doesn't look right at all, lParam is not at the end of the
> structure.
Mybad, fixed in updated patch sent to wine-patches.
> And the variable-size info should really be a byte array
> or something similar, not an LPARAM.
It makes no difference; hardly anyone changes the the extra sp
Hi,
> I thought that gcc will figure the langauge based on the
> extension.
Under v3.3.2, given a file a.c containing
int dwmain(int argc, char*argv) { return 1; }
I get:
[EMAIL PROTECTED] winegcc]$ gcc -c a.c && nm a.o
T dwmain
[EMAIL PROTECTED] winegcc]$ g++ -c a.c && nm a.o
Hi Mike,
Hmm, seems a bit hackish, much like my current solution. I'm a while
from submitting the mapi32 stuff anyway, so I can wait for a proper
resolution.
IMO we need to support the mangled exports, ms tools obviously do. I
seem to recall this used to work, was it changed for cygwin maybe?
Ch
Hi,
winebuild doesn't support export names with an '@' correctly. When
parsing the spec file, the @X is stripped. This causes names to be
incorrectly listed as duplicates.
I'm hitting this with mapi32.dll. Outlook 97 imports using get
procaddress on the name including the '@', and some exports ar
Hi,
>VT_R4: 7.850 -> VarRound(1) -> 7.800
>VT_R4: 7.851 -> VarRound(1) -> 7.900
>Is this the binary representation (in)accuracy?
MS state that rounding is dependent on the internal binary
representation of the number and thus VarRound doesn't always get it
right, i.e. you can't tell with any cert
Hi,
> Im not sure if I understand you,
> Im using the current CVS version of oleaut32.
I think you'll find its the native dll thats failing. I'll be
resyncing again today though, so I'll check nothings changed to break
builtin.
Cheers,
Jon
=
"Don't wait for the seas to part, or messiahs to
Hi,
>Running the oleaut32 tests shows that vartype and vartest are
>failing.
>Has someone an idea about these ?
Your (presumably early) version of oleaut32.dll doesn't support the
VT_DECIMAL type. I'll update the tests shortly.
Cheers,
Jon
=
"Don't wait for the seas to part, or messiahs to
Hi Arthur,
> the generated vendor.dll.so file does contain the correct
> symbols but they are undefined.
By any chance is the vendor dll implemented in C++? If not, this
should work.
If so, you have a bit of a problem, and one that no-one has seriously
tried
to overcome (or at least if they ha
Hi Dmitry,
> vartest.c:4151: Test failed: VarAbs: expected 0x0,5,1.1, got
0x80020005,0,0
> vartest.c:4217: Test failed: VarNot: expected 0x0, got 0x80020008
vt 20|0x0
> vartest.c:4217: Test failed: VarNot: expected 0x0, got 0x80020008
vt 21|0x0
> vartest: 526958 tests executed, 0 marked as todo, 3
Hi Marcus,
> Can you please explain why VARIANT_ValidateType rejects for
> instance VT_SAFEARRAY
> variants (and more) with DISP_E_BADVARTYPE?
>
> Why does it handle the whole range VT_HRESULT - VT_CF as invalid
> (except VT_RECORD) ?
>
> We got one InstallShield regression from this patch (wher
Hi,
> This won't work as by definition a WinAPI function is usually not
> supposed to reset the last error if no error has occurred, so
> GetLastError() may return an error even though the strings were
> just simply equal.
Of course it 'works':
SetLastError(0);
SomeCall();
if (GetLastError()) {
Hi,
> +goto FoldStringA_exit;
> ^^
> No allocation has been done yet, just "return 0;" would be
> enough!
Indeed, although the above is functionally identical. Feel free to
submit a patch if you feel strongly about it...
> Interesting idea, but I wonder how y
--- Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> I hope this is useful?
Brilliant, thanks a lot!
Jon
=
"Don't wait for the seas to part, or messiahs to come;
Don't you sit around and waste this chance..." - Live
[EMAIL PROTECTED]
__
Do you Yahoo!?
The New Y
Hi,
--- Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> That's an excellent suggestion! I made the last log available
> right away and hacked the script to automatically publish logs
> from the daily builds from now on:
> http://rtp.freebsd.org/~gerald/
Great stuff, cheers! The output format is fi
Hi,
--- Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> IMO you should export the FoldString functionality from
> libs/unicode, not the tables.
OK, can do.
> they need to be generated from the Unicode standard data, and
> the code to do that should be added to cpmap.pl.
The data for the numeric
Hi,
> I see, I did not notice the _-versions where inlined. But since
> all uses seem to be in the same file (is this correct), can't
> we just mark the regular ones as extern inline?
I didn't put all the functions in the same file, because a) they
split pretty logically into groups of 12-20 func
--- Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> GCC 3.3 and also GCC 3.2.3 diagnoses the problem, IIRC. I strongly
> recommend to use one of these for Wine development, for they really
> catch a couple of (real) problems that older versions did not.
I'm on 3.2.2 and wasn't planning an upgrade any
Hi Dimitrie,
--- "Dimitrie O. Paun" <[EMAIL PROTECTED]> wrote:
> We don't seem to pass any additional info to _VarDecFromUI1, why
> not simply get rid of it, and implement stuff in the real
> VarDecFromUI1?
Size and speed.
The inlined versions are to meant to be used within the variant code,
the
Hi,
--- Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> Would you mind having a look? Thanks,
What version of gcc are you using? I don't get this warning. However,
It will be gone shortly, all the conversion functions have been
re-written (patches coming v. shortly). So I guess you can ignore
this fo
Hi,
--- Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> Precisely, this way it's obvious which functions are meant to be
> used by Win32 apps and which are internal to Wine.
Hmm, I think any programmer who thinks a static function in one of
the implementation files of a given dll can possibly be
Hi,
> Please don't do that. Internal functions should use standard C
> calling conventions. We don't care about two bytes of extra code.
Can do. Is there any reason why not though? After all, the entire
Win32 api does it...
Cheers,
Jon
=
"Don't wait for the seas to part, or messiahs to co
Hiya,
> Should this not be #define szResLen (sizeof(szRes)/sizeof(WCHAR) -
1) ?
Sorry, I must have dozed off. You are of course right, I'll resend in
a minute. Good spotting!
Jon
=
"Don't wait for the seas to part, or messiahs to come;
Don't you sit around and waste this chance..." - Li
Hiya,
> Is there any reason for changing the calling convention of these
> two functions?
Yes, they are called more than once in the file, so stdcall produces
smaller code (no need to duplicate the argument stack pops).
Similarly any function thats only called once can be explicitly
inlined for s
Hi,
+COORD c = 0;
This won't compile with msvc since COORD is a struct, not a simple
type.
Please use the patch from my mail "Test fixes" instead.
Cheers,
Jon
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
ht
Hi,
>Can some of the widl gurus look at this one please?
This is a known problem with widl, see
http://www.winehq.org/hypermail/wine-devel/2003/03/0359.html.
I sent a patch to fix this issue, but it wasn't the right fix and
probably won't apply unmodified now.
Cheers,
Jon
=
"Don't wait
78 matches
Mail list logo
