• 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

Newbie: Need advise in OS2 programming

Started by CKKwan, 2007.10.23, 10:21:55

Previous topic - Next topic

CKKwan

Sorry in advance if the question is too simple. I can't find any FAQ for newbies here.

I have been assigned to work on an OS2 program with the requirement below:
1. With GUI
2. TCP and UDP Socket
3. Run on OS2 (don't know which version)

Question:
1. Can I write using MFC? I know the chances is very slim.
2. Can I write using Java?
3. If I use only Win 3.1 API, what WInsock can I use?

TIA.

Radek

(1) No.
(2) Yes, but the "newest" version available to you will bee 1.4.2
(3) In fact, you can write a winblows 3.1 app instead of an OS/2 one - OS/2 will run your app in a "seamless" session so that the app will pretend being a full sized PM application. But ...
(a) I am not sure whether your customer will "buy" it.
(b) You can run into problems with additional DLLs

warpcafe

Hi,

I doubt that MFC and OS/2 fit together... not sure however, one never knows... if you go back in time and releases far enough...?

IIRC, you could use VB for example up to version 4 (where it still supports Win 16bit) and again, not sure if there's a useful vbx/ocx for sockets access then - that's too long ago. ;-) Note however that many people don't like running 16bit Windows apps on their OS/2 or eCS... for me personally, there's either "native" or "Java"... so:
If I was to write it, I'ld use REXX via DrDialog (which is an IDE for developing rexx-based GUI apps) and use the rexx-tcp library. That would give you interpreted code but fast, stable and "native".
If you don't know REXX, that will be of no help - so here's the suggestion:

Go for Java.
As long as you can do it in J2SE up to 1.3 or -say- 1.4 it should work out of the box on a contemporary eCS or OS/2 (depending on the JRE installed). The additional benefit (=extra value!) would be that it's platform-independant and could also be run on Windows... for whatever purpose (testing? doc?) moreover, you won't have to fiddle around with strange "OS/2 stuff" but could use java libraries/classes etc. for doing the sockets processing.
You might need the help of a third party or some "volunteers" for doing the testing perhaps, unless you are provided with a working machine (and working Java) running OS/2 or eCS...

Note that I'm no Java developer! I can't tell if what I suggest really works... :-)

Hope this helps, regards,
Thomas
"It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that"
- G.H. Hardy

Andi

Maybe you can find some interesting infos on www.edm2.com, especially in the developer tools section.

Socket examples are in the toolkit (os2tk45).

For C++ and C leading edge GUI development, VAC4.00 will be the preferred tool. But it's doable with OpenWatcom too.

RobertM

#4
Hi,

Thomas' and Andi's suggestions are both with lots of merit... so now you simply need to choose your path.

If you are going for speed in development, REXX might be the way to go. You can make a REXX program cross platform with a little bit of effort... all you need to do is sub-divide the code between the "get the work done" code and the GUI... and then write GUI code dependent on the OS and GUI tools (for instance, GUI code for Dr Dialog, and GUI code for Regina REXX for Windows). Other than that, you just need to make sure you dont use any OS/2 specific calls/code (which you shouldnt need to - so that shouldnt be a problem). I'm currently working on a program to do mapping, which I will be primarily coding in REXX, and intend to be cross-platform (by making each section modular so I can swap in and out the OS specific GUI and drawing sections).

Java, as Thomas pointed out, is also a wonderful, cross platform solution to write your app in... and as long as it works on OS/2, it should work on any other implementation of Java (since they will all be at the same Java level or higher).

VAC++ 4.0 as Andi pointed out (if you can get copies) is also a great method if you feel comfortable working with C++ code. VAC++ produces (at least on OS/2) VERY VERY fast code (though, as Thomas pointed out, REXX will also produce more than sufficiently fast code for your needs), and can be cross-compiled for Windows.


One note about using Dr Dialog... you need to take a few extra steps if you think the app may be run on a system where the REXX subsystem is changed from ObjectREXX to ClassicREXX (or vice versa). You need to either "compile" a version for each (no code change needed), or write a startup script that removes the EAs from the file. The reason being is when you "compile" (and first run) the code, it tokenizes the code and attaches it in the file's EAs... the OREXX tokenized code will not run on CREXX and vice versa. Removing the EAs will resolve that (when the app is run, it will re-create them for whatever version of REXX is running) - just as having two versions compiled (one for each version of REXX) will alleviate that issue as each will have the correct tokenized app attached.

Either method is very easy (and ONLY necessary if you think someone may change which REXX subsystem is running)... so dont let that "issue" discourage you from a REXX solution.

If you have the time to devote to coding the app (and the programming experience in Java or C++), I'd probably choose Java or VAC++. If you poick VAC++ you will find dozens of manuals and sample code to help you along your way (the documentation that comes with it is VERY large, covering virtually every nuance of programming and compiling under VAC++).


-Robert


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|