• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

What is the future of this platform?

Started by miturbide, 2012.05.27, 19:58:07

Previous topic - Next topic

Joop

Quote from: DougB on 2012.09.22, 20:07:34
QuoteSo we have to invest in "how do you do that" in development

QuoteI also agree we need more information on porting software.

Paul Smedley actually released his whole build environment, and others have been using that to port things. I don't know what the details are now, I got the package when it first appeared, and it does work. I am pretty sure that you need to request the package, and possibly pay a modest fee, to get it now. The package does contain a very brief set of instructions on how to use it, but a user does have to do some serious digging, to learn how to go about porting software, especially when it won't build without modifying the code.

Unfortunately, it is probably not as simple as saying "do this..." with a set of instructions. Each program could require something different, so you would need a set of instructions for each program. The trick is, to get good enough at doing the job, that you can write your own instructions, but learning how to do it, is a lot of work.
I have Paul's environment and it still doesn't set me on going. Its too short, an example program to do yourself and how to might help a lot. And I'm willing to pay a humble fee for that, but it has to set me on the right track! Sorry, I don't agree with you. I even think that you can port automated programs because the things where the compilation hangs are always the same things. So you can publish these problems so we haven't to re-invent the wheel time after time. We need to work together, otherwise we can kiss OS/2 goodbye in the future.

DougB

Quoteand it still doesn't set me on going. Its too short

Actually, it is enough to get you going, but you need to pick a relatively simple project to start with. Something that has already been done, so you know that it will compile  a proper program, so that you aren't fighting with program incompatibilities, as well as with setup problems.

Quotebecause the things where the compilation hangs are always the same things

I'll bet that Paul, and the others, are rolling on the floor, laughing at that statement. They are also crying, because it isn't always that simple.

Paul suggests getting the WGET source, and work with that to get started. It is an excellent starting point because the program is not all that complicated, and you don't need to worry about fancy things, like which direction the window locations count. Once you get the basics to work, you can progress into more complicated things. After you do a few of those types of project, you can move on to more advanced projects, learning as you go.

I found that the hardest part, of getting started, was to tweak my setup so that it would work. Once I got that going, other things were easier. You don't want to be starting off by trying to build Firefox, simply because you would have no idea if a problem was caused by your setup, or by some code incompatibility.  The most important thing, is don't be afraid to try things, but be aware, that doing that can cause damage to your system, if you get really unlucky.

Joop

Quote from: DougB on 2012.09.23, 07:46:23
Quotebecause the things where the compilation hangs are always the same things

I'll bet that Paul, and the others, are rolling on the floor, laughing at that statement. They are also crying, because it isn't always that simple.
Keep on rolling laughing on the floor  ;D, at the end we'll see.

dryeo

Here's a couple of porting guides. Understand that they are old and geared towards EMX and many of the referenced problems have been fixed in kLIBC.
http://www.os2site.com/sw/dev/guide.html
http://www.os2site.com/sw/dev/porting-faq.zip

Quote from: Joop on 2012.09.23, 16:36:00
Quote from: DougB on 2012.09.23, 07:46:23
Quotebecause the things where the compilation hangs are always the same things

I'll bet that Paul, and the others, are rolling on the floor, laughing at that statement. They are also crying, because it isn't always that simple.
Keep on rolling laughing on the floor  ;D, at the end we'll see.

Some compilation hangs are simple, eg needing socklen_t typedef. Some are complex such as our TCPIP stack not having getaddrinfo(), a very common function now a days as it supports both ipv4 and ipv6.
The real problems often happen after compilation succeeds, line ending issues is probably the most common. Many times you can find where the issues have already been fixed for Windows and just adding __OS2__ to a define may fix it.
A lot depends on the original source being written with portability in mind. If it uses calls to the Linux kernel such as Gnome does now, then even compiling on *BSD becomes very hard.

diver

Quote from: ivan on 2012.09.22, 19:01:25
I also agree we need more information on porting software.  I am not a programmer but I would be prepared to try IF I knew where to begin.  For example, I use Sigil to produce epubs of the manuals we produce, thanks to Paul we have a port of it but it is version 0.2 and rather short of the features of the latest version 0.5.  If I knew how to start and setup what is necessary to port version 0.4.5 which is the last version possible because of QT4 restrictions, I would try and see if I could port it.

does Sigil 0.5 and better need Qt 4.8? If not it should be possible to port as well, as our Qt 4.7 is very good.

regards
Silvan

ivan

Hi Silvan,

The best I can do is point you to the answer I got when I asked that question on the Sigil forum http://www.mobileread.com/forums/showthread.php?t=189434  see reply #7.

There is also an ongoing discussion re the beta 0.6 version  http://www.mobileread.com/forums/showthread.php?t=191617

I do agree that our Qt 4.7 is excellent - thank you - I use it for things like CoolReader, Image resize (SIR) and so on.

ivan

diver

Qt 4.8 will come sooner anyway, so stay tuned.

regards
Silvan

Paul Smedley

Quote from: DougB on 2012.09.22, 20:07:34
QuoteSo we have to invest in "how do you do that" in development

QuoteI also agree we need more information on porting software.

Paul Smedley actually released his whole build environment, and others have been using that to port things. I don't know what the details are now, I got the package when it first appeared, and it does work. I am pretty sure that you need to request the package, and possibly pay a modest fee, to get it now. The package does contain a very brief set of instructions on how to use it, but a user does have to do some serious digging, to learn how to go about porting software, especially when it won't build without modifying the code.

Unfortunately, it is probably not as simple as saying "do this..." with a set of instructions. Each program could require something different, so you would need a set of instructions for each program. The trick is, to get good enough at doing the job, that you can write your own instructions, but learning how to do it, is a lot of work.

http://os2ports.smedley.id.au/index.php?page=BuildEnvDVD for those that may be interested.  The disc contains a zip of my current build environment.

Paul Smedley

Quote from: Joop on 2012.09.22, 20:59:51
Quote from: DougB on 2012.09.22, 20:07:34
QuoteSo we have to invest in "how do you do that" in development

QuoteI also agree we need more information on porting software.

Paul Smedley actually released his whole build environment, and others have been using that to port things. I don't know what the details are now, I got the package when it first appeared, and it does work. I am pretty sure that you need to request the package, and possibly pay a modest fee, to get it now. The package does contain a very brief set of instructions on how to use it, but a user does have to do some serious digging, to learn how to go about porting software, especially when it won't build without modifying the code.

Unfortunately, it is probably not as simple as saying "do this..." with a set of instructions. Each program could require something different, so you would need a set of instructions for each program. The trick is, to get good enough at doing the job, that you can write your own instructions, but learning how to do it, is a lot of work.
I have Paul's environment and it still doesn't set me on going. Its too short, an example program to do yourself and how to might help a lot. And I'm willing to pay a humble fee for that, but it has to set me on the right track! Sorry, I don't agree with you. I even think that you can port automated programs because the things where the compilation hangs are always the same things. So you can publish these problems so we haven't to re-invent the wheel time after time. We need to work together, otherwise we can kiss OS/2 goodbye in the future.

I can either spend time writing a bunch of docs, or I can spend what little free time I have working on OS/2 related projects.

Or I can spend my time hacking away at my debian server.

I'm not terribly fussed either way...

The community is welcome to write some docs for my build environment - I'm even happy to include those docs with future editions of the disc (with a credit to whoever creates them).

ivan

Hi Paul,

I don't think anyone is asking you to stop doing what you are doing to write a manual.  Myself, am very thankful for what you do - in fact I'm still using the port of Sigil you did.

What I would appreciate is the odd extra line in the readme giving the command you used to build the program - I always miss something when I attempt to build a program and being able to look at what someone has used and been successful with might be the thing that would help me to be successful as well.

I am a guilty as the next person in not thanking you and the others for the work you do for OS/2.  At 70 odd I plead forgetfulness most of the time but this time it is my heartfelt thanks.

ivan

DougB

QuoteI don't think anyone is asking you to stop doing what you are doing to write a manual.

I agree. Paul is not the one to write the manual. He developed his methods the hard way, learning as he went. That usually makes a person skip the obvious, simply because it is obvious (to him). What we need, is somebody to go through the procedure, asking questions along the way, and documenting what needed to be done, and why. I am sure that there are enough people who have done the basics, that we should be able to answer questions, and get something to work.

Any volunteers?

Paul Smedley

Quote from: DougB on 2012.09.28, 00:03:20
QuoteI don't think anyone is asking you to stop doing what you are doing to write a manual.

I agree. Paul is not the one to write the manual. He developed his methods the hard way, learning as he went. That usually makes a person skip the obvious, simply because it is obvious (to him). What we need, is somebody to go through the procedure, asking questions along the way, and documenting what needed to be done, and why. I am sure that there are enough people who have done the basics, that we should be able to answer questions, and get something to work.

Any volunteers?

And I quote.... "I have Paul's environment and it still doesn't set me on going. Its too short, an example program to do yourself and how to might help a lot"

An example of a user who took my environment and ran with it, asking a lot of questions along the way, is Elbert Pol - who has now ported a shedload of apps for OS/2 - far more that I've done in recent times.

miturbide

I think it may help if someone can write some article on the EDM/2 on how to set up Paul's environment.

I had used it to create a "hello world" command line program once, reading a very simple GCC online tutorial.

Martín Itúrbide
OS2World.com NewsMaster
Open Source Advocate

Skype - martiniturbide
Google Talk - martiniturbide@gmail.com

dryeo

Quote from: Paul Smedley on 2012.09.28, 00:51:20
An example of a user who took my environment and ran with it, asking a lot of questions along the way, is Elbert Pol - who has now ported a shedload of apps for OS/2 - far more that I've done in recent times.

Elbert is a good example, he asks lots of questions. I'm often surprised how often I look at some development mailing list archives and there is Elbert asking something.

comp.os.os2.programing.porting is one place to ask questions.

DougB

QuoteI think it may help if someone can write some article on the EDM/2 on how to set up Paul's environment.

Setting up the environment means following the readme.os2 that comes with it. There is no magic there, just do as it says. Of course, you do complicate things somewhat, if you use a different drive letter.

I think the main problem is "what do I do now?" I guess the answer would be to pick a project that you want to build, and then do it. Then, it will either build, or it won't. If it does, you can be pretty sure that your basic setup is good. If it won't build, you need to figure out why it won't build, and that is where asking lots of questions (without being a PITA) comes in. The WGET program was suggested as a reasonable staring point, because it is relatively simple, and it is known to build, without problems (at least that is what I understand, I haven't actually tried it, so let's have a go.

The source is available at: http://www.gnu.org/software/wget/

You have the basic choice of an HTML page, or a FTP page. Now, you need to determine what package to get. Lets be brave, and pick the latest version (1.14). Now, there are 4 files for that. 2 are .sig files, which are probably some sort of file verification thing. We will ignore them. Now, you have a choice between wget-1.14.tar.gz or wget-1.14.tar.xz. I have no idea what .xz is, but .gz is something that the eCS archive viewer will unwrap, so lets see what we get. Looks okay to me (but what do I know?).

The download file contains a directory (wget-1.14). Put that on the same drive as Paul's build environment. Then, click on the icon that you built to launch paul's build environment. That should get you to a command line. Change to the wget-1.14 directory, and now we need to figure out how to build it. Paul's instructions are a little confusing at this point (and somewhat incomplete in some more complicated cases).

Since I am tired, I will quit here, and hopefully, somebody will make this a little easier. I am not at all sure if I still have the original setup files, or if I have messed around with them. I don't normally use the setup as Paul supplied it (which seems to be set up to build a mozilla derivative, and I do not have the latest version), so I am somewhat lost here. I am sure that most people will have the same problem.