home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2643 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  6.3 KB
  1. Path: easy.in-chemnitz.de!mkmk!floh
  2. From: floh@mkmk.in-chemnitz.de (Andre Weissflog)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Multiplatform Development
  5. Message-ID: <Qqi1y*3F0@mkmk.in-chemnitz.de>
  6. Date: Fri, 02 Feb 1996 01:15:32 CET
  7. Reply-To: floh@mkmk.in-chemnitz.de
  8. References: <4eqr9u$s25@sundog.tiac.net>
  9. Distribution: world
  10. Organization: private uucp site
  11. X-Newsreader: Arn V 1.04
  12.  
  13. In article <4eqr9u$s25@sundog.tiac.net>, Darius Taghavy writes:
  14.  
  15. > Does anyone have experience with multiplatform application development?
  16. > I currently have a large Amiga app (not yet released) that I am 
  17. > considering to port to one or more of Mac/Be/NT/OS2.
  18. > 
  19. > I will keep developing on and for the Amiga, but real life economics
  20. > require me to consider some of these other platforms.
  21. > 
  22. > Main questions:
  23. > 
  24. > a) Graphics
  25. >    what is the graphics API like in these other systems?
  26. >    I.e. On the Amiga we use Move(), Draw(),RectFill(),Text() etc.
  27. >    all of which use a struct RastPort * as first argument.
  28. >    I have already abstracted this layer. For example, I have
  29. >    a text display routine that gets (rastport pointer, x,y, text 
  30. >    pointer) arguments.
  31. >    Do these other API's also use a single handle, such as RastPort?
  32. > 
  33. >         Mac: ?
  34. >         NT:  ?
  35. >         OS2: ?
  36. >         Be:  ?
  37. > 
  38. The graphics APIs should be very different, but there should always
  39. be an actual "graphics context" like a RastPort on the Amiga,
  40. and a set of functions that work on it (on the Be, you will
  41. have C++ objects for that).
  42.  
  43. It may be worth it to write stub functions that have the
  44. same interface as their Amiga counterparts, but translate
  45. the call to the specific OS environment. I have done this
  46. for a subset of iffparse.library functions on the PC,
  47. it works pretty well. The problem with this approach is that
  48. you are basically reinventing the wheel, and the new wheel
  49. will never be as good as the existing one, since you
  50. only have a black box to start from.
  51.  
  52. The other approach would be to write a system indepent
  53. library of primitive functions, and use only those functions
  54. in your higher level application code. Then rewrite the library 
  55. for every new platform.
  56.  
  57. > b) Event Handling
  58.  
  59. Can't really serve with this one.
  60.  
  61. > 
  62. > c) Interrupts/Timers
  63. >    My app uses multiple tasks and interrupts. For a non-multi-tasking
  64. >    OS I could still work, as I can conditionally compile into a
  65. >    single task/multiple interrupt model already.
  66. >    Basically, what I need is:
  67. >     - *hardware* timer interrupt
  68.         ^^^^^^^^^^^^^^^^^^^^^^^^^^
  69. That's a problem on PCs under (at least) MS-DOS. You only
  70. have the system clock running at 18.2Hz. If you want better
  71. resolution, you'll have to hit the hardware directly and
  72. install your own timer interrupt server. Nasty...
  73.  
  74. >     - serial interrupt when receive buffer is full  
  75. >     - serial interrupt when transmit buffer is full
  76. > 
  77. Sorry, no idea.
  78.  
  79. > d) CPU/Memory Architecture
  80. >    I love architectures that are based on a linear address
  81. >    space using the 68K family. I use a lot of pointers and
  82. >    have no intention to ever code for a 16 bit OS.
  83. >    I have heard horror stories about Intel processors and
  84. >    have been fortunate to never having had to code for one.
  85.  
  86. Should be no problem under OS/2, or even Win3.1 386. The 
  87. only thing is, you must run in protected mode with
  88. flat memory model, "modern" OS's do this all the time, for
  89. DOS-apps you'll need a DOS extender. It's really not that
  90. horrifying, with Watcom C for instance, you just say
  91. something like "link as 32bit DOS application running under
  92. DOS4GW", and the compiler will do the rest for you, selecting
  93. the right link libraries etc. You can malloc() memory blocks
  94. as big as you want them, and pointer arithmetics works
  95. just fine, like on real computers. Assembly coding
  96. is actually easier in flat memory model, since you don't
  97. need to mess around with segment registers.
  98.  
  99. It only gets tricky if you want to access exotic BIOS functions,
  100. or (just for example) want to use VESA2.0 calls. But that's
  101. all MS-DOS babble...
  102.  
  103. >    Does NT abstract this somehow? Can you just declare
  104. >    long *whatever; and then reference is the same way as on
  105. >    the ami? Or do you have to deal with memory banks etc and
  106.  
  107. Yes, should work on all systems except MS-DOS without
  108. DOS-extender. Just define your pointers, and fool around
  109. with them.
  110.  
  111. >    contruct a pointer from that. If I had to call a function
  112. >    for every pointer I need it would be too slow and I wouldn't
  113. >    even consider such a rediclious environment.
  114. > 
  115. No problem in protected mode, technically you'll still
  116. have segments, but only one for each code, data and stack, and at
  117. least code and data start both at address 0 and go linearly up to
  118. 4GB. Pointers are always 32 bit.
  119.  
  120. > e) Source Code Database
  121. >    How do you actually compile for the different targets?
  122. >    Since there are no multiplatform compilers on the Amiga
  123. >    such as the ones I looked at on Windows/OS2/Mac, how do
  124. >    you maintain a single code base? (I do not like "cut and
  125. >    paste" development).
  126. > 
  127. Can be tricky to avoid. First, there's #ifdef, but of
  128. course the code will soon be unreadable if there are
  129. too many of them. I use a central "sys.h" header, where
  130. I try to encapsulate some system specific things into
  131. macros.
  132.  
  133. >    What comes to mind is to network the Amiga with the other
  134. >    machine(s), then run the compiler on the other machine,
  135. >    accessing the files stored on an Amiga filesystem and store
  136. >    the object code in separate subdirs (one for each target).
  137. > 
  138. This should work.
  139. Currently I have wired the PC via serial line to my Amiga
  140. and transfer all changes on the sources to the PC, which 
  141. is only used for compiling and some debugging. The ultimate
  142. goal for me is to have only one source base, and either cross 
  143. compile, or compile over a NFS link.
  144.  
  145. > There are other issues. I just typed up the ones that came to
  146. > mind immediately. But this should be enough to get a discussion
  147. > started. A public discussion for the benefit of everyone would be
  148. > great, but if you like to help and stay anonymous for whatever
  149. > reason, I would appreciate private e-mail, even if it's just a
  150. > short hint or two.
  151.  
  152. Hope it helped,
  153. -Floh.
  154.  
  155. ====//=== Andre Weissflog <floh@mkmk.in-chemnitz.de> =======
  156. ...// Sep'95: Return Of The Living Death...................
  157. \\// 90% of everything is crap (Sturgeon's Law)...........
  158. =\\===============================================Amiga!=
  159.  
  160.