Just a thought, here. Perhaps those of you who develop cross-platform apps could post some hints and tips on how differences are handled?
I am thinking of using include files that hold anything OS specific. But I am sure there is a better way. And I think many would appreciate ideas on this. Especially if the linux gurus also showed the linux equivalents for winapi calls.
Cross-Platform ideas
Cross-Platform ideas
@}--`--,-- A rose by any other name ..
Well first of all, it is impossible to write a big project completly without using at least some
platform specific commands. That is simply because PB can never include commands
for any task that someone might imagine.
So you will have to deal with it one way or another.
A few things to consider:
Keep API stuff at a minimum.
I think the reason is clear. The less platform specific code there is, the better.
Do not worry too much about speed here (unless you write games).
In application development, speed is usually not that important, as most of the
time is spend waiting for user input anyway, so if you can replace an API call
with a (maybe more complex or slower) PB only code, than this is often the better way to go.
Do not develop everything on the same OS.
The OS where you do the development on is the one where you do the most testing.
Even when you do frequent tests on the other OS, the code will never be executed as often
as on the OS where it was actually written.
To ensure that it really works well on all OS, it is a good thing to switch the
OS you are coding on from time to time.
This effect can be seen on the PureBasic IDE. The Linux version was quite
stable from the beginning, because that is where ~75% of its code was written.
The Windows version however had quite a big number of bugs in the beginning.
Different OS do things differently. The Windows memory management might
tolerate a mistake in your code, while the Linux one might immediately crash.
Switching the OS while you still know which changes were made since the
last time you compiled on a particular OS makes it much easyer to find such bugs.
By developing on not only one OS, you also get to know the OS better from
a developper standpoint, and by getting to know how things need to be done
on the different OS makes it much easier to organize the code.
Find a way to manage changes in your code.
This is also true for large projects on one platform only, but even more for
crossplatform ones in my opinion.
Remember, you are basically developping multiple versions of the same product.
When you make changes to the Windows specific part of your program,
you have to make sure that the same change is applied to the windows
part too, as soon as you are working on that again.
A version management system such as CVS or Subversion can be very usefull
here, even if you are only a single developper, because it allows you to
keep track of changes, see the differences made since the last "commited" version,
and also go back to previous versions if needed.
A system like this is much cleaner than just putting the code on a shared
drive and editing it from the different OS, because it forces you to do things
in a more organized fashion, and that can really save you from lots of trouble here.
Keep things separate.
Crossplatform code should be separated from the OS specific code as much
as possible. I know the temptation is big to just insert a little fix with a "CompilerIf"
here and there, but if you do that too often, you will get into a mess.
Here is my approach to this:
First of all, you have to know what needs to be done on each OS to acomplish
the task that needs to be done. It is quite important to know that before
you implement it. For new stuff i therefore usually start up with a separate
test code, where i can mess around and find out the best way to do things.
Then, find the common tasks to do on all OS and put that code with the
crossplatform code, everything else, put into a procedure for this task that exists for each OS.
This function should be clearly defined in terms of what it does and what
parameters and conditions it expects. Inside that procedure is where the
all the API calls are located then.
Even for tasks that are only needed for one OS, i usually create a procedure
that exists on all OS and is simply empty for the other ones. Remember,
speed is often not an issue, so an empty procedure call does not really hurt.
Of course the description comments for this procedure must mention this.
I usually put such OS specific procedures in one separate file for each OS.
Such a separation has many positive effects. It reduces the overall code
size, as all the common tasks exist only once. It also makes it clearer
which code belongs where, as you know that in such a OS specific file,
you can put any API call where you want, and everywhere else you can't.
It also makes a port to another OS much simpler. The port of the PureBasic IDE
to MacOSX was a relatively easy task, as we simply dublicated the OS
specific files from linux and modified them until it compiled again.
If you have the OS specific code all spread out between the other code,
such a task will be hard work.
For smaller differences between the OS, sometimes just defining a constant
with the proper value for each OS does the trick. For example i always
set up a constant for the path separator and one for the newline sequence
on each OS at the beginning.
This makes also sense for the gui fontnames, the default path options and so on.
A well choosen set of constants with a different meaning on each OS can
save lots of OS specific code.
platform specific commands. That is simply because PB can never include commands
for any task that someone might imagine.
So you will have to deal with it one way or another.
A few things to consider:
Keep API stuff at a minimum.
I think the reason is clear. The less platform specific code there is, the better.
Do not worry too much about speed here (unless you write games).
In application development, speed is usually not that important, as most of the
time is spend waiting for user input anyway, so if you can replace an API call
with a (maybe more complex or slower) PB only code, than this is often the better way to go.
Do not develop everything on the same OS.
The OS where you do the development on is the one where you do the most testing.
Even when you do frequent tests on the other OS, the code will never be executed as often
as on the OS where it was actually written.
To ensure that it really works well on all OS, it is a good thing to switch the
OS you are coding on from time to time.
This effect can be seen on the PureBasic IDE. The Linux version was quite
stable from the beginning, because that is where ~75% of its code was written.
The Windows version however had quite a big number of bugs in the beginning.
Different OS do things differently. The Windows memory management might
tolerate a mistake in your code, while the Linux one might immediately crash.
Switching the OS while you still know which changes were made since the
last time you compiled on a particular OS makes it much easyer to find such bugs.
By developing on not only one OS, you also get to know the OS better from
a developper standpoint, and by getting to know how things need to be done
on the different OS makes it much easier to organize the code.
Find a way to manage changes in your code.
This is also true for large projects on one platform only, but even more for
crossplatform ones in my opinion.
Remember, you are basically developping multiple versions of the same product.
When you make changes to the Windows specific part of your program,
you have to make sure that the same change is applied to the windows
part too, as soon as you are working on that again.
A version management system such as CVS or Subversion can be very usefull
here, even if you are only a single developper, because it allows you to
keep track of changes, see the differences made since the last "commited" version,
and also go back to previous versions if needed.
A system like this is much cleaner than just putting the code on a shared
drive and editing it from the different OS, because it forces you to do things
in a more organized fashion, and that can really save you from lots of trouble here.
Keep things separate.
Crossplatform code should be separated from the OS specific code as much
as possible. I know the temptation is big to just insert a little fix with a "CompilerIf"
here and there, but if you do that too often, you will get into a mess.
Here is my approach to this:
First of all, you have to know what needs to be done on each OS to acomplish
the task that needs to be done. It is quite important to know that before
you implement it. For new stuff i therefore usually start up with a separate
test code, where i can mess around and find out the best way to do things.
Then, find the common tasks to do on all OS and put that code with the
crossplatform code, everything else, put into a procedure for this task that exists for each OS.
This function should be clearly defined in terms of what it does and what
parameters and conditions it expects. Inside that procedure is where the
all the API calls are located then.
Even for tasks that are only needed for one OS, i usually create a procedure
that exists on all OS and is simply empty for the other ones. Remember,
speed is often not an issue, so an empty procedure call does not really hurt.
Of course the description comments for this procedure must mention this.
I usually put such OS specific procedures in one separate file for each OS.
Such a separation has many positive effects. It reduces the overall code
size, as all the common tasks exist only once. It also makes it clearer
which code belongs where, as you know that in such a OS specific file,
you can put any API call where you want, and everywhere else you can't.
It also makes a port to another OS much simpler. The port of the PureBasic IDE
to MacOSX was a relatively easy task, as we simply dublicated the OS
specific files from linux and modified them until it compiled again.
If you have the OS specific code all spread out between the other code,
such a task will be hard work.
For smaller differences between the OS, sometimes just defining a constant
with the proper value for each OS does the trick. For example i always
set up a constant for the path separator and one for the newline sequence
on each OS at the beginning.
This makes also sense for the gui fontnames, the default path options and so on.
A well choosen set of constants with a different meaning on each OS can
save lots of OS specific code.
quidquid Latine dictum sit altum videtur
I'm translating this post for a french site http://purebasic.developpez.com/
And i would like to add few examples, but i know nothing about linux and MacOS.
or this :
Freak is it possible to know how many lines there are for the IDE ? and how many lines with API ? just to add those informations in the article if you are agree.
And i would like to add few examples, but i know nothing about linux and MacOS.
Can someone show a small code for this ?For smaller differences between the OS, sometimes just defining a constant with the proper value for each OS does the trick. For example i always set up a constant for the path separator and one for the newline sequence on each OS at the beginning.
or this :
Does anyone have some other examples like this to show ?This makes also sense for the gui fontnames, the default path options and so on. A well choosen set of constants with a different meaning on each OS can save lots of OS specific code.
Freak is it possible to know how many lines there are for the IDE ? and how many lines with API ? just to add those informations in the article if you are agree.
Please correct my english
http://purebasic.developpez.com/
http://purebasic.developpez.com/
Thank youfreak wrote:The IDE code is now at 60 000 lines, with around 6 000 in platform specific files.
Given the fact that the 6 000 actually counts the code for all 3 OS, the IDE on
each platform contains only about 3% API code, which is not really much.
Please correct my english
http://purebasic.developpez.com/
http://purebasic.developpez.com/
Future
So that 3% then gives you an idea of candidate API calls which can be made cross-platform in the future by PB, eh?freak wrote:The IDE code is now at 60 000 lines, with around 6 000 in platform specific files.
Given the fact that the 6 000 actually counts the code for all 3 OS, the IDE on
each platform contains only about 3% API code, which is not really much.
