[EMAIL PROTECTED] wrote:
I've started with an easy thing, the wine clock, please let me know if I've done
this properly.
mostly yes. Don't forget to tag the string table as
LANGUAGE LANG_ITALIAN, SUBLANG_DEFAULT
A good way to test it (especially for resources in programs/ subdir) is
to run the
Dmitry Timoshkov wrote:
Gregory M. Turner [EMAIL PROTECTED] wrote:
One ritual is that you should not use msvcrt from other dlls, this
will cause trouble with apps that use the Unix libc.
Is it OK to do LoadLibrary/GetProcAddress, or is that equally problematic?
Why don't you use _lclose,
Eric Pouech [EMAIL PROTECTED] wrote:
Why don't you use _lclose, _lcreat, _llseek, _lopen, _lread, _lwrite
exported from kernel32?
except for _lopen which differs a bit from CreateFile, but why not using
ReadFile, WriteFile, CloseHandle...
Because they look too hard for Gregory... Did
Dmitry Timoshkov wrote:
Eric Pouech [EMAIL PROTECTED] wrote:
Why don't you use _lclose, _lcreat, _llseek, _lopen, _lread, _lwrite
exported from kernel32?
except for _lopen which differs a bit from CreateFile, but why not using
ReadFile, WriteFile, CloseHandle...
Because they look too hard for
On Saturday 16 August 2003 03:14 am, Eric Pouech wrote:
Dmitry Timoshkov wrote:
Eric Pouech [EMAIL PROTECTED] wrote:
Why don't you use _lclose, _lcreat, _llseek, _lopen, _lread, _lwrite
exported from kernel32?
except for _lopen which differs a bit from CreateFile, but why not using
Looking at msvcrt's code, it starts to look like a bit much. Take a peek at
dlls/msvcrt/file.c, _open and MSVCRT__sopen functions to get an idea of
what I was hoping to avoid.
msvcrt does a lot more than you need (and also a bit more than the
standard C library).
Looking at
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
I think I've finally figured how dmusic work (especially loading, object
and track interfaces). I'll send all my work next week or one after it,
but there are still some big flaws I'd like to fix before.
1. I've splitted dmusic debug channel into dmusic, dmusic32, dmband,
dmstyle, dmime, etc. and
Your test doesn't make much sense. The call to FindClose should be done
after you check the result of GetLastError, since FindClose should change
the last error to ERROR_SUCCESS if the close operation was successful.
From your test results, it seems that the FindClose implementation on the
Kelly Leahy wrote:
Your test doesn't make much sense. The call to FindClose should be done
after you check the result of GetLastError, since FindClose should change
the last error to ERROR_SUCCESS if the close operation was successful.
From your test results, it seems that the FindClose
AFAIK, it's never said that a successful function call should set the
last error to 0. This only thing MS claims is that when a function
fails, the last error is set to a error code explaining that error.
Moreover, wine's goal is not to make a better design than windows, but
to mimic windows
You're missing my point (or maybe you're not and you just don't agree with
me - in either case, let me make my point in a clearer way). If windows
doesn't say it won't change the last error, we, as programmers, should
assume that it might. In my experience, a large number of functions that
set
Actual implementation of the int 3d call (Standalone FWAIT)
is to patch the code to an fwait(9b) and a noop(90).
It seems that it corrupts the stack in FPU_ModifyCode and prevents vb3
programs
to start. (tests made with current CVS)
Since we do nothing apart an emulated fwait, I commented the
Alex Pasadyn [EMAIL PROTECTED] writes:
it was telling me that it had an error in FindNextFile of
success. I did a relay trace and found out that it was
calling FindFirstFile, FindNextFile a bunch of times,
FindClose, and then GetLastError.
What happens if you change the Windows version? To
Eric Pouech wrote:
You're missing my point (or maybe you're not and you just don't agree
with
me - in either case, let me make my point in a clearer way). If windows
doesn't say it won't change the last error, we, as programmers, should
assume that it might. In my experience, a large number of
make crosstest seems broken on Debian 3.0
Or is it me?
Please give some feedback if you have any. There is a bug filed on
http://bugs.winehq.com/show_bug.cgi?id=1602
Tried it on wine-20030813.
regards,
Jakob
---
i586-mingw32msvc-dlltool -k -l
Dominik Strasser [EMAIL PROTECTED] wrote:
The attached patch hacks^H^H^H^H^Hfixes this problem. Obviously, this
binary doesn't contain a valid PE header. OTOH it seems to be a valid
Windows binary (I haven't checked it myself). Maybe somebody with a more
deep insight into this can come up
Maxime Bellengé [EMAIL PROTECTED] wrote:
Changelog:
* Fix the creation of treeview with checkboxes. Now they display fine.
The only real change in this patch is the following snippet. Could you
retest and send only that chunk alone?
@@ -4848,12 +4850,14 @@
DrawFrameControl(hdc, rc,
On Saturday 16 August 2003 02:25 am, Eric Pouech wrote:
except for _lopen which differs a bit from CreateFile, but why not using
ReadFile, WriteFile, CloseHandle...
A+
After consulting some doc, it seems CreateFile is actually easier to use than
_lopen, if only trivially so, due to the layout
The attached patch hacks^H^H^H^H^Hfixes this problem. Obviously, this
binary doesn't contain a valid PE header. OTOH it seems to be a valid
Windows binary (I haven't checked it myself). Maybe somebody with a more
deep insight into this can come up with a better fix.
Regards
Dominik
Hi,
attached you find a patch which imporves the compiled-in loadorder
detection a little bit.
It adds a win16 flag which states whether the module under scrutiny is
a reserved name under Win16, only.
Surely some more of the names in the default_loadorder should be marked
alike. I am not sure
Hi all,
I observed a program that was bailing out with an absolutely baffling
error message. I have traced it to its cause, but now I'm stuck.
Basically, it was telling me that it had an error in FindNextFile of
success. I did a relay trace and found out that it was calling
FindFirstFile,
Alex Pasadyn wrote:
So, it looks like somewhere in FindClose Wine is resetting the last
error. I started digging through there and the functions it calls but I
was unable to find where it was getting reset. Can anyone shed some
light on this? Is there any way to break on that value
Please, see http://www.winehq.com/site/sending_patches especially:
cvs diff will always ignore newly added files, so you'll need to do
something like:
diff -u /dev/null newfile.c patch.diff
to make a patch for newly added files.
Do you plan to translate other programs and dlls that still they
Eric Pouech [EMAIL PROTECTED] wrote:
So, it looks like somewhere in FindClose Wine is resetting the last
error. I started digging through there and the functions it calls but I
was unable to find where it was getting reset. Can anyone shed some
light on this? Is there any way to
25 matches
Mail list logo
