I just tried to make myself familiar with OpenCL but totally got confused when everyone in the Internet was talking about downloading a Vendor specific OpenCL SDK. Why would I need that?
My understanding of using OpenCL was the following:
Download the OpenCL header files that are maintained by Kronos in the Khronos OpenCL Registry and make it available to your compiler.
Compile your code and link against the OpenCL.dll.
The reason why it confuses me is because I thought that OpenCL should abstract away vendor specific implementations. If I now download a Vendor specific SDK isn't then this advantage destroyed?
Can someone please make this clear?
Your understanding is absolutely correct - you do not need any vendor SDKs in order to develop or run OpenCL programs. All you need are the headers and a library to link against. The vendor SDKs provide sample code that may be useful to look at while you are learning how to use OpenCL, and they may also provide tools that can aid development.
On Windows, you will need an OpenCL.lib library to link against, which the SDKs do provide. You can download the sources for this library and build it yourself if you wish.
There is no harm from using a specific vendor's SDK however. The headers and library that they provide in the SDK should just be the stock Khronos versions that you can download yourself. This means that an OpenCL application built using one vendor's SDK will still run just fine against other vendors' devices.
Related
Bear with me, as I'm not a pro by any means.
I've known about ZeroMQ for a while, and that it offers a very interesting way of utilizing multiple cores by clever use of networking. I'd like to see what I can get going with it, as the lua examples provided are extremely concise and easy to understand.
But adding ZeroMQ as a lua library...Not so much. There are no instructions at all. Closest I could find, were Linux commands to download the repo and add it to the OS' libraries.
The problem, is that I'm on Windows. Nor do the instructions actually say how you add it to a lua project. Never mind how to add it to an IDE, like Zerobrane.
How do I go about this?
I think there are two part to this question: (1) how to add ZeroMQ as a library to a Lua script and (2) how to make it run from ZeroBrane Studio.
(1) To add ZeroMQ as a Lua library you need to use some ZeroMQ binding (essentially a wrapper around ZeroMQ library that provides Lua methods to use). I see two options: https://github.com/zeromq/lzmq and https://github.com/Neopallium/lua-zmq. You'll have to figure out how to compile one of them on Windows and generate .dll library that can be loaded by your Lua application.
(2) When you have the ZeroMQ library and its Lua binding library (they will usually be available as one .dll library), you don't need to do anything special to make it run from ZeroBrane Studio. If you can run your ZeroMQ sample from the current folder, then select that as the project folder in ZeroBrane Studio and run your script. That should be enough.
Make sure that your ZeroMQ binding is compiled against the same version of Lua you plan to use. For example, if you're using Lua 5.3, then the binding needs to be compiled against that version (and requires the support for that version in the ZeroMQ bindings).
There don't seem to be any APIs / examples of how to integrate WebRTC in Xamarin. There is a third party API (IceLink) by a company named Frozen Mountain Software but one requires a paid license to use it.
Any clue as to how to do this ?
You will have to use WebRTC native libraries for Xamarin. If you are good with using precompiled libraries then you may find it over web. However I prefer to compile webrtc native for each target platform. Google has documented steps very well, but it usually take time.
Once you have libraries ready for your platform then you can use it with xamarin. Let me know if you face any issue.
I have an embedded device with WinCE 6.0 as OS. The manufacturer provides an IDE for 3rd party development to it. The IDE pretty much allows nothing else than
.NET 3.5 Compact Framework scripting that's invoked from various events from the main application
Adding files to the device.
The included mediaplayer seems to be using DirectShow and the OS has media codec only for mpeg-1 encoded video playback. My goal is to to be able to play media encoded with some other codecs as well inside that main application.
I've already managed to use DirectShowNETCF (DirectShow wrapper for .NET Compact Framework) and successfully playback mpeg-1 encoded video.
I'm totally new with this stuff and I have tons of (stupid) questions. I'll try to narrow them down:
The OS is based on WinCE, but as far as I've understood, it's actually always some customized version of it (via Platform Builder). Only "correct way" of developing anything for it afterwards is to use the SDK the manufacturer usually provides. Right? In my case, the SDK is extremely limited and tightly integrated into IDE as noted above. However, .NET CF 3.5 is capable for interop so its possible to call native libraries -as long as they are compiled for correct platform.
Compiled code is pretty much just instructions for the processor (assembler code) and the compiler chooses the correct instructions based on the target processor setting. Also there's the PE-header that defines under which platform the program is meant to be run. If I target my "helloworld.exe" (does nothing but returns specific exit code) to x86 and compile it with VC, should it work?
If the PE-header is in fact the problem, is it possible to setup for WINCE without the SDK? Do I REALLY need the whole SDK for creating a simple executable that uses only base types? I'm using VS2010, which doesn't even support smart device dev anymore and I'd hate to downgrade just for testing purposes.
Above questions are prequel to my actual idea: Porting ffmpeg/ffdshow for WinCE. This actually already exists, but not targeted nor built for Intel Atom. Comments?
If the native implementation is not possible and I would end up implementing some specific codec with C#...well that would probably be quite a massive task. But having to choose C# over native, could I run into problems with codec performance? I mean.. is C# THAT much slower?
Thank you.
I've not seen an OEM that shipped their own IDE, but it's certainly possible. That shouldn't change how apps can created, however. It's possible that they've done a lot of work to make sure only things from their IDE work, but that would be a serious amount of work for not that much benefit, so I'd think it's unlikely.
As for your specific questions:
The OS is Windows CE, not "based on" it. The OS is, however, componentized, so not all pieces are going to be available. An SDK generally provides a mechanism to filter out what isn't available. You can actually use any SDK that targets the right processor architecture, but if your app calls into a library for something that isn't in the OS, then you'll get at the very least an error. For managed code this is all not relevant because the CF isn't componentized. If it's there, and CF app can run (and if it's not, you can often install it after the fact). This means that if the platform supports the CF, then you can write a CF app and run it. That app can then call native stuff via P/Invoke (unless, of course, the OS creator decided to add security to prevent that. This is possible in the OS, though I've never seen it implemented).
Yes, compiled code is just "instructions". For native, yes, they are processor instructions. For managed, they are MSIL instructions that the managed runtime in turn converts to processor instructions at JIT time. If your target is an ARM platform, you cannot use an x86 compiler. Broadly speaking, you need to use the correct Microsoft compiler that support Windows CE, and call that compiler with the proper switches to tell it not only the processor architecture, but also the target OS because the linking that needs to be done will be different for OS-level APIs and even the C runtimes. The short of this is that for your platform, you need to use Visual Studio 2008 Pro.
For native apps, you need some SDK that targets the same OS version (CE 6.0) and processor architecture (e.g. ARMv4I). Having it match the OS feature set is also useful but not a requirement. For managed code, you can just use the SDKs that ship with Studio because managed code is not processor-dependent. Still, you have to go back to Studio 2008 because 2010 doesn't have any WinCE compilers.
If you've found an existing library, then you can try to use it. Things that might impede your progress are A) it's unlikely to use an SDK you have so you probably have to create new project files (painful, but workable) and B) if it uses features not available in your OS, then you'd have to work around those. If you're missing OS features, you're probably out of luck but if it already has a media player and codec, I suspect you'll be ok.
Don't implement this in managed code. Seriously, just don't do it. Could you? Yes. Performance could probably be made to be nearly the same except to avoid GC stuttering you're going to have to basically create your own memory manager. The amount of work involved in this path is very, very large.
If I build a DLL with Rust language, does it require libgcc*.dll to be present on run time?
On one hand:
I've seen a post somewhere on the Internet, claiming that yes it does;
rustc.exe has libgcc_s_dw2-1.dll in its directory, and cargo.exe won't run without the dll when downloaded from the http://crates.io website;
On the other hand:
I've seen articles about building toy OS kernels in Rust, so they most certainly don't require libgcc dynamic library to be present.
So, I'm confused. What's the definite answer?
Rust provides two main toolchains for Windows: x86_64-pc-windows-gnu and x86_64-pc-windows-msvc.
The -gnu toolchain includes an msys environment and uses GCC's ld.exe to link object files. This toolchain requires libgcc*.dll to be present at runtime. The main advantage of this toolchain is that it allows you to link against other msys provided libraries which can make it easier to link with certain C\C++ libraries that are difficult to under the normal Windows environment.
The -msvc toolchain uses the standard, native Windows development tools (either a Windows SDK install or a Visual Studio install). This toolchain does not use libgcc*.dll at either compile or runtime. Since this toolchain uses the normal windows linker, you are free to link against any normal Windows native libraries.
If you need to target 32-bit Windows, i686- variants of both of these toolchains are available.
NOTE: below answer summarizes situation as of Sep'2014; I'm not aware if it's still current, or if things have changed to better or worse since then. But I strongly suspect things have changed, given that 2 years have already passed since then. It would be cool if somebody tried to ask steveklabnik about it again, then update below info, or write a new, fresher answer!
Quick & raw transcript of a Rust IRC chat with steveklabnik, who gave me a kind of answer:
Hi; I have a question: if I build a DLL with Rust, does it require libgcc*.dll to be present on run time? (on Windows)
I believe that if you use the standard library, then it does require it;
IIRC we depend on one symbol from it;
but I am unsure.
How can I avoid using the standard library, or those parts of it that do? (and/or do you know which symbol exactly?)
It involves #[no_std] at your crate root; I think the unsafe guide has more.
Running nm -D | grep gcc shows me __gc_personality_v0, and then there is this: What is __gxx_personality_v0 for?,
so it looks like our stack unwinding implementation depends on that.
I seem to recall I've seen some RFCs to the effect of splitting standard library, too; are there parts I can use without pulling libgcc in?
Yes, libcore doesn't require any of that.
You give up libstd.
Also, quoting parts of the unsafe guide:
The core library (libcore) has very few dependencies and is much more portable than the standard library (libstd) itself. Additionally, the core library has most of the necessary functionality for writing idiomatic and effective Rust code. (...)
Further libraries, such as liballoc, add functionality to libcore which make other platform-specific assumptions, but continue to be more portable than the standard library itself.
And fragment of the current docs for unwind module:
Currently Rust uses unwind runtime provided by libgcc.
(The transcript was edited slightly for readability. Still, I'll happily delete this answer if anyone provides something better formatted and more thorough!)
Does anyone know library to browse (and upload/download/stream) on smb shares (SMB/CIFS protocol) from iOS. This must be support for all the Windows OS. This is grade help for me.
Not quite an answer to your question, but I have some tips:
If you write your own client, don't trust the IETF RFC. Microsoft
hasn't been scrupulous in its adherence to the spec. And be sure to
test with Unicode file/folder names, all major versions of Windows,
and so on.
Don't write your own client. :-)
If you use an open-source library, make sure it's not GPL or LGPL,
unless you plan to open-source your entire project. LGPL almost
works—it does on Mac OS X—but it requires dynamic linking, which
isn't supported on iOS.
You may see apps in the app store that use GPL or LGPL libraries,
but don't assume that it is safe to use them yourself. Those apps
are often blatantly abusing the license.
opensource.apple.com has an smb client that's a great reference but
it's a file system kernel extension, so you can't use it directly.