home *** CD-ROM | disk | FTP | other *** search
/ C/C++ Interactive Guide / c-cplusplus-interactive-guide.iso / c_ref / csource1 / mpegplay / os2port.txt < prev    next >
Encoding:
Text File  |  1994-02-16  |  3.1 KB  |  80 lines
  1. Porting of Berkeley mpeg_play to 32 bit OS/2
  2. --------------------------------------------
  3.  
  4. The ported source, ported executable and this file will be / have been
  5. sent to toe.cs.berkeley.edu. I also intend to upload this elsewhere.
  6.  
  7. The target compiler was IBM C-Set++ 2.0. Turning optimisation on does not
  8. appear to break the decoder. Still, it doesn't seem to get it to go much
  9. faster either!
  10.  
  11. To make everything work on FAT filesystems, I have changed all names to the
  12. 8.3 convention. Accordingly mpeg_play is now MPEGPLAY.EXE.
  13.  
  14. I always defined OS2, so that wherever I had to add a hack, I could use
  15. #ifdef OS2. Wherever I made a change, I put a comment with @@@ in it.
  16. The files os2port.h and os2port.c encompass any additional source required.
  17.  
  18. I built all the code multithreaded (/Gm+). This was obviously not a requirement
  19. but is the way I build all my code. Single threaded librarys never seem to
  20. make a significant difference in performance.
  21.  
  22. I wrote a makefile.os2 which makes it.
  23.  
  24. I had to change the fopen(, "r") to use "rb" instead. .MPG files are binary.
  25. Portability could have been aided here by using "rb" etc. (on all systems
  26. I know the b is ignored).
  27.  
  28. random() got mapped to rand() on OS/2.
  29.  
  30. I #ifdef-ed various input event related stuff from XWindows.
  31.  
  32. The signal handler definition must be fully prototyped for OS/2, so I did it.
  33.  
  34. This port supports 320x200 at 8bpp VGA mode display, hence the -dither color
  35. option got removed.
  36.  
  37. The easiest way for me to port the code, given its highly intricate dependency
  38. on XWindows for me to write a module XSTUB, which fakes up enough XWindows
  39. for MPEG Play to work.
  40.  
  41. I defined PIXEL(p) to be p or pixel[p] depending upon whether building for OS/2
  42. or not. This is because in OS/2 I know in many cases pixel[i]==i, so I can
  43. avoid indexing the pixel table. This should make things go faster, but doesn't!
  44. Perhaps my machine has a decent cache size?
  45.  
  46.  
  47. Suggested improvements
  48. ----------------------
  49.  
  50. The supplied code is riddled with XWindows calls, and this is the main problem.
  51. Fundementally, this code creates a window of a given size, gets a palette for
  52. it, and writes bits to the window. A single source file could encapsule the
  53. XWindows dependencies and provide the entrypoints given above. This would have
  54. made my porting job much much easier.
  55.  
  56. Use 8.3 naming convention for files. Allows easier port to OS/2 and DOS.
  57.  
  58. Use ANSI fully prototyped definitions everywhere. How many machines can you
  59. name having only K&R C compilers and not ANSI?
  60.  
  61. Use #defines OPEN_READ_ASCII, OPEN_READ_BINARY as "r" "rb" on OS/2 and DOS,
  62. or "r" "r" on UNIX. Use these wherever fopen() is used.
  63.  
  64.  
  65. Legal-junk
  66. ----------
  67.  
  68. This port was done in my own time with my own equiptment.
  69. It is nothing to do with IBM (despite my address quoted below being in IBM),
  70. or any other company.
  71.  
  72. The basic code I started from may be "freely distributed", so are my
  73. porting changes, and therefore so is the final result.
  74.  
  75.  
  76. {{{ Andy Key
  77.  
  78. Internet: ak@vnet.ibm.com            # Contract valid until Sept 94
  79. IBM-VNET: AKEY @ HVTVM5                # so addresses valid until then
  80.