DLL vs SDK

I guess it kind of depends...

A DLL can be replaced without changing the program using it.
That's both a good and a bad thing; It means you could upgrade the SDK and automatically get new features in an older program without recompiling.

On the other hand, it could also break old programs because a newer DLL might have behave differently; if the SDK is a core part of the program, it can't break unexpectedly, but it also can't be upgraded.

Then again, any dev that wants to can probably build a DLL from the SDK source anyway... So

I don't know. It seems like a bit of a moot point really.

It's an interesting question, but ultimately it seems giving developers access to the SDK source code gives them the most flexibility in integrating with their applications.

"cybereality" wrote:
It's an interesting question, but ultimately it seems giving developers access to the SDK source code gives them the most flexibility in integrating with their applications.

How are having access to source and having the 'default SDK' be a standardized set of functions exported from a C friendly API as a DLL mutually exclusive?

Having the standard SDK be C++ is a mistake, forcing developers to statically link is a mistake. I mean just take the upcoming sdk which promises to fix Yaw drift correction, we could have all code out there support this *Instantly* by just copying a new DLL to the respective app's folder, yet now you pushed the responsibility to the developers, who may or may not still support that specific application. It's bad from a users perspective and i have to say it's bad from a developer perspective, you fix a bug, the developer gets to recompile and run their apps though a complete QA cycle to push an update out, gee thanks!

What IMHO *needs* to happen for successful and proper developer support:

1) Dump the C++ SDK, we all make mistakes, it's how we learn, no big deal.
2) Define a STRONG C API (Strong meaning, once the SDK supports a certain function it's signature or behavior can NEVER EVER change)
3) Deliver this as a DLL on windows and as a shared library on other platforms. (Forcing developers to statically link your code is bad, and you should feel bad)
4) Give developers the right to redistribute this dll with their application.
5) Optional: Release the source for this dll to developers to help them with debugging.

Yes it's a lot of work, and it requires putting a lot of forethought into it. It's also the method 99.99% of all other vendors use. Saying you "have the source, you figure it out, your problem now!" is a cop out, don't be lazy.

I Understand you guys are a new company, and as you grow you learn, but this should be one of those learning moments, and i truly truly hope you recognize it as such. It's not too late, you can still fix this.

Point taken. I can discuss this with the SDK developers, but I already know it's not an easy decision.

I was willing to actually start writing the DLL. But I was not going to do it if it would be a wasted effort.

I will begin working on the DLL in the morning, we can see who comes up with one first :)

thanks for the insight. I was going to write one for myself anyway.

Regards,
Mike

"lazydodo" wrote:

1) Dump the C++ SDK, we all make mistakes, it's how we learn, no big deal.
2) Define a STRONG C API (Strong meaning, once the SDK supports a certain function it's signature or behavior can NEVER EVER change)
3) Deliver this as a DLL on windows and as a shared library on other platforms. (Forcing developers to statically link your code is bad, and you should feel bad)
4) Give developers the right to redistribute this dll with their application.
5) Optional: Release the source for this dll to developers to help them with debugging.

Strongly agree. However, there should be some distinction made... the above best describes a thin hardware abstraction. Minimal code and API to access the hardware.

On top of this can be a featureful SDK, written in C++ for Windows if desired. It seems to me that a larger SDK is really a platform to quickly make demos or start working with Oculus hardware. A core API (C conventions and cross platform) would be easier to fit into an existing engine or application, and access from other languages. And having it as dll/so, as mentioned, lets all software (from various SDKs to applications) benefit from bugfixes and upgrades.

I agree totally as my statement:

"yubinhydin" wrote:
The SDK is a great way to get games modified, and I am glad we have it, but going forward in new projects which would benefit you more??

I do not want them to stop producing upgrading or otherwise remove the SDK. I want to personally make it a Module that can be reused without needing to open the source code of a build after I have released it. Upgrading a Library that is already called from the code doesn't break the code "TYPICALLY". I say that cause I know there are bugs, typos, and just mistakes in general that can make the DLL (library) crash the parent code.



Regards,
Mike

"lazydodo" wrote:
forcing developers to statically link is a mistake.

They're not forcing you to statically link... They've given you the complete source code... >_<

You're more than capable of compiling it into a DLL rather than statically linking to it.

I mean, I know you are otherwise correct, in that doing this yourself wouldn't be as good as having a standardised DLL shared by everyone using it, but nobody is forcing you to use static linking here...

Recompile the code and create a DLL instead. If you're spending this much time arguing about how important it is, surely you know how...

Don't misunderstand me, I know what your real point is here. But why you say things which are clearly untrue is beyond me...

statically linking their code into a dll vs statically linking into an exe, doesn't change the argument really, the dev still has to go though a whole QA cycle to get the code out and trivial fixes in the field and the end user is still depended on dev's get off their ass and release a new update. Also i bet most dev's are more comfortable with a redistributable binary vs 3rd party code with their own license in their source tree's. Especially for something that is essentially a system library.

"lazydodo" wrote:
It's bad from a users perspective and i have to say it's bad from a developer perspective, you fix a bug, the developer gets to recompile and run their apps though a complete QA cycle to push an update out, gee thanks!

Are you suggesting that a third party dll replacement with a newer version is not a significant enough change to running logic to warrant having to go through QA again on the application that makes use of it?