Porting OSDK

Questions, bug reports, features requests, ... about the Oric Software Development Kit. Please indicate clearly in the title the related element (OSDK for generic questions, PictConv, FilePack, XA, Euphoric, etc...) to make it easy to locate messages.

User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Porting OSDK

Post by Dbug »

<Message posted by Paul on comp.sys.oric>
Hi,

I'm not a Win32 user, but would love to use OSDK. Does anyone know where
the source code is for it so I can recompile and use it natively?

TTFN

Paul
--
"Logic, my dear Zoe, is merely the ability to be wrong with authority" -
Dr Who
Hello !

First, I'd like to know what you mean by "natively". For what I know, this could be Linux, Mac OS, MS-DOS, Atari ST, or Sinclair QL :)

This being said, some parts of the OSDK have been adapted to Linux, by Jede and Jylam. Unfortunately the modifications have more or less been lost in some mail exchanges, and they are kind of hard to contact.

Even with that, you have to consider that the OSDK is made of many heterogeneous parts made by many different people at different times:

- Some batch files that are used to glue everything (that are obviously not portable, but I could probably do a portable version of that, it does not makes anything extrordinary, and they are the main reason about why the OSDK needs a system variable to locates itself...
- The GCC preprocessor
- The LCC65 compiler
- The XA cross assembler
- The Link65 linker
- The tape header creator program

on top of that, you can add the non mandatory parts, that are none the less important if you want to do big projects:
- FilePack (the file compressor)
- PictConv (the picture converter)

Some parts should compile out of the box (if I didn't broke anything), and some are probably hard to port (like PictConv that rely on a old version of FreeImage that was not really designed to be ported)

If you are ok to help me do a portable version of the OSDK, I can provide source code. I'm not really interested by giving away the source code directly on the site, because people would simple hack into the code and never give their modifications (been there already with other projects).

Something important to mention too, is that I do not want in anyway the OSDK to look like CC65 with a full featured linker working with binary format for libraries. With the OSDK I just made a more user friendly version of what Fabrice Frances, Vaggelis Blathras, and Alexios Chouchoulas made before me. Having libraries available as source files is a great idea, and does not slow down the compilation -considering the size of the target machine-.

:)
nodoid
2nd Star Corporal
Posts: 22
Joined: Tue Jan 17, 2006 1:34 am
Location: UK
Contact:

Re: Porting OSDK

Post by nodoid »

Dbug wrote:
"Logic, my dear Zoe, is merely the ability to be wrong with authority" -
Dr Who
That's one of my favourite lines. It also helps distinguish between me at work and me at home (the current home one is "wir kamen, wir sahen, wir traten ihren Esel" - Dr Venkman, Ghostbusters - it's not right, but it's quite funny!)
First, I'd like to know what you mean by "natively". For what I know, this could be Linux, Mac OS, MS-DOS, Atari ST, or Sinclair QL :)
Linux and RISC OS.
Even with that, you have to consider that the OSDK is made of many heterogeneous parts made by many different people at different times:

- Some batch files that are used to glue everything (that are obviously not portable, but I could probably do a portable version of that, it does not makes anything extrordinary, and they are the main reason about why the OSDK needs a system variable to locates itself...
Wouldn't it make more sense to follow the set up of the system (for instance, binaries in /usr/bin and libs in /usr/local/lib for Linux or in Program Files for Win32)?
Some parts should compile out of the box (if I didn't broke anything), and some are probably hard to port (like PictConv that rely on a old version of FreeImage that was not really designed to be ported)
This would pose more of a problem, but be a damned sight more fun IMHO
If you are ok to help me do a portable version of the OSDK, I can provide source code. I'm not really interested by giving away the source code directly on the site, because people would simple hack into the code and never give their modifications (been there already with other projects).
That's the risk you run with open source code. However, yes. I would love to get involved with doing the portable version of OSDK - mainly as I'd like to contribute back to an 8 bit system which was my first "real" computer (I don't count my ZX81 or Spectrum), but which I never really used much other than playing Light Cycle, The Ultra, writing an adventure engine on and a hacked down (hugely) TCP/IP stack.
Something important to mention too, is that I do not want in anyway the OSDK to look like CC65 with a full featured linker working with binary format for libraries. With the OSDK I just made a more user friendly version of what Fabrice Frances, Vaggelis Blathras, and Alexios Chouchoulas made before me. Having libraries available as source files is a great idea, and does not slow down the compilation -considering the size of the target machine-.
I tended to play with z88dk, which sounds similar to CC65 but for the Z80 family, until I moved to 64 bit. Now I need to hack around to get the swine to compile. I'll get there one day...
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

I will reply to all that, and try to get a downlodable version of the source this week-end.

I'm a bit overworking right now... sorry for that :(
nodoid
2nd Star Corporal
Posts: 22
Joined: Tue Jan 17, 2006 1:34 am
Location: UK
Contact:

Post by nodoid »

Dbug wrote:I will reply to all that, and try to get a downlodable version of the source this week-end.

I'm a bit overworking right now... sorry for that :(
Not a problem - it happens to the best of us.

I think recompiling it using Z88DK would be quite amusing...
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

I found an old project "osdk-dev" that I made with Jylam when we tried to do a common tree structure that compile both on windows and linux.

Since I'm not sure it's up-to-date compared to the versions I'm using, I will do some tests first.

I keep you informed.
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

Wouldn't it make more sense to follow the set up of the system (for instance, binaries in /usr/bin and libs in /usr/local/lib for Linux or in Program Files for Win32)?
Well, it makes sense, but it is not necessarily practical or even suitable.

The first thing to consider, is that half of the tools old dos based programs that are totaly unable to cope with spaces in the file paths. It's a good reason for not installing to "Program Files" or "My Documents".

Concerning an installer, it can be nice, but the problem is that the OSDK is typically the kind of think you want to get as various places using different versions just to check if something is not broken. Or to transfer it to another computer (laptop) to work for a while and then copy back to the main machine.

Having a real install would be for me really mainfull.

Now I agree that a better configuration/make system is probably a good idea. Using a real makefile does not really fill me with joice. I still consider that "make" and associated build rules (makefiles) are probably one of the worse thing I ever worked with.

In short, I have no problem with the fact of doing changes that can improve the whole thing, if it does not makes me less productive in the end.
nodoid
2nd Star Corporal
Posts: 22
Joined: Tue Jan 17, 2006 1:34 am
Location: UK
Contact:

Post by nodoid »

Dbug wrote:
Wouldn't it make more sense to follow the set up of the system (for instance, binaries in /usr/bin and libs in /usr/local/lib for Linux or in Program Files for Win32)?
Well, it makes sense, but it is not necessarily practical or even suitable.

The first thing to consider, is that half of the tools old dos based programs that are totaly unable to cope with spaces in the file paths. It's a good reason for not installing to "Program Files" or "My Documents".
The thing you need to ask there though is the targetting. If you have no intention in supporting an operating system which died it's death around 1998 then you will need to keep the filenames in the 8.3 format. However, if you want a platform independent fix, you need to ditch dos and move on. Under linux, using spaces in filename is also frowned on.

There is nothing wrong in using macros defined by the OS (for instance, if I build an RPM under Linux, %{_libdir} will automatically install to either /usr/lib or /usr/lib64. I have the zip file you sent at home and will try and get to look at it tonight and see the viability.
Concerning an installer, it can be nice, but the problem is that the OSDK is typically the kind of think you want to get as various places using different versions just to check if something is not broken. Or to transfer it to another computer (laptop) to work for a while and then copy back to the main machine.

Having a real install would be for me really mainfull.
I tend to do the install step via the makefile.
In short, I have no problem with the fact of doing changes that can improve the whole thing, if it does not makes me less productive in the end.
At the end of the day, isn't that what everyone wants?
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

nodoid wrote: The thing you need to ask there though is the targetting. If you have no intention in supporting an operating system which died it's death around 1998 then you will need to keep the filenames in the 8.3 format. However, if you want a platform independent fix, you need to ditch dos and move on. Under linux, using spaces in filename is also frowned on.
I never wrote I wanted to be DOS compatible.

Some of the programs are doing manual file and path handling, and are not made to cope with long paths or filename, and certainly unable to cope with UNC on windows (\\ComputerName\path) or things with special characters, spaces or multiple extensions.

You will see that some of the sources are from the original K&R time where you had to declare parameters types betwen the function name and the opening brackets.

Most of them compile with tons of warnings, and some are even redefining the headers of what is now the standard C Library.
nodoid wrote:There is nothing wrong in using macros defined by the OS (for instance, if I build an RPM under Linux, %{_libdir} will automatically install to either /usr/lib or /usr/lib64. I have the zip file you sent at home and will try and get to look at it tonight and see the viability.
No problem with that. Using COMPUTERNAME, USERNAME and such is fine under windows too.

But under linux you can assume that there is a compiler and makefiles installed.

Under windows you cannot do such an assumption.
I tend to do the install step via the makefile.
Because MAKE is installed by default.
Have you a way to make it portable, easy to use, and not obliging anyone to install MAKE ?

One possibility is of course to port only the core parts:
- C Compiler
- Assembler
- Linker
- Additional utilities

and then have a different system for gluing everything.

The important thing is to get the source codes of oric projects to be compatible and easily interchangeable.

That one run a .SH file, makefile or a .BAT file is not that important in the end.
nodoid
2nd Star Corporal
Posts: 22
Joined: Tue Jan 17, 2006 1:34 am
Location: UK
Contact:

Post by nodoid »

Dbug wrote: Some of the programs are doing manual file and path handling, and are not made to cope with long paths or filename, and certainly unable to cope with UNC on windows (\\ComputerName\path) or things with special characters, spaces or multiple extensions.
Not a problem.
dbus wrote:You will see that some of the sources are from the original K&R time where you had to declare parameters types betwen the function name and the opening brackets.

Most of them compile with tons of warnings, and some are even redefining the headers of what is now the standard C Library.
That is of far more concern and should be addressed first IMHO.
dbus wrote:
nodoid wrote:There is nothing wrong in using macros defined by the OS (for instance, if I build an RPM under Linux, %{_libdir} will automatically install to either /usr/lib or /usr/lib64. I have the zip file you sent at home and will try and get to look at it tonight and see the viability.
No problem with that. Using COMPUTERNAME, USERNAME and such is fine under windows too.

But under linux you can assume that there is a compiler and makefiles installed.
No you can't assume that at all. It is up to the person how installed the distro what is on there. It is completely possible to install without any form of developer toolchain.
Under windows you cannot do such an assumption.
I tend to do the install step via the makefile.
Because MAKE is installed by default.
Have you a way to make it portable, easy to use, and not obliging anyone to install MAKE ?
Yes. Build it and package for different platforms using something like BitRock InstallBuilder 3.5. AIUI, that package will put everything in the correct places platform dependant.
dbus wrote: The important thing is to get the source codes of oric projects to be compatible and easily interchangeable.

That one run a .SH file, makefile or a .BAT file is not that important in the end.
Surely if the source is written in C and uses the OSDK to compile, it shouldn't make a toss of difference which platform it's compiled on. The problem comes if you write some Oric C and compile using a non OSDK compiler - then you're into the realms of different implementations. Remember, there is no Oric C standard.
Post Reply