http://bugs.winehq.org/show_bug.cgi?id=31037
Bug #: 31037
Summary: Microsoft SQL Server 2005 Express Edition: SQL Server
System Configuration Checker fails (Win32_Processor
class table row count not set)
Product: Wine
Version: 1.5.7
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: wmi&wbemprox
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Classification: Unclassified
Hello,
continuation of bug 30089
The app crashes while trying to retrieve "CpuStatus" property of
"Win32_Processor" class.
--- snip ---
Creating class instance Win32_Processor
CreateInstanceEnum Win32_Processor returned 0 (0x0)
Enumerating the first class of Win32_Processor
EnumClass of Win32_Processor returned 1 (0x1)
Getting property CpuStatus
<boom>
--- snip ---
"CpuStatus" property was implemented by commit
http://source.winehq.org/git/wine.git/commitdiff/661d7f19c98b72af18c9487a87…
Code:
http://source.winehq.org/git/wine.git/blob/661d7f19c98b72af18c9487a87fd5a5f…
--- snip ---
361 static void fill_processor( struct table *table )
362 {
363 static const WCHAR fmtW[] = {'C','P','U','%','u',0};
364 WCHAR device_id[14];
365 struct record_processor *rec;
366 UINT i, offset = 0, count = get_processor_count();
367
368 if (!(table->data = heap_alloc( sizeof(*rec) * count ))) return;
369
370 for (i = 0; i < count; i++)
371 {
372 rec = (struct record_processor *)(table->data + offset);
373 rec->cpu_status = 1; /* CPU Enabled */
374 rec->manufacturer = processor_manufacturerW;
375 sprintfW( device_id, fmtW, i );
376 rec->device_id = heap_strdupW( device_id );
377 offset += sizeof(*rec);
378 }
379 }
--- snip ---
The table row count (number of processor items) is not set hence class object
iterator (next) will fail later, leading to crash.
With row count fixed, the crash is gone and the app encounters next WMI
insufficiency ;-)
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=31981
Bug #: 31981
Summary: Microsoft SQL Server 2005 Express Edition: SQL Server
System Configuration Checker fails
Product: Wine
Version: 1.5.15
Platform: x86
URL: http://go.microsoft.com/fwlink/?linkid=65212
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: djelinski1(a)gmail.com
Classification: Unclassified
Created attachment 42142
--> http://bugs.winehq.org/attachment.cgi?id=42142
+wbemprox log of sql server installer
Continuation from bug 31522:
With implemented StdRegProv.GetStringValue installer no longer complains about
WMI/Wbem insufficiencies. Unfortunately, it still fails.
One of the final meaningful lines in +wbemprox log is:
trace:wbemprox:enum_values 0x80000002,
L"SYSTEM\\CurrentControlSet\\Services\\lanmanserver"
This key does not exist in Wine, and its absence is probably the direct reason
of installer failure.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=30707
Bug #: 30707
Summary: Add support for .NET 4.0 assembly cache (.NET 4.0
Framework installer)
Product: Wine
Version: 1.5.4
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: msi
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Classification: Unclassified
Hello,
this is a bug covering Hans' patch http://source.winehq.org/patches/data/86357
'winetricks dotnet40' recipe currently contains 'gacutil' workaround/hack for
installing assemblies into .NET 4.0 GAC.
.NET's native fusion currently fails due to junction support (bug 10601) hence
all assemblies must be manually installed using 'gacutil' as post-installation
step.
Using Hans' patch and setting 'fusion=builtin' before running the .NET 4.0
installer gets .NET 4.0 assemblies installed into GAC.
The installer actually succeeds which is an improvement over the current
"workaround" recipe.
There is a difference though.
With Hans' patch all .NET 4.0 assemblies get installed into:
--- snip ---
$ pwd
/home/focht/.wine/drive_c/windows/assembly
...
$ ls */*
GAC_32/CustomMarshalers:
4.0.0.0__b03f5f7f11d50a3a
GAC_32/ISymWrapper:
4.0.0.0__b03f5f7f11d50a3a
GAC_32/Microsoft.Transactions.Bridge.Dtc:
4.0.0.0__b03f5f7f11d50a3a
GAC_32/Microsoft.VisualBasic.Activities.Compiler:
10.0.0.0__b03f5f7f11d50a3a
...
GAC_32/System.Web:
4.0.0.0__b03f5f7f11d50a3a
GAC_MSIL/Accessibility:
4.0.0.0__b03f5f7f11d50a3a
GAC_MSIL/AspNetMMCExt:
4.0.0.0__b03f5f7f11d50a3a
GAC_MSIL/Microsoft.Build:
4.0.0.0__b03f5f7f11d50a3a
...
--- snip ---
Starting with .NET 4.0 there exist two global assembly caches - the "public"
one and a "private" one for the Framework.
In previous versions, all .NET assemblies were installed into
"C:\\windows\\assembly".
With .NET 4.0 the assemblies are further split.
The "private" GAC for 4.0 is located in "c:\\windows\\Microsoft.NET\\assembly".
See: http://msdn.microsoft.com/en-us/magazine/dd727509.aspx
("Understanding The CLR Binder")
--- quote ---
In .NET Framework 4.0, the GAC went through a few changes. The concept of
placing assemblies into a global directory began in CLR v1.1. In case of .NET
Framework 1.1 (which had CLR v1.1) and .NET Framework 2.0 (which had CLR 2.0),
the GAC was split into two, one for each CLR. This avoided the leaking of
assemblies across CLR versions. For example, if both .NET 1.1 and .NET 2.0
shared the same GAC, then a .NET 1.1 application, loading an assembly from this
shared GAC, could get .NET 2.0 assemblies, thereby breaking the .NET 1.1
application.
The CLR version used for both .NET Framework 2.0 and .NET Framework 3.5 is CLR
2.0. As a result of this, there was no need in the previous two framework
releases to split the GAC. The problem of breaking older (in this case, .NET
2.0) applications resurfaces in Net Framework 4.0 at which point CLR 4.0
released. Hence, to avoid interference issues between CLR 2.0 and CLR 4.0, the
GAC is now split into private GACs for each runtime.
Tools such as GACUtil and Shfusion will behave exactly the same as they did in
pre–.NET Framework 4.0 scenarios. Also, the behavior of publisher policy
(explicitly mentioned, since it is required to install these policy files to
the GAC) will not change. The main change is that CLR v2.0 applications now
cannot see CLR v4.0 assemblies in the GAC.
...
--- quote ---
With the current 'winetricks dotnet40' recipe and help of .NET 4.0 'gacutil'
the assemblies live in "private" GAC:
--- snip ---
$ pwd
/home/focht/.wine/drive_c/windows/Microsoft.NET/assembly
...
$ ls */*
GAC_MSIL/UIAutomationProvider:
v4.0_4.0.0.0__31bf3856ad364e35
GAC_MSIL/UIAutomationTypes:
v4.0_4.0.0.0__31bf3856ad364e35
GAC_MSIL/WindowsBase:
v4.0_4.0.0.0__31bf3856ad364e35
GAC_MSIL/WindowsFormsIntegration:
v4.0_4.0.0.0__31bf3856ad364e35
--- snip ---
"public" GAC with no previous .NET versions installed:
--- snip ---
$ ls assembly/
PublisherPolicy.tme pubpol1.dat temp tmp
--- snip ---
There are some problems when 'fusion' remains set to 'builtin' after
installation though that will be subject to other bugs.
If the .NET 4.0 'private' GAC location is fixed one can safely remove
'fusion=builtin' workaround after running the installer and have a functional
.NET Framework installation running with native mscoree/fusion.
This allows to get rid of 'gacutil' hack.
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27659
Summary: Microsoft .NET 4 disk space blocker
Product: Wine
Version: unspecified
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: blocker
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: Riskexas(a)gmail.com
So i have problems with microsoft .NET 4 - First time i installed it it worked
fine but i had to renew my wine to play Terraria(from 1.3.15 to 1.3.23). So i
did it and now trying to instal .NET 4 it shows that there is not enough disk
space:
Drive c: Required - 64u MB, Available - 64u MB
This blocks my installation.
NOTE:No, mono doesn't work!
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=31128
Bug #: 31128
Summary: Microsoft.Build tool from .NET Framework 4.x requires
kernel32.dll GetDynamicTimeZoneInformation
Product: Wine
Version: 1.5.8
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: kernel32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Classification: Unclassified
Hello,
trying to compile a simple .NET 4.x solution with MSBuild tool results in:
--- snip ---
$ wine "c:\\windows\\Microsoft.NET\\Framework\\v4.0.30319\\MsBuild.exe"
CompressionDemo.sln
...
MSBUILD : error MSB4017: The build stopped unexpectedly because of an
unexpected logger failure.
Microsoft.Build.Exceptions.InternalLoggerException: The build stopped
unexpectedly because of an unexpected logger failure. --->
System.EntryPointNotFoundException: Unable to find an entry point named
'GetDynamicTimeZoneInformation' in DLL 'kernel32.dll'.
at
Microsoft.Win32.UnsafeNativeMethods.GetDynamicTimeZoneInformation(DynamicTimeZoneInformation&
lpDynamicTimeZoneInformation)
at System.TimeZoneInfo.GetLocalTimeZone(CachedData cachedData)
at System.TimeZoneInfo.CachedData.CreateLocal()
at System.DateTime.ToLocalTime(Boolean throwOnOverflow)
at Microsoft.Build.Framework.BuildEventArgs.get_Timestamp()
at
Microsoft.Build.BackEnd.Logging.ParallelConsoleLogger.BuildStartedHandler(Object
sender, BuildStartedEventArgs e)
at
Microsoft.Build.Evaluation.ProjectCollection.ReusableLogger.BuildStartedHandler(Object
sender, BuildStartedEventArgs e)
at
Microsoft.Build.BackEnd.Logging.EventSourceSink.RaiseBuildStartedEvent(Object
sender, BuildStartedEventArgs buildEvent)
--- snip ---
Prequisite: 'winetricks -q dotnet40' and .NET Framework 4.5 (RC) install, see
appdb
Example project:
http://www.codeproject.com/Articles/381661/Creating-Zip-Files-Easily-in-NET…
("Creating Zip Files Easily in .NET 4.5")
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=30635
Bug #: 30635
Summary: .NET 3.x/4.x WPF based installers/apps require
windowscodecs.dll.IWICStream_InitializeFromMemory_Prox
y
Product: Wine
Version: 1.5.3
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: windowscodecs
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Classification: Unclassified
Hello,
continuation of bug 20220.
--- snip ---
wine: Call from 0x7b8393ff to unimplemented function
windowscodecs.dll.IWICStream_InitializeFromMemory_Proxy, aborting
...
Unhandled Exception: System.Reflection.TargetInvocationException: Exception has
been thrown by the target of an invocation. --->
System.Runtime.InteropServices.SEHException: External component has thrown an
exception.
at
MS.Win32.PresentationCore.UnsafeNativeMethods.WICStream.InitializeFromMemory(IntPtr
pIWICStream, IntPtr pbBuffer, UInt32 cbSize)
at System.Windows.Media.StreamAsIStream.IStreamFrom(IntPtr memoryBuffer,
Int32 bufferSize)
at System.Windows.Media.Imaging.BitmapDecoder.GetIStreamFromStream(Stream&
bitmapStream)
at
System.Windows.Media.Imaging.BitmapDecoder.SetupDecoderFromUriOrStream(Uri uri,
Stream stream, BitmapCacheOption cacheOption, Guid& clsId, Boolean&
isOriginalWritable, Stream& uriStream, UnmanagedMemoryStream&
unmanagedMemoryStream, SafeFileHandle& safeFilehandle)
at System.Windows.Media.Imaging.BitmapDecoder.CreateFromUriOrStream(Uri
baseUri, Uri uri, Stream stream, BitmapCreateOptions createOptions,
BitmapCacheOption cacheOption, Boolean insertInDecoderCache)
at System.Windows.Media.Imaging.BitmapFrame.CreateFromUriOrStream(Uri
baseUri, Uri uri, Stream stream, BitmapCreateOptions createOptions,
BitmapCacheOption cacheOption)
at
System.Windows.Media.ImageSourceConverter.ConvertFrom(ITypeDescriptorContext
context, CultureInfo culture, Object value)
at
System.ComponentModel.TypeConverter.ConvertFromString(ITypeDescriptorContext
context, CultureInfo culture, String text)
at System.Windows.Markup.XamlTypeMapper.ParseProperty(Object targetObject,
Type propType, String propName, Object dpOrPiOrFi, ITypeDescriptorContext
typeContext, ParserContext parserContext, String value, Int16 converterTypeId)
...
--- snip ---
$ wine --version
wine-1.5.3-243-g9c0486d
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20220
Summary: AutoCAD 2009: unimplemented function
windowscodecs.dll.WICCreateImagingFactory_Proxy
Product: Wine
Version: 1.1.30
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: lukasz.wojnilowicz(a)gmail.com
Created an attachment (id=23845)
--> (http://bugs.winehq.org/attachment.cgi?id=23845)
backtrace with built-in windowscodecs.dll
I'm using wine-1.1.30-115-gf8ec47d on Fedora 11 32 bit.
Steps to reproduce:
1) start AutoCAD 2009
2) draw a line
3) select a line
4) get Unhandeled exception window from bug #20214
5) unselect line
6) hold left ctrl and select line
Application crashes and closes without error message. If I use native
windowscodecs.dll (699.5 KB) I get neither crash nor application closes.
I did so as Vincent Povirk advised me in bug #20214 so I went to this website
and did all what was written there
http://wiki.winehq.org/Backtraces
built-in windowscodecs.dll
backtrace in attachment
native windowscodecs.dll
no backtrace, no crash
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.