Hello,
Just asking, but does anybody knows which are the major dependences from Windows that tie SWIFT to that OS? I' d like to make it run natively under Linux but first I am trying to get some idea of the amount of work that it entails.

Well, your first issue is that it's not written in C, but Pascal (DELPHI) and is heavily OO (so you'd ideally want C++ anyway). Delphi did have a facility to aim at Linux at one point but the support seems to be drifting these days, although technically still in there somewhere I think.

I haven't written professionally in C for 14 years (and even then it was less than a years work) which is one reason it wasn't used.

At some point I may investigate making a Linux version but the time and effort seems to by quite a lot (judging from posts between Samwise and Francis Loch), so it's a time issue at present.

Does it run under WINE OK ?

What did I say that would discourage Linux support?

Hmm ... looking into it, I wonder if Swift could be converted to/compiled with Free Pascal?

I don't believe it's 100% compatible with Delphi, so it depends on what libraries/functions Swift is dependent on.

If you're willing to share the source, I could see next weekend (busy for most of this week) how far I get in porting it (bearing in mind I have no experience with Delphi or Pascal!)? Unless nicolagiacobbe has more Pascal experience?

Sam.

He he, just reading about the issues when you tested some of Francis's work was enough to put me off !

Mmm... FreePascal. Interesting. Delphi used to be pushing Kylix but I'm not sure how you would target particular Linux platforms, not something I've ever looked into seriously.

At the moment as you know this is not an open source project. This is not to say I wouldn't share the source with trusted individuals, but at this moment in time I'm not going to release it.

I've just checked and it weighs in at over 16,000 lines of code - and that's just my stuff (Didn't realiase I'd done so much !), that doesn't include any additional libraries I've used. So could be quite a job getting it converted over if it doesn't go smoothly as well.

One area that would easily fail would be the control over BeebEm, this uses very specific windows API calls, although I know this could be re-written as a library and then that would probably work fine.

I've not written Linux off, I will do some investigations over the coming weeks ad get back to you all, and if I need a porter then I think your the man Sam !

Well, my pascal is a bit rusty.
The Kylix way (a.k.a. Linux Delphi) is feasible (I have and old copy around) but it is heavily based on wine anyway and not much supported those days.
I think that a complete rewrite in C could be a better approach, it is not the main code 'per se' that will give problems (there are some Pascal to C translators that works, arbeit barely) but the windows API dependence.

A big problem is also the absence of a 'de rigueur' BBC emulator under Linux, something like BeebEm (BeebEm Linux is now stopped at v0.13 from past november).

That was the kind of impression I got from Borland. If there isn't a really good emulator on Linux I wonder if it's worthwhile though ? I'm not familiar with how advanced they are.

I don't think the emulators are a problem.

BeebEm for UNIX is still supported by David Eggleston - though it's recently stopped working for me after a recent upgrade, so I need to work with him to figure out what went wrong. It may be based on an older version, but it usually works OK.

That said, the BBC Micro driver in MESS works fine under Linux too, so that's two to choose from, at least.

I'm pretty certain getting Kylix to work on a modern Linux distribution would be a job in itself, and not something I'd want to wrestle with - it would be easier just to use the Windows version of the app under WINE.

Requesting Steve to start again in C is a mighty big ask, tho, unless it's something he wants to do himself. However, getting the current version to compile under Free Pascal (if we can) and then asking him to avoid Windows Delphi-isms, is probably a more acceptable compromise.

What are your thoughts on the subject, Steve?

Sam.

Oh yes, rewriting 16,000+ lines of code in C, don't think I relish that task to be honest ! I'd estimate at 8 hours a day none stop at 60 characters a minute it would take around 2 solid weeks work just to type it up, that's without thinking about re-writing it in C syntax and debugging. Phew... realistically I think you'd be looking at about 6 months work, perhaps more (probably more).

But converting using FreePascal is something to definitely try. If Free Pascal covers window handling then it might not be so bad, leaving re-writing of the communication with BeebEm/Mess for sure and perhaps one or two other bits and pieces. A lot of the screen rendering (i.e. for the Hex Editor,Sprite Editor) is self written accessing the canvas of the window directly, and I think the canvas commands will definitely be covered i free pascal.

I'll have a look at giving it a whirl over the next week or two. Perhaps with a trial project. In fact do you want me to send you a very simple Delphi Project Sam ? And see how it does with that ?

Whoops. I missed this reply!



Well, I was testing most of Francis' Windows stuff under WINE - which is why there were issues. The only Linux port he published, of Image2BBC, he already knew never actually worked.



I'm pretty certain Kylix is dead to all intents and purposes. I really don't think it's a viable option.



Ah, yes, of course - I wasn't implying we had to release the source, just generate a binary but thinking about it in more depth - TBH, Linux distributions change so quickly that binaries can quickly become useless which might make supporting a Linux version more effort than it's worth, if it's binary-only. A lot of Linux users specifically avoid building a dependence on apps they can't get at the source code of, too ...



The initial port would be the hardest - I'm beginning to think this is asking a lot from you. Basically, to achieve it, it would make most sense to open source it as well as getting you to move development platforms from Delphi to Lazarus. This, basically, aims to be a free cross-platform equivalent to Delphi. You write your code for Windows ... then when it comes to release time, it can be re-linked against GTK or QT instead of the Windows GUI components at the click of a mouse, in order to generate a cross-platform version. I think that's too much for us to ask, though, so I'm not sure it's worth pursuing this unless someone wants to rewrite a similar app from scratch, but make it cross-platform. I think that's probably beyond me, tho.



What controls do you need? If we can get away with command line parameters (which is what most unix programs are designed to do), I'm sure Dave would be happy to help us with anything BeebEm for Unix doesn't already provide.



Ulp. Seriously, I did Modula-2 for a few months about 10 years ago. Don't get your hopes up ... I'd be willing to have a crack at it, tho.

If youe're keeping the option open, can I suggest you stay away from anything Delphi-specific, but unless you want to change your development environment and license, I think pursuing this may prove to be more trouble than it's worth (sadly).

Sam.

Dammit, I keep getting out of synch!!!



Nope, that's a task for anyone else who wants to start from scratch with a cross-platform design, not someone with a good-size project already started.



If you want to do some experimentation, sure. I'm quite busy with rl over this weekend and next week, tho, so I might not have lots of time to spare until next weekend, tho.

Would you consider moving away from Delphi to Lazarus if we did manage to get a port working, or are you reluctant to give up a trusted IDE (I know some ppl get very attached)? I don't fancy the idea of having to port Delphi code to Linux after every release ...

Sam.

You need to be able to shut the app down as well so you don't have umpteen windows opening. Guess when you start an app on Linux though you get it's Process ID and can kill it that way ?



I'll not say no at this point, I'd have to check Lazurus out. Get back to you.

I've just had a really quick look at Lazarus, looks interesting. I might give a try with my FS Manager software first (as it's a smaller project) and see what i makes of it.

This thread has expanded blindingly fast hasn't it.

Process killing is easy - simply record the process ID in a text file and kill it when you're done. That can be easily done from shell script. Or, indeed, I think you can just killall beebem processes, without needing an id, instead (tho that might annoy anyone with another window open!). I'm sure handling BeebEm/MESS wouldn't be an issue, unless you have some really deep hooks into the emulator.

I understand about not moving away from Delphi.

I think we've reached the point where you need to go away and investigate Lazarus/Free Pascal (if you want to chuck me stuff to try out I'm happy to assist, but I think it's probably more a case of reading around them).

I guess you need to weigh up the downsides for you of moving to a new IDE/interpreter and, potentially open sourcing, versus the benefit of it being a cross-platform IDE which may get used by more users from other OSs (tho I do think binary-only releases may possibly put some people off on non-Windows/Mac platforms).

Only you can decide if that's a trade-off worth making, though I'm happy to help as best I can if you do try to move it to an open platform. Until then, I think nicolagiacobbe will have to make do with trying to make it work under WINE (tho whether that can be achieved is a project within itself).

Sam.

P.S. And, yes, Lazarus is designed to closely mimic the output of Delphi, which is why I suggested it as the least-painful porting option. Generally speaking, for every Windows-specific development environment there is usually an open source equivalent which is marginally less polished. But, if you use the latter, you'll find it infinitely easier to port it across OSs. It's not because they are open source, it's because they follow open standards. If we could just convince everyone to do that, whether proprietary or free software, the geek world would be SOO much better off.

I am seriously thinking about a Linux version.
Do not get me wrong, I like and respect the job done by SteveO but as SamWise pointed out, an already started medium-sized project is not the best starting point for something multiplatform.
I will have to do a little sanity check first.

Sam, thanks pointing me in the direction of Lazarus, I've just downloaded it and really like the look and feel, even though I've spent only about 5 mins with it.

So much so I think I might have a good potter with it today (RL permitting). Only issue at the moment is that I have some self written components that I need to integrate into Lazarus but they are not complicated affairs at all, just need to work out how to get them into a package for the IDE to see.

Won't be looking at this again now till this evening but I look forward to another play

Glad it's working out for you.

If you move the whole project over to Lazarus, you shouldn't need me or anyone to port it to another OS. I think you should just be able to spit out a re-compiled version for GTK or QT etc. and then just throw it at me to test.

Plus, you'll have that nice, warm, fuzzy feeling that comes when developing for multiple platforms ...

Sam.

Well, of course the best solution would be SteveO developing a multi-platform version of the SWIFT IDE, I have stopped the sanity check on rewriting it in C and will wait for any news from Steve.
Cheers.

Old chestnut question that you've answered probably 100's of times before, but which distro should I go with for testing ? I'll be running it in a virtual machine so no dual booting or anything like that.

Steve,

If you want to test under Linux yourself, I would suggest 32-bit Ubuntu.

Official Ubuntu VMware appliances are available here. Though, personally, I prefer to use VirtualBox for my virtualisation needs.

Ubuntu is very popular, has a good support community, a large software repository, allows you to run KDE and Gnome side-by-side fairly easily, is generally stable and is more user-friendly than most Linux distributions.

Although, of course, I'm available for testing - I run Debian AMD64 Testing, so can flag up any 64-bit issues.

Sam.

Thanks Sam, hope I don't hassle you with too many questions. I'll be using VMWare Workstation as it's what I get supplied for my job. I did install Unbuntu about two years back but never did much with it and I've changed machines since then. It's all downloading now.