On Monday, 14 October 2013 9:50 PM, Ricardo Filipe wrote:
>I'd be more than happy to help you review your patches, although I am no
>wineconsole expert, I believe I could help you get your changes into wine.
>Contact me if no better offer comes around :) cheers
Hello Ricardo,
Hello Hugh,
I'd be more than happy to help you review your patches, although I am
no wineconsole expert, I believe I could help you get your changes
into wine.
Contact me if no better offer comes around :)
cheers
2013/10/11 Hugh McMaster :
> Can anyone help me on this? I do real
Can anyone help me on this? I do realize that wineconsole is only a minor focus
of development.
Hugh
-
Hi everyone,
I just wanted to know if anyone would mind helping/mentoring me with a few
small patches.
I am working primarily on
Hi everyone,
I just wanted to know if anyone would mind helping/mentoring me with a few
small patches.
I am working primarily on wineconsole's screen buffer problems (to which I
believe I have the solution), but am also looking at implementing some stub
Win32 console functions found in dlls/ke
On Thu, Aug 29, 2013 at 10:38 PM, Charles Davis wrote:
> To add a new request to the server, you first add a definition to
> server/protocol.def . This file is processed by the make_requests tool, which
> generates a bunch of other files from it. The syntax of the server protocol
> definition f
On Aug 29, 2013, at 6:43 PM, Bruno Jesus wrote:
> Hi all, I need some help to continue my current wine work.
>
> In order to implement SO_PROTOCOL_INFO for getsockopt I need to
> retrieve some information from the socket like its family and
> protocol.
>
> I have search
Hi all, I need some help to continue my current wine work.
In order to implement SO_PROTOCOL_INFO for getsockopt I need to
retrieve some information from the socket like its family and
protocol.
I have searched for a few days and ended up with a solution I dislike
so I had a better idea (at
ere
> anyone succeed in install of it?
> Thanks.
> Appreciate your kind help.
Please ask support questions on wine-users mailing list, or on the forum.
This is a development list.
help.
On Jul 25, 2013, at 2:11 PM, Qian Hong wrote:
> On Fri, Jul 26, 2013 at 2:52 AM, Ken Thomases wrote:
>> I think your Valgrind results are telling us that there's a bug in the game
>> where it's using an uninitialized stack variable.
>>
>> There's still a chance that it's something in Wine that'
On Fri, Jul 26, 2013 at 2:52 AM, Ken Thomases wrote:
> I think your Valgrind results are telling us that there's a bug in the game
> where it's using an uninitialized stack variable.
>
> There's still a chance that it's something in Wine that's using the
> uninitialized variable and passing a ga
Hi Qian,
On Jul 25, 2013, at 11:53 AM, Qian Hong wrote:
> On Thu, Jul 25, 2013 at 2:33 AM, Ken Thomases wrote:
>> Hmm. You may need to mark the dummy array as volatile to prevent it from
>> being optimized away. Worth trying. You might also increase the size of
>> the array.
>
> You are ri
how far I can get from here, also I'm open to any suggestion
and appreciate to any help!
Thanks again.
--
Regards,
Qian Hong
-
http://www.winehq.org
t;
>> I bet the crash will change from a read access to 0x0001 to 0x.
>>
>
> Thanks for the advice, it sounds cool and I learned new things, thank you.
> However, it doesn't help in this case, I didn't found any change after
> the dummy hack.
Hmm.
>
Thanks for the advice, it sounds cool and I learned new things, thank you.
However, it doesn't help in this case, I didn't found any change after
the dummy hack.
> The question is: is it a bug in the game or a bug in Wine where Wine is
> returning a garbage pointer t
AddRef to FIXME, the
crashing would be worked around.
However, replacing the TRACE to printf doesn't help. I'm not sure why.
by replacing TRACE to printf, I can reproduce the crashing while have
a look at the refcounting, it seems good to me.
--
Regards,
Qian Hong
-
http://www.winehq.org
Hello,
Thanks everyone's help, sorry for delay, I was blocked by something else.
I've created http://bugs.winehq.org/show_bug.cgi?id=34125 to track
down this bug.
On Fri, Jul 19, 2013 at 10:06 PM, Henri Verbeet wrote:
> Well, it sounds a bit like some form of memory corrupti
On Jul 19, 2013, at 8:34 AM, Qian Hong wrote:
> I was debugging on a popular game [1] [2] (9 GB), it crashes on start.
>
> +relay,+seh,+tid log show that there are some calls to
> wined3d.wined3d_mutex_lock / wined3d.wined3d_buffer_map /
> wined3d.wined3d_mutex_unlock before crashing, so I turn o
On Fri, Jul 19, 2013 at 04:06:56PM +0200, Henri Verbeet wrote:
> On 19 July 2013 15:34, Qian Hong wrote:
> > Further tests show that the simplest hack to avoid crashing is
> > replacing line 71 to:
> > FIXME("anything %x\n", 0xdeadbeef);
> >
> > I have no idea what the real fix is, any suggestion
On 19 July 2013 15:34, Qian Hong wrote:
> Further tests show that the simplest hack to avoid crashing is
> replacing line 71 to:
> FIXME("anything %x\n", 0xdeadbeef);
>
> I have no idea what the real fix is, any suggestion what is the next
> step to debug?
>
Well, it sounds a bit like some form of
Hello,
I was debugging on a popular game [1] [2] (9 GB), it crashes on start.
+relay,+seh,+tid log show that there are some calls to
wined3d.wined3d_mutex_lock / wined3d.wined3d_buffer_map /
wined3d.wined3d_mutex_unlock before crashing, so I turn on +d3d9 trace
to get a new log in details.
To my
Hello all,
thanks much for replies.
On Tuesday 02 of July 2013 18:15:28 Vincent Povirk wrote:
> > What others have suggested in similar situations is to build a Linux
> > application that speaks to the device driver directly, and provides a
> > socket interface, then use sockets from the Windows
ebody else (or even to me
> if I find time one day and return to the problem).
This goes over my head. It sounds like you know a lot about Windows
drivers, and it's too bad you don't have time to help us with that.
> What others have suggested in similar situations is to build a Linux
> application that speaks to the device driver directly, and provides a socket
> interface, then use sockets from the Windows program to talk to the device.
I didn't think of that. A winelib dll providing an API for directly
ac
Hi Vincent, Pavel,
On Tue, Jul 2, 2013 at 8:44 AM, Vincent Povirk wrote:
> Since you're not prepared to spend a lot of time improving Wine's
> driver support, it sounds like modifying core parts of Wine
> specifically to support your application is the best approach.
>
An alternative is to modif
I don't know much about this, but it sounds like a driver is the right
way to do this. It's probably just a case of Wine's driver support not
being good enough yet to support what you want to do. So the less
intrusive/hacky way to fix this would be to improve Wine's driver
support, ideally to a poi
Hello all Wine developers,
[the second attempt to send, is the list subscribers only?]
the firs I would like to express my respect to the work done.
Now to one of our application, we maintain open-source chromatographic
software CHROMuLAN
https://sourceforge.net/projects/chromulan/
Unfortuna
--- On Tue, 2/7/13, Alan W. Irwin wrote:
> > Going personal and accusing others of being biased is
> not a way of
> getting help.
...In short, I have
> a
> prejudice against anyone stating anecdotal evidence
> concerning issues
> with _any_ open-source software if
On Sat, Jun 29, 2013 at 12:34 AM, Juan Lang wrote:
> Ah. Thanks for following the existing style then :-/ No, don't bother
> changing the existing code. I leave it up to you whether to follow my
> suggestion or ignore it, either is fine in this case.
Patch sent, thanks Juan Lang and Daniel Jelińs
On Fri, Jun 28, 2013 at 9:16 AM, Qian Hong wrote:
> Dear Juan,
>
> Thanks for reviewing!
>
> On Fri, Jun 28, 2013 at 11:31 PM, Juan Lang wrote:
> > It's more in line with most C code to use !memcmp(...) instead of
> > memcmp(...)==0. I find it easier to scan, anyway, as I've gotten used to
> !
>
Dear Juan,
Thanks for reviewing!
On Fri, Jun 28, 2013 at 11:31 PM, Juan Lang wrote:
> It's more in line with most C code to use !memcmp(...) instead of
> memcmp(...)==0. I find it easier to scan, anyway, as I've gotten used to !
> comparisons to check equality in memcmp, strcmp, and variants.
>
Hi Qian,
On Fri, Jun 28, 2013 at 3:44 AM, Qian Hong wrote:
> Hi Daniel, new patches sent with improving from your hints, would you
> mind have a look? Thanks in advance!
>
nice work! These look fine to me, but a stylistic nit:
+
ok(memcmp(pbData,cTestData[i].decstr,cTestData[1].enclen)==0,"dec
Hi Daniel, new patches sent with improving from your hints, would you
mind have a look? Thanks in advance!
Hi Daniel,
On Fri, Jun 28, 2013 at 4:47 PM, Daniel Jeliński wrote:
> I'm not convinced that a failed call to CryptDecrypt actually resets
> the key state. It's also possible that CryptDecrypt returns FALSE
> before even trying to decrypt if data length is invalid. To check it,
> you would need to
ch
>> you do not restore before calling the function again.
>
> Thanks a lot of the hint, with your help I finally resolve it! I've
> improved my test and submit two rsaenh patches, would you mind help to
> review them?
>
> Thanks again!
>
>
> --
> Regards,
> Qian Hong
>
> -
> http://www.winehq.org
>
ith Final =
> TRUE should return the same result.
>
> Your testcase fails because CryptDecrypt changes the value of dwLen, which
> you do not restore before calling the function again.
Thanks a lot of the hint, with your help I finally resolve it! I've
improved my test and submit two
It is definitely valid to call CryptDecrypt multiple times with the same
key. Calls with Final = FALSE change the internal state of the key, calls
with Final = TRUE restore the initial state. Subsequent calls with Final =
TRUE should return the same result.
Your testcase fails because CryptDecrypt
Hello,
I was investigating Bug 33898 [1] hardly and get a partial result, I
have a special test case demonstrate the behavior of Aliwangwang [2],
however, I failed to expand the special case to a common test case. My
attempting is shown in [3]. The hack in [3] works for Aliwangwang, but
the test c
So while the translators are busy updating Wine's translations, what
better time than a freeze for developers to fix Wine's conformance
tests, particularly on the new WineTestBot:
http://newtestbot.winehq.org
It does not have as many VMs as the old one but it does have some
interesting new
On Apr 22, 2013, at 1:17 PM, Kirill Smirnov wrote:
>While debugging bug #33307 (http://bugs.winehq.org/show_bug.cgi?id=33307)
> I found a suspicious piece of code, looking like off-by-one error.
>
>Unfortunately, I'm not familiar with this part of wine and I don't know
> how to write co
Hi!
While debugging bug #33307
(http://bugs.winehq.org/show_bug.cgi?id=33307) I found a suspicious
piece of code, looking like off-by-one error.
Unfortunately, I'm not familiar with this part of wine and I don't
know how to write corresponding test case.
If you familiar with th
Hi,
Well, your testcase had a trivial mistake which i now see.
This line:
typedef struct AEffect * (*main_entry_t)(audioMasterCallback);
must read:
typedef struct WINAPI AEffect * (*main_entry_t)(audioMasterCallback);
WINAPI is critical here, as it changes the call from the SysV AMD64
calling
Hey Marcus,
> Can you add a
> printf("plugin %p\n", plugin);
> after above line?
>
> I would suspect things like:
> - checks for processor features and returns 0x if not found.
I added this line to the sources / compiled and tested - here is
output: http://pastebin.com/QMtWttRZ
Hey Marcus
> Works for me on my AMD Phenom(tm) II X4 945 Processor.
great :) (very similar CPU).
> It looks like the
> struct AEffect* plugin = main_entry((audioMasterCallback)
> simple_master_callback);
>
> returns 0x, which is probably a failure indication.
>
> Can you add a
On Thu, Apr 04, 2013 at 07:39:16PM -0400, jordan wrote:
> Hey List,
>
> A few days ago, i posted to the list about possibly porting a winelib
> app to support x86_64. (currently supports x86).
>
> the original post is here (for those interested, but not entirely
> relevant to this post):
> http:/
> Hello!
Hey Gediminas! ;)
> Works fine on my AMD system:
Can you also give me the rest of your specs / distro, please?
> vinis@g44:/media/vinis/code/temp/fsthost-code$
> WINEPREFIX=/media/vinis/bottles/test64 ./test64.exe ../ColourEQ_64.dll
> Load plugin ../ColourEQ_64.dll
> fixme:heap:HeapSet
On Fri, Apr 5, 2013 at 3:36 AM, jordan wrote:
> It's been tested with several wine versions (1.4.1, 1.5.24, 1.5.27).
> On intel systems, it works on ALL versions. On my AMD system, it
> doesn't work at all.
Hello!
Works fine on my AMD system:
vinis@g44:/media/vinis/code/temp/fsthost-code$
WINEPR
Hey Andre.
> only thing that comes to mind is that you need gcc>=4.4, but configure checks
> that for you.
> Did you tried the binaries of your intel mate?
Well, i am using gcc-4.8 (but have also tested with gcc-4.7.3/4). He
is using gcc 4.7.3 or .4.
No, i did not try his binaries ~ but that is
Am 05.04.2013 02:36, schrieb jordan:
> Hey Andre,
>
>> was it the same binary or did you compiled it on each cpu?
>> Do you have the same Wine versions?
>
> Compiled on each respective system. (no sharing of binaries).
>
> It's been tested with several wine versions (1.4.1, 1.5.24, 1.5.27).
> On
Hey Andre,
> was it the same binary or did you compiled it on each cpu?
> Do you have the same Wine versions?
Compiled on each respective system. (no sharing of binaries).
It's been tested with several wine versions (1.4.1, 1.5.24, 1.5.27).
On intel systems, it works on ALL versions. On my AMD s
Am 05.04.2013 02:06, schrieb jordan:
> Hey Austin
>
>> Are y'all using the same OS/distro/kernel/gcc/libc versions?
>
> Different (distro) but everything else is very similar, if not the
> same. My feeling is that this is not going to end up being the problem
> and if i remember correctly, the 2
Hey Austin
> Are y'all using the same OS/distro/kernel/gcc/libc versions?
Different (distro) but everything else is very similar, if not the
same. My feeling is that this is not going to end up being the problem
and if i remember correctly, the 2 Intel systems are not the same
either..
But just
app can be compiled with;
>
> $ make -f Makefile64-most-simple
>
> then
>
> $ ./test64.exe /path/to/64bitVST
>
> a tester can be found here: http://www.ddmf.eu/freeware.php
>
> grab 'ColourEQ' (contains both 32bit and 64bit versions... and
> obviously use
is causing the problem...but i want
to rule out Wine64 being an issue, first - if possible.
any help is appreciated. Thanks
Jordan
On Wed, Jan 16, 2013 at 12:19 AM, Juan Lang wrote:
> Could the password hashes be excluded from the regular tarball? E.g. using
> --exclude in the tar command?
Sorry I didn't reply sooner, been a little busy the past week. I don't have a
copy of the Wine Wiki data in front of me, but if I remembe
Hi Kyle,
On Tue, Jan 15, 2013 at 8:10 AM, Kyle Auble wrote:
> The one thing that would probably help a lot is if there was a regularly
> updated tarball of the wiki content either at WineHQ or Lattica's FTP
> again. I
> haven't messed with cron itself much, but my arch
Hi folks,
Thanks for all the help and hits -- much appreciated.
I ended up writing a few scripts myself that cleaned up
both the pages and users. It should do for now.
Please let me know if you see any problems with the
wiki, I hope I wasn't over-eager when cleaning up spam :)))
Cheers,
On Tue, Jan 15, 2013 at 1:06 PM, Dimi Paun wrote:
> Thanks everyone for your help!
> I'll take down the Pages spreadsheet.
> Now, what about the users? Those are files (not directories) so we don't
> face
> the same low limit (32k), but it would be nice if we could,
rst pass of the script.
Ran it again, we're down to 729. However, eyeballing the result looks pretty
clean, so I'll say this is good enough for now, as far as pages are
concerned.
Thanks everyone for your help!
I'll take down the Pages spreadsheet.
Now, what about the users? Those are
Hi Dimi,
Dimi Paun wrote:
> I've cleanup the deleted pages, were down to about 740 pages,
> mostly good stuff:
>
> https://docs.google.com/a/lattica.com/spreadsheet/ccc?key=0AmY-Kp_Ihu3idFNEOUt0UkVGUko4elhkOHVoaWx2OWc#gid=5
>
> Please check it out, lemme know if any spam is still left standing
Hi guys,
I've cleanup the deleted pages, were down to about 740 pages,
mostly good stuff:
https://docs.google.com/a/lattica.com/spreadsheet/ccc?key=0AmY-Kp_Ihu3idFNEOUt0UkVGUko4elhkOHVoaWx2OWc#gid=5
Please check it out, lemme know if any spam is still left standing.
Any ideas on how we can att
Yes it is done. Ill update the spreadsheet bit later...
André Hentschel wrote:
>Am 14.01.2013 21:40, schrieb Andrew Eikum:
>> On Mon, Jan 14, 2013 at 03:32:40PM -0500, Dimi Paun wrote:
>>> OK, we might be onto something. I've wrote a script
>>> to determine the deleted pages: 20162.
>>>
>>> Shou
Am 14.01.2013 21:40, schrieb Andrew Eikum:
> On Mon, Jan 14, 2013 at 03:32:40PM -0500, Dimi Paun wrote:
>> OK, we might be onto something. I've wrote a script
>> to determine the deleted pages: 20162.
>>
>> Should I just go ahead and nuke those?
>>
>
> Probably, yes.
>
> One common way for spamme
On Mon, Jan 14, 2013 at 03:32:40PM -0500, Dimi Paun wrote:
> OK, we might be onto something. I've wrote a script
> to determine the deleted pages: 20162.
>
> Should I just go ahead and nuke those?
>
Probably, yes.
One common way for spammers to abuse wikis is to intentionally get the
pages dele
Am 14.01.2013 20:00, schrieb Dimi Paun:
> Hm, it doesn't seem to be so simple.
> Each page maintains an edit-log file with all the changes.
>
> grep-ing for -i spam in the edit-log yields less than 400 hits.
>
> Maybe we should look for deleted pages?
>
Simple idea:
Make a backup of the current
OK, we might be onto something. I've wrote a script
to determine the deleted pages: 20162.
Should I just go ahead and nuke those?
Dimi.
On 01/14/2013 01:35 PM, Francois Gouget wrote:
On Mon, 14 Jan 2013, Dimi Paun wrote:
MoinMoin creates a dir for every page. I simply got the list
by listing
Hm, it doesn't seem to be so simple.
Each page maintains an edit-log file with all the changes.
grep-ing for -i spam in the edit-log yields less than 400 hits.
Maybe we should look for deleted pages?
Dimi.
On 01/14/2013 01:35 PM, Francois Gouget wrote:
On Mon, 14 Jan 2013, Dimi Paun wrote:
OK, that's a fair point. Lemme quickly go through that
and I'll report back.
Dimi.
On 01/14/2013 01:35 PM, Francois Gouget wrote:
On Mon, 14 Jan 2013, Dimi Paun wrote:
MoinMoin creates a dir for every page. I simply got the list
by listing these directories. (This is the problem -- there is a
On Mon, 14 Jan 2013, Dimi Paun wrote:
> MoinMoin creates a dir for every page. I simply got the list
> by listing these directories. (This is the problem -- there is a
> limit of 2^15 subdirectories, and this is what we were hitting
> a few days ago).
>
> Does that answer the question?
It feels
MoinMoin creates a dir for every page. I simply got the list
by listing these directories. (This is the problem -- there is a
limit of 2^15 subdirectories, and this is what we were hitting
a few days ago).
Does that answer the question?
Dimi.
On 01/14/2013 12:51 PM, Francois Gouget wrote:
On M
On Mon, 14 Jan 2013, Dimi Paun wrote:
[...]
> https://docs.google.com/a/lattica.com/spreadsheet/ccc?key=0AmY-Kp_Ihu3idFNEOUt0UkVGUko4elhkOHVoaWx2OWc#gid=5
I'm not clear on how this is supposed to work.
For instance I see a ton of pages containing 'joyal' or 'crusher' in
their Page Name. For insta
On 01/14/2013 11:43 AM, Erich E. Hoover wrote:
On Mon, Jan 14, 2013 at 9:38 AM, Dimi Paun wrote:
...
Please let me know if we can do this any simpler or if there are
any problems.
Do you want us to move marked items up to the top of the spreadsheet
or will you do that for us?
I don't think we
On Mon, Jan 14, 2013 at 9:38 AM, Dimi Paun wrote:
> ...
> Please let me know if we can do this any simpler or if there are
> any problems.
Do you want us to move marked items up to the top of the spreadsheet
or will you do that for us?
Erich
xtent that we are reaching system limits.
I need your help to clean them out. First, we have to separate the spam
from the real content. I've created a Google Spreadsheet for pages:
https://docs.google.com/a/lattica.com/spreadsheet/ccc?key=0AmY-Kp_Ihu3idFNEOUt0UkVGUko4elhkOHVoaWx2OWc#gid=5
a
Le 30/12/2012 22:52, Adam Martinson a écrit :
Looking for some help splitting patch 3, not sure how I can cut it
down any more without breaking stuff. I'm guessing patch 9 will need
splitting too, same problem.
I haven't checked whether it's really possible, but one way to
Looking for some help splitting patch 3, not sure how I can cut it down
any more without breaking stuff. I'm guessing patch 9 will need
splitting too, same problem.
~Adam
patches.tar.gz
Description: GNU Zip compressed data
On Thu, Dec 20, 2012 at 6:25 AM, Hamid Lohar wrote:
> I am installing it from source file (wine 1.5.x.tar.bz2) by running
> wine install i get error "x support not found, wine can not fount x,
> please instal xlib/xfree86 devlopment files".
> That is the error.
>
You need to install your X develop
12 at 3:32 PM, Hamid Lohar wrote:
>> Dear sir,
>> I am installing wine 1.3 from source file but i getting fail to
>> install beacose of Xlib/xfree86 devlopnemt packeg so i neet that
>> packege please help me.
>>>
>
> You don't provide enough informat
On Thu, Dec 6, 2012 at 3:32 PM, Hamid Lohar wrote:
> Dear sir,
> I am installing wine 1.3 from source file but i getting fail to
> install beacose of Xlib/xfree86 devlopnemt packeg so i neet that
> packege please help me.
>>
You don't provide enough information about
Dear sir,
I am installing wine 1.3 from source file but i getting fail to
install beacose of Xlib/xfree86 devlopnemt packeg so i neet that
packege please help me.
On 11/09/2012 06:29 PM, Scott Ritchie wrote:
https://www.eff.org/deeplinks/2012/11/no-copyrights-apis-help-us-make-case
There are court cases pending that are very, very relevant to what we
do here. It would help the EFF very much if a few engineers could
send them a short email statement
https://www.eff.org/deeplinks/2012/11/no-copyrights-apis-help-us-make-case
There are court cases pending that are very, very relevant to what we do
here. It would help the EFF very much if a few engineers could send
them a short email statement explaining how Wine's reimplementation of
New draft at
https://testbot.winehq.org/JobDetails.pl?Key=22035
(the testbot seems stuck... Maarten, does it need a kick?)
Thanks to Maarten for getting me to try C varargs again;
the first assembly function is now gone.
I've also added comments that explain the vcomp execution
model, I hope that
On Fri, Oct 05, 2012 at 04:27:24PM +0200, joerg-cyril.hoe...@t-systems.com
wrote:
> So bad, now what is actually needed?
>
> Think assembly.
>
> Using your test example:
> +p_vcomp_fork(0, 5, _test_worker5, 1, 2, 3, 4, 5);
>
> _vcomp_fork finds data:
> 1. on the stack
> 2. in registers
> 3.
27;s a boolean saying whether to actually run in parallel, or just in
the current thread.
> I believe that va_list etc. is not going to lead you anywhere.
I'm going to give Maarten's suggestion a shot. If it works, the
only assembly left will be a nearly verbatim copy of code in oleaut32/
ster
- JMPTO _test_worker5 via scratch register
This assumes there's nothing like CreateThread so you can run from the original
stack.
If there were, you'd need to copy the 5 elements from the stack to the new one
(which is presumably why vcomp_fork receives their number as parameter).
Does this help?
Jörg Höhle
On Thu, Oct 4, 2012 at 1:52 PM, Kyle Auble wrote:
> I'm just wondering is assembly definitely needed?
> This is just based on some googling and skimming
> through StackOverflow, but it sounds like you can
> still use va_list on amd64. It just takes some
> tweaking:
> http://stackoverflow.com/quest
On 10/03/2012 09:49 PM, Dan Kegel wrote:
> The main challenge was figuring out how to get the variable
> list of arguments off the stack, and then put them back onto
> the stack when calling the provided function pointer.
> This bit of varargs hackery can't be done in pure C as far as I
> can tell
could throw at it, I submitted it as
http://source.winehq.org/patches/data/90524,
Alexandre rejected the patch, saying it had multiple problems,
but declining to provide any further hints.
He suggested I find someone to work with to get it in...
so here I am, hat in hand, asking for help.
The patch
On 10/02/12 23:02, Erich E. Hoover wrote:
> If a cleanup occurs because HTML Help window creation fails then
> list_remove() causes a crash, since the window was never added to the
> window list. The attached patch fixes this issue, allowing safe
> reloading of files (needed for pa
> IStream is not exposed to the user, but an internal interface would probably
> end up looking a lot like IStream because we need read/write/seek operations,
> reference counting and the ability to create clones. So we might as well use
> IStream.
Hmmm... Then I want exactly the same as SHCrea
On Wed, 2012-06-20 at 12:13 +0200, robert.van.h...@serioustoys.com wrote:
> IStream is not exposed to the user, but an internal interface would
> probably end up looking a lot like IStream because we need read/write/seek
> operations, reference counting and the ability to create clones. So we
> mig
On Tue, 2012-06-19 at 21:45 +0200, robert.van.h...@serioustoys.com wrote:
> > We don't have to call SHCreateStreamOnFileEx, we can add a suitable
> > implementation to msi.
>
> Ah, I see.
>
> I guess this stream cannot escape from MSI. The only way it can be accessed is
> through MsiRecordReadSt
> We don't have to call SHCreateStreamOnFileEx, we can add a suitable
> implementation to msi.
Ah, I see.
I guess this stream cannot escape from MSI. The only way it can be accessed is
through MsiRecordReadStream and MsiRecordSetStream, but it can never be
accessed directly?
In that case, we
> Yes, the concern is that the file could be changed or removed. We should
> test what native does here but it probably means that we need to create a
> stream
> on the file with a sharing mode that denies writing.
So... I tried this out. I do not understand what I found though!
On Windows, afte
ds,
Robert
Van: Hans Leidekker [h...@codeweavers.com]
Verzonden: dinsdag 19 juni 2012 13:04
Aan: robert.van.h...@serioustoys.com
CC: wine-devel@winehq.org
Onderwerp: RE: msi:RECORD_StreamFromFile bug, help needed
On Tue, 2012-06-19 at 12:36 +0200, robert.van.h...@serioustoys.com wrote:
> I alt
fix
this current behaviour also happened in the instances where the GlobalAlloc
didn't fail.
Any help would be appreciated!
Kind regards,
Robert
Van: Hans Leidekker [h...@codeweavers.com]
Verzonden: dinsdag 19 juni 2012 9:29
Aan: robert.
On Tue, 2012-06-19 at 20:55 +0200, robert.van.h...@serioustoys.com wrote:
> > Yes, the concern is that the file could be changed or removed. We should
> > test what native does here but it probably means that we need to create a
> > stream
> > on the file with a sharing mode that denies writing.
>
On Tue, 2012-06-19 at 12:36 +0200, robert.van.h...@serioustoys.com wrote:
> I altered my local source tree, such that it opens the file exclusively as a
> stream. That seems to work.
>
> Having that fixed, at least provisionally, I am now facing another issue: my
> MSIs
> are most of the time ver
On Mon, 2012-06-18 at 14:14 +0200, robert.van.h...@serioustoys.com wrote:
> But then I was thinking: this seems like such an obvious thing to do, that it
> is
> almost suspicious. Was there any reason for copying the file contents to main
> memory and then create a memory stream?
>
> For instance
1 - 100 of 880 matches
Mail list logo
