Hi folks,
A new version (v0.9) of the Wine 0.9 TODO is available
for your viewing pleasure at:
http://63.138.153.104/wine/Wine-0.9-TODO-0.9.html
The work-in-progress one is available at:
http://63.138.153.104/wine/Wine-0.9-TODO.html
Most important changes in this one is that a bunch of
stuff was moved over to the Wine 1.0 TODO:
http://63.138.153.104/wine/Wine-1.0-TODO.html
Any feedback concerning this (rather large) changes
is more than welcomed.
Note: I had problems with my dssd.ca domain as of late,
I'll try to fix them soon. Meanwhile, the IP
should do.
--
Dimi.
On Thu, 8 May 2003, Juan Lang wrote:
> Sylvain was right, I screwed up the last patch. Here
> 'tis again.
Juan,
Your patches are hard to review, as you compress them.
Please include them in your message as plain text
if you can do it without line wraps, if not attach
them as plain text files. Here are some tips on
sending patches:
http://www.winehq.org/?page=sending_patches
Thanks!
--
Dimi.
Juan Lang <juan_lang(a)yahoo.com> writes:
> ChangeLog: Adds an implementation of iphlpapi.dll;
> most Get* functions introduced through Win98 are
> included.
I've applied the dll (with some changes), but not the test, it will
require some more fixes. The main problem is that you shouldn't check
the Windows version, you should call whatever functions are available
independently of what GetVersion() returns. Also the test must not
print anything to stdout, it should use the trace() macro instead.
--
Alexandre Julliard
julliard(a)winehq.com
Howdy,
I just reinstalled my Linux system (HD crash), and at the same time
moved to a RH9.0 distro. I read about the problems with the NPTL
threading, and I have the latest CVS running (with the --with-nptl).
Now when I have Agent running (which in all other respects seems fine)
every time I go to add an attachment or save an attachment Agent
crashes.
Is this a known problem? Or should I start getting a backtrace and
providing some more information?
Thanks,
--
Oliver Sampson
olsam(a)quickaudio.com
http://www.oliversampson.com
please stop using krnl386.exe export when possible (especially for dos emulation which is going out of kernel32/krnl386.exe combo). So, if CreateFile can do, please use it (ditto for any other krnl386 file related functions)
this is needed for proper DLL separation
> Hmm, and is there a reason to not do it in _lcreat16() instead?
> Or is _lcreat16() really "clever" enough to handle volume labels
> "properly" if called directly?
> Somehow I doubt it... ;)
> Or in fact you could walk further up the chain and maybe find that even
> _lcreat() should be the function to have that check instead...
> (or, for that matter, even CreateFileA and thus CreateFileW...)
>
> So my rough guess is that this should probably be prevented in CreateFileW
> instead even.
> Under Windows (2K) all functions such as DeleteFile, CopyFile, MoveFile,
> CreateDirectory and such do return FALSE and normally set the last error
> to ERROR_INVALID_NAME (123) if one of the filenames passed in contains a
> wildcard (*?).
>
> Wines kernel32 behaves somewhat different. Apart from returning different
> last errors in most cases such as:
>
> DeleteFile: ERROR_FILE_NOT_FOUND (2)
> CopyFile: ERROR_BAD_PATHNAME (161)
> MoveFile: ERROR_FILE_NOT_FOUND (2) when source contains wildcards
>
> which all wouldn't really be a to big issue, there is one thing which
> seems not right at all to me:
>
> MoveFile with a valid existing source and a target with wildcards
> will create a file on disk containing wildcards in its name. This
> certainly can't be the intention!
>
> So according to Win2K it would be probably useful to check in all those
> functions for existence of wildcards in the input file paths and refuse
> them properly.
>
> I took a look at the kernel32 file.c functions and saw that they usually
> all call DOSFS_GetFullName which is supposed to check for valid filenames
> and such. Problem is this function is also used in many other places and
> I can't get a good idea if those might need to accept wildcards in file
> names.
>
> Is there anyone more familiar with the kernel32 implementation in Wine
> who could maybe give me some insight if an according change to
> DOSFS_GetFullName would be useful or rather cause possible regressions?
>
> Otherwise the best thing to do would probably be to add explicit wildcard
> tests to all those file function and refuse with an according last error
> set. If I do not get any reactions this is probably what I will do as I'm
> somewhat weary to change an internal low level function such as
> DOSFS_GetFullName without some third party encouragement.
those functions are likely to be rewritten RSN (and DOSFS_GetFullName may even disappear)
So I'd suggest rather starting by writing test cases for those functions so we could use those tests when the rewrite is going to take place
A+
On May 31, 2003 05:45 am, Shachar Shemesh wrote:
> + /* Treat the case where no special handling was requested in a
> fastpath way */ + /* copy will do if the GCP_REORDER flag is not set
> */
> + if (lpResults->lpOutString)
> + for (i = 0; i < nSet && lpString[i] != 0; ++i)
> + lpResults->lpOutString[i] = lpString[i];
What about a strncpy here:
+ if (lpResults->lpOutString)
+ strncpyW(lpResults->lpOutString, lpString, nSet);
--
Dimi.
Since Alsa has released a 0.9 version, I think we could write a more
complete driver.
(midi output, recording, channel control...)
Eric and Marco,
are you still working on it ?
=====
Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259
No more War !
"What if tomorrow the War could be over ?" Morpheus, in "Reloaded".
For the Law of Oil and Fire, Im an European that lives in France.
For all my Brothers and friends, Im a human living on Earth.
___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com
Na 1054375053, 2003-05-31 ob 11:57, je Raphaël Junqueira napisal(a):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi folks,
>
> I'm trying to get Unreal2 working, with no sound it continue to access some
> dmusic stubs and crash. With this it crash later than befor (in dmusic too).
> If anyone can help to really improve dmusic support as we need a real
> implementation of IDirectMusicPerformance8
I'm working on it but I'd really appreciate any help...
> Else, anyone know how to force an application to not use dmusic (saying that
> it's not supported) ?
Sure, just go into /usr/lib/wine and delete or rename dm*.dll.so :)
> Changelog:
> - some implementation of dmusic stubs
>
> Regards,
> Raphael
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (GNU/Linux)
>
> iD8DBQE+2HyRp7NA3AmQTU4RAphSAJ4k6JEXzMWTk2YkgZe64x24AcNOAwCdHC1g
> EbX3xX1cR1a7fnTzDteoI0Q=
> =z3AZ
> -----END PGP SIGNATURE-----
Hello,
I am wanting to adapt the WINE edit control for use in ReactOS and I
dont understand how the edit control gets called by the application. I
have a simple window program that calls the EDIT class and have stubbed
out the exported functions but I dont see or understand how EditWndProc
gets called from the application. When I look at the imports of my edit
control test application this function isnt called but running it I do
get a Window I can type text in. I am still really new to this whole
programming gig so if I looking in the wrong area please point me in the
right direction.
Thanks
Steven