home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 15 Message / 15-Message.zip / oe991016.zip / Pr991015.txt < prev    next >
Text File  |  1999-10-16  |  14KB  |  360 lines
  1.  
  2.                   OS/2 Programming                 (Fidonet)
  3.  
  4.                  Saturday, 09-Oct-1999 to Friday, 15-Oct-1999
  5.  
  6. +----------------------------------------------------------------------------+
  7.  
  8. From: Vitus Jensen                                      08-Oct-99 00:40:04
  9.   To: Will Honea                                        10-Oct-99 01:50:04
  10. Subj: VAC 3.0 Subsystem Librar
  11.  
  12. Hello Will,
  13.  
  14. 05.10.99 02:15, Will Honea wrote a message to Vitus Jensen:
  15.  
  16. VJ>> I'm implementing some DLLs to allow third party applications to
  17. VJ>> control machines via serial lines.  The DLLs use CRT routines
  18. VJ>> (malloc,free) and are currently statically linked to their own
  19. VJ>> version of CRTs. I'm wondering whether those statically linked
  20. VJ>> CRTs are the correct way to do it or may even cause errors (in
  21. VJ>> fact there is currently a hang situation reported).
  22.  
  23.  WH> Well, static linking is a good way to use LOTS of memory.  Since
  24.  WH> you are using several DLL's you could save a lot of space by
  25.  WH> dynamic linking.  I use it in one big app I work on and the RTL
  26.  WH> (re-named per IBM rules) is bigger than any of the 'functional
  27.  WH> DLL's.
  28.  
  29. The DLLs are quite simple and don't use much of the CRT.  Filesizes between 50 
  30. and 70 KB with static linking.  And the machine is really oversized for the
  31. job: 128 MB RAM.
  32.  
  33.  
  34. VJ>> Could someone explain the use of the subsystem library (compile
  35. VJ>> switch /Rn)  and whether it's use would be better in my case. And
  36. VJ>> please remember that I have a thread hidden inside the DLLs
  37. VJ>> (currently started via _beginthread but /Rn doesn't support it,
  38. VJ>> DosStartThread plus some magic code required?).
  39.  
  40.  WH> I use _beginthread() liberally.  Most of my threads deal with
  41.  WH> comm links - network and serial - so it only makes sense to spin
  42.  WH> them off that way.  There are some slicker ways to instantiate
  43.  WH> the threads but they all seem to deny me some important tweeking.
  44.  WH>  A couple of the threads I run will need from 28k to 4 meg for
  45.  WH> stack/heap and _beginthread() allows me the flexibility to
  46.  WH> allocate enough that the thread can then commit whatever it
  47.  WH> really needs.  BTW, all these threads are launched from DLL code
  48.  WH> and use semaphores and a message queue for control and
  49.  WH> process-related communications.  
  50.  
  51. And those DLLs use statically linked full/subsystem CRT?  Or a shared CRT as
  52. DLL?
  53.  
  54.  
  55.  WH> Just be VERY careful of where you put your waits and be extra
  56.  WH> meticulous about cleanup on thread exit.  The biggest trap the
  57.  WH> programmers I work with fall into is misuse of shared memory -
  58.  WH> they just can't seem to clean up after themselves.  I think it's
  59.  WH> a carryover from using multiple processes rather than true
  60.  WH> threads.  Just to ease your mind a little, one comm job that gets
  61.  WH> done has been known to run over 100 threads in an iterative
  62.  WH> challenge-reply communications exchange and I've always been able
  63.  WH> to kill the process cleanly at any stage.  
  64.  
  65. Actually I think memory allocation/cleanup, waiting (or not waiting) for
  66. threads to die is no complicate task.  You have to stop and think sometimes
  67. but, well, you write every line and there is always time to think (or should).
  68.  
  69. The most complicated in this scenario are the things you don't see.
  70. What happens in _DLL_InitTerm?   With full CRT support you don't really need
  71. to code your one but what has been done by the compiler vendor?  I can tweak
  72. VAC to call DosWaitEventSem(,-1) during the _CRT_Term called in
  73. _DLL_InitTerm...
  74.  
  75. Another major point are exceptions.  I've learned that I need my own exception 
  76. handlers if I use my own CRT (#pragma handler will do).  But what has to be
  77. done in threads started by _beginthread?  And won't my exception handler
  78. return XCPT_CONTINUE_SEARCH if it doesn't want to handle the exception?  This
  79. will end up in the application's exception handler which has no idea about the 
  80. code which generated the exception...
  81.  
  82. With /Rn there is no need for exception handlers (as I understand?).
  83.  
  84.  
  85.  WH> Also, don't be fooled by the IOC propaganda - the base API's like
  86.  WH> _beginthread()\_endthread() are still quite available.
  87.  
  88. ?IOC?
  89. The compiler tells me that /Gm isn't compatible with /Rn and ignores it.  For
  90. this reason prototypes of _beginthread/_endthread aren't available.  When I
  91. scan cppon30.lib (I think this is the library the compiler links with) then
  92. there the word 'thread' can't be found.
  93. Are you sure that /Rn supports _beginthread?
  94.  
  95. C-x C-s
  96.     Vitus
  97.  
  98. --- Sqed/rexx 114:
  99.  * Origin: Coming Soon!!  Mouse Support for Edlin!! (2:2474/424.1)
  100. 7102/1
  101.  
  102. +----------------------------------------------------------------------------+
  103.  
  104. From: David Calafrancesco                               08-Oct-99 22:43:12
  105.   To: Mod Rules Poster                                  10-Oct-99 07:04:07
  106. Subj: OS2PROG Echo Rules
  107.  
  108. Mod Rules Poster wrote in a message to All:
  109.  
  110.  MRP> Rev: Wed 6 Oct 99 21:34
  111.  MRP> ============================================================
  112.  MRP> ================ The Official Rules of The FidoNet OS2PROG
  113.  MRP> Echo
  114.  
  115.  MRP> The objectives of the OS2PROG echo are:
  116.  
  117. Could the moderator contact me offline. The email address below will work
  118. well. 
  119.  
  120. Dave Calafrancesco, Team OS/2
  121. dave@drakkar.org
  122.  
  123. ... They got the library at Alexandria, they're not getting mine! 
  124. --- 
  125.  * Origin: Druid's Grove BBS - (914)/876-2237 (1:2624/306)
  126. 900/525
  127.  
  128. +----------------------------------------------------------------------------+
  129.  
  130. From: Vitus Jensen                                      09-Oct-99 22:40:15
  131.   To: Mads Orbesen Troest                               13-Oct-99 22:41:22
  132. Subj: VAC 3.0 Subsystem Library
  133.  
  134. Moin Mads,
  135.  
  136. 05.10.99 15:46, Mads Orbesen Troest wrote a message to Vitus Jensen:
  137.  
  138.  VJ>> Could someone explain the use of the subsystem library (compile
  139.  VJ>> switch /Rn) and whether it's use would be better in my case.
  140.  
  141.  MOT> As far as I am informed, the Subsystem switch means that /no/
  142.  MOT> startup/termination code is inserted in the generated code. If
  143.  MOT> you use any library functions whatsoever, this is probably not a
  144.  MOT> very good switch to check.
  145.  
  146. There *is* startup/termination code inserted.  Check your documentation:
  147. _rmem_init/_rmem_term is called.
  148. There is a limited range of library functions available, including malloc and
  149. free.
  150.  
  151. /*BUT*/ that runtime library has no support for multithreading!  So when I
  152. recoded my DLLs to make a test with the subsystem CRT I had to protect the CRT 
  153. via a mutex.  On the other hand there seems to be no need for a exception
  154. handler.  And the result is smaller.
  155.  
  156. I still don't know which way is best...
  157.  
  158. C-x C-s
  159.     Vitus
  160.  
  161. --- Sqed/rexx 97:
  162.  * Origin: That'll be $67.50  CCCHHHHHIIIIINNNNGGGG!!!! (2:2474/424.1)
  163.  
  164. +----------------------------------------------------------------------------+
  165.  
  166. From: Vitus Jensen                                      09-Oct-99 22:58:18
  167.   To: Will Honea                                        13-Oct-99 22:41:22
  168. Subj: VAC 3.0 Subsystem Librar
  169.  
  170. Hi Will,
  171.  
  172. 08.10.99 00:40, Vitus Jensen wrote a message to Will Honea:
  173.  
  174. ...
  175.  WH>> Just be VERY careful of where you put your waits and be extra
  176.  WH>> meticulous about cleanup on thread exit.  The biggest trap the
  177.  WH>> programmers I work with fall into is misuse of shared memory -
  178.  WH>> they just can't seem to clean up after themselves.  I think it's
  179.  WH>> a carryover from using multiple processes rather than true
  180.  WH>> threads.  Just to ease your mind a little, one comm job that
  181.  WH>> gets done has been known to run over 100 threads in an iterative
  182.  WH>> challenge-reply communications exchange and I've always been
  183.  WH>> able to kill the process cleanly at any stage.  
  184.  
  185.  VJ> Actually I think memory allocation/cleanup, waiting (or not
  186.  VJ> waiting) for threads to die is no complicate task.  You have to
  187.  VJ> stop and think sometimes but, well, you write every line and
  188.  VJ> there is always time to think (or should).
  189. ...
  190.  
  191. And if you did something wrong it shows up in a debugger and looks familiar.
  192.  
  193. I assumed a DosWaitEventSem() on a private semaphore will fail if called
  194. during Exitlist processing.  After all there is no other thread which will
  195. ever post that semaphore.  But OS/2 thinks different: just ERROR_TIMEOUT after 
  196. some time of waiting...
  197.  
  198. Is there any special flag I should check?  Mhmm, that thread I started should
  199. be dead during exitlist processing.  What resources are belonging to a
  200. thread... only stack and the TID.  But no API DosQueryThread(tid,...). :-(
  201.  
  202. He, there is DosGetInfoBlocks and the PIB holds a bit saying "the current
  203. process is in exit list processing". I will check this flag.
  204.  
  205. Bye,
  206.     Vitus
  207.  
  208. --- Sqed/rexx 87:
  209.  * Origin: Windows NT?  New Technology?  I don't think so... (2:2474/424.1)
  210.  
  211. +----------------------------------------------------------------------------+
  212.  
  213. From: Vitus Jensen                                      13-Oct-99 01:47:01
  214.   To: Will Honea                                        14-Oct-99 05:34:02
  215. Subj: VAC 3.0 Subsystem Librar
  216.  
  217. Hello Will,
  218.  
  219. 09.10.99 22:58, Vitus Jensen wrote a message to Will Honea:
  220.  
  221. [...DosWaitEventSem in Exitlist...]
  222.  
  223.  VJ> He, there is DosGetInfoBlocks and the PIB holds a bit saying "the
  224.  VJ> current process is in exit list processing". I will check this
  225.  VJ> flag.
  226.  
  227. This did the job, no more hangs.
  228.  
  229. But I'm uncertain whether I'm testing the correct bit.  Read the
  230. documentation:
  231.  
  232. ========<start>=======================================
  233.   pib_flstatus (ULONG) 
  234.      Process' status bits. 
  235.  
  236.      A value of 1 in this bit flag indicates that the current process is in
  237. exit 
  238.      list processing. 
  239. ========<end>=========================================
  240.  
  241. pib_flstatus is indeed bit coded, I've seen 0x10 during normal processing and
  242. 0x17 in the Exitlist.
  243. I'm now testing Bit 0, when this bit is set exitlist processing is assumed and 
  244. no waiting will occur.  Do I test the correct bit???
  245.  
  246. C-x C-s
  247.     Vitus
  248.  
  249. --- Sqed/rexx 440:
  250.  * Origin: Those who can, do.  Those who can't, supervise! (2:2474/424.1)
  251.  
  252. +----------------------------------------------------------------------------+
  253.  
  254. From: David Van Hoose                                   14-Oct-99 10:30:00
  255.   To: All                                               14-Oct-99 15:24:10
  256. Subj: GetGetInfoBlocks
  257.  
  258. Does anyone here know if there is a Linux version
  259. of DosGetInfoBlocks()?
  260.  
  261. -Dave
  262.  
  263. --- PCBoard (R) v15.4 (OS/2) 250 Beta
  264.  * Origin: Destiny BBS: 1-850-477-1262 (1:3612/333)
  265. 900/525
  266.  
  267. +----------------------------------------------------------------------------+
  268.  
  269. From: MIKE RUSKAI                                       14-Oct-99 19:29:00
  270.   To: ALL                                               15-Oct-99 01:07:19
  271. Subj: DosDevIOCtl, cat8, f64
  272.  
  273. I'm collecting information on the size of the HPFS directory band, with
  274. respect to the size of the drive.  To do this, I read the Super Block by
  275. opening the drive as a file.
  276.  
  277. This fails, however, with drives over 2GB in size, since DosRead() and
  278. cousins can't handle files that size (except perhaps on Aurora - I had one
  279. person run it successfully on a 14GB drive, and am awaiting information on
  280. what he's running).
  281.  
  282. To get around this, I figure I need to make a call to DosDevIOCtl(),
  283. category 8 (IOCTL_DISK), function 0x64 (DSK_READTRACK).
  284.  
  285. The problem is that part of the parameters are the drive head and cylinder.
  286. How do I figure out which head and cylinder I need to read from?  This
  287. isn't a physical disk category, so I don't see why the head and cylinder
  288. are there in the first place.
  289.  
  290. I managed to get the function to run (it seems very sensitive to invalid
  291. parameters, even when they appear quite valid), using 0 for the head and
  292. cylinder values.  What I get back, however, is data that doesn't appear to
  293. be on the drive at all.
  294.  
  295. Can anyone shed some light on this?
  296.  
  297. Mike Ruskai
  298. thannymeister@yahoo.com
  299.  
  300.  
  301. ... And the sound we make together is the music to the story in your eyes.
  302.  
  303. ___ Blue Wave/QWK v2.20
  304. --- Platinum Xpress/Win/Wildcat5! v3.0pr2
  305.  * Origin: FIDO QWK MAIL & MORE!  WWW.DOCSPLACE.ORG (1:3603/140)
  306. 900/525
  307.  
  308. +----------------------------------------------------------------------------+
  309.  
  310. From: MIKE RUSKAI                                       14-Oct-99 19:52:00
  311.   To: ALL                                               15-Oct-99 01:07:19
  312. Subj: DosDevIOCtl()
  313.  
  314. Forget that last post.  The head/cylinder numbers are relative to the
  315. beginning of the logical drive.  Sort of.  With head and cylinder set to 0,
  316. you'll get X sectors of garbage before the boot sector, where X is the
  317. number of sectors per track of the drive.  Setting head to 1, and cylinder
  318. to 0 makes sector 0 the boot sector.
  319.  
  320. Mike Ruskai
  321. thannymeister@yahoo.com
  322.  
  323.  
  324. ... Are there any lawyers here? <BLAM> Any more?
  325.  
  326. ___ Blue Wave/QWK v2.20
  327. --- Platinum Xpress/Win/Wildcat5! v3.0pr2
  328.  * Origin: FIDO QWK MAIL & MORE!  WWW.DOCSPLACE.ORG (1:3603/140)
  329. 900/525
  330.  
  331. +----------------------------------------------------------------------------+
  332.  
  333. From: Rob Basler                                        14-Oct-99 18:37:02
  334.   To: All                                               15-Oct-99 02:07:00
  335. Subj: Watcom fails on WSEB
  336.  
  337. FYI Watcom C++ 11.0b's debugger does not work on OS/2 WSeB.  There is
  338. something wrong with the startup code generated by the compiler so that
  339. a task exception (general protection fault) happens before the debugger
  340. gets to the startup code (even before it goes to main()).  It looks like
  341. it might be failing either in the debugger or in some .DLL's
  342. initialization.  The only way to get an EXE to load into WD is to either
  343. get rid of the .SYM file (no symbols makes for tough debugging) or use
  344. "Debug Startup" but that traps before it gets to the start of your code.
  345.  
  346. If anyone else if affected by this, I would recommend you get to
  347. Watcom's website, newsgroups and if your stomach can take it, tech
  348. support ASAP since powersoft is wrapping up Watcom C++ support.
  349.  
  350. Rob.
  351. ___
  352.  X SLMR 2.1a X Summer is half the clothing, twice the fun!
  353.  
  354. --- Maximus/2 3.01
  355.  * Origin: Frog Hollow Port Moody BC 604-469-0264/0284 (1:153/290)
  356.  
  357. +----------------------------------------------------------------------------+
  358.  
  359. +============================================================================+
  360.