Alexandre Julliard wrote:
> Folks,
>
> I just released 20050930, this should be considered the pre-0.9
> release, so please give it some good testing. In particular, please
> test the things that new users will encounter first, like the
> automatic .wine creation and winecfg.
>
This is fantastic.
I have a question though what should I call this release in bugzilla?
20050930
20050930 pre beta 0.9.0
0.9.0 pre beta (20050930)
other suggestions????
Obviously we should decide now how our release nameing structure is
going to be called and I did not want to just put it in without some
feedback...
--
Tony Lambregts
I did regression testing and found patch Id=19048 triggers this error
wine-pthread: run.c:142: ME_RunOfsFromCharOfs: Assertion `nCharOfs >=
nParaOfs' failed.
filed http://bugs.winehq.org/show_bug.cgi?id=3239
The application is a free download and the bug has steps to generate the
failure. It is still a problem with cvs from 20050909.
Paul
Looks like someone else is having this problem. I've
tried looking at listview.c and the treeview
equivalent as well, but I can't made heads or tails of
it. I have no experience with C.
Anybody on this list make any changes to listview or
treeview in the last few months?
Hiji
> ------- Additional Comments From
> qingdao33122(a)yahoo.com 2005-04-08 23:58 -------
> About the same problem with AceFTP
>
> Free download for trial
>
http://software.visicommedia.com/en/products/aceftpfreeware/
>
> wine-20050524-1fc1winehq
>
> Problem starts before I do the FTP thing.
> When I drag a file within the local pane(a
> listview),
> a copy of that file is immediately created. But
> things
> don't stop there. The moment I move the mouse a bit,
> AceFTP asks me with a popup menu if want to:
> Move to current location
> Copy to current location or
> Create a short
> If I choose to copy, ANOTHER copy of the file is
> created.
> After that, every time I move the mouse,
> AceFTP asks me again, thus an infinite loop
> and infinite number of copies of the same file.
>
> BTW. I have to use native shell related dlls for
> AceFTP to
> display the local pane. So I suspect the problem is
> with
> the interaction between native and builtin code.
>
> I hope my English is good enough for me to make some
> sense...
>
> --
> Configure bugmail:
> http://bugs.winehq.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
I saw the bug described in:
http://winehq.com/hypermail/wine-users/2001/01/0516.html
happened again to a program I was trying to use. At least the behavior
is the same. I have no access to the source code. It seems the problem
was fixed in revision 1.42 of socket.c. But now at 1.139, WSACleanup
again return 0 forever on repeating calls.
Could somebody please point me to an online documentation on the
functions exported by DIBENG.DLL and how an userspace application could
use them? I want to evaluate whether a possible DIB engine for Wine
could use the DIBENG.DLL API. I googled and all I find are reports of
GPFs involving DIBENG.DLL. Same issue when searching MSDN. Of course,
DIBENG.DLL might not be the best model to implement for a DIB engine, so
I wait for suggestions. I was planning on writing a C program that would
load DIBENG.DLL via LoadLibrary() and call its functions in order to
build tests for it.
Alex Villacís Lasso
On 9/30/05, Alex Villacís Lasso <a_villacis(a)palosanto.com> wrote:
> This patch is required in order to run any application that embeds
> DBGRID32.OCX from MS VisualBasic 5 or 6
>
> Changelog:
> * Add additional condition for creation of interface
A patch would be nice =)
Thanks
Steven
Hi people,
I read in the today's Wine Weekly News something about rpms for Fedora
Core 4.
In august I begann building some for FC 4. I built rpm's for the july
and the august version.
The rpm's were based on Vincent Beron's. They were downloaded about 700
times from my server.
There is also a mirrorserver that also hosts my rpms. In
fedoraforums.org just one guy reported a problem
with the rpm.
They can be downloaded here:
http://komi.bluezones.org/wine/fc4/
I'll build also rpms for the coming cvs drop out.
In this, I will take care of things I read in the WWN.
Any comments, improvements, suggestions are very welcome!
Regards,
Dieter Komendera
i am making the "amateur" version of progress: i just had
echo_server.exe run for the first time on win32: echo_client.exe
has been running successfully since this morning.
rpcd.exe - the endpoint mapper - just crashed :)
hmmm... recv_state_timer is indicating Ping timeout, sending "Orphan
timeout", and then bombing out... hmmm...
this despite echo_server.exe happily running.
i don't really know enough to say what's going on here -
other than to consider quite cheerfully disabling the ping
rpc timer code with a _huge_ manic grin on my face :)
i have had to disable TCP (ncacn_ip_tcp) for now, and will try that
next.
i've refrained from notifying wine-devel of status reports until i
actually had something working. for your benefit:
* i am using pthreads-win32, from sourceware.org, with pthread_self.c
patched to set sp->implicit = 0 instead of 1.
this gets the dcethreads test programs to work: whether this is
a good thing remains to be seen...
* i have removed the awfulness that is linux-specific (system call
wrapping) which previously made dcethreads non-portable to win32:
instead, you now must #define sys_pthread_create pthd4_create because
dcethreads provides pthd4_xxx.
* the dcethreads exception emulation library still uses setjmp and
longjmp and to my surprise and horror it actually works.
* i have tracked down an implementation of gettimeofday, and liberally
sprinkled it across the code, statically, instead of providing a
nice library routine
* i have provided a win32_winsock.c "wrapper" set of code to divorce
the #including of <windows.h> and <winsock.h> from everything else.
no, it is _not_ appropriate to put #include <windows.h> in the
freedce header files.
there are too many conflicts for that to be suitable. HANDLE,
handle_t, UUID, uuid_t rpc_binding_t ain't the half of it.
* i could not be arsed to write yet another version of uuid_create()
and the uuid_create() function in freedce conforms to the RFC - grabs
networking MAC address etc. etc.
therefore, rather than rip wine code from UuidCreate(), i decided
to call UuidCreate() - via a wrapper function.
this _could_ therefore get interesting, if someone decides to make
rpcrt4.dll utilise uuid_create() ... :)
* i have NOT done any proper file locking stuff - yet - in rpcd.exe.
there's a database that really needs to be locked: i aim to grab
APR's apr_open(), apr_flock() etc. etc. and utilise those because
i _so_ cannot be bothered to reinvent the wheel.
wine-devel team: you now have a partially-working and therefore
proof-of-concept port of freedce to win32.
there are many next steps that can be taken from here.
--
--
<a href="http://lkcl.net">http://lkcl.net</a>
--