On 4/10/2012 4:48 AM, Vitaliy Margolen wrote:
On 04/09/2012 12:14 PM, Kornél Pál wrote:
I think this would work. (But don't know whether it was accepted.)
No, it won't work. Wine itself (ntdll kernel32) accesses it.
In my opinion it still would work, just would not be optimal.
Note that I
On 4/9/2012 7:46 PM, Francois Gouget wrote:
On Thu, 22 Mar 2012, Kornél Pál wrote:
[...]
A bit better approach was to mark that page PAGE_GUARD. Then wine could get an
indication that it needs to be updated. Frequent accesses were not impacted
because PAGE_GUARD could be reset by an APC some
On 3/22/2012 2:19 PM, Vitaliy Margolen wrote:
BTW one more thing, this change will most likely break number of copy
protection systems. Such as safedisk. They use user shared date times to
estimate time it took for some kernel operations. And some of those time
intervals are really tight.
I'm
On 3/22/2012 6:00 AM, Dmitry Timoshkov wrote:
Joey Yandledra...@dancingdragon.be wrote:
It's been explained several times already that any approach to share data
between wineserver and clients is going to be rejected.
I think this is the reason that timers in shared_user_data are not being
On 3/22/2012 7:43 AM, Kornél Pál wrote:
On 3/22/2012 6:00 AM, Dmitry Timoshkov wrote:
Joey Yandledra...@dancingdragon.be wrote:
It's been explained several times already that any approach to share data
between wineserver and clients is going to be rejected.
I think this is the reason
On 3/21/2012 2:20 PM, Marcus Meissner wrote:
However, I do not know if we can have additional threads at all in a
Win32 process without confusing the win32 processes, or if this needs
to be solved differently (APC?).
If user_shared_data was written by wineserver and mapped read-only to
wine
On 3/21/2012 9:11 PM, Joey Yandle wrote:
If user_shared_data was written by wineserver and mapped read-only to
wine processes there was no need to create separate threads in wine
processes. As I know Windows is sharing this structure and is updating
it in kernel mode so wine behavior was
Hi,
Note that these changes were introduced in Windows Vista, so
applications that are being actively maintained should have no issues
with these changes.
Also note that on localized versions localized folder names link to the
English physical folder, so the folder structure is more
Alexandre Julliard wrote:
Remco remc...@gmail.com writes:
On Mon, Apr 6, 2009 at 2:52 AM, Chris Robinson
chris.k...@gmail.com wrote:
On Sunday 05 April 2009 5:35:36 pm Ben Klein wrote:
My suggestion is a drop-down box in the Advanced tab of Drives to
control filesystem type
Why not make
Remco wrote:
A while back there was some case where a buggy Windows program would
run in Wine, while it didn't run in any version of Windows. After Wine
became better, the buggy program stopped working. Of course it also
meant that a lot of other programs started working. At some point you
Hi,
Wine is still using Mono by creating a new process altough it has
support for _CorExeMain and _CorDllMain. There is a MonoFixupCorEE
method exported by mono.dll that could be used.
I also did some research on executing exe assemblies without creating a
mono.exe process on MS Windows by
Andrew Fenn wrote:
Actually I wanted to ask a question about this..
When implementing an API do we have to change the variable names from
those given in the msdn documentation?
More specifically, the typedefs for the xinput structs ( documentation
here:
Hi,
Paul Millar wrote:
As an aside: this looks to me like a logical fallacy. If I may rephrase your
argument:
1. Most signed software is from a large code-base (probably true)
2. Large code-bases are more likely to have vulnerabilities (probably true)
3. Therefore, signed software is
Hi,
IANAL, but the sources are for the kernel only. This does not include
the UI and other DLLs built on top of the kernel. If we know what DLLs
the sources correspond to, shouldn't the students be restricted to not
contributing to those DLLs only (just like if you use Visual Studio
you
Hi,
Laurent Vromman wrote:
You often use the word Mauvais as a translation for Bad. Sometimes,
it could be better not to translate literally. For example, I think
Niveau de pilote incorrect is a better translation for Bad driver
level than Mauvais niveau de pilote. You should try to avoid
Hi,
I have spent some time to investigate the mixed-mode msvcrt issue.
There are three different runtime DLLs:
msvcm80/90.dll managed C++ runtime implemented using native code
msvcp80/90.dll C++ runtime
msvcr80/90.dll C runtime
The managed version does only have it's own functionaly while even
From: Juan Lang
The main contributors that have not done so that I saw after a quick
perusal were Alexandre and Rob Shearman. If you can't get their
permission, you'd have to start with the last MIT/X11 licensed
version, or get Transgaming's most recent ReWind version and start
from there.
Hi,
From: Dan Kegel
But Wine has its own increasingly useful implementation of msvcrt,
at least the part that uses the C api. (The C++ api is difficult for us
because it has to be written in C; g++ uses a different ABI than Microsoft
C++.)
Perhaps, once we work the kinks out, Mono can
From: Dan Kegel
Also note that Mono's Class Library is licensed under MIT/X11 because
inlining (done by the runtime) may be incompatible with GPL that would
not
allow non-GPL programs to be executed within Mono. Would it be possible
to
have a MIT/X11 licensed msvcrt?
That's an
From: Steven Edwards
So the question is: If the current authors permit to make msvcrt MIX/X11
licensed would it be possible to make Wine's msvcrt MIT/X11 licensed for
future releases as well (no legal question but philosophical)?
You will need to review the git history and contact anyone
Hi,
I am working on it but seems to be a longer process because MSVCRT depends
on a lot of undocumented characteristics of the MS implementation of .NET
Framework and documented functionality that is not used outside of C++ (so
isn't implementet by Mono).
If you know real world applications
Hi,
I have recently committed required changes to Mono SVN repository as
r102052.
Now Mono has mixed-mode assembly support on Windows. These is no full MSVCRT
support because that heavily depends on the unmanaged API of .NET Framework
but programs compiled using Microsoft Visual C++ and not
From: Dan Kegel
I have recently committed required changes to Mono SVN repository as
r102052.
Now Mono has mixed-mode assembly support on Windows.
Wow, congratulations! When will a windows installer be available
for a version of mono with your changes included? It would make
testing
Hi,
I am almost complete with implementing mixed-mode support for Mono only some
code cleanup is remaining. Note that however this still will not support
MSVCRT becuase that assumes that is running on .NET Framework. Also note
that applications using unmanaged API (COM interfaces and DLL
Hi,
From: Hin-Tak Leung [EMAIL PROTECTED]
I can't comment on anything else, but after trying to get a .NET WinForms
application
(mentioned in some of the bugs I filed) for a few months under the 3
options of
native linux mono, wine+.NET and wine+mono, I can say that win32 mono uses
The only major difference I know is that Mono uses UTF-8 instead of ACP
for
ANSI functions.
UTF-8 will break most of Windows applications since they don't expect to
see
strings in a multibyte encoding.
I know that. And the problem is that there is a mess of ACP and UTF-8 inside
native
Hi,
1) support for mixed assemblies in Mono for Windows
I'm trying to do some work on that.
2) porting Mono's WinForms on top of Wine gdiplus
instead of Mono gdiplus (and making it more win32-ish as
a result)
Mono is using MS GDI+ on Windows since it uses GDI+. Mono's libgdiplus is
only
slc.dll is part of Windows Vista, and seems to be responsible for
activation, key validation, maybe genuine validation and probably trial time
limit.
I don't think that this is required by Wine unless the DLL has some
publically documented API.
Kornél
- Original Message -
From:
Hi,
If you mean passing an IStream interface to DOMDocument.save method:
As far as I know save method is synchronous (if I'm wrong you still can set
the async property to FALSE). So when the save method returns you know that
the entire document has been passed to the IStream.
If you want to do
PROTECTED]
To: Kornél Pál [EMAIL PROTECTED]
Sent: Monday, February 11, 2008 12:58 PM
Subject: Re: IStream interface for domdoc and terminate call
Hi
I mean using call IStream_write like it is describe in bug #4811.
Kornél Pál napsal(a):
Hi,
If you mean passing an IStream interface
of disposing the
interface so that call may have effect on the object as well.
Kornél
- Original Message -
From: Kornél Pál [EMAIL PROTECTED]
To: Josef Reidinger [EMAIL PROTECTED]; wine-devel@winehq.org
Sent: Monday, February 11, 2008 1:15 PM
Subject: Re: IStream interface for domdoc and terminate
Hi,
I think GetSystemInfo should return x86 even on x64 when running 32-bit
applications just like a 32-bit Windows or WOW64 does. But
GetNativeSystemInfo could return the actual 64-bit CPU altough I'm not sure
that it makes any sense without WOW64.
Kornél
- Original Message -
From:
Hi,
I tried to run Mono 1.2.5.1 on Wine but it dies with the Weird VirtualQuery
result error message. Are there any know bugs of Wine or Mono that prevent
it from running?
I would like to make Mono run on Wine and I am willing to contribute patches
to Wine and Mono as well to achieve that.
33 matches
Mail list logo
