Hi folks,
I know people are concerned right now with more important
matters, but given that (1) we're cleaning up the tree, and
(2) we're getting close to 0.9, I figured it maybe time to
bring this up. Namely, under dlls/ we have by and large a
flat structure, with the exception of a few 'special
On December 10, 2003 10:39 pm, Tom wrote:
> I've kept a check on our status and we have been there #1 download and
> we have never dropped below the #1 spot in the last six months..
Nice. And we are now #39 @ SF, which is not bad, but we've done better :)
Truth be told, we don't release nearly as
Hi,
I sent this mail :
http://www.winehq.org/hypermail/wine-devel/2003/06/0581.html
to wine-devel almost six months ago about wine being the #1 download at
rpmseek.
I've kept a check on our status and we have been there #1 download and
we have never
dropped below the #1 spot in the last six mon
Found the problem.
launch_entry is using SEE_MASK_IDLIST, which isnt handled by
ShellExecuteExA32 now.
The optional shell namespace mode should be disabled by a
"#define _NO_EXTENSIONS", but I didnt manage to use it.
Martin, could you bring us some light ?
http://www.winehq.com/hypermail/wine-patc
Thanks Rolf (and Uwe).
I did some further investigation and it looks like CreateFile (actually
CreateFileW) looks at the filename and if it starts with "\\.\" it
calls DEVICE_Open(). DEVICE_Open() compares the file name (without the
"\\.\" ) against all the entries in VxDList[] and if there is
On Wed, Dec 10, 2003 at 07:36:45PM +, Mike Hearn wrote:
> On Wed, 2003-12-10 at 08:10, Jody Goldberg wrote:
> > Hello, I maintain Gnumeric and have run into a problems when writing
> > xls files larger than 13-14 meg. MS excel can read them, but
> > promptly corrupts them. I had hoped this wa
On Wednesday 10 December 2003 04:30 pm, Alexandre Julliard wrote:
> "Gregory M. Turner" <[EMAIL PROTECTED]> writes:
> > actually, AFAICS it's just looking at "wine"... where is a good place to
> > verify this (with a trace)? Perhaps this is the whole problem? I am not
> > mentally up-to-date on t
"Gregory M. Turner" <[EMAIL PROTECTED]> writes:
> actually, AFAICS it's just looking at "wine"... where is a good place to
> verify this (with a trace)? Perhaps this is the whole problem? I am not
> mentally up-to-date on the latest with wine-{k,p}thread, the wrapper, etc...
> maybe it's time
On Wed, 2003-12-10 at 21:07, Steven Edwards wrote:
> Someone submitted source/binarys for a repleacement stdole32.tlb a year
> or so ago but I think it required MS_VC to build.
Yes, we have the IDL (mostly) but Alexandre won't accept binaries into
CVS, we need to be able to translate the IDL into
On Wednesday 10 December 2003 01:52 pm, Eric Pouech wrote:
> > Indeed. Looking at the loop in DEBUG_ReadExecutableDbgInfo, the values
> > of dyn.d_tag it iterates through look nothing like the output of "readelf
> > -d wine" (they should, right?)
>
> yup
> The numbers it shows me (after adding a t
--- Mike Hearn <[EMAIL PROTECTED]> wrote:
> On Wed, 2003-12-10 at 19:25, Boaz Harrosh wrote:
> > What is the situation on Wine. can widl or any other tool produce a
>
> > proper .TLB structure?
>
> No, not as far as I know :( We really need this, for many years now
> Wine
> has been shipping OLE
On Wed, 2003-12-10 at 19:25, Boaz Harrosh wrote:
> What is the situation on Wine. can widl or any other tool produce a
> proper .TLB structure?
No, not as far as I know :( We really need this, for many years now Wine
has been shipping OLE that is nearly non-functional for some important
tasks bec
On Wed, 10 Dec 2003 11:33:04 -0800, you wrote:
> Yep, it's all my fault. This should fix it:
Confirmed, thanks.
Rein.
--
Rein Klazes
[EMAIL PROTECTED]
Indeed. Looking at the loop in DEBUG_ReadExecutableDbgInfo, the values of
dyn.d_tag it iterates through look nothing like the output of "readelf -d
wine" (they should, right?)
yup
The numbers it shows me (after adding a trace)
don't even map to the DT_ constants I see in elf.h at all... (agai
Sylvain Petreolle wrote:
Couldnt we stop to maintain the 0.9 part since 1.0 is almost out ?
no, because it's not because 1.0 is out that all installed boxen on
earth with 0.9 will instantaneously be upgraded to 1.0.
We should at least drop the 0.5 part since its no longer supported by
the ALSA de
Sylvain Petreolle <[EMAIL PROTECTED]> writes:
> Couldnt we stop to maintain the 0.9 part since 1.0 is almost out ?
No, most people are still using 0.9.
> We should at least drop the 0.5 part since its no longer supported by
> the ALSA developpers.
That doesn't mean no one is using it.
--
Alex
On Wed, 2003-12-10 at 08:10, Jody Goldberg wrote:
> Hello, I maintain Gnumeric and have run into a problems when writing
> xls files larger than 13-14 meg. MS excel can read them, but
> promptly corrupts them. I had hoped this was a windows bug, but
> just in case I installed an older copy of cro
Rein Klazes <[EMAIL PROTECTED]> writes:
> I did not look at it myself, but maybe this is enough for a clue?
Yep, it's all my fault. This should fix it:
Index: windows/win.c
===
RCS file: /opt/cvs-commit/wine/windows/win.c,v
retrievi
Was it someone (from ROS) that said they had an "Internet explorer"
replacement written in C++ ?
Was that a shell-folder explorer or an iexplorer type of application.
Can it be made to support "Internet Explorer" controls.
(the "Shell.Explorer"/IWebBrowser2 one, that can be placed in user
applic
Ove Kaaven wrote:
Consider that the reason could be that C++ has too many interoperability
problems to solve any within an interoperability project like Wine. Just
try to compile something like MFC with g++ and see how well the result
would run MSVC++-compiled programs.
I don't think anyone was
Message: 2
Date: Tue, 9 Dec 2003 14:56:16 -0800
Subject: Adding support for a USB device
From: Dan Timis <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Hi,
>I need help with supporting a particular USB device under wine. I have
>to start by saying that although I am an experienced C/C++ programmer
To be honest, if you follow my previous posts, I DID write some C++.
Albeit, that was not reallt necessary ... ;)
Anyways, I will submit a pure C and a C++ version of future patches, sch that both
work under the current WINE.
After that, it will be upto Sir Julliard...
Season's Greetings
Subh
Sylvain Petreolle wrote:
I was about to write to the list for the same problem.
Winefile doesnt crash here, but hangs, trying to execute very strange
file names which dont seem to have any relation to the original
application or document.
However, File|Execute is still working.
This can be a start
ons, 10.12.2003 kl. 08.24 skrev Shachar Shemesh:
> Alexandre Julliard wrote:
>
> >"Subhobroto Sinha" <[EMAIL PROTECTED]> writes:
> >
> >>However, soon many of his elves found out that technologies like
> >>MFC, WTL, ATL, COM, DCOM, COM+ and other MS bloops were getting too
> >>complex to be imple
> "Dan" == Dan Kegel <[EMAIL PROTECTED]> writes:
Dan> Uwe Bonnes wrote:
>>> "Dan" == Dan Kegel <[EMAIL PROTECTED]> writes:
Dan> This is on RH9 SMP with wine-20031118. Trying to run the MS SFU
Dan> 3.0 (hey, I got it for $5 from that special offer they ran on
Dan> slash
Uwe Bonnes wrote:
"Dan" == Dan Kegel <[EMAIL PROTECTED]> writes:
Dan> This is on RH9 SMP with wine-20031118. Trying to run the MS SFU
Dan> 3.0 (hey, I got it for $5 from that special offer they ran on
Dan> slashdot a couple weeks ago...) setup.exe from the commandline
Dan> yields t
On Wed, 2003-12-10 at 00:12, Andrew de Quincey wrote:
> Yeah, I've played with it under windows... an ITypeInfo is supposed to
> AddRef() the ITypeLib ONCE when its retrieved using things like
> ITypeLib.FindName(). (when you release it, you do it just once as well, when
> the original refcount
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
Hello, I maintain Gnumeric and have run into a problems when writing
xls files larger than 13-14 meg. MS excel can read them, but
promptly corrupts them. I had hoped this was a windows bug, but
just in case I installed an older copy of cross over office with
office 2k. That combination produced
Couldnt we stop to maintain the 0.9 part since 1.0 is almost out ?
We should at least drop the 0.5 part since its no longer supported by
the ALSA developpers.
> Well, I'm not sure that's really necessary at this point. The 0.9
> code
> builds just fine, and IMO we can simply wait until supporting
I was about to write to the list for the same problem.
Winefile doesnt crash here, but hangs, trying to execute very strange
file names which dont seem to have any relation to the original
application or document.
However, File|Execute is still working.
This can be a start to understand what is ha
>I am really sorry for making multiple posts - I got the Rediffmail mailer's
>verification after 20 minutes (normally Yahoo!'s mailservers notify almost
>instantaneously..), but before I could realize it, my 4 messages had already been
>mailed out of the queue...
>
>This was the first time I wa
On Wednesday 10 December 2003 07:50, Dan Kegel wrote:
> Trying to launch any app, e.g. wine's notepad, by double-clicking on
> the .exe in 'winefile' crashes wine, like this:
>
> 0x42079c30 (NTDLL.DLL.strcpy+0x20): movzbl 0x0(%edx),%eax
> Wine-dbg>bt
> Backtrace:
> =>0 0x42079c30 (NTDLL.DLL.st
Hi,
winfile (from a win98 installation) that I use to track problems with 16
bit file dialog fails today:
| 0030:Call USER.452: CREATEWINDOWEX(,129701a8 "WFS_Frame",12970efa "File
Manager",02cf,0029,0046,03c0,02c0,,,1296,) ret=1277:164f ds=1297
| 0030:Call kernel32.Gl
On Wed, 2003-12-10 at 07:50, Dan Kegel wrote:
> Trying to launch any app, e.g. wine's notepad, by double-clicking on
> the .exe in 'winefile' crashes wine, like this:
Strange. It works fine here. Really though we need this debugger
breakage fixed, these debuginfo-less backtraces are a pain
On Wed, 2003-12-10 at 08:06, Marcus Meissner wrote:
> Read what Alexandre wrote. To paraphrase:
>
> "Feel free to write it in C++ and submit it when you are done."
ie I guess there is no rule, it's just a matter of using it when
appropriate (and of course Alexandre must agree that it is appropria
> "Dan" == Dan Kegel <[EMAIL PROTECTED]> writes:
Dan> This is on RH9 SMP with wine-20031118. Trying to run the MS SFU
Dan> 3.0 (hey, I got it for $5 from that special offer they ran on
Dan> slashdot a couple weeks ago...) setup.exe from the commandline
Dan> yields the crash:
This is on RH9 SMP with wine-20031118.
Trying to run the MS SFU 3.0 (hey, I got it for $5 from that
special offer they ran on slashdot a couple weeks ago...) setup.exe
from the commandline yields the crash:
Unhandled exception: page fault on read access to 0x0049002e in 32-bit code
(0x400b73fd).
See if I understand what you need:
- vendor.dll (windows binary only)
- myapp.exe.so (winelib application that uses vendor.dll API and
compiles against "vendor" header files )
Check that you have done the following
1) wrote a vendor.dll.spec (spec syntax for all functions used from
"vendor" head
On Wed, Dec 10, 2003 at 09:24:26AM +0200, Shachar Shemesh wrote:
> Alexandre Julliard wrote:
>
> >"Subhobroto Sinha" <[EMAIL PROTECTED]> writes:
> >
> >
> >
> >>However, soon many of his elves found out that technologies like
> >>MFC, WTL, ATL, COM, DCOM, COM+ and other MS bloops were getting to
Trying to launch any app, e.g. wine's notepad, by double-clicking on
the .exe in 'winefile' crashes wine, like this:
0x42079c30 (NTDLL.DLL.strcpy+0x20): movzbl 0x0(%edx),%eax
Wine-dbg>bt
Backtrace:
=>0 0x42079c30 (NTDLL.DLL.strcpy+0x20) (ebp=4072ed8c)
1 0x40778fd4 (SHELL32.DLL.FindExecutable
Alexandre Julliard wrote:
"Subhobroto Sinha" <[EMAIL PROTECTED]> writes:
However, soon many of his elves found out that technologies like
MFC, WTL, ATL, COM, DCOM, COM+ and other MS bloops were getting too
complex to be implemented using plain C, and thus developments in
those areas were soon
42 matches
Mail list logo
