[...]
C++ is not a portable programming language and any, non
trivial, program will only work on the system is was
designed to work on.
That's not been my experience. I've moved several large (500
KLoc or more) applications from Windows or Solaris to Linux,
with no real problems. Given the way the language has evolved,
it's often been more work to move to a more recent version of
the compiler than to move from Windows to Unix.
Even a very basic windows winmain function and messsage loop cannot
be
ported, your lucky if it runs on your version of windows nvm Linux.
What's a windows winmain function? I've never seen one.
Standard entry point function for a windows process.
It's certainly not standard, and I've never seen it used.
[...]
I can't think of any programs that requires no user input
User input is often, if not always, from a file.
A lot of Windows "applications" are plugins (e.g. to Excel). In
which case, there isn't really any entry point; they're DLL's,
which require some sort of registration (not just system
dependent, but application dependent) with the hosting
application.
Interestingly enough, you can port such programs to another
system, provided you can find an application which can host it.
Windows DLL's still have entry point functions namely DLLMain.
From the context, I would say they were talking about program entry
point (which is unique in most cases today). For plugin, the entry
points are just some transient callback. Unless you want to execute a
whole application in a dynamic load call; which is not practical
since, the context is then constrained, by example, you can load a
library in a DllMain (I don't know if this applies to threads started
from this point).
......................................................................................................
I think it's quite clear what he is talking about when he says this.."there
isn't really any entry point; they're DLL's, which require some sort of ..."
If you load an Exe you create a new process this is different from loading a
DLL. Although threads are like a mini-process, a process runs in ints own
memory space and has ownership of threads.
threads created in dll's are also owned by the calling process.
I don't know what you mean by a plug-in, I only know of browser plug-ins.
They may be similar across OS's, but the loading/registration process and
function signatures all create a different program structure that cannot
be
ported.
Here is a *very* simple winodws DLL program (at bottom of page). Please
tell
me how it is possible to make this code
portable.
http://msdn.microsoft.com/en-us/library/ms682583.aspx
I don't see your point here. The dynamic load process can be
abstracted away and I have done so on many occasions.
IIRC examples are the Boost.Plugin library or DynObj (I don't known
the state of those project nowadays) .
..........................................................................................................
Using a DLL in itself makes code portable(across applications). To make this
code portable across platform you need to isolate the code that is not
imp-specfic and copy/paste that code into a different program structure.
For example:
returnType winDLL(args){
//non portable code
//portable code copyable into Linux DLL
}
returnType nixDLL(args){
//non portable code
//portable code copyable into windows DLL
}
You need to create 2 different DLL's and compile them on their respective
machines.
I don't know if any compiler/linkers have some support for building a Linux
DLL on a windows machine or vice versa.
I don't think this can be abstracted away at programmer level.
