Good morning / afternoon
Unity itself lacks the ability to allow you to control the “target” render window, although this is a single “bit” switch when they compile the player, it is not in their design to allow you to do it yourself,
In directX, this is simple enough to do, same with direct3d and openGL, they all have a feature that allows them to start up either full screen or in a window, or even on a control (like a panel, picture box, etc), the thing is, you have to pass in a boolean value of how to start it up (windows, full screen) and a pointer to the object it will render in. Since Unity uses OpenGL, this feature is disabled for us. Ultimately all we really need is the ability to pass the window handle of the device context that we want to render in. There is like a million GL / DX / DD examples on how to start up your own instance and draw in a window or what ever you want. The architecture of Unity locks this down though, they do not want their program run natively inside someone elses program. Simple enough.
The only work around you have right now as of 3.1.03f is to simply create a web browser control in your program and then have that control launch Unity as a web app by simply pointing to the html code that runs the activex control of Unity. Even though you will be running the program locally, you can still interact with Unity as it is run in the window through TCP/IP, RakNet, or other networking interfaces, this approach can have its upsides and downsides, it is not ideal, but it is functional. Simply put, our hands are tied to their architecture when using their program as our engine.
You see, Unity itself is an interpreter, all libraries of code are actually external to their player, the player is no different than that of 3Impact as an example, (at least unlike 3Impacts DLL version, just like its Binary version), all of our code is compiled into a single DLL, no brainer on that one, Unity then hooks into this self contained library of libraries to run our code, in truth, this means that they can update their player and if we never change our code, we can redistribute their player binary to our package and not have to rebuild the code.
The downside to this is that they can deprecate code which could in theory break working programs, but they have been very good at keeping this to a bare minimum over the years.