Definitely try to implement some sort of "com-like" reference counting mechanism when passing objects to and from unmanaged code. You never know when the GC might collect your delegates, and you're stuck with bad pointers. Can really be hard to diagnose without a library like SysLibs. I usually have a class used for interop with native code and store a Dictionary<long,object> to keep objects alive. When unmanaged code is done using it, simply remove the object from the dictionary (unmanaged code must know the long corresponding to the object). This approach has worked very well when interoperating with C-C++-Google V8 for me, and I'm sure the same approach could also work for Java interop as well.
Does Microsoft plan to continue supporting Win32 APIs after Windows 8 is released (desktop applications)Aug 24, 2012 at 4:37PM
@IDWMaster: Don't forget, anything written in WinRT MUST be installed from Microsoft Marketplace. Chew on that candy for a while! You no longer are ALLOWED to give YOUR application to whoever you like WITHOUT PERMISSION from Microsoft.
The bigger question is not about Win APIs, the question is, is your PC YOURS anymore?
Of course, anything else rather than praises and flowers will be bashed here by the 10-15 regulars hanging in here. Don't expect much from them. Their bags are all empty.
I would like to point out that this is not true. Applications may also be distributed within Enterprise businesses through Windows Server, and Microsoft announced other alternative means of distribution as well, but haven't provided any details on them yet.I would also like to point out that I have no problem with this app model as long as "desktop applications" are still supported, and is not considered a "legacy" feature that will be dropped in the next version of Windows.
Bottom line: THE DESKTOP SHOULD NOT be a legacy feature.
Does Microsoft plan to continue supporting Win32 APIs after Windows 8 is released (desktop applications)Aug 24, 2012 at 3:13PM
I've noticed that all "Windows-8 style" applications have been switched over to the WinRT API set. This is concerning, because it perhaps indicates a "transitional" period for Windows in which Microsoft urges developers to start switching from Win32 to WinRT/"windows 8 interface (or whatever you call Metro now). The main thing I'm concerned about, is that certain features which I've previously enjoyed on the Windows platform may be made unavailable to developers using Visual Studio 2012, particularly dynamic code generation and execution. I work on a number of compilers, and programs which need to use compilers internally inside their processes, and the lack of a VirtualProtect or LoadLibrary function makes this impossible to do at runtime. I understand this is for security reasons, however, I'm also concerned that "desktop" profiles may no longer be supported in developer tools, making Windows no longer a viable platform for many applications. "Windows 8 style" libraries simply don't cut it for everyone. I'm sorry if this post offends anyone at Microsoft or elsewhere, but it would be really nice to have an answer to this question.
Another thing I would like to point out is that if Microsoft completely kills the desktop, users will then be stuck with Internet Explorer as the only browser, and will not be able to choose any other browser (Metro doesn't support runtime compilation of code, so there will be no way to make a reasonably performant browser for it).
Or this one, which still crashes my NVidia graphics drivers (part of which run in ring0, and hence Chrome's sandbox it just window dressing).
Whoa! That certainly shows a problem with BOTH Google Chrome's and NVidia's implementations! It's really annoying that a website can cause a computer to freeze like that. Google Chrome should work with NVIdia to fix that bug! However, the vulnerability isn't indicative of a flaw in WebGL or OpenGL itself, but instead indicates a crucial vulnerability in the implementation of the specification.
WebGL can easily be disabled from a command line option passed into most WebGL compliant browsers. Also; who says that WebGL HAS to run whenever a page requests it? Couldn't browsers make it so the user is required to OK the use of WebGL before it runs on the system? There's nothing that says that a browser can't do this.
Earlier Microsoft made its infamous decision that WebGL is inherently insecure because it allows access to your GPU. Why then; is Silverlight secure? Silverlight 5 gives web pages the same type of access. It should also be pointed out that Canvas2D is now GPU-accelerated in Windows anyways; if an attacker mis-used even a 2D context based on your theory it could then be used to compromise a system via a DOS attack in the same way that it could supposedly be compromised in an attack on a WebGL implementation. Security is not usually an issue within a specification of a technology, but is usually an issue within its particular implementation. If Silverlight can be implemented "securely", why can't WebGL? I do encourage you do read this argument about enabling WebGL. Although someone strongly worded, he does explain how WebGL can be implemented securely. It's also sad to see that Windows 8's Metro browser has absolutely no 3D support of any kind; including Silverlight. For a company claiming to support HTML5 and use it to innovate the web, it is not a good idea to pick and choose only a small subset of HTML5 features. Other browsers such as Chrome and Firefox are known for their frequent updates, which actually add new features to the browsers on a regular basis. I do hope that Microsoft chooses to reverse some of its business decisions regarding these matters; and your browser, and your new OS would become much more popular among consumers.
Got a better webcam --- A higher resolution version is now posted, see my original post. Video editing these days is pretty simple with Photoshop for texture editing, DirectX for 3D rasterization, OpenCL and OpenCV for image analysis, and DirectShow for video encoding.
Somehow Channel9 glitched and double-posted. See below for my response.
Mar 06, 2012 at 3:47PM
Disabling the tiles still fails to disable the background updates performed by Windows for the mail. I still am seeing TCP connections to Windows Live when tile updates are disabled, which contain personally identifiable information that I would not want to send over a public network, as well as a CLEARTEXT view of all my contact's e-mail addresses!