<Swing Dev> swing-dev Digest, Vol 130, Issue 13
Prasanta Sadhukhan
prasanta.sadhukhan at oracle.com
Fri Feb 9 09:23:01 UTC 2018
Hi Reinhard,
Yes, I was running as a Administrator. But, I created another Standard
user and login through that but I still get the same problem.
Regards
Prasanta
On 2/9/2018 12:09 PM, Reinhard Pointner wrote:
> Dear Prasanta,
>
> The ant script calls the Add-AppxPackage function and fails with this
> error message:
> "Add-AppxPackage : Deployment failed with HRESULT: 0x80070005, Access
> is denied."
>
> Are you running CMD / PowerShell as Administrator? I search for this
> error message on Google, and I found a few results were running as
> normal user (and not as Administrator) solved the issue. I've tried
> again myself as well, and I can easily reproduce the issue on a newly
> factory reset Windows 10 machine with the latest updates running the
> build via CMD as my normal user.
>
> Greetings,
> Reinhard
>
> On 9 February 2018 at 12:58, <swing-dev-request at openjdk.java.net
> <mailto:swing-dev-request at openjdk.java.net>> wrote:
>
> Send swing-dev mailing list submissions to
> swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.openjdk.java.net/mailman/listinfo/swing-dev
> <http://mail.openjdk.java.net/mailman/listinfo/swing-dev>
> or, via email, send a message with subject or body 'help' to
> swing-dev-request at openjdk.java.net
> <mailto:swing-dev-request at openjdk.java.net>
>
> You can reach the person managing the list at
> swing-dev-owner at openjdk.java.net
> <mailto:swing-dev-owner at openjdk.java.net>
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of swing-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: JDK-8189938: Proposed patch (Semyon Sadetsky)
> 2. Re: JDK-8189938: Proposed patch (Matthias Bl?sing)
> 3. Re: JDK-8189938: Proposed patch (Sergey Bylokhov)
> 4. Re: JDK-8189938: Proposed patch (Semyon Sadetsky)
> 5. Re: JDK-8189938: Proposed patch (Prasanta Sadhukhan)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 8 Feb 2018 12:06:04 -0800
> From: Semyon Sadetsky <semyon.sadetsky at oracle.com
> <mailto:semyon.sadetsky at oracle.com>>
> To: Matthias Bl?sing <mblaesing at doppel-helix.eu
> <mailto:mblaesing at doppel-helix.eu>>,
> swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
> Subject: Re: <Swing Dev> JDK-8189938: Proposed patch
> Message-ID: <31b2fba0-07dc-3a21-9aab-c19c980df142 at oracle.com
> <mailto:31b2fba0-07dc-3a21-9aab-c19c980df142 at oracle.com>>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Yet another question. Do you know what might call CoInitialize in a
> different mode? It looks like we use STA everywhere in JDK.
>
> --Semyon
>
>
> On 02/08/2018 11:55 AM, Semyon Sadetsky wrote:
> > I meant the case when MTA COM service is actually used, it might
> cause
> > issues since the JDK code invokes an another API which assumes
> > synchronization. At least performance may be affected.
> >
> > We don't do separate testing of JDK in MTA mode especially on the
> > regular base. That is why I wouldn't consider MTA mode as supported.
> >
> > So, before push the change I would make sure of the regression test
> > suite run in MTA mode hasn't brought any surprises.
> >
> > --Semyon
> >
> > On 02/08/2018 11:18 AM, Matthias Bl?sing wrote:
> >
> >> Resend: I accidentally dropped swing-dev from receivers
> (@Semyon I'm
> >> subscribed to swing-dev, so we could direct the mails to the
> >> mailinglist)
> >>
> >>
> >> Hey Semyon,
> >>
> >> Am Donnerstag, den 08.02.2018, 10:52 -0800 schrieb Semyon Sadetsky:
> >>> Since you are suggesting to switch from STA to MTA which
> >>> consequences
> >>> will it have to the current JDK code that was written to
> support STA
> >>> only?
> >> I think there are two questions hidden here:
> >>
> >> === How does this affect the common codepath taken today? ===
> >>
> >> It does not. It only changes the behaviour if CoInitalize fails. So
> >> behavioural changes can only occur in environments that did not
> work
> >> previously.
> >>
> >> Before this changeset:
> >>
> >> ? * CoInitialize works => The ShellFolder code can be used as is
> >> ? * CoInitialize failes => The ShellFolder code raises an exception
> >>
> >> After this changeset:
> >>
> >> ? * CoInitialize works => The ShellFolder code can be used as is
> >> ? * CoInitialize failes => retry CoInitializeEx with multi-threaded
> >> ??? apartment
> >> ? * if CoInitializeEx fails for multi-threaded apartment raise
> exception
> >> ??? as before
> >>
> >> === Is it expected to cause problems in the new code path? ====
> >>
> >> My understanding of STA vs. MTA is, that it only affects calls from
> >> native to java and not the other way round.
> >>
> >> To get calls from outside you'd need to install a callback. My
> >> understanding is, that you'd need to use an IConnectionPoint
> and call
> >> its Advise method. I did not spot any such methods.
> >>
> >> So while I did not go through the whole code base, I think this
> >> changeset should be save.
> >>
> >> Greetings
> >>
> >> Matthias
> >>
> >>> On 02/08/2018 10:32 AM, Matthias Bl?sing wrote:
> >>>> referring to this bug:
> >>>>
> >>>> https://bugs.openjdk.java.net/browse/JDK-8189938
> <https://bugs.openjdk.java.net/browse/JDK-8189938>
> >>>>
> >>>> With the instructions given in:
> >>>>
> >>>> https://bugs.openjdk.java.net/browse/JDK-8193928
> <https://bugs.openjdk.java.net/browse/JDK-8193928> (closed as
> >>>> duplicate of JDK-8189938)
> >>>>
> >>>> I was able to reproduce the problem on a clean Windows 10
> >>>> Installation,
> >>>> as described in the initial report.
> >>>>
> >>>> The resulting exception leads to my proposed fix:
> >>>>
> >>>> ????????? Could not initialize COM: HRESULT=0x80010106
> >>>>
> >>>> That HRESULT translates to: RPC_E_CHANGED_MODE
> >>>>
> >>>> This means, that the COM subsystem is already initialized,
> but with
> >>>> a
> >>>> different mode. The code uses CoInitialize and this
> initializes the
> >>>> threading module to be apartment threaded. The above HRESULT
> means
> >>>> the
> >>>> thread was already initialized to be multi-threaded.
> >>>>
> >>>> The mode can't be changed after is was set once, so instead of
> >>>> bailing
> >>>> out, I suggest to accept the situation and initialize to be
> multi-
> >>>> threaded.
> >>>>
> >>>> The consequence is that calls from COM to Java could end up
> on the
> >>>> wrong thread. A quick look through the code suggest, that COM
> >>>> advises
> >>>> are not used, so this is a risk that should be taken.
> >>>>
> >>>> The fix in this case works like this:
> >>>>
> >>>> ?? * try to initialize COM as it was
> >>>> ?? * check the return
> >>>> ?? * if it is RPC_E_CHANGED_MODE, retry initialization als multi-
> >>>> threaded
> >>>> ?? * only if that fails raise an exception
> >
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 08 Feb 2018 22:19:51 +0100
> From: Matthias Bl?sing <mblaesing at doppel-helix.eu
> <mailto:mblaesing at doppel-helix.eu>>
> To: Semyon Sadetsky <semyon.sadetsky at oracle.com
> <mailto:semyon.sadetsky at oracle.com>>,
> swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
> Subject: Re: <Swing Dev> JDK-8189938: Proposed patch
> Message-ID: <1518124791.13185.19.camel at doppel-helix.eu
> <mailto:1518124791.13185.19.camel at doppel-helix.eu>>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi,
>
> Am Donnerstag, den 08.02.2018, 12:06 -0800 schrieb Semyon Sadetsky:
> > Yet another question. Do you know what might call CoInitialize in a
> > different mode? It looks like we use STA everywhere in JDK.
>
> I tried to find some documentation how the FullTrustProcessLauncher of
> an UWP application works, but while the MSDN full of documentation
> about UWP, the lifecycle of a native application seems not to be
> covered. But my suspicion is this: The launching of an APPX package
> involves the runtime system creating an environment for the
> application
> and that seems to rely heavily on COM.
>
> So I assume, that COM is initialized outside the java core and the
> java
> process get this inherited. (But this is speculation!).
>
> I base this on the fact, that CoInitializeEx succeeds and multi
> threaded, but fails appartment threaded and the JDK code holds exactly
> three files calling CoInitialize (D2DPipelineManager.cpp,
> ShellFolder2.cpp, PLATFORM_API_WinOS_DirectSound.cpp).
>
> > On 02/08/2018 11:55 AM, Semyon Sadetsky wrote:
> > > I meant the case when MTA COM service is actually used, it
> might cause
> > > issues since the JDK code invokes an another API which assumes
> > > synchronization. At least performance may be affected.
> > >
> > > We don't do separate testing of JDK in MTA mode especially on the
> > > regular base. That is why I wouldn't consider MTA mode as
> supported.
> > >
> > > So, before push the change I would make sure of the regression
> test
> > > suite run in MTA mode hasn't brought any surprises.
>
> Aggreed and I'd like to help you, but in fact I was happy, that I
> managed to compile the JDK on windows and I have zero experience
> working on the JDK sources.
>
> As an observation: The COM initialization and usage looked pretty
> tight
> together in the sources and at least initialization happens only
> in the
> three files mentioned above. The DirectSound part is even limit to a
> small thread. The ShellFolder2 code looks to be the biggest direct
> user.
>
> Greetings,
> Matthias
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 8 Feb 2018 13:58:32 -0800
> From: Sergey Bylokhov <Sergey.Bylokhov at oracle.com
> <mailto:Sergey.Bylokhov at oracle.com>>
> To: Matthias Bl?sing <mblaesing at doppel-helix.eu
> <mailto:mblaesing at doppel-helix.eu>>,
> swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
> Subject: Re: <Swing Dev> JDK-8189938: Proposed patch
> Message-ID: <340b2b22-4f83-4f16-18bf-7bca181c85ab at oracle.com
> <mailto:340b2b22-4f83-4f16-18bf-7bca181c85ab at oracle.com>>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi, Matthias.
> Did you have a chance to find why this code works on jdk8u152(this is
> reported in the bug description).
>
> On 08/02/2018 10:32, Matthias Bl?sing wrote:
> > Hi all,
> >
> > last month I saw the message from Reinhard Pointer on this list:
> >
> >
> http://mail.openjdk.java.net/pipermail/swing-dev/2018-January/008132.html
> <http://mail.openjdk.java.net/pipermail/swing-dev/2018-January/008132.html>
> >
> > referring to this bug:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8189938
> <https://bugs.openjdk.java.net/browse/JDK-8189938>
> >
> > With the instructions given in:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8193928
> <https://bugs.openjdk.java.net/browse/JDK-8193928> (closed as
> duplicate of JDK-8189938)
> >
> > I was able to reproduce the problem on a clean Windows 10
> Installation,
> > as described in the initial report.
> >
> > The resulting exception leads to my proposed fix:
> >
> > Could not initialize COM: HRESULT=0x80010106
> >
> > That HRESULT translates to: RPC_E_CHANGED_MODE
> >
> > This means, that the COM subsystem is already initialized, but
> with a
> > different mode. The code uses CoInitialize and this initializes the
> > threading module to be apartment threaded. The above HRESULT
> means the
> > thread was already initialized to be multi-threaded.
> >
> > The mode can't be changed after is was set once, so instead of
> bailing
> > out, I suggest to accept the situation and initialize to be multi-
> > threaded.
> >
> > The consequence is that calls from COM to Java could end up on the
> > wrong thread. A quick look through the code suggest, that COM
> advises
> > are not used, so this is a risk that should be taken.
> >
> > The fix in this case works like this:
> >
> > * try to initialize COM as it was
> > * check the return
> > * if it is RPC_E_CHANGED_MODE, retry initialization als
> multi-threaded
> > * only if that fails raise an exception
> >
> > One could argue, that if COM is already initialized, you don't
> need to
> > do it yourself, but documentation states, that every successful
> call to
> > CoInitialize/CoInitializeEx must be paired with CoUninitialize.
> >
> > D3DPipelineManager tracks this in bComInitialized, the other two
> > callers in the JDK are:
> >
> > - PLATFORM_API_WinOS_DirectSound.cpp
> > - ShellFolder2.cpp
> >
> > Both are covered in the patches. For ShellFolder2 there is an
> > initialization check, this is modified as described above. And
> if both
> > initialization variant (apartment threaded and multi threaded fail)
> > this raises an exception.
> >
> > PLATFORM_API_WinOS_DirectSound is slightly different. The
> fallback in
> > the initialization is still done, but no exception is raised in the
> > error case. This follows the code flow before this change.
> >
> > I attached the diffs against JDK10 and JDK9 to this email. If
> they are
> > stripped, they can be found here:
> >
> > http://www.doppel-helix.eu/JDK8189938-openjdk9.diff
> <http://www.doppel-helix.eu/JDK8189938-openjdk9.diff>
> > http://www.doppel-helix.eu/JDK8189938-openjdk10.diff
> <http://www.doppel-helix.eu/JDK8189938-openjdk10.diff>
> >
> > I hope this helps with a fix.
> >
> > Greetings
> >
> > Matthias
> >
>
>
> --
> Best regards, Sergey.
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 8 Feb 2018 14:42:12 -0800
> From: Semyon Sadetsky <semyon.sadetsky at oracle.com
> <mailto:semyon.sadetsky at oracle.com>>
> To: Matthias Bl?sing <mblaesing at doppel-helix.eu
> <mailto:mblaesing at doppel-helix.eu>>,
> swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>,
> Prasanta Sadhukhan
> <prasanta.sadhukhan at oracle.com
> <mailto:prasanta.sadhukhan at oracle.com>>
> Subject: Re: <Swing Dev> JDK-8189938: Proposed patch
> Message-ID: <d6211787-1e9f-4a11-8e40-bc7a5083e441 at oracle.com
> <mailto:d6211787-1e9f-4a11-8e40-bc7a5083e441 at oracle.com>>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 02/08/2018 01:19 PM, Matthias Bl?sing wrote:
>
> > Hi,
> >
> > Am Donnerstag, den 08.02.2018, 12:06 -0800 schrieb Semyon Sadetsky:
> >> Yet another question. Do you know what might call CoInitialize in a
> >> different mode? It looks like we use STA everywhere in JDK.
> > I tried to find some documentation how the
> FullTrustProcessLauncher of
> > an UWP application works, but while the MSDN full of documentation
> > about UWP, the lifecycle of a native application seems not to be
> > covered. But my suspicion is this: The launching of an APPX package
> > involves the runtime system creating an environment for the
> application
> > and that seems to rely heavily on COM.
> It looks like there is an internal reason. Probably for UWP apps only
> MTA is allowed because of their life-cycle (the app may be suspended).
> > So I assume, that COM is initialized outside the java core and
> the java
> > process get this inherited. (But this is speculation!).
> >
> > I base this on the fact, that CoInitializeEx succeeds and multi
> > threaded, but fails appartment threaded and the JDK code holds
> exactly
> > three files calling CoInitialize (D2DPipelineManager.cpp,
> > ShellFolder2.cpp, PLATFORM_API_WinOS_DirectSound.cpp).
> >
> >> On 02/08/2018 11:55 AM, Semyon Sadetsky wrote:
> >>> I meant the case when MTA COM service is actually used, it
> might cause
> >>> issues since the JDK code invokes an another API which assumes
> >>> synchronization. At least performance may be affected.
> >>>
> >>> We don't do separate testing of JDK in MTA mode especially on the
> >>> regular base. That is why I wouldn't consider MTA mode as
> supported.
> >>>
> >>> So, before push the change I would make sure of the regression
> test
> >>> suite run in MTA mode hasn't brought any surprises.
> > Aggreed and I'd like to help you, but in fact I was happy, that I
> > managed to compile the JDK on windows and I have zero experience
> > working on the JDK sources.
> Prasanta,
>
> since the bug is assigned to you can you test the suggested fix in MTA
> mode and sponsor it if there are no issues?
>
> --Semyon
> >
> > As an observation: The COM initialization and usage looked
> pretty tight
> > together in the sources and at least initialization happens only
> in the
> > three files mentioned above. The DirectSound part is even limit to a
> > small thread. The ShellFolder2 code looks to be the biggest direct
> > user.
> >
> > Greetings,
> > Matthias
>
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 9 Feb 2018 11:24:30 +0530
> From: Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com
> <mailto:prasanta.sadhukhan at oracle.com>>
> To: Semyon Sadetsky <semyon.sadetsky at oracle.com
> <mailto:semyon.sadetsky at oracle.com>>, Matthias Bl?sing
> <mblaesing at doppel-helix.eu
> <mailto:mblaesing at doppel-helix.eu>>, swing-dev at openjdk.java.net
> <mailto:swing-dev at openjdk.java.net>
> Subject: Re: <Swing Dev> JDK-8189938: Proposed patch
> Message-ID: <ee194e8a-4995-e80d-cd06-75bac3843c1d at oracle.com
> <mailto:ee194e8a-4995-e80d-cd06-75bac3843c1d at oracle.com>>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi,
>
>
> On 2/9/2018 4:12 AM, Semyon Sadetsky wrote:
> > On 02/08/2018 01:19 PM, Matthias Bl?sing wrote:
> >
> >> Hi,
> >>
> >> Am Donnerstag, den 08.02.2018, 12:06 -0800 schrieb Semyon Sadetsky:
> >>> Yet another question. Do you know what might call CoInitialize
> in a
> >>> different mode? It looks like we use STA everywhere in JDK.
> >> I tried to find some documentation how the
> FullTrustProcessLauncher of
> >> an UWP application works, but while the MSDN full of documentation
> >> about UWP, the lifecycle of a native application seems not to be
> >> covered. But my suspicion is this: The launching of an APPX package
> >> involves the runtime system creating an environment for the
> application
> >> and that seems to rely heavily on COM.
> > It looks like there is an internal reason. Probably for UWP apps
> only
> > MTA is allowed because of their life-cycle (the app may be
> suspended).
> >> So I assume, that COM is initialized outside the java core and
> the java
> >> process get this inherited. (But this is speculation!).
> >>
> >> I base this on the fact, that CoInitializeEx succeeds and multi
> >> threaded, but fails appartment threaded and the JDK code holds
> exactly
> >> three files calling CoInitialize (D2DPipelineManager.cpp,
> >> ShellFolder2.cpp, PLATFORM_API_WinOS_DirectSound.cpp).
> >>
> >>> On 02/08/2018 11:55 AM, Semyon Sadetsky wrote:
> >>>> I meant the case when MTA COM service is actually used, it
> might cause
> >>>> issues since the JDK code invokes an another API which assumes
> >>>> synchronization. At least performance may be affected.
> >>>>
> >>>> We don't do separate testing of JDK in MTA mode especially on the
> >>>> regular base. That is why I wouldn't consider MTA mode as
> supported.
> >>>>
> >>>> So, before push the change I would make sure of the
> regression test
> >>>> suite run in MTA mode hasn't brought any surprises.
> >> Aggreed and I'd like to help you, but in fact I was happy, that I
> >> managed to compile the JDK on windows and I have zero experience
> >> working on the JDK sources.
> > Prasanta,
> >
> > since the bug is assigned to you can you test the suggested fix
> in MTA
> > mode and sponsor it if there are no issues?
> >
> I am still not able to reproduce in our WIndows 10 Pro
> (EN-W10P64-10.0.01.0). "Developer Mode" and "execute powershell
> script"
> is enabled. This is what I am getting
> $ ant clean appx install
> Buildfile: D:\prasanta\8189938\JDK-8189938-master\build.xml
>
> clean:
> ?? [delete] Deleting directory
> D:\prasanta\8189938\JDK-8189938-master\bin
> ?? [delete] Deleting directory
> D:\prasanta\8189938\JDK-8189938-master\dist\appx
> ??? [mkdir] Created dir: D:\prasanta\8189938\JDK-8189938-master\bin
> ??? [mkdir] Created dir:
> D:\prasanta\8189938\JDK-8189938-master\dist\appx
>
> build:
> ??? [javac] Compiling 1 source file to
> D:\prasanta\8189938\JDK-8189938-master\bin
> ??? [javac] warning: [options] bootstrap class path not set in
> conjunction with -source 9
> ??? [javac] 1 warning
> ????? [jar] Building jar:
> D:\prasanta\8189938\JDK-8189938-master\dist\appx\main.jar
>
> appx:
> ???? [copy] Copying 5 files to
> D:\prasanta\8189938\JDK-8189938-master\dist\appx
> ???? [exec] Expected SHA256 checksum:
> ffcd6d774cfba78d88a1af253eecad0ec3639bdeabdfb3345e61d1c2355267a4
> ???? [exec] Actual SHA256 checksum:
> ffcd6d774cfba78d88a1af253eecad0ec3639bdeabdfb3345e61d1c2355267a4
> ???? [exec] Download complete: jre-9.0.4_windows-x64_bin.tar.gz
> ??? [untar] Expanding:
> D:\prasanta\8189938\JDK-8189938-master\jre-9.0.4_windows-x64_bin.tar.gz
> into D:\prasanta\8189938\JDK-8189938-master\dist\appx\jre
>
> install:
> ???? [exec] Add-AppxPackage : Deployment failed with HRESULT:
> 0x80070005, Access is denied.
> ???? [exec] Deployment Register operation with target volume C: on
> Package JDK8189938_1.0.0.0_x64__hz258y3tkez3a from:
> ???? [exec] (AppxManifest.xml)? failed with error 0x80070005. See
> http://go.microsoft.com/fwlink/?LinkId=235160
> <http://go.microsoft.com/fwlink/?LinkId=235160> for help
> ???? [exec] diagnosing app deployment issues.
> ???? [exec] NOTE: For additional information, look for [ActivityId]
> 02867602-9e78-0006-8ffb-8802789ed301 in the Event Log or use
> ???? [exec] the command line Get-AppxLog -ActivityID
> 02867602-9e78-0006-8ffb-8802789ed301
> ???? [exec] At line:1 char:1
> ???? [exec] + Add-AppxPackage -Register dist/appx/AppxManifest.xml
> ???? [exec] + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ???? [exec]???? + CategoryInfo????????? : SecurityError:
> (D:\prasanta\818...ppxManifest.xml:String) [Add-AppxPackage],
> PSSecurityE
> ???? [exec]??? xception
> ???? [exec]???? + FullyQualifiedErrorId :
> DeploymentError,Microsoft.Windows.Appx.PackageManager.Commands.AddAppxPackageCommand
> ???? [exec]
> ???? [exec] Result: 1
>
> BUILD SUCCESSFUL
> Total time: 6 seconds
>
> ARAPTE-PC+client at ARAPTE-PC
> /cygdrive/d/prasanta/8189938/JDK-8189938-master
> $ ls
> appx? bin? build.xml? dist? get-java.ps1
> jre-9.0.4_windows-x64_bin.tar.gz? LICENSE? README.md
> screenshot.png? src
>
> ARAPTE-PC+client at ARAPTE-PC
> /cygdrive/d/prasanta/8189938/JDK-8189938-master
> $ JDK8189938
> bash: JDK8189938: command not found
>
> Regards
> Prasanta
> > --Semyon
> >>
> >> As an observation: The COM initialization and usage looked
> pretty tight
> >> together in the sources and at least initialization happens
> only in the
> >> three files mentioned above. The DirectSound part is even limit
> to a
> >> small thread. The ShellFolder2 code looks to be the biggest direct
> >> user.
> >>
> >> Greetings,
> >> Matthias
> >
>
>
>
> End of swing-dev Digest, Vol 130, Issue 13
> ******************************************
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180209/7b7494e8/attachment.html>
More information about the swing-dev
mailing list