Vulkan has instance and device extensions, but I cannot find any information anywhere about what the difference between them is. What does it mean exactly if something is a device extension or an instance extension? Why is VK_KHR_external_memory a device extension and VK_KHR_external_memory_capabilities an instance extension? Why is it not just a single, unified extension system?
The difference between instance extensions and device extensions is the difference between instances and devices.
The Vulkan instance is the piece of code that is used to set up devices. It deals with things like enumerating VkPhysicalDevices and querying their properties, as well as the call to create VkDevices itself.
The Vulkan device is for dealing with Vulkan rendering systems.
Device extensions pertain to the behavior of a particular VkDevice object which was created with that extension activated. As such, that extension cannot describe the behavior of stuff that happens before the device is created.
External memory, for example, has obvious implications for the rendering system. So it is a device extension. However, particular VkPhysicalDevice objects have different properties that can be queried with regard to their external memory functionality. You need to be able to query these properties before you create the device, because if the device doesn't provide the properties you need, there's no point in making the device at all. Or at least, of making the device with that extension active.
But device extensions govern the behavior of a device. If you don't have a device yet because you haven't created one, because you're trying to decide whether to create one at all... what do you do?
Well, that behavior has to be an instance extension. It extends the part of Vulkan that deals with the set up for devices, not that governs the behavior of the device itself.
Related
Dynamic Ice manual section doesn't explain how to obtain a list of operations (their names, argument and result types) implemented by an object, which seems to be pretty much necessary to "create applications such as object browsers, protocol analyzers". Is it possible? I am thinking of a case where a client doesn't have access to all Slice interfaces known to the server (e.g. because new ones can be loaded dynamically) and so wants to learn about them at the runtime. Is there any built-in way to do this in Ice?
Ice doesn't provide any introspection along the lines of the CORBA interface repository. You can create requests dynamically (without using compiled stubs), and you can respond to them dynamically (without using compiled skeletons) but, if you need to find out what types are involved, you have to get this knowledge from somewhere else.
Michi.
I am currently learning OOP on my own with books and websites. I am at the point I need to practice. I started a small project that I know how to do in a procedural way. But it leaves me with questions when I try to do it in a OOP manner.
My project concept is like this. I want to organize/archive/manage interconnection on our system at work. I use 2 classes. Device and Interface.
A Device have some Interfaces.
Device class have the following methodes:
void addInterface( String name)
void removeInterface( Interface i)
Interface getInterface( Interface i) # I should have wrote : Interface getInterface( String interfaceName )
void printAllInterface()
Interface class have the following methodes :
void connectInterface( Interface interfaceToConnectTo )
void disconnectInterface( Interface interfaceToDisconnectFrom )
void printAllConnection()
Basically, I create two device, add some interfaces to each and finally make some connection between interfaces.
A device know all its interfaces. An interface know all other interface it is connected to.
But given an interface how do I know to what device it belong?
If Interface is aware of Device, they become tightly coupled. For what I learn so far it is not really good OO. An other way would be to browse all device to know if they have the Interface I am looking for. It seems really inefficient. I am sure I missed something obvious. Can anybody sees it?
Thanks
update :
This can be seen as shapes and connections in a MS Visio file. the interface is really just a connector on a shape. The device is the shape.
If you have the requirement that you must be able to determine the Device for a given Interface, that means that Device and Interface are already tightly coupled even if you haven't coded it. If you decouple the two classes then you can no longer assume that all Interfaces belong to a Device.
If it is the case that all Interface objects must belong to a Device, then I don't see any problem having setDevice/getDevice methods on Interface. Yes it creates a circular dependancy, but it looks like that is the best way to model your specific domain. Searching through every Device just to see if it contains a specific Interface is a much worse design decision in my opinion.
However, if it is desirable for an Interface to exist without belonging to a Device, or maybe belonging to a totally different class, then you'll need to rethink the architecture at a higher level. Something along the lines of: How can I restructure these classes so I don't need to get a Device from an Interface? The answer really depends on your specific domain, which we don't know very much about just from the information in your question.
A small comment on your existing interfaces. IMHO the print method on the interfaces should be moved to a different interface so that the Device interface has a single responsibility of just maintaining the Interfaces it controls. Also, what does the method "Interface getInterface(Interface pInterface)" receive as Input argument and return?
As for the answer, there are a few questions that the answer above raises. If I understand correctly, the device class creates an interface when addInterface() is invoked; If the use case is such that given an interface a device is to be returned, a getDevice() on Interface is okay (I wouldn't add a setDevice() method; Device can be passed into the Interface's constructor) if an Interface always belongs to a device.
Edit : The setDevice() method would however be preferrable if you want to give the user of your api an impression that your use case so demands that the device associated with an interface can change at runtime.
I'm undecided as to what classes I could have that could adapt to an existing system which is an online video game. Here's what I want to achieve:
Get a series of settings from objects in the server.
Listen for clients to connect.
For each client, check that the settings on the client correspond with those from the server.
If settings don't correspond (something has been tampered with), either disconnect the client or change their settings.
This will be handled by class that will act as an entry point and can serve as a form of controller.
Now, the settings are strewn accross a number of instances: players, weapons, flags, lights, etc. In procedural programming, I'd get all this information and store it an array. However, is there a better way of doing this according to an OO approach? Can I make one or more classes that will have the values of these settings and act as a form of facade?
Encapsulate the settings data and behavior into at least one object (i.e. Settings). Depending on how your system is constructed this becomes part of other objects' composition (e.g. Player, Weapon, etc...), perhaps via dependency injection, or referenced from some global context. Settings is responsible for validation the match between client and server (e.g. Settings.validateClientServerSettingsMatch()). In terms of retrieving individual settings, two possible approaches explicit or implicit.
Explicit
Your Settings object, or perhaps other entities that make its composition, have methods for each setting managed. So it could be something like Settings.getPlayerSettings().getSomeSetting() or 'Settings.getSomePlayerSetting()`. How nested really depends on your system. Either has the advantage of making clear what settings are available to the client development and it procides compile time type checking if you're using a language such as Java. The tradeoff is needing to alter an object every time a new setting comes into play.
Implicit
This just has a generic method in the Settings object - Settings.getSetting(settingName). This makes it very easy to add settings, at the expense of any sort of useful type checking, unless you do something on your own using some meta magic of sorts in a language such as Python or Ruby or large case statements in Java.
I want to find a tool that can see all the interface, including the methods, properties, events, exposed by a COM(or ActiveX) component. Is such tool available?
It's not actually possible to build such a tool for ANY COM object, you might have some luck with specific objects. If a type library is available then you could use OLEView or you can programatically open and traverse the type library itself. Bear in mind that the contents of the type library is just what the developer wanted to include in it; there's nothing to stop objects implementing more interfaces than their type libraries say they do.
For objects without type libraries it's impossible to produce a general purpose tool:
Given the way that QueryInterface works you would have to ask the object under investigation if it supports every interface possible. Where would such a tool obtain a list of all possible interfaces that the object in question could support? Whilst it's true that some interfaces are registered in the registry due to proxy requirements not all interfaces are and it's by no means a requirement that they should be.
Once you know that an object supports a given interface how do you work out what methods that interface supports? If the interface derives from IDispatch then this is possible as that's the purpose of IDispatch, but for interfaces derived from IUnknown there is no way to programatically discover things about the interface.
You also have the added problem that some objects may have additional interfaces implemented for them by the proxy layer, for example, if an interface has been proxied then you will also be able to QueryInterface from it to IProxyManager though the object itself does not implement this interface (it's part of the proxy).
If the component has a typelib (in resources or shipped separately) you can use OLE View that comes with Visual Studio. You should use "View Typelib", not "Bind to File" there.
I have a COM inproc DLL that we are using in our product.
Now if someone finds out which interface and APIs we have exposed from the DLL then those APIs can be called easily.
Is there a way to stop unknown applications from calling my APIs?
Can we add some signature in COM?
The formal way of controlling use of your object is by implementing IClassFactory2 on the class factory that creates your COM objects.
Here's a link at MSDN explaining the interface.
IClassFactory2 at MSDN
The benefit of creating an implementation is that nobody can fetch an instance without clearing the hurdles of registration through IClassFactory2.
The downside is that you'll have to inspect all the locations where you are creating an object, to make sure that they haven't broken. Creating instances becomes more burdensome, although some languages already have facilities to make the process less painful (ex. VB6).
If you are trying to protect an object that has a lot of instantiation activity, you might want to go with Mastermind's method of adding a key parameter, or add an unlock method of some sort to your interfaces that must be called correctly before the component behind it can be used.
You could make your interfaces inheriting directly from IUnknown (without IDispatch) and not include the type library into the DLL. This way only those who have access to the type library will be able to find what interfaces are supported and the only other way to discover the interfaces will be to just guess. If you go this way you might also wish to minimize the number of classes exposed to registry (those that can be created with CoCreateInstance()) and use a set of factory methods of some dedicated registry-exposed class instead.
This implies that only vtable early-binding will work with your component. You will also be unable to use default call marshaling with this component (since no type library is included). And this is not real protection, just a way to hide things.
Nothing prevents you from adding a "key" parameter to the methods which will just return if the key is wrong.
Very simple but will do for starters.
Other than some sort of 'key' param, you can't prevent the curious from discovering your function and then calling it. All it takes is a debugger and some patience. To be totally secure you'd have to require some sort of certificate that authorized code could obtain but all others couldn't but that would mean you're code would have to be able to verify the certificate.