Skip to content

Instantly share code, notes, and snippets.

@ar

ar/bix_ctask.txt

Created March 17, 2024 20:24
Show Gist options
  • Save ar/62fc29e0c792daace5e831a58b59b7e1 to your computer and use it in GitHub Desktop.
Save ar/62fc29e0c792daace5e831a58b59b7e1 to your computer and use it in GitHub Desktop.
Download ZIP
CTask conference at BiX
Raw
bix_ctask.txt
Read:help
<null line>................See next message.
[number]...................See message [number].
[number] to [number].......See messages in that range.
ALl........................See all new messages (note: quit
will not work, use with care).
BAckward [#] to [#]........Read in reverse direction.
BYE........................Log off (works immediately).
COMment....................Make a comment on the message
you have just read.
DAte [date] [to da [date]..Read messages added on day(s)
specified. Format: date 24jun85.
FILe [option]..............Write result to scratchpad.
FIRst......................Read first message in topic.
FIRst to Last..............Read every msg (not just unseen).
FOrward....................Read forward direction (default).
HEAder [msg #].............See message header and first line only.
Help.......................Display help message.
Join [conf/topic]..........Leave current conf,join another.
LAst.......................Read last msg. Also "skip to la".
MAil.......................Leave conf., enter Mail subsyst.
OPTion.....................Leave conf., enter Opt. subsyst.
ORIGinal...................See msg to which current one is a
comment.
Quit.......................Return to main level.
REFerence..................Read by reference.
SAy........................Make an original contribution.
SEARch [word]..............List all occurrences of [word]
in this topic.
SHow [option]..............Any show option (eg all,p,who).
SKip [number]..............Do not see next [number] msgs.
SKip to [number]...........Skip all msgs up to [number].
WIthdraw [msg #]...........Retract your comment [#].
Note: [number] can be a number, or the words "first" or
"last".
"Forward", "Backward" and "Reference" are "sticky"; that is,
they remain in force until you change them or until you
leave the topic you are reading.
------------------------------------------------------------------------------
:join ibm.other/ctask
Welcome to the 'ibm.other' conference.
Welcome to the ibm.other conference!
This conference is for all general IBM related stuff you can't find a
suitable topic for in one of the other conferences of the IBM
exchange. Topics may be changed or added from time to time to better
serve your needs. You'll get a complete list when you enter
"show ibm.other" at the main prompt.
Your administrative moderator for this conference is Thomas Wagner
(twagner). Send BIXmail to me if you want to make suggestions for new
topics or special events, or complain about anything in this
conference. You can also talk to any of the other IBM exchange
moderators, see "show ibm.other" for a complete list of moderators.
If you want to know more about me, enter "show res twagner" at the
main prompt.
Thomas Wagner
==========================
ibm.other/**BULLETIN** #1686, from twagner, 361 chars, Mon Jul 9 06:12:20 1990
--------------------------
Topic changes
The new SAA topic in this conference is open to discuss user
interfaces and IBM's SAA. All, users and developers alike, are
welcome, so you are automatically joined.
The "flames" topic has been inactive for some time, so I deleted it.
If you should ever need a place for your flamethrower, just drop me a
note and it will be resurrected.
Thomas
Joining conference 'ibm.other', topic 'ctask'. 25 new messages.
Read:
==========================
ibm.other/ctask #181, from jlo, 102 chars, Fri Oct 26 23:47:34 1990
This is a comment to message 180.
--------------------------
Of course, that makes perfect sense. I completely forgot about multiple
Ctask invocations. Thanks.
Read:
==========================
ibm.other/ctask #182, from gmelville, 304 chars, Wed Nov 14 15:15:46 1990
There is/are comment(s) on this message.
--------------------------
TITLE: CTASK22 Floating point
Tom, I notice in the readme with V2.2 that floating point emulation will not
work. I am using TC++ 1.0, (with patches). Can you suggest any way of
using floating point math without resource protection. (possibly ALT MATH)
Any thoughts appreciated,
Regards Gavin Melville.
Read:
==========================
ibm.other/ctask #183, from twagner, 268 chars, Thu Nov 15 16:04:09 1990
This is a comment to message 182.
There are additional comments to message 182.
--------------------------
If possible, try to collect all floating point stuff in one task.
This circumvents possible problems. Other than that -
I haven't had time to check out floating point, and I don't know
anything about the reentrancy of the alternate math package. Anyone
else?
Thomas
Read:
==========================
ibm.other/ctask #184, from mshiels, 333 chars, Thu Nov 15 20:23:19 1990
There is/are comment(s) on this message.
--------------------------
TITLE: Resident kernels/shared code
Has anyone gotten this to work. Say using MINRES as the resident
kernel. And MSPAWN as the non resident code sharer? I couldn't get
things to link up properly because even though the stubs were defined
the object modules were still being dragged in with lots of duplicate
labels being defined.
Read:
==========================
ibm.other/ctask #185, from twagner, 642 chars, Fri Nov 16 04:36:18 1990
This is a comment to message 184.
There is/are comment(s) on this message.
--------------------------
> Resident kernels/shared code - Has anyone gotten this to work
Yes, I have, and it's working fine for me. I did modify the stub
table for my application, though, so you might be running into a
problem with the supplied stub table. I don't have time to check now
(I'll be off for a weekend trip in two hours), but you should make
sure you have all entries of a module defined as either "stub" or
"dstub". Don't mix the two within a module. Also, specify the /NOE
option with the Microsoft linker, or it will complain about
duplicates even though it doesn't pull in the objects. If it still
doesn't work, I'll check it out on Monday.
Thomas
Read:
==========================
ibm.other/ctask #186, from cblum, 361 chars, Sun Nov 18 22:33:42 1990
This is a comment to message 182.
--------------------------
Gavin (et al) -
I am working on the Turbo C++ floating point emulator^{...
I believe I will soon have code to allow its use under Ctask. WIll be
similar to fp support there now, saving emulator status and restoring
in dispatcher... some overhead but looks possible. Will keep you
posted here.
Chris Blum - cblum
Read:
==========================
ibm.other/ctask #187, from twagner, 912 chars, Mon Nov 19 12:21:37 1990
--------------------------
TITLE: Bugs in version 2.2
Two fixes for minor bugs in CTask version 2.2:
1) Register SI is clobbered in tsk_install_dos. This causes the
speedup parameter in tsk_install_main to cease working when compiled
with MSC 6.0 /Ox. The fix: add a "uses" clause to the function header.
In file TSKDOS.ASM
replace
Localfunc tsk_install_dos
with
Localfunc tsk_install_dos,<uses si>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (PATCH REALIZADO. CS 08/01/91)
2) An incorrecn
c++Yy3, TWATCH) is returned for timeouts on event
waits. The timeout structure, and with it the significance of some
fields, was changed in version 2.2. I forgot to apply the necessary
change to the tsk_timer_action routine, in the TKIND_WAKE/TKIND_TASK
clause of switch (elem->struckind). The fix: modify to use the queue
head type field instead of elkind.
In file TSKTTSK.C, routine tsk_timer_action
replace
((elem->elkind & 0xf0) == TELEM_TIMER)
with
(elem->link.kind == TYP_TIMER)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (PATCH REALIZADO. CS 08/01/91)
Thomas
Read:
==========================
ibm.other/ctask #188, from mshiels, 452 chars, Mon Nov 19 19:20:48 1990
This is a comment to message 185.
There is/are comment(s) on this message.
--------------------------
Is MINRES a good basis for the resident part of the kernel? Ie is it
enough for a resident kernel basis? I will see if I can describe what I
am trying to do.
Main resident task is called "network" and basicaly is waiting on a mailbox
and when packets arrives upcalls them to the proper protocol layer.
On another note. How are you thinking of supporting Windows 3.0? I
have the retail copy and SDK and DDK and would love to see what I can
offer.
Read:
==========================
ibm.other/ctask #189, from twagner, 792 chars, Tue Nov 20 14:34:01 1990
This is a comment to message 188.
--------------------------
> Is MINRES a good basis for the resident part of the kernel?
It depends... ;) Minres is *extremely* basic, it doesn't set up
SS=DS, it doesn't clear the BSS area, it doesn't support stack
checking. You can add all this relatively easily, but it's very
memory model and compiler dependent. The best approach is to take the
startup module of the compiler you're using, strip everything you
don't need, and then add the CTask specific stuff from Minres. This
will put you on the safe side.
> How are you thinking of supporting Windows 3.0?
I think I'll have to write a virtual device driver that
a) notifies CTask when the virtual machine is switched, and
b) allows Windows apps to communicate with the CTask kernel.
The first part should be easy. The second part looks hairy.
Thomas
Read:
==========================
ibm.other/ctask #190, from pcquote, 186 chars, Wed Nov 21 19:09:07 1990
--------------------------
TITLE: Ctask and Dos 5.0
Just in case someone was wondering, Ctask 2.2 seems to work fine
with the beta release on Dos 5.0.
Ctask is great, Thomas.
Thanks,
Rich
Read:
==========================
ibm.other/ctask #191, from mshiels, 2698 chars, Wed Nov 21 21:49:47 1990
There is/are comment(s) on this message.
--------------------------
TITLE: MINRES with SNAP/TSKSTUB
Here is the TSKSTUB.ASM which I am currently testing with.
--------
;
; module tskinst
;
stub tsk_install_main
stub tsk_remove_chain
stub tsk_remove_tasker
;
; module tskutil
;
stub preempt_on
stub preempt_off
stub tsk_ena_preempt
stub tsk_dis_preempt
stub t_delay
;
; module tsktask
;
stub create_task
stub tsk_kill_queue
stub kill_task
stub start_task
;
; module tskasm
;
stub schedule
stub yield
stub c_schedule
stub tsk_dseg
stub tsk_flags
stub tsk_dis_int
stub tsk_ena_int
stub tsk_cli
stub tsk_sti
stub tsk_inp
stub tsk_inpw
stub tsk_outp
stub tsk_nop
stub tsk_scheduler
stub sched_int
stub tsk_callfunc
;
;-------------------------------------------------------------------
;
; The following functions may be either 'stub' or 'dstub',
; but are normally used by kernel routines anyway, so you can
; keep them as 'stub'.
;
; module tskrsc
; Resources are used in the DOS module
;
stub create_resource
stub delete_resource
stub release_resource
stub request_resource
stub request_cresource
stub c_request_resource
stub c_request_cresource
stub check_resource
;
; module tskflg
; Flags are in the DOS module, too
;
stub create_flag
stub delete_flag
stub set_flag
stub clear_flag
stub clear_flag_wait_set
stub wait_flag_set
stub wait_flag_clear
stub check_flag
;
; module tskcnt
; Counters are used for the timer tasks
;
stub create_counter
stub delete_counter
stub clear_counter
stub wait_counter_set
stub wait_counter_clear
stub inc_counter
stub dec_counter
stub set_counter
stub check_counter
;
--------
I also changed CODESHARING and LOAD?DS in tskconf.h
I compiled the whole package. With MINRES resident and SNAP with the
complete tasker linked in things work great. Now I link in the TSKSTUB.ASM
and when SNAP is doing it's INT21(4C) terminate something goes wrong and
it dies.
Read:
==========================
ibm.other/ctask #192, from twagner, 1543 chars, Thu Nov 22 08:47:58 1990
This is a comment to message 191.
There is/are comment(s) on this message.
--------------------------
> Code Sharing problems
Uh oh - I lied. Version 2.2 code sharing does not work - the version
I was using in my program was an intermediate one. Sorry!
As you already found out, some required entry points are missing in
the stub table. But there's a second problem: all entries in the stub
table must be *Global* functions. Also, the tsk_memcpy function is
called before the secondary link is established. The fix follows:
File TSKSTUB.ASM:
Add under heading "module tskinst":
stub tsk_remove_chain
Add under heading "module tskasm":
stub tsk_scheduler
stub tsk_callfunc
stub tsk_memcpy
Add under heading "module tskcnt":
stub dec_counter
Add under heading "module tsksec":
dstub tsk_free_mem
dstub tsk_getpsp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>PATCHED (CS 8/1/91)
File TSKINST.C:
Change "Localfunc" into "Globalfunc" for functions
tsk_install_main, tsk_remove_chain, tsk_remove_tasker
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>PATCHED (CS 8/1/91)
File TSKASM.ASM:
Change "Localfunc" into "Globalfunc" for functions
tsk_callfunc
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>PATCHED (CS 8/1/91)
File TSKSEC.ASM:
Change "Localfunc" into "Globalfunc" for functions
tsk_free_mem, tsk_getpsp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>PATCHED (CS 8/1/91)
File TSKLOCAL.H:
Change "Localfunc" into "Globalfunc" for all of the
functions listed above.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>PATCHED (CS 8/1/91)
File TSKDOS.ASM:
Change "Locext" into "Globext" for external definition of
tsk_remove_tasker
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>PATCHED (CS 8/1/91)
File TSKMAIN.C, routine install_tasker:
Replace
tsk_memcpy (tsk_glob_rec.id, tsk_version, 8);
By
for (rc = 0; rc < 8; rc++)
tsk_glob_rec.id [rc] = tsk_version [rc];
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>PATCHED (CS 8/1/91)
-----------------------------------------
Thomas
Read:
==========================
ibm.other/ctask #193, from mshiels, 723 chars, Thu Nov 22 22:20:15 1990
This is a comment to message 192.
There is/are comment(s) on this message.
--------------------------
Thanx. I was hoping I wasn't losing my mind.
I am looking into a couple of additions to CTASK which people might
find usefull. MOUSE interface as fake keystrokes for movement/up/down etc.
I have already done a NETBIOS interface which will allow very powerful
netbios gateways to be created since it is based around MAILBOXes. I have to
polish this off and make sure I didn't leave any great big holes but it
should make a good addition to the system.
Is there a specific todo/doing list which is kept anywhere? I would like to
see what other people are working on so wedon't duplicate efforts.
Ctask is also working out well for a JT-FAX driver which I am starting to
work on now.
Thanx again for a great product.
Read:
==========================
ibm.other/ctask #194, from twagner, 787 chars, Fri Nov 23 12:33:11 1990
This is a comment to message 193.
There is/are comment(s) on this message.
--------------------------
Ah, a NETBIOS interface would be great. I had thought about doing
one myself, but didn't get very far yet (the usual lack of time).
> Is there a specific todo/doing list which is kept anywhere?
Well, you just started the 'doing' list. Just post away in this
topic, or in long.messages if you have more ideas than fit on two
screens. If you (any of you) have a CTask application/addition in the
works you'd like to let others know about, please post a note (even
if it's a commercial app - just don't be too blatant :).
If you have some addition to CTask (sample programs, utilities, ...)
you'd like to donate to the PD, BIXmail it to me for inclusion in the
library, even if you think it's not polished enough. I can help with
the polishing (though it may take some time...).
Thomas
Read:
==========================
ibm.other/ctask #195, from mshiels, 534 chars, Sun Nov 25 18:06:02 1990
There is/are comment(s) on this message.
--------------------------
TITLE: residency
The changes mentioned fixed the HANGING problems. But I linked MSPAWN
with the TSKSTUB and it worked OK except that when I ran SNAP it didn't
list any of the processes (2) for MSPAWN so I think there is something
else wrong. I al took a little different approach to TSK^[MEMCPY.
I moved it to the tskres.asm module since those modules are linked
into each copy of ctask programs. Other than that the Globalfunc/Localfunc
was the major hanging problem. Maybe I will have to wait till the next
release of Ctask.
Read:
==========================
ibm.other/ctask #196, from twagner, 293 chars, Tue Nov 27 06:32:29 1990
This is a comment to message 195.
There is/are comment(s) on this message.
--------------------------
> when I ran SNAP it didn't list any of the processes (2) for MSPAWN
That's strange. I tried the code sharing versions of MSPAWN and SNAP,
and SNAP listed all tasks and events in MSPAWN. Did you re-compile
the supplemental modules (esp. TSKSNAP) after changing the tskconf.h
options?
Thomas
Read:
==========================
ibm.other/ctask #197, from mshiels, 385 chars, Tue Nov 27 19:23:00 1990
This is a comment to message 196.
--------------------------
Back to the drawing board. Scratch code with only the changes you
mentioned and I will see what happens.
I have been looking in the DynamicLinkLibrary code in the May issue
of DDJ and it looks like a great way to load code into an EMS page
frame and then start the process from there. Once that process is
running you can setup another setup of pages and link in another process.
Read:
==========================
ibm.other/ctask #198, from mshiels, 2069 chars, Tue Nov 27 21:26:24 1990
--------------------------
TITLE: residency
OK. I went back to 2.2 scratch and made the following changes.
TITLE: Bugs in version 2.2
Two fixes for minor bugs in CTask version 2.2:
1) Register SI is clobbered in tsk_install_dos. This causes the
speedup parameter in tsk_install_main to cease working when compiled
with MSC 6.0 /Ox. The fix: add a "uses" clause to the function header.
In file TSKDOS.ASM
replace
Localfunc tsk_install_dos
with
Localfunc tsk_install_dos,<uses si>
2) An incorrect value (-3, TWATCH) is returned for timeouts on event
waits. The timeout structure, and with it the significance of some
fields, was changed in version 2.2. I forgot to apply the necessary
change to the tsk_timer_action routine, in the TKIND_WAKE/TKIND_TASK
clause of switch (elem->struckind). The fix: modify to use the queue
head type field instead of elkind.
In file TSKTTSK.C, routine tsk_timer_action
replace
((elem->elkind & 0xf0) == TELEM_TIMER)
with
(elem->link.kind == TYP_TIMER)
ALSO
File TSKSTUB.ASM:
Add under heading "module tskinst":
stub tsk_remove_chain
Add under heading "module tskasm":
stub tsk_scheduler
stub tsk_callfunc
stub tsk_memcpy
Add under heading "module tskcnt":
stub dec_counter
Add under heading "module tsksec":
dstub tsk_free_mem
dstub tsk_getpsp
File TSKINST.C:
Change "Localfunc" into "Globalfunc" for functions
tsk_install_main, tsk_remove_chain, tsk_remove_tasker
File TSKASM.ASM:
Change "Localfunc" into "Globalfunc" for functions
tsk_callfunc
File TSKSEC.ASM:
Change "Localfunc" into "Globalfunc" for functions
tsk_free_mem, tsk_getpsp
File TSKLOCAL.H:
Change "Localfunc" into "Globalfunc" for all of the
functions listed above.
File TSKDOS.ASM:
Change "Locext" into "Globext" for external definition of
tsk_remove_tasker
File TSKMAIN.C, routine install_tasker:
Replace
tsk_memcpy (tsk_glob_rec.id, tsk_version, 8);
By
for (rc = 0; rc < 8; rc++)
tsk_glob_rec.id [rc] = tsk_version [rc];
END
Read:
==========================
ibm.other/ctask #199, from mshiels, 3229 chars, Tue Nov 27 21:29:54 1990
--------------------------
TITLE: residency
What I also do is link MSPAWN/SNAP with TSKSTUB.OBJ to get
RESMSPAW/RESSNAP.
And here's the output from using MINRES with MSPAWN and RESSNAP
Task List (VM=0000):
Name State Queue Timeout TCB-addr Stackptr Stackbot Instrptr Prior
>> Group CTRES (1413:19a0), C:-MAIN- (1413:147e), B:1ccc:27d6, L:0000:0000
-MAIN- Run 1413:193c - 1413:147e 02b6:07ea 1413:127e f000:e393* 100
-KILLER- Stop 0000:0000 - 1413:1552 1413:1198 1413:0faa 0ff4:0edc 100
-TIMER- Elig 1413:193c - 1413:1626 1413:1432 1413:127e 0ff4:1a8f 61440
-INT8- Elig 1413:193c - 1413:11aa 1413:18c6 1413:16fa 0ff4:1a8f 100
>> Group Spawn (1ccc:27d6), C:-MAIN- (1413:147e), B:322e:1738, L:0000:0000
SnapTask Delay 0000:0000 3 1ca3:0078 1ccc:6672 1ccc:6294 1623:097d 100
DosCTask Delay 0000:0000 0 1ca3:015a 1ccc:625a 1ccc:5e94 1623:097d 100
>> Group Snap (322e:1738), C:-MAIN- (1413:147e), B:0000:0000, L:0000:0000
List of Events:
Name Type State Waitfor(Queue) Tasks
>> Group CTRES (1413:19a0), C:-MAIN- (1413:147e), B:1ccc:27d6, L:0000:0000
DOSUPPER Resource Free
DOSLOWER Resource Free
HARDDISK Resource Free
FLEXDISK Resource Free
ALLOCRSC Resource Free
TIMCOUNT Counter 1
INT8CNT Counter 1
KEYAVAIL Flag Set
>> Group Spawn (1ccc:27d6), C:-MAIN- (1413:147e), B:322e:1738, L:0000:0000
ALLOCRSC Resource Free
>> Group Snap (322e:1738), C:-MAIN- (1413:147e), B:0000:0000, L:0000:0000
ALLOCRSC Resource Free
And here's the output when I use RESMSPAWN^
And here's the output when I use RESMSPAWN/RESSNAP
Task List (VM=0000):
Name State Queue Timeout TCB-addr Stackptr Stackbot Instrptr Prior
>> Group CTRES (1413:19a0), C:-MAIN- (1413:147e), B:1ac4:17f8, L:0000:0000
-MAIN- Run 1413:193c - 1413:147e 02b6:07dc 1413:127e f000:e383* 100
-KILLER- Stop 0000:0000 - 1413:1552 1413:1198 1413:0faa 0ff4:0edc 100
-TIMER- Wait 1413:1902 - 1413:1626 1413:1432 1413:127e 0ff4:1a8f 61440
-INT8- Elig 1413:193c - 1413:11aa 1413:18c6 1413:16fa 0ff4:1a8f 100
>> Group Spawn (1ac4:17f8), C:-MAIN- (1413:147e), B:3026:1738, L:0000:0000
>> Group Snap (3026:1738), C:-MAIN- (1413:147e), B:0000:0000, L:0000:0000
List of Events:
Name Type State Waitfor(Queue) Tasks
>> Group CTRES (1413:19a0), C:-MAIN- (1413:147e), B:1ac4:17f8, L:0000:0000
DOSUPPER Resource Free
DOSLOWER Resource Free
HARDDISK Resource Free
FLEXDISK Resource Free
ALLOCRSC Resource Free
TIMCOUNT Counter 0
INT8CNT Counter 0
KEYAVAIL Flag Set
>> Group Spawn (1ac4:17f8), C:-MAIN- (1413:147e), B:3026:1738, L:0000:0000
ALLOCRSC Resource Free
>> Group Snap (3026:1738), C:-MAIN- (1413:147e), B:0000:0000, L:0000:0000
ALLOCRSC Resource Free
See the difference. See the next message for some still outstanding
problems. Maybe Thomas you could do a unix type DIFF on the current
version you are using and the 2.2 release and put those DIFFs up for
download?
Read:
==========================
ibm.other/ctask #200, from mshiels, 323 chars, Tue Nov 27 21:30:55 1990
--------------------------
TITLE: residency
Here are some things I noticed while trying to compile MSPAWN/SPAWN into
resident versions use MINRES as a core
in TSKSTUB.ASM
moved wake_task from tsktask area to tsktutl
in TSKTASK.C it still needs some changes
I think there is at least one more Globalfunc/Localfunc but I havn't
gotten that far yet.
Read:
==========================
ibm.other/ctask #201, from pcquote, 258 chars, Wed Nov 28 17:21:59 1990
This is a comment to message 194.
There is/are comment(s) on this message.
--------------------------
I have writted some reentrant monochrome text routines. They will put a string
to a screen location, scroll the screen up or down, or clear a line or the whole
screen. I've just started a VGA graphics library, if anyone is interested let
me know here.
Rich
Read:
==========================
ibm.other/ctask #202, from the_monk, 62 chars, Wed Nov 28 18:16:22 1990
This is a comment to message 201.
--------------------------
Rich, I would certainly be interested in those routines!
Tom
Read:
==========================
ibm.other/ctask #203, from r.rice, 601 chars, Thu Jan 3 21:15:31 1991
There is/are comment(s) on this message.
--------------------------
TITLE: TC++ & EXEC23
Hello Thomas,
I am attempting to build a graphical menu system in TC++ but I can not
get the EXEC23 system to intergrate into my system. To show you a
good example of what I mean. Trying to compile and link the EXEC.C
file. It compiles just fine but the linker cant find do_spawn. My
knownledge of assembly is not that good so I have not try to fix it.
The system compile just fine if you have it set to C++ option only
on extentions but once you set it to C++ always it loses whether do_spawn
is located.
I would appreicate any help you could give.
RRICE.
Read:
==========================
ibm.other/ctask #204, from twagner, 396 chars, Fri Jan 4 17:57:51 1991
This is a comment to message 203.
There is/are comment(s) on this message.
--------------------------
> the linker cant find do_spawn
That's because TC assumes that do_spawn is a C++ routine, so it uses
an incorrect name. Please change the extern definition in the file
exec.c to extern "C" int do_spawn.
I've uploaded a new version (2.5) tonight, which fixes this problem
(it uses an #ifdef __cplusplus) besides some other bugs in version 2.3.
Filename is EXEC25.LZH in IBM.PC/listings.
Thomas
Read:
==========================
ibm.other/ctask #205, from r.rice, 385 chars, Sat Jan 5 18:36:45 1991
This is a comment to message 204.
--------------------------
I was about to explain why EXEC23 does not work in TC++ but I am
pleased to see that you have already address the problem. I wish
the TC manual would address the issue. I even called borland but
the TECH guy at the other end was not much help. I kept saving
name mangling but never actual explain the proble,m.
Well from one tired programmer, I do appreciate you help.
rrice.
-------------------------------------------------------->Acceso 17/01/91
==========================
ibm.other/ctask #206, from sexton, 227 chars, Wed Jan 9 10:58:28 1991
This is a comment to message 205.
There is/are comment(s) on this message.
--------------------------
I also wish the manual would address this.
This isn't really the place for this but does anyone know how name
mangling works? It would be nice to be able to call C++ from other
languages. And while I'm at it, what is EXEC23?
Read:
==========================
ibm.other/ctask #207, from twagner, 807 chars, Wed Jan 9 18:37:26 1991
This is a comment to message 206.
There is/are comment(s) on this message.
--------------------------
> And while I'm at it, what is EXEC23?
exec25.lzh 26624 Approx time (min): 27 at 300 baud, 7 at 1200 baud
Contributed by: twagner Date: Fri Jan 4 17:56:43 1991
Swap program to EMS or Disk, spawn another program.
This file contains full source code (in C, Pascal, and Assembler)
for a module that allows you to swap your program to EMS or disk,
and then spawn any DOS program, including COMMAND.COM. Only a small
(less than 1k) reload stub is left in memory. Compatible with
Microsoft C, Turbo C, Watcom C, and Turbo Pascal. Binaries included,
recompilation requires MASM 5.1 or TASM 1.0 or later versions.
Unrestricted Public Domain, no registration or royalty fees.
Version 2.5 released 91-01-04, uploaded by author.
Keywords: $binary UTILITY assembler c exec pascal source spawn swap
Thomas
Read:
==========================
ibm.other/ctask #208, from sexton, 41 chars, Thu Jan 10 11:30:34 1991
This is a comment to message 207.
--------------------------
impressive... I'll have to download it.
Read:
==========================
ibm.other/ctask #209, from bobsteve, 491 chars, Sun Jan 13 17:18:00 1991
There is/are comment(s) on this message.
--------------------------
TITLE: missing bits?
Thomas,
I just dragged down ctask22 and found the following.
tsksio.c not in lzh file
tsksub.c not in lzh file
tsktsub.c not in lzh file
tskttsk.c not in lzh file
tsktops.c not in lzh file
tskutil.c not in lzh file
tskstub.asm not in lzh file
tskrsc.c has garbage in lzh file
Did I miss something obvious??
I plan on compiling with TopSpeed C. It has some multi-tasking
support built into its library routines. Know if anyone has tried
.More..
this already?
Bob White
Read:
==========================
ibm.other/ctask #210, from dandrews, 1046 chars, Mon Jan 14 14:44:24 1991
There is/are comment(s) on this message.
--------------------------
TITLE: Ctask TSR and PSP currency
Thomas, I'm fighting with my first Ctask application and am experiencing
a problem. The program goes TSR, a subtask monitors a serial port for
activity, and a second subtask writes the port activity to a disk file.
Nothing particularly magic here. It goes and goes, no sweat, but a few
minutes later the PC "hangs", during a period when yet another TSR is
probably also doing disk I/O.
My code does OPENs, CLOSEs and WRITEs. I got worried about what PSP
was "current" when the Ctask scheduler gives my write task control, but
I haven't been all that successful in determining this from your code.
(I'm learning!)
Anyway: when a Ctask TSR is executing, I know your INT13 handler will
take care of DOS non-reentrancy. What about PSP currency?
.More..
(BTW, has Addison-Wesley published _Undocumented DOS_ in Germany yet?
I picked this up here (Florida) last month and it is wonderful. I
don't expect you'd learn much from it, but for us pikers who haven't
got a handle on DOS internals, it's pretty nice.)
- Dave
Read:
==========================
ibm.other/ctask #211, from twagner, 181 chars, Mon Jan 14 18:23:23 1991
This is a comment to message 209.
--------------------------
Looks like the file was damaged during download. The file was checked
out, and downloaded by quite a few users without problems. Which
protocol did you use for downloading?
Thomas
Read:
==========================
ibm.other/ctask #212, from twagner, 1101 chars, Mon Jan 14 18:23:42 1991
This is a comment to message 210.
There is/are comment(s) on this message.
--------------------------
> PSP currency...
> I haven't been all that successful in determining this from your code.
Small wonder... ;-) The current PSP pointer is hidden within the "DOS
variable" block that is swapped on a task switch. So the PSP should
be correct. Have you tried to activate the debug display? A second
monitor could be helpful in determining whether it's a full-scale
crash, or if there's a deadlock. How is the other TSR activated? Is
it "clean", i.e. does it check for the DOS-busy flag? Is the effect
similar if you set the IFL_INT8_DIR installation flag? Have you
turned on the CHECKING mode?
"Undocumented DOS" sounds like a "must-have" book, I've heard a lot
of praise. It's usually no problem ordering foreign books from here,
there's an excellent technical bookshop in Berlin that has yet to
.More..
fail on an order. It just may take a while. Barry Nance's Network
programming book (really recommended if you're interested in network
programming) took two months, and the record holder is the PC
Technical Ref from Sigma Press (in England) which arrived more than
four months after I ordered...
Thomas
Read:
==========================
ibm.other/ctask #213, from dandrews, 471 chars, Tue Jan 15 09:31:18 1991
This is a comment to message 212.
There are additional comments to message 212.
--------------------------
The other TSR is actually three separate TSRs controlling two Intel
Connection Coprocessor fax boards. They have run in the background
for over a year with no incident, so I expect that they are probably
reasonably solid.
I will check the behavior with CHECKING and IFL_INT8_DIR set.
I have stacks of _Undocumented DOS_ sitting in a local bookstore here.
If you like, I'll run down and get it and forward it to you. Might
beat special-ordering from the publisher.
Read:
==========================
ibm.other/ctask #214, from dandrews, 1184 chars, Tue Jan 15 12:27:48 1991
This is a comment to message 212.
There are additional comments to message 212.
--------------------------
IFL_INT8_DIR has no effect on the problem. Neither does CHECKING.
I'm trying to understand how you do critical-section checking. In
versions prior to DOS 3.1, you use the INDOS flag, right? I can't
see in your code where you hook INT28, but I see that you do.
In the code for TSKDOS.ASM, you write:
"The support for the critical section interrupt was dropped in
version 2.1. Swapping the DOS variable area eliminates the
need for maintaining critical sections across calls."
This seems to disagree with the _Undocumented DOS_ book, where
they say that you cannot change the contents of the SDA if any
critical section is held.
INT 0x2A fn 0x80 begins the DOS critical section. AL contains:
.More..
0x01 DOS kernel, SHARE.EXE
0x02 DOS kernel
0x05 DOS 4+ IFSFUNC
0x06 DOS 4+ IFSFUNC
0x08 ASSIGN.COM
INT 0x2A fn 0x81 ends a specific critical section. The codes in AL
are the same as in function 0x80.
INT 0x2A fn 0x82 ends ALL critical sections 0-7. It is issued by
the INT 0x21 function dispatcher for functions 0, 0D-58, 5A onward.
I'm just reading from the book, so I probably am confused. Maybe
you can straighten me out (maybe not!)
Thanks - Dave
Read:
==========================
ibm.other/ctask #215, from dave2, 354 chars, Tue Jan 15 21:17:47 1991
This is a comment to message 212.
--------------------------
>Technical Ref from Sigma Press
Uh, oh. And I was wondering why my royalty checks weren't looking
so hot. I'm having a LOT of trouble with Sigma over marketing and
stuff, but I didn't know they were having shipping troubles too.
<sigh> Barryn's book is hard to get too. I just had a distributor
tell me it was "not available", whatever that means.
No more unread messages in this topic
----------------------------------------------------------------------
==========================
ibm.other/ctask #230, from twagner, 950 chars, Sun Feb 3 06:43:24 1991
This is a comment to message 229.
--------------------------
> But no task spawned DOS!
Well, "spawn" seems to be the wrong word... ("to produce eggs or
offspring esp. in large numbers" [Webster] ;-)
What I meant to say was: The task that, in whatever way, calls a DOS
function that results in another application (the command processor
or whatever) to be loaded and executed. Wheter it does an EXEC call
or a TSR is of little importance. What *is* important is that the
task in question doesn't mysteriously disappear, or stop execution.
All DOS code, and any application that's running, is simply an
extension of the tasks code. Theoretically, CTask couldn't care less
whether the code that's executed in a task is linked into the program
to begin with, or if it's loaded by EXEC or the command processor.
It's still the same task.
.More..
> the example TSR in _UD_ uses the SDA swap mechanism and
> ignores the INDOS flag...
Oh my... Well, it's just an additional precaution, it shouldn't be
essential.
Thomas
Read:
==========================
ibm.other/ctask #231, from compuservice, 880 chars, Mon Feb 4 15:32:12 1991
There is/are comment(s) on this message.
--------------------------
TITLE: tsk_sprintf and tsk_vsprintf
Thomas,
Thank you very much for writting CTask and placing it in the
Public Domain. It's a really neat product. We are using it as a
kernel in our design of a multiline BBS down here in Uruguay.
Question 1: We are trying to replace all printf functions with the
new ones defined in 'tskprf.asm' and we experienced some problems
with 'tsk_sprintf' and 'tsk_vsprintf'. It's seems not to put the null
terminator in the 'destination' string. Is that correct ?
Question 2: Is there any easy way to 'restart' a task from its very
beggining (from another task) without having to kill, create and start
it again ?
.More..
The situation is: One 'watchdog' task checks for carrier loss and
kills the 'user' task. Then it creates and starts the user task
again. This lowers the performance of other active usertasks on slow
machines.
Thanks again.
Read:
==========================
ibm.other/ctask #232, from tbusch, 412 chars, Tue Feb 5 11:59:48 1991
There is/are comment(s) on this message.
--------------------------
TITLE: Groups?
Perhaps I'm not clear ast ^^ to how groups are supposed to work. I'm trying
to start a task from main(), and then this subtask invokes install_tasker
again to create a new group. When I run snapshot from a subsequent task,
the display repeats until the computer has to be shut off. When I checked
the branch pointer for the lower-level task, it pointed to its own group.
What am I doing wrong?
Read:
==========================
ibm.other/ctask #233, from twagner, 1452 chars, Tue Feb 5 12:12:08 1991
This is a comment to message 231.
--------------------------
Uruguay? South America seems to be busy with CTask users writing BBS
apps - I just got a letter from a BBS writer in Brasil! :)
> problems with 'tsk_sprintf' and 'tsk_vsprintf'
You're right, that's a bug. Please insert
mov es,word ptr(dest) + 2
mov byte ptr es:[bx],0
immediately after the "call @disprintf" in both functions.
> Is there any easy way to 'restart' a task from its very beginning
------ cut here, insert following into tsktask.c ------
.More..
/*
restart_task
Restart "task" at the beginning of function "func", without
changing any other attributes. The original stack size must
be passed in parameter "stksz".
The task must be in stopped state.
NOTE: The stack size passed *must* match the stack size the
task was created with.
CAUTION: NOT TESTED!
*/
int Globalfunc restart_task (tcbptr task, funcptr func, word stksz);
{
struct task_stack far *stk;
CHECK_TCBPTR (task, "Restart Task");
if (task == NULL)
.More..
return -1;
if (task->state != ST_STOPPED)
return -2;
stk = (struct task_stack far *)(task->stkbot + stksz - sizeof (struct task_st
ack));
stk->r_ds = task->t_es = tsk_dseg ();
stk->r_flags = tsk_flags ();
stk->retn = func;
stk->dummyret = killretn;
task->t_bp = 0;
task->stack = (byteptr) stk;
task->state = ST_ELIGIBLE;
C_ENTER;
tsk_runable (task);
C_LEAVE;
return 0;
}
.More..
-------- cut here ----------
Thomas
Read:comment
Comment to message number 233. Enter text. End with '.<CR>'
>We have made the corrections you suggested in tskprf.asm and we put
the new routine 'restart_task' in tsktask.c and prototype in tsk.h.
>Everything works perfectly.
Thanks a l>ot for your help.
>Anybody else writting BBS software around CTask?
>We would like to share impressions and ideas.
>>.
Add/action:add
Adding message...Message 236 added.
Read:quit mail
No unread inbasket messages.
Mail:send
Sorry, 'send' not yet implemented.
Mail:?
Mail commands
To [username]..........Start a new message to person named
[null line/<Return>]...Read messages in In-Basket
[number]...............Read message with that number.
BYe....................Log off (works immediately).
DELete [#].............Delete message [#]
DOWnload...............Receive (i.e., download) data stored in
your scratchpad using Xmodem, Zmodem, or Kermit.
FILE [option]..........Write result of [option] to scratchpad.
INBask.................Displays your Inbasket
OPTion.................Leave Mail subsystem, enter Option subsystem.
OUTbask................Displays your Outbasket
REAd...................Leave Mail subsystem, enter the
conferenceing subsystem
SHOw [options].........Use any "show" option (see "show")
SHOw WHo [name]........Get BIXname for [name].
STAtus.................List contents of In- & Out-Baskets
UNRead.................Display only your unread messages in your inbasket.
.More..
UPLoad.................Send (i.e., upload) data from your computer up
to your scratchpad using Xmodem or Kermit.
WIThdraw # ............Retract message [#].
QUIt...................Return to main level
-------------------------------------------------------------
:join ibm.other/ctask
Joining conference 'ibm.other', topic 'ctask'. 6 new messages.
Read:
==========================
ibm.other/ctask #234, from twagner, 331 chars, Tue Feb 5 12:49:20 1991
This is a comment to message 232.
There is/are comment(s) on this message.
--------------------------
Hmm... apart from the fact that there seems to be a bug in the group
code (I'll look into it), what do you want a new group for? I did
intend groups to be used for coordination between *different*
instances of CTask, i.e. TSR's or programs that EXEC CTask apps. I'm
surprised that apparently there's another use for them.
Thomas
Read:
==========================
ibm.other/ctask #235, from tbusch, 700 chars, Tue Feb 5 15:31:32 1991
This is a comment to message 234.
--------------------------
Well, I thought it would be neat to logically group the tasks and events
together under a hierarchy of groups, but you are correct. I noticed in
"advanced "topics" you DID say the primary program has to go TSR before
another kernel is installed. So you could say I didn't follow the instruc-
tions correctly. I'm not really using different programs. (But I like the
idea.) I'm creating a set of simulation programs, and each simulator should
act as an independent application, all controlled by a user interface pro-
gram. I was hoping to cheat and put all of them into one exec, but I may
talk myself into putting them into separate files. I should read the manual
al^little more thoroughly.
Read:
==========================
ibm.other/ctask #236, from compuservice, 288 chars, Wed Feb 6 11:40:00 1991
This is a comment to message 233.
There is/are comment(s) on this message.
--------------------------
We have made the corrections you suggested in tskprf.asm and we put
the new routine 'restart_task' in tsktask.c and prototype in tsk.h.
Everything works perfectly.
Thanks a lot for your help.
Anybody else writting BBS software around CTask?
We would like to share impressions and ideas.
Read:
==========================
ibm.other/ctask #237, from jamey, 327 chars, Wed Feb 6 23:47:39 1991
This is a comment to message 236.
There is/are comment(s) on this message.
There are additional comments to message 236.
--------------------------
I am starting a project using CTask and the Galacticomm break through librari
to build a NetBIOS communications server ( modem pools ). I think C++ combined
with CTask would be great... I am already building Classes for the Serial I/O an
d the
Ctask routines... Got some realy abstract ideas going on !
Later, Jamey ( Hi Burt )
Read:
==========================
ibm.other/ctask #238, from dzendzian, 374 chars, Thu Feb 7 01:28:20 1991
This is a comment to message 236.
--------------------------
Yes, I am using Ctask for a BBS. I was finding that trying to get some
memory location to contain which line the current task is using was
a major problem. Then TC++ came out. It solved all my problems. Are
you planning on making your BBS multi-line? Hopefully now that I am
over that major problem, it won't be too much longer until I get
something running.
David Z
Read:
==========================
ibm.other/ctask #239, from dzendzian, 410 chars, Thu Feb 7 01:30:16 1991
This is a comment to message 237.
--------------------------
Jamey, how are you going about the serial I/O classes? I am thinking of
the basic 'root' class for the async having the buffers being static,
so each class built off of that will just have a protected variable which
says which buffer to use. Sorta like that, how are you planning on doing
it? And how much did that Galacticomm break through library cost? I
made my own(not the best, but it works).
David Z
==========================
ibm.other/ctask #240, from dgh, 1251 chars, Thu Feb 7 12:49:49 1991
--------------------------
TITLE: Network Crashes CTASK program
When I am running a program that uses CTASK, any network activity that gets
directed to my PC causes it to crash. I'm using LANtastic with all PCs set
up as both servers and workstations. Am I forgetting to do something in my
program, or is CTASK just incompatible with the server? I have no problems
accessing files on other PCs, but if any PC tries to log in to my server or
do anything that results in disk activity on my server, my PC crashes. Help
me please! I'm using CTASK to develop a factory-floor application the must
have both multi-tasking and network capability on ANCIENT PC and COMPAQ H/W
that has been upgraded to XT class. If I can't use CTASK (which would be a
shame, because it has everthing I need), I will have to use setjmp, etc. to
simulate multi-tasking (I'm not using pre-emption) and write or buy serial
interface software - all of which will be a you know what in the you know
what! I am amazed that this pd software is so complete and robust. Thomas
Wagner deserves congratulations, praise, and thanks (and gets mine) for the
effort he has placed into CTASK. Thank you Thomas and keep up the excellent
work.
.More..
|) /\ \/ | |)
p.s. Good luck with your new computer fax product!
==========================
ibm.other/ctask #242, from vadim, 353 chars, Sat Feb 9 10:31:59 1991
There is/are comment(s) on this message.
--------------------------
TITLE: CTask and Novell
Hello Thomas,
I'm experiencing problems running CTASK on Novell workstations.
It appears that EMS version of Netware Shell dies immediately
when ctask app. is loaded. XMS version of the shell survives a little
longer. I've been trying with and without IFL_INT8_DIR having the same
result. Do you have any advice?
Vadim.
Read:
==========================
ibm.other/ctask #243, from vadim, 782 chars, Sat Feb 9 10:32:24 1991
There is/are comment(s) on this message.
--------------------------
TITLE: Task switching & Dos context
Thomas,
I have couple of comments on CTASK internal workings.
1. The Ctask sheduler does complete Dos context swap on each task switch.
This operation is rather costly in terms of cpu time.
Why not to delay Dos Context Swap until the moment the task tries to use
DOS? This will speed up tings significiantly for the tasks not issuing
DOS system calls. The DOS context swapping code would maintain
the pointer to last task which used DOS and will not swap the context
if current task equals to last DOS owner.
2. The scheduler have a special code to handle the case when there is no
.More..
task eligible to run. This situation can be avoided by creating a
lowest priority null task, performs a infinite loop.
Vadim.
Read:
==========================
ibm.other/ctask #244, from twagner, 763 chars, Sat Feb 9 15:17:03 1991
This is a comment to message 242.
--------------------------
Looks like something is broken... the last message also reported
trouble with a net. I couldn't yet reproduce it, though. We're
running the Invisible Net, and CTask didn't cause problems with
either the EMS or the standard memory version. I did not yet run a
CTask app on an Invisible Net server. I'd say that a *lot* could go
wrong with the kind of heavy background activity going on on a
server. However, even without running on a server, I've experienced
occasional hiccups with version 2.2 lately (system drops dead, or
tasks get into a deadlock waiting for DOS access). I am investigating
the problem, and the hints I received here on critical sections may
prove helpful. I still haven't received THE book, so please don't
expect immediate results.
Thomas
Read:
==========================
ibm.other/ctask #245, from twagner, 1834 chars, Sat Feb 9 15:17:35 1991
This is a comment to message 243.
--------------------------
> Why not delay Dos Context Swap until the task tries to use DOS?
> ... special code to handle the case when there is no task eligible
Both problems are somewhat related. You're right, in a *normal*
multitasking system, you'd have an Idle task, and you also would omit
all the special code that checks whether someone tries to put the
current task to sleep when there is no current task. But, sadly
enough, CTask *running under DOS* is not at all in a normal
situation. The problem is that CTask does *not* have complete control
over, nor complete knowledge about, the state of the system. There
can be interrupt handlers popping out of nowhere, calling DOS in
strange ways, possibly even (indirectly) requesting resources that
aren't free. So there you are - the idle task is interrupted, the
interrupting TSR (or whatever) tries to access DOS, is put to rest,
and the idle task is no longer eligible. If you don't have special
code to detect this, it's bye-bye time.
.More..
Likewise, if I only did a context swap when I knew that the task uses
DOS, I could miss those cases where a background interrupt has taken
over and changed the context. If the TSR was installed before CTask,
I might never see the INT 21 call (it's usual practice for many TSRs
to chain into INT 21, calling the previous in chain instead of
issuing the INT), so I wouldn't know that the running task
(indirectly) has entered DOS.
Such a situation could also be the root of the crashes with
Novell/Lantastic. Interrupts being interrupted, and then again
interrupting... I'm only speculating here, but my experience
indicates that 90% of all TSRs, and possibly even Network
redirectors, are written with the single-tasking nature of DOS in
mind. Even though they interrupt the system themselves, they all too
often expect to never be interrupted in turn.
Thomas
Read:
==========================
ibm.other/ctask #246, from dgh, 298 chars, Tue Feb 12 20:35:34 1991
--------------------------
TITLE: CTASK with CodeBase 4.2
Has anybody else tried to use CodeBase 4.2 with CTASK? I've made good progress
on the project, but now the program fails h4free_test () after it's been run
more than one time. Running any program in-between runs of my program causes
the failure to go away. Wierd.
==========================
ibm.other/ctask #248, from tbusch, 304 chars, Thu Feb 14 12:20:00 1991
This is a comment to message 244.
--------------------------
I've been using CTask on a ^^^^Zenith 248 on Novell with no problems. We ha
ve
replaced the 3COM driver software (we're using 3c505's) with a BYU packet
driver, and changed IPX to be compatible. We did this so we could share the
3COM card with TCP/IP software...maybe we gained an additional advantage.
Read:
==========================
ibm.other/ctask #249, from dgh, 490 chars, Sun Feb 17 21:41:28 1991
This is a comment to message 246.
--------------------------
Never mind - I gave up and restructured a critical area of the program,
simplifying it in the process and finding (and correcting) some mistakes
(none of which could have had to do with the problem, because they were
in areas of the program that were not executed). The thing seems to work
fine now. I just hope it isn't merely because the overall code is smaller,
because then the problem could come back as the program continues to grow...
I'm keeping my fingers crossed!
|) /\ \/ | |)
Read:
==========================
ibm.other/ctask #250, from amargerison, 150 chars, Sun Feb 24 10:51:06 1991
This is a comment to message 242.
--------------------------
Hmm.. We're also developing CTASK apps and ours works fine with all the 1.01 fla
vours of the SHells. Doing anything par
ticularly exotic ??
Stephen
Read:
==========================
ibm.other/ctask #251, from dzendzian, 849 chars, Sun Feb 24 15:08:35 1991
--------------------------
TITLE: Ctask and Dos interrupt 10h
I was reading through the ctask 2.2 manual, and saw that it supports a
video interrupt thingy. I am trying to convert a BBS to multi-line with Ctask,
and one of the things it does is catches dos interrupts so any program
which just prints to the screen can be redirected through the com port. I am
quite new to the idea of redirecting interrupts. What I want to do is have
the BBS program, if you specify that the program it is to run will redirect
interrupts, will redirect them, but not interfere with Ctask.
Another thing I want to do, is have anything that is to be printed on the
screen to be redirected to a window module, so it will allow each 'line' to
have it's own window.
If you have any idea what I just said, or any suggestions on what I'm trying
to do, it would be greatly appreciated.
David Z
==========================
ibm.other/ctask #252, from twagner, 545 chars, Wed Feb 27 16:59:52 1991
This is a comment to message 251.
There is/are comment(s) on this message.
--------------------------
The video interrupt support in CTask currently only serializes access
to INT 10. You could, however, easily expand this to redirect any
output through INT 10 to a window or comm port. For example, you
can change the @videntry routine in TSKDOS.ASM to call a routine you
supply. I'd recommend calling this routine after the call to
request_cresource, so you don't have to worry about reentrancy.
The registers passed to INT 10 are available on the stack. You can,
for example, access the original AX through save_ax[bp].
Does this help?
Thomas
Read:
==========================
ibm.other/ctask #253, from dzendzian, 342 chars, Sun Mar 3 03:36:30 1991
This is a comment to message 252.
There is/are comment(s) on this message.
--------------------------
It makes some sense. The idea of catching video interrupts, and redirecting
them is kinda new to me. I'll have to look through it. That part can wait
a while though.
Oh Thomas, you wouldn't happen to maybe possibly be expanding Ctask to C++
now that it is available w/Turbo?? I would think that doing it in classes
would be easier.
David
Read:
==========================
ibm.other/ctask #254, from twagner, 626 chars, Sun Mar 3 16:37:32 1991
This is a comment to message 253.
There is/are comment(s) on this message.
--------------------------
> expanding Ctask to C++
Ah, if I only had time... I don't see a CTask++ any time soon. There
has been some work done by others (for Zortech), though. I always
wanted to work with C++ (I even bought a C++ front-end four years
ago), but there was always some other work to do. Classes should
definitely make a number of things easier. One concern, however, is
performance (besides portability between compilers). Do you have any
experience whether C++ programs using classes tend to be slower or
faster than equivalent C programs? And how easy/difficult it is to
interface Assembler routines to a class-based program?
Thomas
Read:
==========================
ibm.other/ctask #255, from dzendzian, 537 chars, Mon Mar 4 01:03:11 1991
This is a comment to message 254.
There is/are comment(s) on this message.
--------------------------
As for C++ speed, the only speed difference I've been able to
really notice is in compiling. Running, it is similar in speed
to a normal C program, but not really noticeable(I'll have to
finally try out this Turbo Profiler and see how it works).
I don't know the name of but it is on Object Orientated
Assembler(That may be the title, I'm not sure).
Personally, since I started using C++, I find many things
a lot easier to do in C++. Good luck with it, I've got too
many projects of my own to see what I can see within it.
David Z
Read:
==========================
ibm.other/ctask #256, from sexton, 299 chars, Mon Mar 4 12:39:29 1991
This is a comment to message 255.
--------------------------
Its not too hard to construct a set of classes that manage lower
level stuff and make it easier to work with at a higher level.
I've done this for a handful of libraries, including ctask, just
so I could work faster. This does add function call overhead
though. Heck, buy a faster computer right?
==========================
ibm.other/ctask #257, from dzendzian, 380 chars, Sat Mar 16 20:45:17 1991
--------------------------
TITLE: Windows for Ctask
I picked up a book called "Systems Software Tools" by Ted J. Biggerstaff
at the ACM national convention, which has some nice stuff on how to
write a windowed premptive multi-tasker which supports memory management!
It is quite helpful for my problems w/understanding Ctask(which has some
things his doesn't, but his has the memory management!!).
David Z
Read:
==========================
ibm.other/ctask #258, from dgh, 3992 chars, Mon Mar 18 18:26:43 1991
--------------------------
TITLE: Network Problem - CTASK Related?
Hi, remember me? I reported a problem with my CTASK project a while back that
I resolved by restructuring the program. I now have another problem...
The application is a multi-tasking data collection and bar code tag printing
system. All of the various tasks access databases via Code Base 4.2 and use
the resource database_resource to lock each other out to insure that the Code
Base 4.2 stuff is single-threaded, because it doesn't know diddley from multi-
tasking, with the exception of some enhancements I've added to the keyboard
and error handling. There are three PCs in the system, all running the
identical software, with command line parameters distinguishing them as PC 1,
2 or 3. These PCs (two IBM 5150 PCs (you know, the ORIGINAL PC) and one
Compaq, '84 vintage - all of which have had the mother boards and cases
scrapped in favor of 12 Mhz XT MBs and 8-slot cases) are networked to a server
(AT&T 386SX) via LANtastic. The network task can be made to do nothing but
sleep (via t_delay) by not attaching a specific network drive (N:). OK, enough
background - here's the problem:
.More..
If I leave network drive N: detached, so that the network task on each PC does
nothing, I have no problems. The PCs stay up and running for days on end until
I pull the plug on them. BUT, if I attach network drive N: on ANY PC, thereby
enabling the network task to update the common database on the server from the
PCs local database, the PC will run anywhere from 15 seconds to two days and
then die. No error messages, no bleating of the speaker, the screen is still
up, the keyboard type-ahead buffer still works, but my tasks aren't switching
or doing anything else useful (Oh, I forgot to mention earlier that I have
pre-emption DISABLED). I have one hot-key that wakes up the NULL task to do
a snap-shot, but the snap-shot doesn't get executed (maybe some task is tied
up in its underwear and is not releasing time-slices to other tasks?) I am at
my wit's end on this one. I've been through the network stuff with a fine-
tooth comb (so to speak), but it appears to request and release the required
resources at the appropriate times and even calls schedule () to free up time-
slices for other tasks. I'm fairly certain that the problem is NOT one of
multiple tasks getting tied up waiting for multiple resources (the snap-shot
should still work even if that were the case, should it not?). The only thing
that I can think of is that there is some subtlety with using a network with
CTASK.
.More..
One thing that I discover that may relevant has to do with critical error
handling. I'm using Turbo C and have my own critical error handler. I wrote
a small test program to check it out with network accesses and CTASK. What I
wanted to do was to force a Retry on a "Network Connection Broken" error,
otherwise force a Fail. This worked like a champ. If I rebooted the server,
the workstation would get a critical error, see that it was "N..C..B.." and
do a re-try. The next error it would get was a different network error, so it
would fail. So every five seconds, when it attempted to access the network
file, it would get Retry, Fail and go back to sleep. When the server came
back on-line, it would get the N..C..B.. error, do a Retry which SUCCEEDS, and
go ahead and process the network file. The workstation was a 386/25 Mhz and
the server was a 386SX/16 Mhz. I then integrated this into the project that
I needed this for and didn't worry about it anymore. BUT, when I later put
the (nearly) completed program on the PC/XT clones, with the 386/25 Mhz as the
server, the PCs would CRASH EVERY TIME that my critical error handler tried to
do a Retry. By taking out the Retry and ONLY forcing Fail, the PCs no longer
crash, but they can't automatically re-connect to the server either.
Any help, hints, suggestions, obvious and/or not-so-obvious things that I
.More..
might have overlooked will be GREATLY appreciated!
|) /\ \/ | |)
Joining conference 'ibm.other', topic 'ctask'. 40 new messages.
Read:
==========================
ibm.other/ctask #259, from dgh, 2454 chars, Thu Mar 21 01:12:39 1991
This is a comment to message 258.
There is/are comment(s) on this message.
There are additional comments to message 258.
--------------------------
It's CTASK related and it's probably related to the explanation of CTASK vs.
network redirector that Thomas gave a while back. Here's the experiment I did
to uncover this:
Step 1: Write a simple C/CTASK program that opens a file on the server and
reads it periodically, printing the results as it goes.
Step 2: Run it on one PC - all is fine.
Step 3: Run it on a second PC - all still appears to be fine (both were
already connected to the server before the test program was run on
either of them).
Step 4: Connect the third PC to the server and do a NET ATTATCH/VERBOSE to
get attached to all of the server's resources. AHA! After attach-
ing to two resources, the third PC starts going beep-beep, which
means that the network is having difficulties accomplishing the
desired task. Also, the other two PCs have crashed, leaving the
.More..
type-ahead buffer functional (but nothing else). After a while,
the third PC manages to finish attaching to the server, but the
other two PCs stay dead.
Step 5: Reboot all the PCs.
Step 6: Create a second test program, but strip all of the CTASK stuff out
of it.
Step 7: Attach PCs 1 and 2 to the server.
Step 8: Run the C/CTASK test program on PC 2
Step 9: Run the C only test program on PC 1
Step 10: Attach PC 3 to the server - First it looks like both PC2 AND PC1
have crashed. However, after PC3 finally finishes connecting to
the server, PC1 (running the C only test program) resumes testing,
whereas PC2 (running the C/CTASK test program) stays dead.
Conclusion - listed before the steps...
Questions:
What can I modify in the CTASK kernel to attempt to avoid this conflict?
I do NOT need pre-emptive multi-tasking (don't use it, in fact). My
application only needs co-operative multi-tasking. Are there things that
I could move from the kernel to a function that I would explicitly have to
call when I wanted to switch tasks? I have looked at some of the kernel
.More..
code in the past, but I am not familiar enough with it to answer these
questions on my own.
|) /\ \/ | |)
p.s.
Didn't someone mention earlier that they were successfully using CTASK with a
network application? If so, could you please tell me if you did anything
special or modified CTASK and how? Thank you very much in advance!
Read:
==========================
ibm.other/ctask #260, from dgh, 239 chars, Thu Mar 21 21:05:27 1991
This is a comment to message 259.
There is/are comment(s) on this message.
--------------------------
One last plea:
If ANYBODY has experience in running a CTASK based program on a LANtastic
workstation, especially if the program accesses files on the server, PLEASE
reply to this message and give any details you can!
|) /\ \/ | |)
Read:
==========================
ibm.other/ctask #261, from dave2, 85 chars, Thu Mar 21 21:50:51 1991
This is a comment to message 260.
There are additional comments to message 260.
--------------------------
If you can BIXmail a sample to me I can report what it does on my LANtastic
system.
Read:
==========================
ibm.other/ctask #262, from barryn, 155 chars, Fri Mar 22 09:24:26 1991
This is a comment to message 258.
There are additional comments to message 258.
--------------------------
Tom Wagner will be back shortly; he's at the CeBit trade show
in Hannover this week. Perhaps Tom will have an answer for the
LANtastic/CTask problem.
Read:
==========================
ibm.other/ctask #263, from twagner, 757 chars, Fri Mar 22 16:38:29 1991
This is a comment to message 258.
--------------------------
I'm back, and slowly catching up on the tons of messages...
I haven't yet seen problems with CTask on a network, but I don't
think I tested your particular application. I'll try to reproduce
your problem on our network (Invisible) next week. Could you BIXmail
me your test program?
There may be some hidden bug in CTask that only surfaces in special
configurations. Something smells fishy, but I can't pinpoint it. I
tried for weeks to get CTask to reliably work with Windows 3.0, but
no luck. Strange crashes with no discernible pattern. And Periscope
doesn't work with Windows 3... It may be a problem completely
unrelated to your network troubles (Windows seems to crash a lot of
background switchers), but I'm not sure. I'll keep on digging.
Thomas
.More..
Read:
==========================
ibm.other/ctask #264, from sworthington, 456 chars, Tue Mar 26 20:26:51 1991
This is a comment to message 260.
There is/are comment(s) on this message.
--------------------------
We run our CTask application on LANtastic workstations all the time,
without any trouble. Although I haven't done it recently, I've also
run it with its database on a server and still had no trouble.
When we DO get into trouble is running a CTask app on a SERVER. It's
fine as long as no other workstation uses the server's disk. If that
happens, it's instant Black-Hole City. I think at both ends.
(I think Tom knows about this one)
Andrew Merton
Read:
==========================
ibm.other/ctask #265, from sjadams, 726 chars, Tue Mar 26 23:38:18 1991
There is/are comment(s) on this message.
--------------------------
TITLE: protected mode ctask ??
I would like to be able to have ctask run with access to all of the memory
on my machine (2 Megs) not just 640K. What would be involved in getting
ctask to run in protected mode (not using any fancy protected mode
task protection) simply to have access to the full 16 Meg address space.
I am not so concerned about returning to DOS or even calling DOS once
in protected mode but am not sure of what is involved in generating
code which will run in protected mode. There are some examples around
which will get you into and back out of protected mode (these are in assembly)
Also are there any simpler alternative such as tasks being able to use ems/
expanded memory ????
Thanks,
Stuart Adams
.More..
Read:
==========================
ibm.other/ctask #266, from dgh, 513 chars, Wed Mar 27 10:23:51 1991
This is a comment to message 264.
--------------------------
I've reported the CTASK/Server crash problem also. That one I understand.
The one where the only the Workstations crash only when they access files on
the server is really giving me headaches.
I have an alternate solution (replace CTASK with the C++ co-operative
multitasker from the April '91 Dr. Dobbs Journal and the SilverWare
C Comm Library), but I'd rather not have to switch horses (so to speak)
this late in the game...
I'm actually hoping that it's something stupid that *I'm* doing wrong
in my code...
Read:
==========================
ibm.other/ctask #267, from twagner, 893 chars, Thu Mar 28 19:17:00 1991
There is/are comment(s) on this message.
--------------------------
TITLE: Crashes with CTask and Networks
I tested David's test program on our Invisible Network for a while.
No matter what I did - no crash. The test program repeatedly reads
from a file on drive N: (a net drive), and from the local drive.
Even when the test program was run on a server, everything was
normal. My final test was:
- Station 1 (server): map N: to station 2, run test
- Station 2 (server): map N: to station 1, run test
- Station 3 (works.): map N: to station 1, run test
- Station 4 (works.): access files on stations 1 and 2
Even with this setup the program ran for 30 minutes (I then
terminated the test) without a glitch.
.More..
So - what next? It looks like an incompatibility between Lantastic
and CTask, but I don't have Lantastic to check it out. Does anyone
have at least a hint on what could be happening? What does Lantastic
do that Invisible doesn't?
Thomas
Read:
==========================
ibm.other/ctask #268, from twagner, 1265 chars, Thu Mar 28 19:17:51 1991
This is a comment to message 265.
There is/are comment(s) on this message.
--------------------------
> protected mode ctask
I haven't done any protected mode programming yet, but as I
understand it, it's like writing for a completely different machine.
To get CTask to work in all aspects under protected mode, you'd have
to recompile everything with a compiler capable of generating
protected mode code (Turbo and MSC aren't), and you'd have to rewrite
all Assembler parts. So... I'd say there will be no protected mode
CTask any time soon.
As we've just discussed in ibm.other/other, it may be possible to
access more memory from Assembler routines without all the protected
mode hassle, i.e. CTask and your program would still be running in
real mode. However, this would be completely incompatible with any
other memory manager (HIMEM, EMM386, QEMM, 386MAX, extended memory
.More..
cachers, and even VDISK). I also wouldn't see the connection to
CTask, such routines should IMO be indepent of CTask, or interface
with it through the standard mechanisms (resources, task switch
save/restore calls) where necessary.
Using EMS in CTask routines is supported. The current EMS page status
(standard 64k page frame only) is saved and restored on a task
switch, so you can use different mappings in different tasks. With
anything else (XMS etc.) you're on your own.
Thomas
Read:
==========================
ibm.other/ctask #269, from dgh, 264 chars, Thu Mar 28 19:40:45 1991
This is a comment to message 267.
There are additional comments to message 267.
--------------------------
Ouch, ouch, ouch, ouch!
Looks like I'll have to go the alternate route after all. I wish I could give
you a clue as to what LANtastic does different from Invisible, but I have no
idea. Maybe dave2's testing will shed some light on the situation...
|) /\ \/ | |)
Read:
==========================
ibm.other/ctask #270, from mvanditta, 768 chars, Thu Mar 28 21:59:27 1991
This is a comment to message 267.
There is/are comment(s) on this message.
--------------------------
Thomas,
I had a problem with my workstation based non-dedicated print server
for NetWare (MTVSpool) that was much like the problem this person is
experiencing. The problem turned out to be caused by the interrupt stacking
discpline that DOS versions 3.2 and above use. It seems that old Big Blue
forced MS to add code into the DOS kernel which would allocate local stacks
automatically to ISRs. After close observation (and a little reverse
engineering), I found that DOS will tend to run out of these local stacks
if it has a preemptive multitasker thrust upon it. Also, I determined that the
best way to handle this problem was to tell DOS not to allocate local stacks
to ISRs by adding STACKS=0,0 to the workstation's CONFIG.SYS file.
Mark T. Van Ditta
Read:
==========================
ibm.other/ctask #271, from mvanditta, 260 chars, Thu Mar 28 22:03:08 1991
This is a comment to message 268.
There is/are comment(s) on this message.
--------------------------
Thomas,
One can write protected mode code with Turbo C or C++; but, they must set
up their own Descriptor tables, write their own device drivers (as bios does
not work in protected mode), and pray that every thing works the first time.
Mark T. Van Ditta
Read:
==========================
ibm.other/ctask #272, from thu, 20 chars, Fri Mar 29 00:45:42 1991
There is/are comment(s) on this message.
--------------------------
What is CTask?
Tim
Read:
==========================
ibm.other/ctask #273, from twagner, 586 chars, Fri Mar 29 12:44:04 1991
This is a comment to message 270.
There is/are comment(s) on this message.
--------------------------
> adding STACKS=0,0 to the workstation's CONFIG.SYS file
Ah ha! This could be an important lead. I have stacks=0,0 on my
development machine (one of the workstations I used for testing),
I'll have to check the other stations after the easter holidays.
David's program doesn't use preemption, but there still could be some
unpleasant interaction between DOS's stack switching and the
switching CTask does. Another explanation could be differences in
interrupt frequency between Lantastic and Invisible. Does Lantastic
use EMS, XMS, or extended memory to store its code or data?
Thomas
Read:
==========================
ibm.other/ctask #274, from twagner, 423 chars, Fri Mar 29 12:44:18 1991
This is a comment to message 271.
There is/are comment(s) on this message.
--------------------------
> One can write protected mode code with Turbo C or C++
Oh, that's interesting. I always thought that the meaning of certain
instructions changes if you go to protected mode, for example that
some instructions access only the 16-bit part of the registers if you
are in real mode (unless you use a special prefix), and the same
instruction uses the full 32-bit register in protected mode. Am I
completely off base?
Thomas
Read:
==========================
ibm.other/ctask #275, from twagner, 183 chars, Fri Mar 29 12:44:40 1991
This is a comment to message 272.
--------------------------
> What is CTask?
It's a preemptive multitasking kernel for C (Turbo and Microsoft).
Public Domain, and comes with complete sources. Do a "sear key ctask"
in ibm.pc/listings.
Thomas
Read:
==========================
ibm.other/ctask #276, from dgh, 521 chars, Fri Mar 29 14:03:08 1991
This is a comment to message 273.
There is/are comment(s) on this message.
--------------------------
>STACKS=0,0
Sorry, no such luck for me! The problem is still there. LANtastic does not
use EMS, XMS or extended memory, besides which I have none on the XT machines.
It only uses whatever memory it allocates when it goes TSR, plus it uses the
RAM on the Ethernet card. I'm using Artisoft's WD8003 driver and AILANBIOS on
MPX number C7 (WD8003 and AILANBIOS communicate via INT 2F, MPX=C7). Unless I
hear something positive from dave2 by Monday, I will have to start switching
over to the Dr. Dobb's C++ multitasker.
Read:
==========================
ibm.other/ctask #277, from dzendzian, 871 chars, Fri Mar 29 18:12:29 1991
There is/are comment(s) on this message.
--------------------------
TITLE: Multiple-DOS sessions
Hi, I'm working on a multi-line BBS w/Ctask, and I've run into a little
problem. I would like a function of the BBS to be able to intercept the
DOS calls and redirect them to whichever line is using it. In other words
I'd like to have one line play a game or run a program which uses BIOS or
ANSI calls, etc and redirect them to that line, and then another line
able to do the same thing.
The problem is that I can easily redo the INT 21 so it will send the
calls to an interpreter for a com port, but I can't get the new INT to
distinguish which port to send it to. I've decided to write it in C++
which saves a lot of problems for normal port conflicts, but this one
low level function can only be installed once.
If anyone has any idea what I'm talking about, and has any suggestions
I'd be extremely greatful to hear them.
.More..David Z
Read:
==========================
ibm.other/ctask #278, from mvanditta, 338 chars, Fri Mar 29 21:33:38 1991
This is a comment to message 274.
There is/are comment(s) on this message.
There are additional comments to message 274.
--------------------------
You are partially right, one can write 286 protected mode code with TC or
TC++ because it still uses 16 bit words and offsets, but one cannot write
386 protected mode code with TC or TC++ because of the 32 bit addressing.
That is not to say that the code cannot be run on a 386, it just cannot
take advantage of 32 bit addressing.
Mark
Read:
==========================
ibm.other/ctask #279, from mvanditta, 121 chars, Fri Mar 29 21:36:31 1991
This is a comment to message 276.
There is/are comment(s) on this message.
There are additional comments to message 276.
--------------------------
David,
If you want a C++ alternative to Ctask, then see my code in the Borland
C++ conference.
Mark T. Van Ditta
Read:
==========================
ibm.other/ctask #280, from twagner, 351 chars, Sat Mar 30 17:46:39 1991
This is a comment to message 276.
There is/are comment(s) on this message.
--------------------------
Oh well... <sniff> there goes another customer... :-(
I hope you'll be more successfull with the Dr. Dobbs stuff. Sometimes
I think I've bitten off more than I could chew by trying to make
CTask compatible with every TSR and strange driver under the sun. Some
#@$% feature is haunting you, me, and a few others. If I only knew
where to look!
Thomas
Read:
==========================
ibm.other/ctask #281, from twagner, 374 chars, Sat Mar 30 17:47:00 1991
This is a comment to message 278.
There is/are comment(s) on this message.
--------------------------
Oh my, naturally <blush>. I'm writing Windows programs all day, and
the 16-bit code runs just fine in protected mode! Where did I get
that idea? Looks like I should take a lengthy vacation... Now I
think I remember - it's an attribute bit in the code segment
descriptor that controls whether instructions are interpreted as
32-bit or 16-bit, am I right this time?
Thomas
Read:
==========================
ibm.other/ctask #282, from twagner, 474 chars, Sat Mar 30 17:47:14 1991
This is a comment to message 277.
There is/are comment(s) on this message.
There are additional comments to message 277.
--------------------------
> distinguish which port to send it to
You do have separate tasks for each port, I'd assume. So the task
issuing the DOS call must implicitly be connected to a port line.
You could use the "user pointer" in the task control block to point
to an info block for each task, or extend the TCB structure to
contain the necessary info. Then you'd simply access the current
task's TCB with curr_task(), and get the port number (or port pointer
or whatever) from this TCB.
Thomas
Read:
==========================
ibm.other/ctask #283, from mvanditta, 928 chars, Sat Mar 30 17:58:58 1991
This is a comment to message 280.
There are additional comments to message 280.
--------------------------
Thomas,
Don't be sad, I have the same kind of problem which haunts me with
MTVSpool, my non-dedicated workstation based printer server for NetWare.
I believe that when one tries (as I did with MTVSpool) to preemptively
multitask DOS (also NetWare in my case), they will ultimately find hardware
configurations which will not support the application. I have customers who
can run MTVSpool and the XMSNETx.EXE shell without any problem, and I
have customers who cannot run this configuration for 1 minute without
hanging the machine. I too would like to find the section of code which is
causing this problem, but until then, I recommend that my customers stay as
far away from the XMSNETx.EXE shell as possible. Keep up the good work,
I have seen your software and it looks very good to me. I do have one
suggestion though, and that is to look at how you are handling DOS's critcal
sections.
.More..
Mark T. Van Ditta
Read:
==========================
ibm.other/ctask #284, from mvanditta, 24 chars, Sat Mar 30 18:00:03 1991
This is a comment to message 281.
--------------------------
You are correct Thomas.
Read:
==========================
ibm.other/ctask #285, from thu, 255 chars, Sat Mar 30 21:34:51 1991
This is a comment to message 274.
--------------------------
There are two modes on the 386: 32-bit and 16-bit. If you're in 32-bit mode,
you need to use prefixes to use 16-bit data. If you're in 16-bit mode, you
need to use prefixes to use 32-bit data. I believe this is true in both
protected and real mode.
tim
Read:
==========================
ibm.other/ctask #286, from mshelley, 359 chars, Sat Mar 30 22:12:34 1991
This is a comment to message 277.
There is/are comment(s) on this message.
--------------------------
If your creating a BBS, you might want to consider using another OS instead
of Dos (especially for a multi-line BBS)... To accomplish a multi-line BBS
under Unix, you would just write to stdout and read from stdin for your I/O...
Multi-tasking is very easy, communications between processes is very easy
also... It might be worth considering...
Mike Shelley
Read:
==========================
ibm.other/ctask #287, from dgh, 667 chars, Sun Mar 31 15:57:11 1991
This is a comment to message 280.
There is/are comment(s) on this message.
--------------------------
Don't think of it as losing another customer, think of it as gaining
... uh, uh, bad analogy - never mind...
Part of my problem was that I did not anlalyze my multi-tasking needs
carefully enough before I jumped in with both feet. As it turned out,
all I needed was cooperative MT and a serial I/O library. A fully
pre-emptive MT, such as CTASK, was overkill. I would have stuck with it
if it were not for the network problem... I will consider it in the future
if I need a fully pre-emptive non-networked application. You have a good
product - the only problem is that it has to sit on top of DOS, the dog of
operating systems (for non-embedded apps, anyway).
Read:
==========================
ibm.other/ctask #288, from dgh, 249 chars, Sun Mar 31 16:40:23 1991
This is a comment to message 279.
There is/are comment(s) on this message.
--------------------------
Thanks for the pointer. It looks more complete than the Dr. Dobbs code, plus
it handles all memory models. Dr. Dobbs code has a single round-robbin queue.
For those who want to download the code, it is in borland/b.c.plus.plus #541.
|) /\ \/ | |)
Read:
==========================
ibm.other/ctask #289, from mvanditta, 218 chars, Sun Mar 31 17:01:20 1991
This is a comment to message 288.
--------------------------
David,
You're welcome, I hope you can put my Cooperative Multitasking Class
Library for TC++ and BC++ to good use. If you have any questions, then
please feel free to contact me via BIX mail.
Mark T. Van Ditta
Read:
==========================
ibm.other/ctask #290, from dzendzian, 307 chars, Mon Apr 1 00:09:44 1991
This is a comment to message 282.
There is/are comment(s) on this message.
--------------------------
I was hoping to stay away from that "control block", but I agree
I think it will be the best method. As for mvanditta, I've seen
your code, got a copy of it, just need to play with it. However
it has a long way to go until it can compare w/Ctask. But it is a
nice foundation.
So many choice...
David Z
Read:
==========================
ibm.other/ctask #291, from dzendzian, 185 chars, Mon Apr 1 00:11:01 1991
This is a comment to message 286.
--------------------------
Yes another OS would make things easier..but with several million(maybe
billion) PC's out there, there is a much larger market. Especially
with the new Peer-to-peer lans, etc.
David Z
Read:
==========================
ibm.other/ctask #292, from twagner, 1154 chars, Mon Apr 1 16:06:39 1991
This is a comment to message 287.
There is/are comment(s) on this message.
--------------------------
> the only problem is that it has to sit on top of DOS
Exactly. I had to give up CTask myself for a recent FAX project
because I couldn't get it to cooperate with Windows 3.0. On our FAX
card itself, however, CTask has been running flawlessly for months on
end. Despite recent protests in another conf: the whole DOS/TSR/Windows
shebang is a big kludge. But still, DOS can't be beat for simplicity
and ease of expansion. Writing a Windows device driver is hard
enough, and I've heard horror stories about writing OS/2 drivers.
Adapting a strange device to DOS on the other hand usually can be
done with a little trickery in a relatively short time. Sure, you
likely end up with a kludge on top of a kludge, but at least it
works...
Well, I'm rambling off topic - back to CTask: I don't give up that
.More..
easily. I will continue to try to find the incompatibility with
Windows, and if I find it it might turn out to be the same problem
that was killing your app. Brett Salter has announced that they're
working on making Periscope to cooperate with Windows, so I might
finally get back my most important debugging tool. Too late to help
you, though.
Thomas
Read:
==========================
ibm.other/ctask #293, from cblum, 1003 chars, Mon Apr 1 21:58:32 1991
--------------------------
TITLE: Ctask in the 'Real World'
Thomas:
I had to take pity on you with the recent gripes in the message stream,
so I thought I would contribute a success story.
I am an industrial controls consultant, and my latest project owes much
to your efforts. It is a two axis servo system running an eddy current
test aparatus looking for grinding injuries on bearing race surfaces. It
does real-time data acquisition ( 800hz sampling on two analog channels ),
vector analysis, real-time graphing in 16 color 640 x 480 VGA resolution
and serial communication at 38.4KB using a 386/387 running at 20Mhz.
The only change required was to upgrade the serial port chip to a
NS16550A and change Ctask to support the FIFO buffer ( code will be uploaded
to you shortly ). This was needed because during extended bursts ( several
thousand bytes at a time at full speed ) the standard setup occasionally
lost a character.
.More..
Thanks for a REALLY GREAT piece of work made available to us all!
Chris Blum
Read:
==========================
ibm.other/ctask #294, from mvanditta, 391 chars, Mon Apr 1 22:45:11 1991
This is a comment to message 290.
There is/are comment(s) on this message.
--------------------------
David,
I did mean to compare my code to Ctask, I only offered it as an
alternative set of primatives. Since, my primative (and I do mean primative)
Cooperating Multitasking Library is object oriented, its objects can be
used to create more powerful objects (i.e. the semaphore class can be used
as a basis for resources, events, pipes, mailboxes et al).
Mark T. Van Ditta
Read:
==========================
ibm.other/ctask #295, from mvanditta, 265 chars, Mon Apr 1 22:55:03 1991
This is a comment to message 292.
There is/are comment(s) on this message.
--------------------------
Thomas,
Have you checked the INT 2F - 1681/1682 functions that turn off/on windows
preemption. The NetWare Shell as well as IPX use these functions to keep the
Windows Multitasker out of the way while they are in critical sections of code.
Mark T. Van Ditta
Read:
==========================
ibm.other/ctask #296, from twagner, 198 chars, Tue Apr 2 19:31:16 1991
This is a comment to message 295.
--------------------------
I tried to protect the scheduler with those functions, but it didn't
help. Without a working debugger, it's a royal pain to locate such a
problem, so further development may have to wait...
Thomas
Read:
==========================
ibm.other/ctask #297, from dgh, 1258 chars, Tue Apr 2 22:17:39 1991
This is a comment to message 294.
There is/are comment(s) on this message.
--------------------------
I mentally added a "not" between "did" and "mean" 8^)=
I was pleasantly surprised to find that you had already implemented semaphores
in you object scheduler. I have already added a mailbox class based on it. I
am using semaphores where I used to use counters and resources. I initialize
resource semaphores to 1 and counter semaphores to 0. It looks to be very
extensible. With the Dr. Dobbs object tasker, I would have had to write the
semaphores myself, which would have been a disaster, because I am VERY new to
object programming with C++. So far, I've gotten through the first five
chapters of the Annotated C++ Reference Manual by Stroustrup and Ellis, but I
haven't even cracked the covers on the Tao of Objects by Entsminger. I can
see that the main advantage your object scheduler has over the Dr. Dobbs
object tasker is in that you have a list class underlying everything, whereas
Dr. Dobbs has the task class do EVERYTHING...
.More..
At any rate, I'm forging ahead with the conversion. I'm useing SilverWare's
SilverComm "C" Async Library for the serial I/O. I almost tossed a coin to
decide which package to get, but in the end I picked this one because a
colleague had good experience with the Clipper version of the library.
|) /\ \/ | |)
Read:
==========================
ibm.other/ctask #298, from mvanditta, 800 chars, Tue Apr 2 23:33:19 1991
This is a comment to message 297.
--------------------------
David,
That's the beauty of counting semaphores, you can build just about any
mutual exclusion or interprocess communication device with them. As far as
object oriented programming, I have yet to read a book on the subject.
I became an object oriented programmer during my Ada programming days. Ada
was the first language I used that provided mechanisms for information
hiding and overloading. In addition, my Cooperative Multitasking Kernel was
originally developed in Object Turbo Pascal (my favorite language); so, if
anyone would like a copy of the OTP version, I will upload it to the Borland
listings in a day or two. Also, the descendence from the Node Class was done
for a reason, and that was to allow one to create lists of tasks, queues,
semaphores et al.
Mark T. Van Ditta
==========================
ibm.other/ctask #299, from mshiels, 275 chars, Sun Apr 7 00:22:30 1991
There is/are comment(s) on this message.
--------------------------
TITLE: Resident programs with CTask
Has anyone had any experiences lately with Resident programs and
Ctask?
Thomas: How did you envision Ctask/Windows co-operating? I have done
some TSRs which run under windows and allow TSRs to call into different
Enhanced mode windows.
Read:
==========================
ibm.other/ctask #300, from twagner, 283 chars, Sun Apr 7 16:58:00 1991
This is a comment to message 299.
--------------------------
> How did you envision Ctask/Windows co-operating?
Ah yes, a vision it is - but not reality (see previous messages). The
problem isn't the communication between a Windows app and CTask (all
you need are a few DPMI calls), it's getting Windows and CTask to
cooperate at all.
Thomas
Read:
==========================
ibm.other/ctask #301, from datacode, 283 chars, Thu Apr 11 17:30:14 1991
--------------------------
TITLE: Ctask22
Is there one spot to locate all contributed fixes to Ctask22?.
I have a problem where tsk_timer_action receives a tlinkptr for a
TKINK_TASK but the elem-> elkind contains a 0, this renders a TWATCH
return code when the wait was for a time period (sb TIMEOUT).
==========================
ibm.other/ctask #302, from wwang, 308 chars, Wed Apr 17 11:12:09 1991
--------------------------
TITLE: keyboard interface for XT.
Can some one tell me why I have problem upgrading program from CTASK20 to
CTASK22 with keyboard routine on my XT. The t_read_key() keeps on getting
a NULL char and locking up the system. The same program runs OK on an AT.
I kind of feel it must be something fundamental.
Read:
==========================
ibm.other/ctask #303, from cmpetersen, 351 chars, Thu Apr 18 20:48:54 1991
--------------------------
TITLE: ISR for RTC
I've been playing around trying to get the RTC interrupt to work (IRQ8 at
vector 0x70 I think). I understand that this should generate 1024 Hz
interrupts, but I seem to get nothing. I don't have any documentation at all
about how this hardware works. If anybody has a C code fragement or some
details, I'd appreciate it.
Chris
Read:
==========================
ibm.other/ctask #304, from kokhong, 530 chars, Sat Apr 20 09:54:46 1991
There is/are comment(s) on this message.
--------------------------
TITLE: Extended keyboard
I have a 101 key extended keyboard. When I run the test program in ctask,
I found that the ASCII code returned by the arrow keys, PGDN, PGUP, HOME, END,
DEL, INS keys are different - depending on whether I use the ones on the
numeric keypad. On investigating, I found that the ones on the numeric
keypad correctly return an ASCII code of 0 and the correct scan code. But
the other keys ALL return a 0xe0 as the ASCII code, although the scan codes
are still correct. Does anyone know of this problem?
Read:
==========================
ibm.other/ctask #305, from awhitlock, 543 chars, Sun Apr 21 16:09:12 1991
--------------------------
TITLE: CTASK & 3RD Party Apps
Hello, I am evaluating CTASK to see if it can help mulit task a couple
of my own TSRs, a 3rd party apps which is getting data via a net card
and an off-the-shelve package(s) either PROCOMM of CARBON COPY. My TSRs
will be monitoring the comms for incoming calls. My concern is with
running 3rd party apps which I cannot touch. I have CTASK2.0 and
have begun reading your material but I'm concerned about any
gotcha's I should be aware of in running 3rd party apps & CTASK.
Thanks for your contributions,
Andy.
Read:
==========================
ibm.other/ctask #306, from twagner, 281 chars, Sun Apr 21 16:49:43 1991
This is a comment to message 304.
--------------------------
That's how it's supposed to work, so you can distinguish between the
different keypads. The E0 code is returned by the BIOS on an extended
keyboard read on all keys unique to the 101-key keyboard (except
those that have a normal ASCII code in the lower byte, and F11/F12).
Thomas
==========================
ibm.other/ctask #307, from haziz, 179 chars, Tue May 14 13:01:42 1991
--------------------------
TITLE: C-Task Huge memory under Bor C++ 2.0
I have been having problems with generating the C-Task library in huge memory
model under Borland C++ v2.0. I have C-Task v2.2.
[H.A]
Read:
==========================
ibm.other/ctask #308, from twagner, 1107 chars, Thu May 16 19:37:15 1991
--------------------------
TITLE: CTask update in Listings
I've posted an update for CTask version 2.2 to version 2.2b today.
It contains those files changed since the original 2.2 release only,
you need CTask 2.2 or 2.2a for the complete CTask source.
Filename is "ctupd22b.lzh", listings area "ibm.pc/listings".
If you've applied the bug fixes to 2.2 posted here, then there's no
pressing need to download this file unless you want to work with BC++
in huge model. A complete 2.2b release will follow some time next
week.
The known bugs posted here were fixed. Other fixes:
- Turbo C Huge model produced fixup errors due to an incorrect placement
of an "extern" directive in TSKINT17.ASM.
This release also corrects a problem with Borland C++ 2.0 Huge model.
BC++ uses a slightly different data segment structure, which has to
be accounted for in the Assembler modules. TSK.MAC was changed, and
you have to define BC_HUGE instead of TC_HUGE when compiling for BC++
2.0 Huge model.
Typecasts were added in several modules to allow compilation in C++
"native" mode, which does not support some ANSI C type coercions.
Thomas
Read:
==========================
ibm.other/ctask #309, from rmholm, 286 chars, Tue May 21 00:24:49 1991
--------------------------
TITLE: CTASK and VGA graphics
I promised aome re-entrant vga routines that would work with
CTASK a while back, and now that I have some free time from work
I can work on them again. I currently have a VGASetMode, VGAPixel,
and a VGAReadPixel. If anyone wants I will upload them.
Rich
Read:
==========================
ibm.other/ctask #310, from twagner, 690 chars, Tue May 28 17:43:48 1991
--------------------------
TITLE: Fix for source update bug
The version 2.2b source update still contains a bug in tsk.mac. The
definition for the "tick_rec" structure doesn't agree with the
corresponding definition in tsk.h (which is the correct one). Since
the automatically installed TSKINT17 assembler module uses a ticker,
you'll get all kinds of strange crashes, especially when removing the
tasker.
The correct definition is
tick_rec struc
ticknext dd ?
ticklo dw ?
tickhi dw ?
IF GROUPS
tickchain db TYPE queue_head dup(?)
ENDIF
IF TSK_DYNAMIC
tickflags db ?
ENDIF
tick_rec ends
Thomas
==========================
ibm.other/ctask #311, from twagner, 685 chars, Tue May 28 17:44:10 1991
--------------------------
TITLE: Away from the keyboard
I'll be on a three-week US tour starting this Thursday, so I won't
be on for a while (I don't have a laptop). Please try to help each
other while I'm gone, post questions/fixes here instead of BIXmailing
them to me.
The promised "full" CTask update will have to wait till I'm back, I'm
afraid. No time left...
BTW, if you're in or around Charleston, SC on the 5th or 6th of June,
don't miss the concert in the Cathedral of St. John the Baptist. I'll
be singing (together with about 80 others) the "Elias" by
Mendelssohn-Bartholdy. Nice music, and (hopefully) a fine example of
how to coordinate 120 individual tasks using a single resource. ;)
Thomas
Read:
==========================
ibm.other/ctask #312, from cblum, 418 chars, Mon Jun 10 22:38:47 1991
--------------------------
TITLE: Ctask 2.2 Serial support
Thomas: ( and anyone else interested )
Ctask Serial support for multiple ports with shared interrupts which
you said in the doc was untested - is now tested and works fine. Using it
to drive four (4) ports sharing one (1) interrupt on a STD bus controller
talking to hand-held terminals. CPU is an 8088 at 10Mhz. Another fine
piece of work, Tom. Thanks again.
Chris Blum - cblum
Read:
==========================
ibm.other/ctask #313, from marco.m, 856 chars, Wed Jun 12 12:10:05 1991
--------------------------
TITLE: Spawning multiple DOS tasks
I'm writing a multiuser bulletin board system using Ctask 2.2. It works fine
but I'm in a situation that need to launch some external utilities (and, if
possible, a DOS shell for background maintenance).
Spawning DOS works well, but, when the Sysop-side task is in the DOS shell,
all other tasks aren't able to open files with fopen() functions but only
with then open() function (that don't dinamically allocate memory, I think).
I figured out the problem and a possible solution: the task that
intend to spawn a DOS program, must allocate a sufficient memory
area, load the program into that memory, then execute them.
Is anyone out there that has solved this kind of problem? Actually
my knowledge of the DOS load & start functions isn't enough to
write a similar function......any help is greatly appreciated.
Bye
Read:
==========================
ibm.other/ctask #314, from mnagel, 962 chars, Sat Jun 15 17:00:28 1991
--------------------------
TITLE: MSC 5.1 and stacks in the heap
^UI'm developing a voice messaging product using CTask and I'm finding myself
in need of more stack space. ^F I've tried allocating stack from the heap
rather than using alloca, but all attempts have failed. Originally, they
failed because the MSC runtime library forces stack checking in some routines.
So we got the source and turned it off. Now we no longer get stack overflow
crashes, but other things are mysteriously odd. For example, difftime no
longer works properly. The gmtime function gets everything right except the
hours and minutes are completely messed up. I'm guessing this has to do with
the way MSC passes return values that do not fit into registers, but other
than that, I'm stumped. I have Borland C++ also, but have not yet tried
rebuilding the system with that. Would that solve my problems? Or is there
a way to get around this with other modifications to the library or extra
compiler flags?
Read:
==========================
ibm.other/ctask #315, from tgentry, 493 chars, Sat Jun 22 23:56:07 1991
There is/are comment(s) on this message.
--------------------------
TITLE: CTask and C++ - compatible?
I'm running Turbo C++ (and Borland C++, less frequently), and I'm wondering
if the memory alloction reentrancy problem has been solved in that language
yet. I tried surrounding the calls to the "new" operator with
request_resource() calls, but the program still doesn't run correctly (if
"doesn't run correctly" can be translated as "locks the machine up completely").
Is anybody using CTask under C++? Any good tips? I'd appreciate the help...
-Tim
Read:
==========================
ibm.other/ctask #316, from rlh, 167 chars, Mon Jun 24 17:51:36 1991
--------------------------
TITLE: CTask and C++ - new operator
Have you tried overloading the new operator? If you haven't, try overloading
new so that it calls tsk_alloc() to allocate memory.
Read:
==========================
ibm.other/ctask #317, from cblum, 351 chars, Mon Jun 24 23:06:52 1991
This is a comment to message 315.
There is/are comment(s) on this message.
--------------------------
I have sent Thomas a piece of code that takes care of all memory allocates
under Borland C++. He will be posting it soon. It is basically changes to
his module that handles malloc, but it front-ends all calls to all
varieties of allocation or free, even if ( it thinks it is ) direct to
malloc, etc. I have used it and it seems to work well for me.
Read:
==========================
ibm.other/ctask #318, from tgentry, 256 chars, Wed Jun 26 00:29:27 1991
This is a comment to message 317.
There are additional comments to message 317.
--------------------------
I look forward to seeing it, thanks. The memory allocation in C++ (in
this case, Turbo C++) seems to be a problem even after creating an
overloaded new operator, both "globally", and in a test class. Sigh.
I'll be waiting for this code to pop up here...
Read:
==========================
ibm.other/ctask #319, from tgentry, 596 chars, Wed Jun 26 02:10:23 1991
There is/are comment(s) on this message.
--------------------------
TITLE: CTask-compatible windowing library needed
I'm looking for a CTask-compatible, text-based windowing package that
doesn't have a steep learning curve, if possible. I've been tearing out
my hair for the past couple of days trying to get CTask and DFlat (the
subject of recent C programming columns in Dr. Dobbs) to work together,
but to no avail. I need to get an app together in the next month or so,
and I can't afford the time to integrate the two - unless one of you has
already managed to do so (he said, with a hopeful grin)? Any suggestions
would be very welcome. Thanks.
-Tim
Read:
==========================
ibm.other/ctask #320, from twagner, 271 chars, Wed Jun 26 15:46:43 1991
This is a comment to message 317.
--------------------------
Yes, really soon now... Got back from my US trip on the weekend,
still suffering a bit from the jet-lag, and still behind on the
several MB of messages that piled up while I was away. But I should
be back in synch, and ready to post the updated CTask, next week.
Thomas
Read:
==========================
ibm.other/ctask #321, from rlh, 472 chars, Wed Jun 26 18:22:01 1991
This is a comment to message 319.
There is/are comment(s) on this message.
There are additional comments to message 319.
--------------------------
Tim,
I have a very simple minded windowing (text mode) library...in C++. If
it would be of some use to you I can upload it. Like I said, its simple...but
also small. It includes a video object, OptionList (for menu selection) object
and a Window object. On top of the window object is a WindowManager object
for pop-up menus and a PullDownMenu object. There nothing very fancy but
may be helpful.
Let me know if you want them (or anyone else out there).
Russ
Read:
==========================
ibm.other/ctask #322, from tgentry, 188 chars, Thu Jun 27 00:29:57 1991
This is a comment to message 321.
There is/are comment(s) on this message.
--------------------------
I'd be very interested, if the package will work with CTask. Since I'm new
to BIX, though, I'm not sure how to arrange this kind of file transfer.
Could you fill me in? Thanks!
-Tim
Read:
==========================
ibm.other/ctask #323, from marco.m, 335 chars, Thu Jun 27 04:35:50 1991
This is a comment to message 319.
There is/are comment(s) on this message.
There are additional comments to message 319.
--------------------------
I'm using the CLX v.5.1 library (now renamed TCXL) with CTask and it work
very well...you can only take care that two tasks aren't allowed to write
text onto two different windows at the same time (because of the CXL's
internal windows management system).
You can download the last version in the ibm.vendors/listings conference.
Bye
Read:
==========================
ibm.other/ctask #324, from marco.m, 262 chars, Thu Jun 27 09:54:54 1991
There is/are comment(s) on this message.
--------------------------
TITLE: yeld() & schedule()
What is the real difference between yeld() and schedule() ? I need to release
all the CPU time to other tasks when a task is waiting for an event (a
keystroke or an input from the RS-232), what is the best function to use?
> Marco <
Read:
==========================
ibm.other/ctask #325, from twagner, 1099 chars, Thu Jun 27 14:57:01 1991
This is a comment to message 324.
--------------------------
> yield() & schedule()
The difference is in the handling of task priority. If the priority
of the task that is calling schedule/yield is the same or lower than
that of all other eligible tasks, there is no difference between the
two. The yield function enqueues the task at the end of the eligible
queue, regardless of the tasks priority. The schedule function
enqueues the task before all tasks with a lower priority.
For example, imagine two tasks, hi_pri with a priority of 100, and
lo_pri with a priority of 10. Task hi_pri is currently running,
lo_pri is eligible. If hi_pri calls schedule(), nothing happens,
since hi_pri is inserted in front of lo_pri in the eligible queue,
and is immediately scheduled back in. If hi_pri calls yield(), lo_pri
is run next, followed by hi_pri no matter whether lo_pri calls
schedule() or yield().
.More..
Both functions should only be used when doing a "polled" wait. Both
your examples (keystroke/RS-232 input) are best handled by waiting
for a CTask event (t_wait_key/v24_receive). This will take the task
off the eligible queue, reducing system load.
Thomas
Read:
==========================
ibm.other/ctask #326, from rlh, 1398 chars, Thu Jun 27 19:29:57 1991
This is a comment to message 322.
There is/are comment(s) on this message.
There are additional comments to message 322.
--------------------------
Tim,
I'm not totally sure how to xfer via Bix, either. My best guess is that
I would send a file to BIX in some listing area like "c.plus.plus" and you
would be able to download it from there...along with anyone else. That's fine
with me if other people use my code...it's not very pretty at this point, I've
only been able to spend a few hours at a time on it for the last month or two.
I read another comment to your request for a windowing package. That may
be a better approach because it should be a pick-up-and-go kind of deal, where
mine is a need-to-modify-to-go deal. For example, I've been planning for the
longest time to create a member function in the window object that works like
cprintf() so you can have multiple windows open simultaneously (at this time
it uses the window() command and cprintf() to keep things clean). If you are
still interrested, it's yours. I'll log on Friday and check to see if you
.More..
want it, and I'll try to put it in a form that can be uploaded.
Which archive program do you have? I haven't figured out how to download
those programs from this board so I have had to look around for the ones that
I have. If you don't have PKZip I wouldn't want to send you a .ZIP file, for
example! I guess I could make the file self-extracting, but that would make
it longer and take more time to up/download. Let me know what you decide.
-Russ
Read:
==========================
ibm.other/ctask #327, from macbeth, 88 chars, Thu Jun 27 23:59:51 1991
This is a comment to message 322.
--------------------------
You can transfer files to other Bixen via email by attaching it as a binary
attachment.
Read:
==========================
ibm.other/ctask #328, from tgentry, 551 chars, Sat Jun 29 02:00:33 1991
This is a comment to message 326.
There is/are comment(s) on this message.
--------------------------
Russ -
Sure, I'm still interested - if only to see how somebody else has worked
CTask-compatible C++ code. You may be right about the TCXL library, but I've
got a couple other aces up my sleeve before I play that game. DFlat just
had a new release that might magically fix my problems, and another product
(in beta, to be released soon) may help out as well.
As far as archive programs go I can take almost anything - ARC, ZIP, LHarc,
tar, cpio -- anything else? <grin> Thanks for the help, and I look forward
to seeing your code.
-Tim
Read:
==========================
ibm.other/ctask #329, from rlh, 379 chars, Mon Jul 1 11:06:11 1991
This is a comment to message 328.
--------------------------
Tim,
I'll try to send it to you ASAP (hopefully this afternoon or tomorrow
early). A friend of mine and I are writing a CTask specific windowing system,
which we just started yesterday. If these routines don't work very well, you
can always have the ones we come up with...unfortunately it will be a while
before we have them done. I'll keep you posted.
|\
|/
|\uss
Read:
==========================
ibm.other/ctask #330, from rlh, 783 chars, Mon Jul 1 12:04:24 1991
There is/are comment(s) on this message.
--------------------------
TITLE: Paradox Engine & CTask ???
To anyone who as gone before me,
I am working on a multiuser BBS in CTask that will be a large on-line
dabase query system. I have been using Paradox Engine for some of my other
projects and was wondering if anyone knows if it is CTask-able. Is the engine
re-enterant, or do you have to play some games with it (like resources)?
I have been thinking of buying the C/Database Toolchest ($30 w/source) tto
modify for C++/CTask, but would rather use something I am familiar with and
that works relatively well. Any comments would be appreciated. I'm also going
to leave a message in the ocr section about a fast way to scan data into the
databases if you have any input on that end.
Thanks in advance!
|\
.More..
|/
|\uss
Read:
==========================
ibm.other/ctask #331, from rkendall, 586 chars, Mon Jul 1 23:30:54 1991
There is/are comment(s) on this message.
--------------------------
TITLE: POWER TRANSFORMER FOR CDS 224 SERIES II MODEM
I recently acquired two Concord Data Systems Series II 224 modems without
the power transformers. Efforts to locate Concord Data Systems have met
with no success. Their last known phone number and address in Marlborough,
MA are no longer valid. Does anyone know if this company is still in
existence? and if so, a current phone number? Alternatively, can anyone out
there assist me in obtaining a power transformer from a second source? Any
help you can provide is greatly appreciated as I am at my wits end.
Sincerely,
R. Kendall
Read:
==========================
ibm.other/ctask #332, from barryn, 170 chars, Mon Jul 1 23:36:55 1991
This is a comment to message 331.
--------------------------
Do you at least have the specs for DC voltage (3v, 6v, 9v, 12v, etc.)
you need for the modems? Radio Shack should have something if you know
the voltage, I think.
Read:
==========================
ibm.other/ctask #333, from tgentry, 456 chars, Tue Jul 2 01:16:43 1991
This is a comment to message 330.
--------------------------
Russ -
As part of this very same project that needs your C++ window routines I'm
using the Paradox engine as well (what are you doing, trying to outdo me?
<grin>). I'll keep you posted as to the results. At this point I'm just
planning on creating a resource and using that resource to serialize access
to Paradox. This should keep the need for record-locking and any non-
reentrancy problems to a minimum. I'll let you know what happens.
-Tim
Read:
==========================
ibm.other/ctask #334, from tgentry, 1101 chars, Tue Jul 2 02:17:32 1991
--------------------------
TITLE: What causes a task to lockup?
Allright, I know that the above question could have a *bunch* of answers,
but I'll give you some symptoms anyway. I've got a user interface (D-Flat
again...) that I'm running in a thread, and a "beep thread" (beeps every
2 seconds and dumps a snapshot off to disk) running as the second thread.
The "beep thread" keeps running with no problems, and the UI thread runs
fine until I try to do something... The snapshots show the thread as
eligible but the instruction pointer as not changing (i.e. the task is
not running or not being scheduled). Has anybody else had this problem
with a thread? Are there any CTask functions that explicity schedule a
thread (I don't see any in the manual)?
I've had this same problem with D-Flat and another UI product (which,
unfortunately, must remain nameless since it's still in beta...). It leads
me to believe that there's something in the keyboard/mouse/video routines
of the UI package that conflicts with CTask, but I really don't know where
to begin looking. Any suggestions would be MUCH appreciated...
.More..
-Tim
Read:
==========================
ibm.other/ctask #335, from marco.m, 1799 chars, Tue Jul 2 11:25:36 1991
--------------------------
TITLE: Two "little" problems
I have two problems running an application that uses CTask 2.2 that I'm like
to resolve ASAP.....
1. DesqView. CTask seems to be incompatible with DesqView 2.32/QEMM 386
5.12. My program hang the task everytime.
2. The serial I/O. I don't know if I missed somewhat in the installation of
this driver, but...everytime I power on my computer and try to run the BBS
program (that uses CTask for serial I/O) it hang the machine when I try to
do something (either remote logins, or local console operations...).
After resetting the machine (either with hard reset or CTRL-ALT-DEL) the
program work pretty well.....
I thing that has to do with the serial I/O driver, because if I use Telix
after the BBS, then exit and run the BBS again, it hang.
Here is my machine configuration:
.More..
Vegas 386DX/20MHz
2 MBytes RAM
VGA 512K
DesqView 2.32/QEMM 386/5.12 (configured with 2 big DOS tasks)
CTask 2.2 (downloaded from bix, with the update to 2.2b)
Turbo C++ 1.01
Some utility TRSs (@Last, Mouse, Norton Cache). I have tried to remove all
TSRs but nothing happen.
The BBS program can be configured with 6 lines plus a local console task
(total of 7 task running simultaneusly). In my test configuration I have 1
line on the modem (this task hang in the modem initialization procedure if
running for the first time) with the serial port locked at 4800 baud, 1
line on a local terminal (this task survive few seconds after a normal login,
but hang if running the first time). The local console task look at the BBS
event scheduler and display the clock time every second (this task hang after
a keypress, if running the first time).
If can help, I will post the source code segments that install the task,
.More..
serial I/O, and initialize the modem.
Read:
==========================
ibm.other/ctask #336, from rlh, 2250 chars, Tue Jul 2 12:23:26 1991
--------------------------
TITLE: Windowing Stuff
Tim-
I'll be uploading the windowing routines to you today...finally! I have
tried to add a lot of comments and examples so you won't struggle too much with
learning what I am upto. I played with the idea of removing the window()/
cprintf() dependency that is built into my window routines, but decided that I
would send you what I have now. When I accomplish that mission (creating my
own, window-relative printing) I'll send you that version if you would like it.
What are you doing with your CTask/PdoxEngine project? I know I've said
this probably a zillion and two times, but I'm in the process of writing a
multi-user BBS that has to have great database capabilities...much more than I
would like to write myself!! If Paradox Engine does not work, I have a backup
plan. I've ordered the C/Database Toolchest from Mix (w/source--of course).
If Paradox doesn't handle time-slicing, I'll force the Mix package to do so!
If I have to go that route, I'll be sure to send you my updates. The
entire package costs $30 from Mix, so it isn't Public Domain or Shareware,
.More..
but I will give you my modifications to their source. I just hope Paradox
works! I thought about a couple approaches to remove the worry about the
re-enterancy of the engine:
1. Make it a resource. The problem I have with this is that if I have
several tasks trying to do long queries it could mean that the last
user to enter a query would have to wait unacceptably long amounts of
time *ALL* other queries to be processed.
2. Use Mailbox/Pipe/Buffer to pass messages to another task that actually
calls the engine functions. This technique has the advantage of being
capable of processing "simultaneous" queries by using a simple FIFO
scheduler. At most (if there are n tasks that might need access to
the database) there would be n messages in the mailbox/pipe/buffer
for the engine task to process. The disadvantage is that this would
be rather involved coding!
It would be nice if the engine were CTask-able directly...I think I'll ask
the experts at Borland about what the possibilities are of making it so.
|\
.More..
|/
|\uss
Read:
==========================
ibm.other/ctask #337, from rlh, 798 chars, Tue Jul 2 20:29:14 1991
There is/are comment(s) on this message.
--------------------------
TITLE: SIO and CTask
I have come to a point where all I need is three functions to complete a
modem object for C++/CTask. First, I need to be able to Answer to phone when
the RI (ring indicator) is TRUE. I know how to wait for RI to be true, but
how do you go on-line? Second, I need to know how to hang-up. Is that done
with v24_change_dts()? (I can't seem to find my CTask manual at the moment...
but it's one of those two commands I'm thinking of). Lastly, how do you put
the modem in command mode? There has to be some way to xmit the AT commands
as data, so the modem cannot always be in command mode.
Anyone with some modem experience out there? I wish I had paid more
attention to my instructor in Telecommunications 101! THANKS for any help!!
|\
|/
|\uss
Read:
==========================
ibm.other/ctask #338, from marco.m, 589 chars, Wed Jul 3 07:24:06 1991
This is a comment to message 337.
There is/are comment(s) on this message.
--------------------------
> How do you go on-line?
You can send ATA<CR> to the modem, then wait for the carrier to be raised
or the string CONNECT xxx, where xxx is the baud rate.
> How to hang-up
Use the function v24_change_dtr(siop, 0) to lower the DTR line, the wait
until the carrier drop, then use v24_change_dtr(siop, 1) to raise the DTR
again.
> How do you put the modem in command mode?
Clear the outbound buffer and wait one or two seconds, send the command +++
(three plus) then wait for the string OK. Now you are in command mode.
.More..
Marco.
Read:
==========================
ibm.other/ctask #339, from jamey, 343 chars, Wed Jul 3 10:23:12 1991
This is a comment to message 319.
--------------------------
Try SMP (screen Manager Professional) from MaGee Associates (Automenu people)
I am using it, and you would not beleive how well it works... There are a few in
itilization querks such as when to init
ialize, but once the sequence is down, the system works beautiful. I have a SMP
window with a trap to interrupt 29; thi
s redirec("COMMAd
Jamey
Read:
==========================
ibm.other/ctask #340, from jamey, 82 chars, Wed Jul 3 10:24:23 1991
This is a comment to message 323.
--------------------------
That isnt a problem in SMP... It is a bit pricy, but the system works great
Jamey
Read:
==========================
ibm.other/ctask #341, from rlh, 884 chars, Wed Jul 3 16:19:55 1991
This is a comment to message 338.
There is/are comment(s) on this message.
--------------------------
Thanks!
I still have a question about command mode, though: how can you send the
sequence that puts you in command mode as data (+++)? I guess I'm still a bit
confused on how the modem interprets data/command sequences. Do I wait for
the CONNECT xxx and OK to appear in the input buffer? Is there someway to use
register level commands to accomplish these things (auto answer & hangup),
because I feel much more comfortable going that route that having to deal with
putting the modem into/out-of command mode...And one last question (finally):
once I'm in command mode how do I get out of it? (This relates to my first
question on how to send "+++" across the wire as I have twice while entering
this message).
Thanks for your help. I appreciate all the help I've gotten on BIX, it
has been top-notch! (I'm a new user--about 2 weeks on-line).
.More..
|\
|/
|\uss
Read:
==========================
ibm.other/ctask #342, from marco.m, 1593 chars, Thu Jul 4 12:37:08 1991
This is a comment to message 341.
--------------------------
> Do I wait for the CONNECT xxx and OK to appear in the input buffer?
Yes. After that the modem is in on-line state and every sequence of bytes
will be transmitted over the telephone line.
> Is there someway to use register level commands to accomplish these
> things (auto answer & hangup),
Yes but with my experience with modems and telecommunications (I'm a FidoNet
System Operator and wrote a BBS program myself) this isn't the best way to
control a modem.
If you set the modem to auto answer an incoming call, you can test the
Carrier Detect line (DCD, v24_modem_status(siop) & CD, with CTask) to be
raised, something like:
.More..
printf("Waiting\n");
while (!(v24_modem_status(siop) & CD))
yield();
printf("Connect\n");
With this, your modem always answer the phone, even if your program crashes
the machine without lower the DTR line.
> once I'm in command mode how do I get out of it? (This relates to my
> first question on how to send "+++" across the wire as I have twice
> while entering this message).
Your modem wasn't in command mode because it requires a few moments of
silence before (and after) the +++ sequence. Silence mean that no
characters are received or transmitted for a certain amount of time
(depending on you modem's configuration).
After reading this message try to wait 3/4 seconds at the 'Read:' prompt,
then press +++ (whithout pressing Enter after the last plus), your modem
.More..
go into command mode (it send to you OK), to return in on-line state you
can type ATO<CR>, the modem sends the string CONNECT xxxx.
Read:
==========================
ibm.other/ctask #343, from tgentry, 133 chars, Sat Jul 6 23:04:47 1991
--------------------------
TITLE: CTask and MS-DOS 5.0
Has anybody experimented with CTask under DOS 5.0? And, if yes, what are
the current verdicts?
-Tim
Read:
==========================
ibm.other/ctask #344, from rlh, 815 chars, Mon Jul 8 11:31:23 1991
--------------------------
TITLE: Making a BTS for CTask
I was wondering if there is some way to get the effect of the 80386's BTS
instruction in CTask. I need to set a flag and then know what its previous
value was for further processing. I guess what I am asking is this: does
CTask use the NMI to initiate a context switch? If not, I belive the following
code will work:
byte BTS(byte far *aflag)
{
asm {
pushf
cli
}
old = *aflag;
*aflag = TRUE;
asm popf
return old;
.More..
}
Sorry; I forgot to decalre: "byte old;" at the top of the procedure. Does any
one out there know if this will work? It would be real nice if it would
because I want this to work on other multi-tasking systems (if I ever
come across one I like).
Thanks,
|\
|/
|\uss
Read:
==========================
ibm.other/ctask #345, from rlh, 285 chars, Mon Jul 8 11:33:17 1991
--------------------------
TITLE: New Release of CTask?
I heard a rumor that a new version of CTask was going to be released soon. Not
that I'm trying to rush anyone, but what is the current state of that release?
I would be very interrested in any enhancements to an already excellent program.
|\
|/
|\uss
Read:
==========================
ibm.other/ctask #346, from rlh, 879 chars, Mon Jul 8 11:39:47 1991
There is/are comment(s) on this message.
--------------------------
TITLE: BBS's w/CTask
I remember getting a message from someone (macro?) that said they had written
a BBS program. I was wondering if someone out there has a BBS program (or any
pieces of one), that they would consider parting with. I am writing a BBS for
a commercial venture (it would not involve selling the BBS software in whole
or in part!) and am basically starting from scratch with everything except that
I have CTask to help me make it multi-user and Paradox Engine (or C/Database
Toolchest) for the database.
I would prefer an already multi-user BBS program as compared to a single
user, but any code would help...especially if you are using the CTask serial
I/O routines! You are dealing with a modem novice, here so please be patient!
Thanks in advance,
|\
|/
.More..
|\uss
PS: Pardon the comma before "here" in the last line. It should have
been after.
Read:
==========================
ibm.other/ctask #347, from iarslangiray, 147 chars, Tue Jul 9 01:53:49 1991
This is a comment to message 346.
There is/are comment(s) on this message.
--------------------------
[to Russ]
If you are interested I do have source code for JBBS (Dbase/Clipper
BBS source code). It is about 1meg and you may only get it via mail!
Read:
==========================
ibm.other/ctask #348, from tgentry, 216 chars, Wed Jul 10 01:20:45 1991
This is a comment to message 347.
There is/are comment(s) on this message.
There are additional comments to message 347.
--------------------------
Russ -
Take a good, long look at the Galacticomm MajorBBS product. Source is
available and it supports up to 64 users (with special hardware) on a
stock AT-class machine. If you need details, let me know.
-Tim
Read:
==========================
ibm.other/ctask #349, from rlh, 487 chars, Wed Jul 10 14:01:10 1991
This is a comment to message 347.
There is/are comment(s) on this message.
--------------------------
Thanks. I would be interrested in seeing the source code for it. It does
support multiple users online simultaneously doesn't it? What I need is the
source for the BBS itself (including modem routines) so I can make *lots* of
changes. The project I am working on is not a normal BBS...it's an online
database basically. It doesn't support up/download or even E-mail for that
matter.
If you think JBBS fits the bill, I'd love to look at it.
Thanks again
|\
|/
|\uss
Read:
==========================
ibm.other/ctask #350, from rlh, 1370 chars, Wed Jul 10 14:09:05 1991
This is a comment to message 348.
There are additional comments to message 348.
--------------------------
Tim,
I have heard a little (very little) about the Galacticom MajorBBS software
but am running on a >>>small<<< budget. It's more of a time investment than
anything else at this point. No one involved has the $$$ to spend for new
hardware or $1000 software packages. Last I heard, the Gal. BBS was pretty
expensive if you wanted only a moderate number of lines.
If we get the thing going with CTask, it can be put on a faster machine
with more lines easily...compared to buying a 16 line card and dumping the 8
line card! If you have had some experience with Gal. BBS, I would love to hear
about it, but-at least for now-the price is just too high for me (us). Thanks
for your info...I wish I could buy a package solution. I would consider it if
I new I could get in there and add the database support and strip out the extra
clutter that comes with most BBS's.
.More..
Thanks again!!
|\
|/
|\uss
P.S.: Did you have a chance to look at the C++ stuff yet? I am in the middle
of writing all of the enhancements I mentioned and then some into the
next generation Window object. It is going to have occlusion control
(optional, of course), multiple overlapping windows with simultaneous
output and #ifdef's to support ^Z(:ycritical sections when used with CTa
sk.
I'll let you know what happens...i.e., who wins!
Read:
==========================
ibm.other/ctask #351, from iarslangiray, 211 chars, Thu Jul 11 02:38:11 1991
This is a comment to message 349.
There are additional comments to message 349.
--------------------------
[to Russ]
It's author is operating a BBS in San Diego and he is a Fido-Net
node. He may have the latest source code!..How do you like to receive
the source code if you can not get it from him? BIXMAIL me!..TTYL
Read:
==========================
ibm.other/ctask #352, from rlh, 252 chars, Thu Jul 11 10:44:42 1991
--------------------------
TITLE: Emm 386's BTS opcode
Has anyone had a chance to ponder my question about the BTS() function yet? I
was wondering if anyone knows if it will work with CTask...if CTask traps the
NMI to do it scheduling, it won't...
Thanks!
|\
|/
|\uss
Read:
==========================
ibm.other/ctask #353, from jamey, 321 chars, Fri Jul 12 14:41:33 1991
This is a comment to message 348.
--------------------------
I agree with the Gal BBS. We use the GSBL's to develop ASYNCH mainframe
links in our software. With the latest version, you can now support up-to
255 users! I would also take a look at COMM-DRV if you want lower level
serial IO stuff. It was designed to be re-entrant, so we bought it to use
with CTask.
Later, Jamey
Read:
==========================
ibm.other/ctask #354, from jamey, 166 chars, Fri Jul 12 14:42:59 1991
This is a comment to message 349.
There is/are comment(s) on this message.
--------------------------
Galacticomm has a special set of utilities to hook into their BBS to
allow on-line database support. Presently it uses Btrieve as it file management
and DBMS engine.
Read:
==========================
ibm.other/ctask #355, from rlh, 1526 chars, Fri Jul 12 15:45:45 1991
This is a comment to message 354.
There is/are comment(s) on this message.
--------------------------
I don't suppose they have a demo version of Galacticomm? I really need a VERY
sophisticated database system...one that will take a lot of coding on my part
to function they way I want it to. It is almost like an abstract base class
with zillions of derived classes each of which has an attached database with
special information about the particular object. Like this:
Fruits
------
| | |
| | |
+-----------------------+ | +------------------------------+
| | |
---------- ------------- ----------
Apples Pineapples Bananas
---------- ------------- ----------
.More..
| Color | Size | Shelf Life
| Sweetness | Hardness | Softness
| Price/bushel | Price | Price
Granted this is a stupid thing to put into a database, but my point is that I
will have several "terminal" databases (of different structure) in a heirarchy
of types. This will have the appearance of a DOS directory tree for each of
use. I have my doubts that a packaged BBS will give me the flexibility to put
this design to work. If I am wrong, please tell me! I wouldn't do this for
my health!
Thanks everyone!
|\
|/
|\uss
Read:
==========================
ibm.other/ctask #356, from jreynolds, 353 chars, Sun Jul 14 13:02:27 1991
--------------------------
TITLE: Keyboard
I compiled tsio.c on my turbo xt and found that the t_read_key & the other
two keyboard functions wouldn't work correctly...I have been using bioskey()
but doing so i have to put the task using it on hold while i spawn to dos
does anyone have a cure for this? ....Am i the only one....?
If you know how to repair this let me know.....
Read:
==========================
ibm.other/ctask #357, from jamey, 286 chars, Mon Jul 15 13:39:47 1991
This is a comment to message 355.
--------------------------
If you are going to be storing Object generalizations, I would suggest
reading "Object-Oriented Modeling and Design" by Rumbaugh, Blaha,
Premerlani, Eddy and Lorensen. It has a chapter dedicated to maping object
heiarchies into a relational database model... Very good reading.
Jamey
==========================
ibm.other/ctask #358, from rlh, 377 chars, Tue Jul 23 13:16:59 1991
There is/are comment(s) on this message.
--------------------------
TITLE: Where is everyone...?
Hello................................................
Anyone out there.....................................
?????????????????????????????????????????????????????
Anyone heard 'bout the update to CTask rumored about
sometime back...............................????????
Echo....Echo.....echo......
|\ | | / /
|/ | | \ \
|\ |_| / /
Read:
==========================
ibm.other/ctask #359, from cblum, 85 chars, Tue Jul 23 16:44:18 1991
This is a comment to message 358.
There is/are comment(s) on this message.
--------------------------
Patience is a virtue... Thomas is a busy man. It will be worth the wait.
Chris Blum
Read:
==========================
ibm.other/ctask #360, from rlh, 274 chars, Tue Jul 23 18:36:12 1991
This is a comment to message 359.
--------------------------
Oh I'm sure it will...I was just commenting on the lack of messages in this
topic lately, not on Thomas' schedule for an update of CTask. My question was
just to stimulate discussion...it looks like it worked :-)
Later,
|\ | | / /
|/ | | \ \
|\ |_| / /
Read:361
==========================
ibm.other/ctask #361, from compuservice, 446 chars, Thu Jul 25 12:32:38 1991
--------------------------
TITLE: iostream_withassign and CTask
I would like to create an iostream_withassign object attached to
Ctask's sio drivers. It would be great to write : com1 << myString;
Also I would like to create a buffered iostream object to allow
input/output of messages thru a NetBIOS Session. Do you think it
can cause reentrancy problems within the iostream class?
I am using TC++ 1.01, and I have the run time library source code.
Thanks in advance.
==========================
ibm.other/ctask #362, from vadim, 1962 chars, Fri Jul 26 14:51:49 1991
--------------------------
TITLE: Ctask bug
Hello Thomas.
I think that i found the reason while your CTask package does not cooperate
wery well with some TSR's. The problem is with saving/restoring Dos Context
(l_swap buffer in TCB).
Consider following scenario, in which Ctask and one
non-Ctask TSR are trying to cooperate.
SDA - Swappable Dos Area
(I use SDA Name for Dos Context area. For the sake of
the discussion we assume that SDA contains only one integer value,
PSP for example)
T1,T2 - Two Ctask-created tasks
CT - Current task (Ctask internal)
DOS.SDA is current value in the SDA
TASK.SDA is the SDA value save in the TASK's l_swap buffer
Ctask Task Switch algorithm:
CT.SDA = DOS.SDA
CT = T2
DOS.SDA = CT.SDA
TSR.SDA - SDA value which non-Ctask TSR will use when popped up
TSR.SAVESDA - SDA value as seen by non-Ctask TSR at the pop-up moment,
The pop-up algorithm is as following (it is very common scheme):
TSR.SAVESDA = DOS.SDA
DOS.SDA = TSR.SDA
<Run the tsr code>
TSR.SDA = DOS.SDA
DOS.SDA = TSR.SAVESDA
Initial State:
DOS.SDA == 2
T1.SDA == 2
T2.SDA == 3
CT == T1
TSR.SDA == 4
TSR.SAVESDA == 4
CTask Switch occurs
CT.SDA = DOS.SDA
CT = T2
DOS.SDA = CT.SDA
This is the state after the task switch:
DOS.SDA == 3
T1.SDA == 2
T2.SDA == 3
CT == T2
TSR.SDA == 4
TSR.SAVESDA == 4
TSR is activated
TSR.SAVESDA = DOS.SDA
DOS.SDA = TSR.SDA
State is:
DOS.SDA == 4
T1.SDA == 2
T2.SDA == 3
CT == T2
TSR.SDA == 4
TSR.SAVESDA == 3
Ctask Switch occurs (we're still in TSR)
CT.SDA = DOS.SDA
CT = T1
DOS.SDA = CT.SDA
State is:
DOS.SDA == 2
T1.SDA == 2
T2.SDA == 4 !!!!
CT == T1
TSR.SDA == 4
TSR.SAVESDA == 3
If one more Ctask Switch occurs at this stage - T2 will run with DOS.SDA==4
which is incorrect -- T2 was using 3 as DOS.SDA value before preempttion!!!
Vadim.
P.S. I found this problem when debugging my own C++ multitasking kernel...
But it applies to CTask too.
==========================
ibm.other/ctask #363, from twagner, 812 chars, Sat Jul 27 08:22:07 1991
This is a comment to message 358.
There is/are comment(s) on this message.
--------------------------
> Where is everyone...?
I don't know about the others, but I'm not here... :-)
Really, I'm supposed to be on vacation in Denmark with my family. Had
to get back for a week to finish a thesis, then I'll be off to
Blavand again. I had planned on finishing that paper on return from
my US trip, but I had to write a Windows virtual device driver
instead to finally get this one client/pest off my back. Ah, writing
a VDD is so much fun... So you probably can imagine why the new
version of CTask had to wait, and why my activity level around here
was rather low. I'll refrain from making another promise I can't
keep, but my workload should be a tad lighter when the vacation is
over (around August 10th), so maybe, just maybe, you'll see a new
version around the end of August.
Sorry to keep you waiting
Thomas
Read:
==========================
ibm.other/ctask #364, from twagner, 877 chars, Sat Jul 27 08:22:48 1991
This is a comment to message 362.
--------------------------
But I'd say that's how it's supposed to be! The TSR acts like an
"extension" to T2, it doesn't continue to execute through the task
switch. If T2 is reactivated, it's the TSR that continues to execute,
so DOS.SDA *must* be 4, since this is what the TSR expects. When the
TSR finishes, it will switch the SDA back to 3.
To continue from your example:
DOS.SDA == 2
T1.SDA == 2 (irrelevant)
T2.SDA == 4
CT == T1
TSR.SDA == 4
TSR.SAVESDA == 3
after task Switch to T2/TSR:
DOS.SDA == 4
T1.SDA == 2
T2.SDA == 4 (irrelevant)
CT == T2/TSR
TSR.SDA == 4
TSR.SAVESDA == 3
TSR terminates, restoring SDA:
DOS.SDA == 3
T1.SDA == 2
T2.SDA == 4
CT == T2
TSR.SDA == 4
TSR.SAVESDA == 3
after Task switch to T1:
DOS.SDA == 2
T1.SDA == 2
T2.SDA == 3
CT == T1
TSR.SDA == 4
TSR.SAVESDA == 3
So we're back to where we started from, and everything is just fine.
Do I miss something?
Thomas
Read:
==========================
ibm.other/ctask #365, from mvanditta, 121 chars, Sat Jul 27 21:42:14 1991
This is a comment to message 363.
There is/are comment(s) on this message.
--------------------------
Thomas,
Where did you get the information on how to write a virtual device
driver for Windows?
Mark T. Van Ditta
Read:
==========================
ibm.other/ctask #366, from twagner, 753 chars, Sun Jul 28 16:11:47 1991
This is a comment to message 365.
--------------------------
> information on how to write a virtual device driver
About 10% from the DDK documentation, the rest from days of
headscratching, reading through the supplied VDD source code
forwards, backwards, and sideways, and plain trial and error. The
main problem is the lack of documentation on which routines of the
standard VDDs (in my case the VCD comm driver) are called from
Windows routines/apps under what circumstances. Nothing about that in
the printed docs, and next to nothing in the sources. But you can
find out the most important stuff by inserting lots of debug
statements in the standard drivers and running under the debugging
kernel with WDEB386. You need a serial terminal, though (or a second
PC running a comms program like Telix).
Thomas
Read:
==========================
ibm.other/ctask #367, from sworthington, 1307 chars, Sun Jul 28 17:01:17 1991
--------------------------
TITLE: CTask 2.2 and DOS 5.0
I have been running a version of CTask 2.2 (significantly modified by
a someone who no longer works for us) for several weeks under DOS 5.0
and I have just discovered that DOS 5.0 is doing something different
to DOS 3.30. Under DOS 3.30, I never get to the yield() call in
wait_dos_free() in TSKDOS.ASM when I am running the program under
simple test conditions. Under DOS 5.0, I get there frequently from
calls to INT 21 AX=2A00 (GET DATE). I also get a crash when two
similar tasks which access the date and do file access run at the
same time (they are both triggered every midnight). The crash is
quite repeatable. I can not yet verify that it is actually the date
calls that are causing the crash. The install_tasker() options used
are:
IFL_VIDEO | IFL_DISK | IFL_INT8_DIR
It could be that CTask 2.2 has a hole that DOS 5.0 is falling into,
or that DOS 5.0 has a bug, or the the modifications to CTask 2.2 have
introduced bugs. Unfortunately, due to pressure of other work, I can
not investigate further at this time, or test it on a real CTask 2.2
program (we have simply not authorised the program to be used on
anything except DOS 3.30!). Is there anyone else who is using CTask
2.2 with DOS 5.0 yet? Have you had any similar problems?
Stephen Worthington
Read:
==========================
ibm.other/ctask #368, from rlh, 882 chars, Mon Jul 29 13:16:01 1991
--------------------------
TITLE: Pdox Engine w/CTask
Someone out there (Tim?) mentioned that they were working on a project that
involved Paradox Engine and CTask. I'm not sure if you have found the messages
that I have left around the borland/pdox.engine area, but I have uploaded a
file called PXH.ZIP that contains a Table object for use with the Engine. I am
currently polishing up an update to this object to serialized access to the
Engine, since it is non-reentrant. If you were to use this object to do all
Engine access, you would have no reentrancy problems. I am also working on a
set of record locking functions for use in a non-network environment where
such things might be needed (such as CTask). I hope to finish this update and
post it A.S.A.P.. If someone is interrested in this class (for BC++), let me
know and I will put a rush on it...I'm not in too big of a hurry yet :-).
Russ
==========================
ibm.other/ctask #369, from mvanditta, 31 chars, Wed Jul 31 20:52:09 1991
This is a comment to message 366.
--------------------------
Thank you.
Mark T. Van Ditta
Read:
==========================
ibm.other/ctask #370, from jamey, 417 chars, Thu Aug 1 13:04:59 1991
This is a comment to message 361.
--------------------------
I am working on the same types of things... I have created the following
classed derived from streambuf - commbuf and netbuf.
You may wish to consider adding IO manipulator support such as:
commbuf serialLine(192000,N,8,1);
iostream com1(serialLine);
com1 << timeout(10) << dial("555-1212");
comm1 >> waitfor("CONNECT");^[[D^[[K;
com1 << timeout(30) << "blah...blah...blah";
If you need any help, send me a line.
jamey
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Email enviado a 'jamey'
From compuservice
To jamey
Subjetc: commbuf, netbuf
Dear fellow,
First of all, thank you very much for your offer in ibm.other/ctask #370.
Some help to write those classes and manipulators would be appreciated.
Have you experienced any kind of reentrancy problems with your classes
derived from streambuf?
Are you working on BBS software? We have been operating an 8 line system
down here in Uruguay written in C with CTask, for about three years
now. As we need more lines, and X.25 support we are implementing a
distributed processing architecture around NetBIOS, with C++ and
CTask. We've chosen Btrieve as the record manager for the new
release.
If you think any of our material may be of interest to you, feel
free to ask and we can Bixmail it to you.
If you want to try our system, it can be accessed thru Tymnet, at
node 74829680690.
Thanks in advance.
----------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Email recibido de jamey
From Memo * Date
1 jamey 55582 Wed Aug 14 08:34 commbuf, netbuf
Mail:1
Memo #55582
From: jamey
Date: Wed, 14 Aug 91 08:34:36 EDT
To: compuservice
Message-Id: <memo.55582>
In-Reply-To: <memo.53003>
Subject: commbuf, netbuf
First of all, I am not sure why you feel the need to use full blown Ctask
for just 8 lines on your BBS... Ctask is a great tool, but you may wish to
take a look at the Galacticomm GSBL (libraries) and have a look at the
source code for the Major BBS... If you still feel that you need Ctask,
I would suggest using the Pipes, Buffers and Semaphores and have them talk
to the stream I/O routines; this will isolate the stream I/O to a single
task and give you more control over the I/O... I would also suggest doing the
same thing with the Btrieve; only allow one task to do the updates... I am
also working on a streambuf for netbios, which will be done by the end of
next week. I have started on running Ctsaks pipes, etc through netbios as
well... Similar to the way OS/2 supports named pipes ! Galacticomm also
supports x.25.
Galacticomm is located in Ft Lauderdale Florida.
Again, let me know if I can assist you.
Jamey
read/action:delete
----
Thanks a lot for your help. We had taken into account some time ago
the posibility of using GSBL but we feel that CTask gives us more
flexibility. We will continue our work in the same direction as we
feel that there is only a little final effort left. The system is
running quite well with C and CTask now, and we are migrating to C++
only to simplify future maintenance. We have here an ARTIC real time
interface coprocessor and we are trying to control it from CTask to
be able to use it in our system. Do you think it will be usefull?
We are new to C++ and still need a bit of help on deriving commbuf
from streambuf. Have little bibliography on C++ (just the Stroustrup
book and a couple of 'C++ primers...', remember we are down in South
America...) and can't find much info on the iostream library. An
outline of the derived class would be appreciated. About X.25, we
have modified a ham packet radio TNC and we are writing Z80 code to
support the lower layers. Upper layers will run under CTask,
interfacing with the HOST (another PC thru Token Ring) via NetBIOS.
About Btrieve, we are protecting calls with a resource; Adding a task
to receive messages and call Btrieve would be great. If that task
receives messages trhu NetBIOS would be better, but I think that we
would be reinventing the wheel. Novell offers such a product (I think).
Thanks in advance!
----------------------------------------------------------------------
==========================
ibm.other/ctask #371, from harrellfreeman, 134 chars, Tue Aug 13 01:38:36 1991
There is/are comment(s) on this message.
--------------------------
TITLE: HOW TO USE CTUPD22B.LZH??
NEW TO BIX DOWNLOADED CTUPD22B.LHZ BUT IF I EDIT IT,CANT SEE ANYTHING
HOW DO I CONVERT IT ?
HARRELL.
Read:
==========================
ibm.other/ctask #372, from mheller, 90 chars, Tue Aug 13 05:49:51 1991
This is a comment to message 371.
There is/are comment(s) on this message.
--------------------------
You need LHA, which you'll probably find with "j ibm.utils/listings" and
" brow name lh*"
Read:
==========================
ibm.other/ctask #373, from karenk, 127 chars, Tue Aug 13 12:01:11 1991
This is a comment to message 372.
--------------------------
Look for lha212.exe in ibm.utils/listings. It's a self-extracting
archive (just run it to expand it). Includes doc's.
Karen
Read:
==========================
ibm.other/ctask #374, from ron_ritchey, 269 chars, Tue Aug 13 13:19:41 1991
--------------------------
TITLE: CTASK & DOS 5.0
Does anyone know of any incompatibilities between CTASK and MS DOS 5.0?
I am having some difficulties and would like to be able to rule out DOS.
Thanks in advance
Ron Ritchey
==========================
ibm.other/ctask #375, from harrellfreeman, 471 chars, Tue Aug 13 20:10:05 1991
This is a comment to message 374.
There is/are comment(s) on this message.
--------------------------
RON, I AM NEW TO CTASK AND BIX BUT I DID START OUT ON 4.01
AND THINGS WENT FINE. UPGRADED TO 5.0 AND HAD PROBLEMS USING QUARTERDECK
QEMM ,SWITCHED TO MICROSOFT SUPPLIED MANAGER BUT MY CTASK STILL "HANGS"
AND I GET EMM MESSAGES FROM TIME TO TIME NOW. NOT SURE HOW TO TROUBLESHOOT IT
YET. HAVE BEEN SUSPECTING AN APPLICATION PROBLEM,MAYBE. I KHAVE THE SAME
QUESTION AS YOU, 5.0 JUST DOESNT "FEEL" RIGHT WITH CTASK. ANYONE ELSE KNOW???
TNX. HARRELL
PS. TNX FOR HELP ON LZH.
Read:
==========================
ibm.other/ctask #376, from cblum, 287 chars, Tue Aug 13 20:51:20 1991
This is a comment to message 375.
--------------------------
I am using Ctask with DOS 5.0 loaded high with HIMEM.SYS ( no EMS, just
DOS loaded high ) and everything seems to work fine. I have found no
problems yet. I have tested shelling to another COMMAND.COM and saw
no problems with the subtasking either. Serial I/O looked OK too.
Chris Blum
Read:
==========================
ibm.other/ctask #377, from ron_ritchey, 811 chars, Wed Aug 14 10:49:37 1991
There is/are comment(s) on this message.
--------------------------
TITLE: Debugging CTASK programs
I am trying to develop a program using a set of routines sold under the
name Multivox. These routines rely on CTASK to provide multi-tasking
support. I am having problems debugging the programs I am producing
and am looking for pointers in debugging CTASK programs. Heres a few
of the questions I have.
1. What debugger should I use?
2. Is it possible to debug seperate threads executing at the same
time?
3. How do I calculate the correct stack size for each task?
(I read something about this in the CTASK manual but did
not follow it entirely)
4. What are the problems with doing dynamic allocation in a
CTASK program besides the re-entrancy question?
.More..
Any replies will be much appreciated.
Ron_Ritchey
Read:
==========================
ibm.other/ctask #378, from twagner, 1849 chars, Wed Aug 14 18:04:25 1991
This is a comment to message 377.
There is/are comment(s) on this message.
--------------------------
> 1. What debugger should I use?
For application-level debugging, you can use Turbo Debug or Codeview
without problems. If you want to get into the guts of CTask, you
might have to go the Periscope route.
> 2. Is it possible to debug seperate threads executing at the same time?
This could cause problems. Better debug one task after the other. If,
for example, you set a "hard" breakpoint in two tasks, the debugger
could become quite confused:
1) Task 1 runs into breakpoint, debugger is entered (for CTask, the
debugger code is part of Task 1 now).
2) Debugger starts to display current status etc.
3) Task switch to Task 2 occurs, debugger is preempted.
.More..
4) Task 2 runs into breakpoint, debugger is re-entered while in
some internal routine.
5) Crash!
If preemption is off, or the debugger restores the timer interrupt to
its original BIOS value while active (Periscope does this), it should
be safe. But I don't think TD or CV restore INT 8. Having a hard
break hit in one task while you're single-stepping another could also
cause you to become quite confused.
> 3. How do I calculate the correct stack size for each task?
The values in the manual are very conservative. If you enable
CHECKING (you should while debugging), you can start out with a large
value (1-2k), and output a snapshot dump before terminating. The
snapshot dump will display the stack actually used by the tasks, so
you can fine-tune the stack size. Just be sure that the tasks have
run through all possible routine nesting depths, and leave a little
leeway.
.More..
> 4. What are the problems with doing dynamic allocation ...
None I know of besides reentrancy. Just be careful with dynamic
allocation of task stacks - if any routine called in that task has
check stacking enabled, it will crash since the stack is outside the
normal range.
Thomas
Read:
==========================
ibm.other/ctask #379, from ltroxler, 133 chars, Wed Aug 14 23:49:38 1991
This is a comment to message 378.
--------------------------
I was under the impression that the Turbo Debugger swaps _all_ the
interrupt vectors when it is entered. Is this wrong ????
Larry
==========================
ibm.other/ctask #380, from vram, 1013 chars, Fri Aug 16 00:08:30 1991
--------------------------
TITLE: Floating Point Problem ??
Hi, does anyone know what's wrong with the following 18 line program?
#include "tsk.h"
#include "tskconf.h"
tcb T;
float val = 3.14;
void far LL (void) {
tsk_printf ("%d\n", (int) val);
tsk_printf ("test this = %d\n", 3);
}
int main () {
install_tasker (0, 0, IFL_DISK | IFL_INT8_DIR | IFL_PRINTER, "M");
create_task (&T, LL, LNULL, 4096, 100, NULL TN("LL"));
start_task (&T);
while ((t_read_key() & 0xFF) != 27)
;
remove_tasker ();
return 0;
}
---------------------------------------------------
On my 286, it prints out a 0 instead of a 3, and
on my 386, it prints out "Internal stack overflow. System halted."
It does not depend on tsk_printf (the stdio.h printf produces similar
problems). Also, the Turbo C function "farheapcheck()" reports that
the stack has become corrupted after the first printf.
I am using Ctask 2.2, Turbo C++ 1.0.
We've been stumped on this for weeks;
any help would be greatly appreciated!
Thanks!
==========================
ibm.other/ctask #381, from dgh, 107 chars, Fri Aug 16 20:35:04 1991
This is a comment to message 380.
There is/are comment(s) on this message.
--------------------------
>floating point problem??
Change the "float" to a "double" and see if the behaviour changes.
|) /\ \/ | |)
Read:
==========================
ibm.other/ctask #382, from vram, 108 chars, Fri Aug 16 21:29:13 1991
This is a comment to message 381.
--------------------------
We've already tried changing the float to a double -- still bad behavior.
Thanks for the suggestion though.
==========================
ibm.other/ctask #383, from harrellfreeman, 225 chars, Sat Aug 17 19:50:32 1991
This is a comment to message 376.
--------------------------
Ctask and 5.0
the problem I reported in 375 turned out to be a change I made in the
application just before installing 5.0 that didnt show a bug until later.
application has been running 48+ hours now and working OK.
Harrell
Read:
==========================
ibm.other/ctask #384, from vram, 570 chars, Mon Aug 19 23:20:44 1991
--------------------------
TITLE: Floating Point and Ctask 2.2
Hi again! I thought it might be a good idea to ask if anyone has successfully
used any type of floating point operations with Ctask...
The 18 lines of code in message #380 demonstrates a potential problem.
We've found that anytime we use any type of floating point operations, two
things happen:
1. The heap gets currupted.
2. The resulting code runs unreliably; for example:
The machine hangs
The program returns strange values
Or... the program runs ok...
Anyone else had problems?
Thanks in Advance for any replies!
==========================
ibm.other/ctask #385, from cblum, 664 chars, Tue Aug 20 21:01:58 1991
--------------------------
TITLE: C-task and float math.
I am using Ctask with a 387 in an industrial control application ( Turbo C++ )
I found out several things the hard way.
1. Borland's f.p. emulator uses the stack for everything - stack requirements
for the same program ( only difference in compile was -f vs. -f287 ) was
as much as 2K (!!!) more with the emulator.
2. Task switching with the f.p. emulator is real tricky. - I made sure that
I did not task switch while inside the emu code.
3. Ctask support code works fine with a real 387.
BTW, I am working on Ctask code to really support the ( Borland ) emu. I
will post it when ready. Don't hold your breath, though.
Chris Blum
Read:
==========================
ibm.other/ctask #386, from ron_ritchey, 215 chars, Wed Aug 21 11:11:34 1991
--------------------------
TITLE: Rebuilding with CHECKING option
Is there any way to rebuild the CTASK libraries without owning
MASM. I would like to create a version of the libraries with CHECKING
turned on.
Thanks in advance
Ron_Ritchey
==========================
ibm.other/ctask #387, from sworthington, 2404 chars, Thu Aug 22 15:58:18 1991
--------------------------
TITLE: MS-DOS 5.00 CTask 2.2 incompatibility
I have discovered one instance of what DOS 5 is doing differently
that is causing CTask 2.2 to crash. I was executing an INT 21h
AH=3DH (Open file) and I discovered that the "relres" routine in
TSKDOS.ASM was being called, from inside the INT 21H. It turns out
that after DOS clears the "in DOS" flag (123:321 on my DOS 5), it
does a call to a INT 21H AX=6300 (a new entry point for DOS 5 I
believe - it is not in "Undocumentd DOS"). Since the "in DOS" flag
is cleared, CTask 2.2 assumes that the "upper_dos" resource should
not be locked and calls "relres" to unlock it. On return from the
INT 21H AX=6300, the task is still in INT 21H AH=3d, but the
"upper_dos" resource is now unlocked. This means that another task
is now capable of calling INT 21H, despite this task still being in
DOS in INT 21H AH=3D. This is still usually all right, since the
yield call in "wait_dos_free" catches clashes for DOS use where "in
DOS" has again been set. However, when I have two tasks doing file
open calls at the same time (eg two tasks which are both woken up at
midnight to change to new files for the new day), I get a crash.
It is also now dangerous to change the value of the "in DOS"
(dos_in_use) flag by incrementing (as in TSKASM.ASM). I have seen,
for example, DOS comparing "in DOS" with literal 1 (at 1213:8094 in
my DOS 5). "Undocumented DOS" refers to the values 0, 1 and 2 having
specific meanings for "in DOS", with, if I remember correctly, 2
meaning that DOS is processing a critical error on a different stack.
A former colleague in Auckland says he has no problems so far with
his modified CTask 2.2 running under DOS 5. What he has done (he
says - I do not have the code) is to completely do away with the
"upper_dos" and "lower_dos" resources and instead to rely on swapping
the DOS swappable data area given by INT 21H AX=5D06. Since it would
be possible to need to swap while in DOS, the TCBs would have to be
expanded take the full size of the DOS swappable data area returned
by INT 21H AX=5d06 in CX, instead of the short "always swap" data
area size returned in DX. And perhaps the INT 21H AX=5d0B call should
be used instead of INT 21H AX=5D06. According to "Undocumented DOS"
though, it is still not possible to swap if DOS is in a critical
section delimited by INT 2AH AH=80 and INT 2AH AH=81H,82H
Stephen Worthington.
,
Read:
==========================
ibm.other/ctask #388, from dgh, 69 chars, Fri Aug 23 02:43:05 1991
This is a comment to message 384.
--------------------------
I wish I could help, but I haven't used FP with Ctask.
|) /\ \/ | |)
Read:
==========================
ibm.other/ctask #389, from dgh, 81 chars, Fri Aug 23 02:43:16 1991
This is a comment to message 386.
--------------------------
Do you have Borland's TASM? That's what I used when I recompiled.
|) /\ \/ | |)
==========================
ibm.other/ctask #390, from dgh, 111 chars, Mon Aug 26 21:25:10 1991
This is a comment to message 387.
--------------------------
Oh, that's NASTY! What the HECK is DOS doing calling a DOS function from
inside a DOS function!
|) /\ \/ | |)
Read:
==========================
ibm.other/ctask #391, from twagner, 1329 chars, Tue Aug 27 16:15:43 1991
There is/are comment(s) on this message.
--------------------------
TITLE: MASM 6.0
I need a show of hands...
The assembler modules of CTask are not compatible with MASM 6.0, even
if the compatibility option is used. I'll have to touch some modules
for the new version anyway (the DOS resource and SDA swap handling
obviously needs a redesign), and I have some mixed feelings about
converting.
Some of the features of MASM 6.0 are really nice when interfacing to
HLLs. The INVOKE directive, for example, should be a lot more readable,
and easier to maintain, then my 'callp' macro. Nested structures and
unions would allow all field names to match their C counterparts.
HTOINC would finally eliminate mismatches between the include files.
So an all-out conversion to 6.0 could increase readability and
reliability.
But - this would leave everyone not owning MASM 6.0 out in the cold,
especially Borlanders with TASM. I haven't heard anything on whether
Borland will update TASM for 6.0 compatibility, but even if they did,
it would probably take a while before such a version could be released.
So what do you recommend? Should I
a) Ignore MASM 6.0 and change nothing (not a good idea IMO)?
b) Ignore TASM and go all the way to full MASM 6.0 code (my preference)?
c) Try to maintain compatibility with TASM and change only those
parts that won't assemble with 6.0 in /Zm mode?
Thomas
Read:
==========================
ibm.other/ctask #392, from ltroxler, 292 chars, Wed Aug 28 01:29:57 1991
This is a comment to message 391.
--------------------------
As a TASM user, naturally my vote is to not require MASM 6.0.
Furthermore, even if Borland decides to go for compatibility, but only
in the Borland line and not the Turbo line, I would still say
no good. I don't know what the 6.0 /Zm flag is, so I don't understand
your choice "c".
Larry
Read:
==========================
ibm.other/ctask #393, from ron_ritchey, 343 chars, Wed Aug 28 13:43:40 1991
--------------------------
TITLE: DYNAMIC TASK STACKS
I need to allocate stack space for many (up to 32) tasks. Because of
the 64K stack/data limitation I have been allocating the space for them
dynamically. However, I have just been told that this is a no no in CTASK.
Is there any safe way of allocating a large amount of stack space while
using CTASK.
Ron_Ritchey
==========================
ibm.other/ctask #394, from bernardo, 133 chars, Wed Aug 28 14:29:54 1991
This is a comment to message 391.
There are additional comments to message 391.
--------------------------
[From twagner #391]
IMO, try to maintain compatibility with TASM and MASM. You can write
different routines for each one.
Bernardo
Read:
==========================
ibm.other/ctask #395, from twagner, 902 chars, Wed Aug 28 15:46:28 1991
This is a comment to message 393.
--------------------------
> DYNAMIC TASK STACKS
CTask couldn't care less where you place your task stacks, since the
kernel is model independent, and always uses far pointers. You can
even tell CTask to allocate the stack for you on create_task. The
only problem is with some of the C Run-Time-Lib routines. A number of
them, especially in the small data models, assume DS==SS, which isn't
true for dynamic stacks allocated on the far heap. Some routines even
do stack checking, which will crash when the stack is outside the
standard stack frame. That's why I recommend creating the task stacks
as auto variables in main().
If you take care not to call such routines in tasks with dynamic
stacks (and you have stack checking turned off and the DS!=SS option
set when compiling), all should be well. I don't have the manuals
around, but there should be a listing of the routines you can't call
with DS!=SS somewhere.
Thomas
Read:
==========================
ibm.other/ctask #396, from gquance, 42 chars, Thu Aug 29 02:41:28 1991
This is a comment to message 391.
--------------------------
My vote goes to option (c).
George Quance
Read:
==========================
ibm.other/ctask #397, from ron_ritchey, 162 chars, Thu Aug 29 17:44:35 1991
--------------------------
TITLE: CTASK Database
Does anybody know of a good database package to use with CTASK? I am
currently using dbVista and am having some difficulties.
Ron_Ritchey
==========================
ibm.other/ctask #398, from cblum, 1003 chars, Thu Aug 29 21:40:19 1991
This is a comment to message 391.
There are additional comments to message 391.
--------------------------
Thomas -
My first choice, being a TASM user, is stick with it if not too much
work for you. I have Microsludge Massive Assembler 5.1 upgrade, and do not
plan to upgrade to 6.0 unless forced into it for some reason. As I use
Ctask in real time controls applications, your choice to fully convert to
MASM would force me to do that. That would not be a major problem for me,
however, so I defer to your judgement. As a developer, I fully understand
( and sympathize with ) your situation and in your place might just choose
the conversion route and say 'too bad' to those who do not have MASM. I
wonder just how many of your users
A) realize how much work you have 'given away' by releasing Ctask, and
B) really have a need to make changes to the assembler modules.
If the number of (B)s are low, I say go with conversion. If the number of
(A)s are low, I am very sorry for you and I hope your level of self-derived
gratification is high. Thanks AGAIN for a really fine product.
Chris Blum
Read:
==========================
ibm.other/ctask #399, from dgh, 123 chars, Fri Aug 30 20:06:51 1991
This is a comment to message 391.
There are additional comments to message 391.
--------------------------
>To require MASM 6.0 or not.
Why not use "IFDEF MASM60 <MASM 6.0 code> ELSE <TASM code> ENDIF" where
needed?
|) /\ \/ | |)
Read:
==========================
ibm.other/ctask #400, from gquance, 491 chars, Mon Sep 2 04:31:42 1991
There is/are comment(s) on this message.
--------------------------
TITLE: CTask Help
I am new to CTask and could use some help in the following areas:
1) Is there a way to perform disk reads and writes and by-pass the
critical area protection which ctask puts around the call? I an
doing timing studies and this restriction is proving to be awkward.
2) Could someone post a small code si/// snipit that shows me how to
access and set a tasks priority?
I would be most gratefull for any help in these areas.
The^/// Thank you, George Quance
Read:
==========================
ibm.other/ctask #401, from amargerison, 100 chars, Mon Sep 2 07:51:49 1991
This is a comment to message 391.
There are additional comments to message 391.
--------------------------
As a confirmed Borlander and rabid Anti-Bill <g> I must place my vote with (c)
Regards
Stephen.
Read:
==========================
ibm.other/ctask #402, from mvanditta, 438 chars, Mon Sep 2 21:55:57 1991
This is a comment to message 400.
There is/are comment(s) on this message.
--------------------------
George,
The only other way that I know of to perform this operation is to use
a device monitor and a message queue. In this model, the file system would
owned by the monitor task. To perform an I/O, a message would sent to the
monitor task; and, the monitor task would send back a I/O result message
after performing the I/O operation. One could then place the I/O timing
code inside of this monitor task.
Mark T. Van Ditta
Read:
==========================
ibm.other/ctask #403, from ltroxler, 491 chars, Tue Sep 3 01:05:09 1991
This is a comment to message 402.
There is/are comment(s) on this message.
There are additional comments to message 402.
--------------------------
Mark,
I noticed you used the term "monitor". I was at a VRTX seminar once,
where they desribed a monitor as a set of protected function calls used
to access a device. This is a little different the queing messages into
a seperate task, although externally the interface would be the same,
i.e. though function calls. I am by no means arguing your use of the
term, rather, I would be interested to know if there _is_ and
accepted definition of "monitor" in rt-parlance.
Larry
Read:
==========================
ibm.other/ctask #404, from gquance, 60 chars, Tue Sep 3 01:30:45 1991
This is a comment to message 402.
There are additional comments to message 402.
--------------------------
Mark,
Thanks for your response. I .m
Thanks for yu^
Read:
==========================
ibm.other/ctask #405, from mvanditta, 1728 chars, Tue Sep 3 23:09:59 1991
This is a comment to message 403.
There is/are comment(s) on this message.
--------------------------
The definition you were given is the text book definition [Hoare 1974 and
Brinch Hansen 1975], and as such is quite correct.
"A monitor is a collection of procedures, variables, and data structures
that are grouped together in a special kind of package. Processes may call
the procedures in a monitor whenever they want to, but they cannot
directly access the monitor's internal data structures from procedures
declared outside of a the monitor." [Tanenbaum 1987]
"Monitors have an important property that makes them useful for achieving
mutual exclusion: only one process can be active in a monitor at any instant.
Monitors are a programming language construct, so the compiler knows they
are special and can handle calls to monitor procedures differently from
other procedure calls." [Tanenbaum 1987]
Thus, in order to develop a true monitor, the programming language being
used must support monitors in its syntax (i.e. Ada with its task types).
Since C does not support monitors natively, one must implement them by
either encapsulating a set of P() (wait on semaphore) and V() (
send on semaphore) operations inside of the pseudo-monitor's access
procedures, or they must encapsulate a set of SendMessage/ReceiveMessage
procedures inside of the pseudo-monitor's access procedures. I prefer a
kernel which is based on the message passing model because it can be
implemented in such a way as to have the monitor's protected data
access procedures (the ones that actually access the data, not the message
passing stubs) implemented on another processor or its access procedures
and protected data on the different machine (a network file system is
a good example of a loosely coupled monitor).
Mark T. Van Ditta
Read:
==========================
ibm.other/ctask #406, from gquance, 399 chars, Wed Sep 4 02:11:51 1991
This is a comment to message 402.
There is/are comment(s) on this message.
--------------------------
Mark,
Thanks for your response. I'm not sure that approach will work, tho.
The problem is (if I am reading the ctask docs correctly) that ctask
encapsuleates all Dos call in a critical section automatically. Since
I am tring to measure the Dos call itself (the disk I/O) this approach
and the Dos call will still reside in a ctask task we are back to
square one. However, perhaps by comp~^]. ->
Read:
==========================
ibm.other/ctask #407, from twagner, 378 chars, Wed Sep 4 04:52:01 1991
This is a comment to message 406.
--------------------------
You could create a "naked CTask" version by recompiling everything
with DOS set to FALSE in tskconf.h. This disables all DOS specific
stuff, including INT 21 trapping and SDA swapping. IBM should be left
TRUE, but you can disable GROUPS. Just be sure that CTask is
uninstalled on termination (there's no automatic trap if DOS is
FALSE), and that you don't reenter DOS.
Thomas
Read:
==========================
ibm.other/ctask #408, from ron_ritchey, 178 chars, Wed Sep 4 18:22:21 1991
--------------------------
TITLE: FP operations in CTASK
Does anybody know if a problem similar to message 384 (Floating point
related crashes) occurs when using Ctask 2.2 and Microsoft 5.1.
Ron_Ritchey
Read:
==========================
ibm.other/ctask #409, from harrellfreeman, 105 chars, Wed Sep 4 22:46:08 1991
This is a comment to message 391.
There are additional comments to message 391.
--------------------------
my vote..b to save you work. If you are willing to do all this "upkeep"
I am willing to buy 6.0.
Harrell
Read:
==========================
ibm.other/ctask #410, from mshiels, 120 chars, Thu Sep 5 20:35:14 1991
This is a comment to message 390.
--------------------------
DOS is quite capable of calling itself from itself since it knows it's
own states and knows which calls can be called.
Read:
==========================
ibm.other/ctask #411, from tgentry, 496 chars, Fri Sep 6 01:02:04 1991
This is a comment to message 391.
There are additional comments to message 391.
--------------------------
Hi, Thomas
Unfortunately for your sanity I have to go with the "Maintain TASM
compatibility" vote. I don't have MASM (any version), and work exclusively
with TASM. Should this be a problem I would be willing to go and purchase
MASM <gasp>, but would really prefer to work with TASM overall.
As others have said already, thanks for a great piece of work. CTask
saved my hide on my current project, and I can't wait to see what's new
in the next version ;-). Thanks again.
-Tim
Read:
==========================
ibm.other/ctask #412, from ltroxler, 770 chars, Fri Sep 6 01:06:31 1991
This is a comment to message 405.
--------------------------
Mark, thanks for the clarification on "monitors". So except for the
reqiurement that a monitor be intrinsically implemented by the compiler
( did I read you right, that doesn't make too much sense to me ), I'm
glad to see that my thougts are in sync with the description regarding the
alternatives of protecting each call via. mutual exclusion, vs. queuing
messages into another task loop. However to me, the mutex approach seems
to have the advantage of less overhead ( no need for seperate task, also
if the resource is sparsely used, no task switches, etc ), although the
message queue has the advantages that you mentioned.
I've been learning C++, and have found that there is often a close
correspondence between classes and monitors. Would others agree?
Larry
Read:
==========================
ibm.other/ctask #413, from twagner, 349 chars, Fri Sep 6 05:25:07 1991
This is a comment to message 391.
--------------------------
No to MASM 6.0
A rather unanimous vote! Is no one actually using MASM 6? I haven't
done any serious work with it, either, but I liked some of the new
features. Oh well, so I'll stay with TASM compatibility, and just
change the few things that won't assemble under 6.0 with the
compatibility switch. Likely less work than a full conversion.
Thomas
==========================
ibm.other/ctask #414, from koziol, 228 chars, Fri Sep 6 22:33:53 1991
--------------------------
TITLE: Watcom C?
Howdy,
Has anyone ever gotten the ctask library to compile and work under
Watcom C (8.0)? I would like to try, but didn't want to duplicate anyones
existing work if I could help it.
Thanks,
Quincey Koziol
Read:
==========================
ibm.other/ctask #415, from mvanditta, 97 chars, Sat Sep 7 17:50:48 1991
This is a comment to message 412.
--------------------------
C++ is indeed a language in which monitors could be implemented very
easily.
Mark T. Van Ditta
Read:
==========================
ibm.other/ctask #416, from dgh, 727 chars, Mon Sep 9 20:19:28 1991
This is a comment to message 410.
There is/are comment(s) on this message.
--------------------------
OK, I'll accept that DOS should be able to call its own functions, BUT, the
function in question is AH=63 and the new "MS-DOS Programmer's Reference 5"
from Microsoft Press says the following: "This chapter does not include
reference pages for Interrupt 21h functions that are obsolete - that is,
not supported by MS-DOS version 5.0. Following are the numbers of the six
obsolete functions: 18h, 1Dh, 1Eh, 20h, 61h, and 63h." But in Stephen's
original message, he states that he traced DOS calling INT 21h with AH=63h
in DOS 5.0! So my question now is: What is DOS 5.0 doing calling a function
that is listed as obsolete and unsupported (which implies that it may have
been supported in earlier DOS versions).
|) /\ \/ | |)
Read:
==========================
ibm.other/ctask #417, from dave2, 289 chars, Mon Sep 9 21:45:19 1991
This is a comment to message 416.
--------------------------
The MS 5.0 reference documents *some* previously undocumented stuff,
brings in a lot that was documented in Microsoft Journal and the
Encyclopedia, and still glosses over some stuff or pretends some
doesn't exist.
"obsolete" and "unsupported" mean "don't ask, 'cause we ain't tellin'."
Read:
==========================
ibm.other/ctask #418, from ron_ritchey, 655 chars, Thu Sep 12 11:07:34 1991
There is/are comment(s) on this message.
--------------------------
TITLE: MS FP with CTASK
I don't beleive CTASK works correctly with Microsoft's FP emulator.
I have been trying to write a multi-line voice program using CTASK.
I am using it in conjunction with the Raima database product,
dbVista. Periodically the program would crash. This occured most
frequently when doing intensive database searches. I got Raima's
source code, and recompiled it after removing all floating point
references from there code. The program hasn't crashed since.
Two questions,
1. Any idea why FP emul would cause a CTASK crash?
2. IF FP emul doesn't work, would a real co-processor
solve the problem.
Ron_Ritchey
Read:
==========================
ibm.other/ctask #419, from cblum, 483 chars, Thu Sep 12 21:41:50 1991
This is a comment to message 418.
There is/are comment(s) on this message.
--------------------------
Ron:
FP emulation is all done in software using a fairly large area on the
stack. Task switches in the middle of emulation, with another task using
emulation also, reenters the ( non-reentrant ) FP emulation code and
KA-BOOM!
I have been working on Ctask code to allow use of Borland's FP emulator
but it has slipped onto the back burner.
Yes, a real coprocessor fixes the problem ( if you enable the Ctask
coprocessor code ). I have used it - works well.
Chris Blum
Read:
==========================
ibm.other/ctask #420, from ron_ritchey, 34 chars, Thu Sep 12 22:42:32 1991
This is a comment to message 419.
--------------------------
Thanks for the info.
Ron_Ritchey
--------------------
Email enviado a ron_ritchey y mnogel:
We read with interest your message in ibm.other/ctask about
developing a voice system using CTask. We have developed a multiline
voice product (hardware and software) down here in Uruguay, South
America, also using CTask.
As we target completely different markets, we think that some
information exchange will usefull for both of us.
Our product (Telephone Manager) provides Fax/Telex/Email output as
well as voice response. We have an agreement with the local branch of
IBM that give them exclusive rights to market our product in Uruguay.
Hoping to hear from you soon
----------------------------------------------------------------------
- Aqu° ir°an algunos mensajes que est†n en la red
----------------------------------------------------------------------
==========================
ibm.other/ctask #433, from mshiels, 195 chars, Sat Oct 5 23:03:03 1991
This is a comment to message 429.
There is/are comment(s) on this message.
--------------------------
What type of programming interface is there for the Bigmouth board?
I am looking for a good programmable voice board with phone interface
for doing a Electronic Mail voice retreival station.
^D.
Read:
==========================
ibm.other/ctask #434, from ndws, 375 chars, Sun Oct 6 10:17:03 1991
This is a comment to message 433.
There are additional comments to message 433.
--------------------------
The Bigmouth board has a c-programming toolbox. It is free now I
understand. It has functions and macros for recording,playing,answering,
touch tone detection, etc. If you would like, I will mail you a list
of functions on BIX, or leave a message in here. It is perfect for voice
mail. It took about an evening to get the base for the program done
with their toolbox.
Ray
Read:
==========================
ibm.other/ctask #435, from iarslangiray, 141 chars, Tue Oct 8 01:26:41 1991
This is a comment to message 433.
--------------------------
[to mshiels]
There is another voice mail package aloows you to do the things
without programming and ten times expensive then BIGMOUTH. TTYL
Read:
==========================
ibm.other/ctask #436, from jmoritz, 225 chars, Tue Oct 8 07:01:45 1991
This is a comment to message 426.
There is/are comment(s) on this message.
--------------------------
I've downloaded and looked at this version, but I don't think I'll use it.
It looks like just a straight port with little use of C++ features, which
is not what I want or need for my project. I'm porting 2.0 myself, instead.
Read:
==========================
ibm.other/ctask #437, from ltroxler, 188 chars, Tue Oct 8 21:36:49 1991
This is a comment to message 436.
--------------------------
I never looked at the port myself. When you say little use was made of C++
features, what features do you mean were not used?
At any rate, keep us posted on your 2.0 conversion.
Larry
1448
Msg: 1448
De: APR
Fecha: 06/10/91
Hora: 00:56:52
Tema: Email en Bix
Daniel, acabo de entrar a Delphi y Bix (por las buenas por supu).
En Bix como interesante ten°amos la respuesta de uno de los dos tipos
que les mandamos Emails por el tema AudioTex. Ser°a bueno seguir el
dialogo, el lunes vemos de contestarle.
----------------------------------------------------------------------
Memo #3402
From: ron_ritchey
Date: Thu, 19 Sep 91 10:15:43 EDT
To: compuservice
Message-Id: <memo.3402>
In-Reply-To: <memo.1826>
Subject: Voice response
I would be happy to find another voice developer out there using CTASK.
Just to let you know my configuration, I am developing using CTASK 2.2,
Multivox (A library of Dialogic, and Rheotorix utilities), and dbVista.
I use MS 5.1 for my compiler and DOS 5.0 for my OS.
If you have any questions or problems, please feel free to write. The
only problem I've had recently was the Floating Point problem I
discussed on ibm.other/ctask. Just in case you didn't see those posts,
FP emul at least with Microsoft is a definite no-no with CTASK.
See ya later,
Ron_Ritchey
read/action:delete
----------------------------------------------------------------------
Elimina mensaje ? 144
Por favor, responda Si o No.
Elimina mensaje ? s
Correo>1449
Msg: 1449
De: APR
Fecha: 06/10/91
Hora: 00:57:48
Tema: Actualizaci¢n CTASK.CNF
==========================
ibm.other/ctask #421, from ndws, 175 chars, Fri Sep 27 00:37:51 1991
--------------------------
TITLE: MASM 6.0...
I actually have it, but still on the shelve not used. Felt the asm code
worked well enough as it was. Whatever tom feels is best is ok. CTASK
is the best.
Read:
==========================
ibm.other/ctask #422, from r.rice, 163 chars, Sat Sep 28 00:24:51 1991
There is/are comment(s) on this message.
--------------------------
I am not using Ctask but I am using EXEC as a base to build a menu
system. What I would like to know is have you done any further
work to better this module.
Read:
==========================
ibm.other/ctask #423, from twagner, 184 chars, Sat Sep 28 15:54:32 1991
This is a comment to message 422.
--------------------------
> EXEC... have you done any further work
Depends on which version you have. The current version is 3.2a, and
it's in EXEC32A.LZH in ibm.utils/listings (and ibm.pc/listings).
Thomas
Read:
==========================
ibm.other/ctask #424, from jmoritz, 433 chars, Mon Sep 30 15:11:38 1991
--------------------------
TITLE: C++ implementation
I have written the better part of a bios for an embedded application in
(no, I'm not kidding) C++. I'm planning to use ctask as my operating
system, since the application demands multitasking and ctask is, well, free!
Has anyone translated this Christmas gift into C++? If no one else has, or
is willing to part with their code at any price, I will. But I'd still be
curious to hear how you fared.
James M.
Read:
==========================
ibm.other/ctask #425, from jmoritz, 553 chars, Mon Sep 30 15:28:35 1991
This is a comment to message 361.
There is/are comment(s) on this message.
--------------------------
Hi, there! I see I'm not alone. I'm currently designing an operating system
for an embedded controller in C++. I've implemented and tested my own additions
to the iostream class library to make them work with 8256 UART serial and
parallel ports. Now I'm trying to figure out how to make it work with/as a
ctask pipe event. Unlike you, I can't use the sio drivers, since I'm not in
a normal PC environ. Have you been able to make it work? I'm starting a
translation of ctask from C to Borland C++, and would welcome any sort of
exchange of info on this.
Read:
==========================
ibm.other/ctask #426, from ltroxler, 294 chars, Tue Oct 1 00:46:18 1991
This is a comment to message 425.
There is/are comment(s) on this message.
--------------------------
Someone on the BPROGB forum in Compuserve recently uploaded a C++
version of ctask. I think he started with ctask 1.5, however. I haven't looked
at it myself. Maybe you would want to get in touch with him. I don't
remember who did it off-hand, and I'm not sure if he's on Bix himself.
Larry
Read:
==========================
ibm.other/ctask #427, from jmoritz, 8 chars, Tue Oct 1 07:06:00 1991
This is a comment to message 426.
--------------------------
Thanks!
Read:
==========================
ibm.other/ctask #428, from jmoritz, 380 chars, Tue Oct 1 07:28:27 1991
This is a comment to message 370.
--------------------------
At the risk of sounding redundant, I am working along the same lines,
although not on a PC platform. I have tested my additions to the stream
classs^FO;^T hierarchy, and am trying to figure out a way to marry it with
CTask pipe events. If you have learned anything profound I will be
eternally grateful for any insightful comments you care to bestow upon me.
Thanks!
James Moritz.
Read:
==========================
ibm.other/ctask #429, from ndws, 717 chars, Thu Oct 3 23:05:02 1991
--------------------------
TITLE: general..
Am developing a talking weather phone with the "bigmouth" board doing
the talking. Ctask runs main program, with a comm program running as
another task. This comm program downloads a new set of area temperatures
fromFAA and weather service stations. Each state has a "mailbox"
with a current forecast,extended forecast, and current temps available.
The bigmouth speaks out the temps to the user with canned numbers.
The key is to disable task preemption when the bigmouth has to speak.
This is not too easy implimented with most multitaskers. CTASK works
great, as the time can be scheduled as needed. Use XMODEM to transfer
daa in case the bigmouth preempts a data frame. It simply is resent.
Ray
Read:
==========================
ibm.other/ctask #430, from harrellfreeman, 224 chars, Fri Oct 4 00:56:11 1991
--------------------------
TITLE: Reenterancy
Does anyone have a list of Microsoft 6.0 dos 5 functions
that can be safely reentered? if not how can reenterancy be
determined easily. should resources be used around *ALL* library
functions?
tnx
Harrell
Read:
==========================
ibm.other/ctask #431, from deggert, 507 chars, Fri Oct 4 15:58:40 1991
There is/are comment(s) on this message.
--------------------------
TITLE: dos file write problem
i am using ctask in an application that uses several tasks. during execution
of some of the tasks and 'error' file may be written to log errors. my problem
is that when writing to this file, the system gets confused and crashes. i
tried to allocate a 'file' resource and request/release it to no avail. my
system only has a floppy on it and no hard drive (target system). does any
one have any suggestions as to what i can try ?
thanks for the help in advance.
deggert
Read:
==========================
ibm.other/ctask #432, from cblum, 279 chars, Fri Oct 4 16:10:28 1991
This is a comment to message 431.
--------------------------
I would suggest setting up one task to write to the file. Use the mailbox
feature to have the tasks send their messages to the file-writer task. That
will probably serve to ( somewhat ) simplify and modularize your code, too.
The mailbox stuff is pretty easy to use. Chris Blum.
==========================
ibm.other/ctask #433, from mshiels, 195 chars, Sat Oct 5 23:03:03 1991
This is a comment to message 429.
There is/are comment(s) on this message.
--------------------------
What type of programming interface is there for the Bigmouth board?
I am looking for a good programmable voice board with phone interface
for doing a Electronic Mail voice retreival station.
Read:
==========================
ibm.other/ctask #434, from ndws, 375 chars, Sun Oct 6 10:17:03 1991
This is a comment to message 433.
There are additional comments to message 433.
--------------------------
The Bigmouth board has a c-programming toolbox. It is free now I
understand. It has functions and macros for recording,playing,answering,
touch tone detection, etc. If you would like, I will mail you a list
of functions on BIX, or leave a message in here. It is perfect for voice
mail. It took about an evening to get the base for the program done
with their toolbox.
Ray
Read:
==========================
ibm.other/ctask #435, from iarslangiray, 141 chars, Tue Oct 8 01:26:41 1991
This is a comment to message 433.
--------------------------
[to mshiels]
There is another voice mail package aloows you to do the things
without programming and ten times expensive then BIGMOUTH. TTYL
Read:
==========================
ibm.other/ctask #436, from jmoritz, 225 chars, Tue Oct 8 07:01:45 1991
This is a comment to message 426.
There is/are comment(s) on this message.
--------------------------
I've downloaded and looked at this version, but I don't think I'll use it.
It looks like just a straight port with little use of C++ features, which
is not what I want or need for my project. I'm porting 2.0 myself, instead.
Read:
==========================
ibm.other/ctask #437, from ltroxler, 188 chars, Tue Oct 8 21:36:49 1991
This is a comment to message 436.
--------------------------
I never looked at the port myself. When you say little use was made of C++
features, what features do you mean were not used?
At any rate, keep us posted on your 2.0 conversion.
Larry
==========================
ibm.other/ctask #438, from harrellfreeman, 138 chars, Sat Oct 12 15:20:11 1991
This is a comment to message 433.
There is/are comment(s) on this message.
--------------------------
Who makes Bigmouth? how many lines? I mam using Multivox
(514) 597-1692 with Dialogic. Easy to use with excellent
quality audio.
Harrell
Read:
==========================
ibm.other/ctask #439, from mnagel, 642 chars, Sat Oct 12 19:05:42 1991
There is/are comment(s) on this message.
--------------------------
TITLE: PC Anywhere
We've developed a voice mail application using CTask in non-preemptive mode.
Unfortunately, we have not been able to get remote control programs such as
PC Anywhere to function with the system. They seem to live fine together
until you actually call. Then the system locks up. I've also noticed that
attempting to stuff keys into the keyboard buffer for later reading causes
similar lockups, though they might very well be unrelated. Has anyone any
insights into why either of these two behaviors might occur? I'm now building
remote access into the system, but it's starting to get a little cramped in
there...
Mark
Read:
==========================
ibm.other/ctask #440, from harrellfreeman, 147 chars, Sat Oct 12 19:46:43 1991
This is a comment to message 439.
--------------------------
I had the same problem with PC Anywhere IV. Switched to
Remote-2 and it works Ok. If anyone has PC Anywhere working
pls post the fix.
tnx
Harrell
Read:
==========================
ibm.other/ctask #441, from iarslangiray, 158 chars, Sun Oct 13 02:16:53 1991
This is a comment to message 438.
There are additional comments to message 438.
--------------------------
[to harrell]
I don't have the complete info right now, but if you are more
interested on it, drop me a BIXMAil and I will get the info together
for you. TTYL
Read:
==========================
ibm.other/ctask #442, from ndws, 230 chars, Sun Oct 13 19:56:53 1991
This is a comment to message 438.
--------------------------
Bigmouth is made by Talking Technologies ^[s of Alameda Cal.
The basic one is single line , and they have a multi-line available.
Not sure how many the multi is, havent handled it yet. Our remote
access works fine via touch tone.
Read:
==========================
ibm.other/ctask #443, from ltroxler, 453 chars, Mon Oct 14 01:32:07 1991
--------------------------
TITLE: Short suspensions of timer task OK?
I would like to use the timer link elements to drive some real time
processing. However, this processing needs to allocate memory, thus
may need to suspend briefly.
There is mention in the documentation that timer elements should do nothing
to suspend the current task. However, from looking through the source, it
seems that the timer task is a full fledged task, and thus can be
suspended.
Larry
Read:
==========================
ibm.other/ctask #444, from thvaring, 277 chars, Thu Oct 17 04:56:13 1991
--------------------------
TITLE: Bug in CTask 2.2, tskutil.c
Thomas,
There's a bug in tskutil.c that shows up if CLOCK_MSEC is TRUE.
Line 104 in t_delay() which now reads
tsk_enqtimer (&task->timerq.link, ticks);
should read
tsk_enqtimer (&task->timerq.link, tsk_timeout(ticks));
Regards,
Tron.
==========================
ibm.other/ctask #445, from mnagel, 1230 chars, Mon Oct 21 21:48:32 1991
--------------------------
TITLE: More on PC Anywhere...
I haven't heard much yet other than that Remote-2 might work, so I delved in
deeper. The following program is what I delved with:
#include "tsk.h"
main()
{
int k = 0;
install_tasker(0, 0, IFL_STD TN("MAIN"));
while (tolower(k & 0xFF) != 'q')
{
if ((k = t_wait_key((dword)ticks_per_sec())) == TIMEOUT)
{
printf("[****]\n");
continue;
}
printf("[%04X]\n", k);
}
remove_tasker();
exit(0);
}
If I run ANYWHERE AUTOMATIC and then run this program, when I call in the host
freezes before even getting to the password prompt. It runs fine when no
call is received or if ANYWHERE is never executed. Also, if I call in to
the host first and then run the above program, it works fine as well.
During my tests I disabled the HOTKEYS config definition. When this is done
with the above program, it fails to halt properly (locks up when you type
'q'). This seems like a bug in CTask to me. I'm planning on trying Remote-2
as was suggested here, but I guess I hope someone else has run into this bug
before and solved it. It seems to me to be a problem with interrupt chaining,
but I don't see any obvious problems with the code in tskkbd.asm
Mark
Read:
==========================
ibm.other/ctask #446, from rkrampf, 76 chars, Wed Oct 23 06:01:35 1991
This is a comment to message 317.
--------------------------
I'm going to be using Borland C++. Can you tell me where this code is ??
..
------------------------------------------------------------------------------
Mensaje enviado por nosotros:
TITLE: Microsoft C 5.1 and TC++ 1.0
We have to link two packages.
1) Low level that drives 2 IBM ARTIC Multiport/2 written in MSC 5.1
2) High level written in TC++ based on the great CTask.
We have lot of alternatives but since CTask can help also in the low level,
we think that having two EXEs would simplify things. (Making the low level
in MSC resident)
Do you think 'find_name' and 'send_mail' would work between the two versions
of CTask ?. At first thought it should work, but things like byte alignment,
etc., can get into the way... ;-)
Anybody using ARTIC Multiport/2 ?
------------------------------------------------------------------------------
Read:
==========================
ibm.other/ctask #448, from pcquote, 64 chars, Wed Oct 23 23:21:43 1991
This is a comment to message 446.
--------------------------
Check either ibm.dos or ibm.pc. Ctask is a great package!
Rich
Read:
==========================
ibm.other/ctask #449, from rkrampf, 1676 chars, Thu Oct 24 03:32:08 1991
There is/are comment(s) on this message.
--------------------------
TITLE: Help !!!!!!!!!
hopefully someone out there can help me get up and running on CTask
I'm new to bix and am having some difficulty navigating, new to CTask
and having problems getting it all running, and my assembler skills are a
bit rusty so I'm having problems debugging. Not knowing any better I
downloaded 1.1 in the frombytes area and got it up and running. I fought withfor
a while and found several bugs. I call
ed back to try and contact twagner
and found this conference section. I now have 2.2b and seem to have most of
it running. I'm not sure I've put in all the bug fixes and I have two other p
problems. I've applied the patch from msg444 and msg310. I found the patch
in msg444 after I had experienced difficulties with t_delay. After grepping
all the sources, it appears that patch may be appropriate in other places??
Can anyone tell me if I've applied all the known fixes to 2.2b? The other
problems are floating point and vga display. Ctask will be running on a
dedicated system under dos 5.0 so I don't have to worry about windows, tsrs,
or other complications. Has anyone modified the debug display for vga, I
can't seem to get it running. I'm using BC++ 2.0 and cannot do 'any floating
point operations. I've try to protect the floating point calculations with
CRITICAL sections but that doesn't seem to work. I don't think I understand
what's going on with floating point operations. I will not be able to use
an NDP. oops... I forget to mention the details of the vga. It is 640x480,
16 color grayscale. - I would greatly appreciate all the help I can get
I'll be checking daily for the next couple of days if anyone can help.
Thanks !!
Read:
==========================
ibm.other/ctask #450, from jmoritz, 1809 chars, Thu Oct 24 10:24:04 1991
This is a comment to message 437.
--------------------------
What I mean is that design was not really considered during conversion.
Ctask has an implicit object-oriented design, but, because it was
implemented in C, a lot of it is hidden. The version I looked at (I'm sorry,
I can't think of the author's name, offhand)---the C++ version, I mean---
converted the obvious, such as the various "event" classes, but ignored a
lot of the other stuff. For instance, Ctask uses unions quite a bit in
structure definitions. This allows the same type of pointer to be used for
more than one type of structure. C++ class inheritance permits pointers to
derived classes to be assigned to variables that point to the base class.
A look at the queue and timer structures would help to illustrate my point.
Even the event classes, which were converted, were a crude conversion. Why
keep a name like "read_pipe" in a class called "pipe"? A C++ call to that
function is going to look like: pipe.read_pipe (). Better to just call the
function "read". The read function could also be overloaded in place of the
function c_read.
My conversion is going fairly well, if somewhat slow (I can't dedicate every
waking moment to it). I'm over the hump, at least. I've found that C++
can really clean up the code. For instance, my base class for nearly every
other class has its own built-in memory allocation/deallocation. Each class
"knows" whether or not it was created dynamically (with new) and can be
"delete"ed with impunity (gotta be careful with destructor code, though).
Gone are all those #ifdef TSK_DYNAMIC conditional blocks. I am being fairly
careful not to alter the underlying logic of the system and try to restrict
my changes to simple syntactic replacements. There are, however, several
places where large switch statements are replaced by C++'s internal
virtual tables.
Read:
==========================
ibm.other/ctask #451, from cblum, 459 chars, Thu Oct 24 16:03:50 1991
This is a comment to message 449.
--------------------------
As to floating point under BC++, forget it for now without coprocessor. The
coprocessor code in Ctask works great, but the emulator takes mucho stack
space and is not reentrant. I was looking into writing Ctask code to support
it but shelved the project for time ( and just got a 387 for the dedicated
app I was doing ). I realize that's not encouraging, but you can spend a
lot of time trying ( like I did ) and end up frustrated ( like I did ).
Chris Blum.
Read:
==========================
ibm.other/ctask #452, from pcquote, 252 chars, Thu Oct 24 22:45:54 1991
This is a comment to message 447.
--------------------------
We use ARTIC cards, but under OS/2. I don't think there is much
problem with byte alignment between MS and Borland. I while back I
wrote mouse routines and compiled them with MS C 5.0. I have been
using that same LIB for years, and with Borland.
Rich
Read:
==========================
ibm.other/ctask #453, from rkrampf, 129 chars, Fri Oct 25 01:40:51 1991
This is a comment to message 451.
There are additional comments to message 451.
--------------------------
Thanks for the reply! SInce the platform's just an 80286
I'll guess I'll buy a 287. Hope the coprocessor code works
in CTask.
Read:
==========================
ibm.other/ctask #454, from ltroxler, 94 chars, Fri Oct 25 01:53:45 1991
This is a comment to message 451.
There is/are comment(s) on this message.
--------------------------
Chris, is the floating point only a problem if you attempt it from more
than one task?
Larry
Read:
==========================
ibm.other/ctask #455, from ltroxler, 578 chars, Fri Oct 25 01:59:48 1991
This is a comment to message 450.
There is/are comment(s) on this message.
--------------------------
I did finally download that C++ version. My impression was that he
simply didn't have a lot of time to spend on it. Understandable.
Since you're working with C++, maybe you can help me with something.
I'm overloading global new and delete, by testing ctask_active and then
either calling tsk_alloc or malloc, or tsk_free or free. Does this seem
ok? The reason I ask is that I seem to crash occasionally, and I was
wondering if it might have someithing to do with the overloaded allocator,
or something with the fact that I'm using a global object to start
CTASK, etc.
Larry
Read:
==========================
ibm.other/ctask #456, from cblum, 462 chars, Fri Oct 25 08:50:46 1991
This is a comment to message 454.
There is/are comment(s) on this message.
--------------------------
From what I found, that seemed to be true. One way to ( try to ) minimize the
exposure is to have only one task do math. This is difficult, though, because
any time you even refer to a floating point number you use a math routine of
some kind. If you can do it all in one task, you are ok, though. Note again,
the Ctask code for coprocessor support *DOES* work if you really have an '87
so the investment ( getting smaller all the time ) may be worth it. Chris.
Read:
==========================
ibm.other/ctask #457, from bernardo, 165 chars, Fri Oct 25 09:36:34 1991
This is a comment to message 447.
--------------------------
[From compuservice #447]
what about linking all together into one .EXE using TC++, or compile the low
level with TC++ converting from MSC 5.1 to TC++ ???
Bernardo.
Read:comment
Comment to message number 457. Enter text. End with '.<CR>'
>The ARTIC Development Toolkit do not provide source code. It was compiled
>with IBM C/2 so linking it together with TC++ libraries it's a 'no no'.
>Thanks anyway.
>.
Add/action:send
Adding message...Message 468 added.
Read:
==========================
ibm.other/ctask #458, from jmoritz, 1040 chars, Fri Oct 25 14:15:49 1991
This is a comment to message 455.
There is/are comment(s) on this message.
--------------------------
Re Using C++ operators versus tsk_alloc and tsk_free:
Shouldn't be a problem if you're using tsk_alloc and tsk_free for the
actual allocation. The problem's probably somewhere else, such as in a
constructor or destructor. Are you using new and delete only in your own
tasks, or have you altered CTask, itself? How are you using them?
Re Rich Smith's C++ version:
It's good, as far as it goes. It just doesn't go far enough for me. I have
another C++ system of my own that I need to merge with CTask, and I need
more of an object hierarchy than Rich provided. If you don't need that, than
I don't see any reason for not using his conversion. I confess that
I've become something of an object-oriented bigot, and probably would have
converted CTask myself, anyway, since I like to turn my programs into giant
class hierarchies and Rich didn't do that.
Thanks for answering my message. I would welcome any more questions or answers
you'd care to direct my way. Have you contacted Rich, at all? I haven't, but
I'd like to.
James Moritz
Read:
==========================
ibm.other/ctask #459, from jmoritz, 520 chars, Fri Oct 25 17:56:31 1991
--------------------------
Can anyone help me? I am trying to make sense of the timer queue. The tlink
structure has a union, "elem", that, along with the "elkind" data member,
permit a tlink to be used as either a port watch, memory watch or timeout
timer. Two new functions, wait_port and wait_memory, switch the type of the
timerq link in the task control block of the current task, then insert it
into the the watch queue. Is it up to the task to extract itself from
whatever timer queue it might happen to be in before invoking one of these
Read:
==========================
ibm.other/ctask #460, from ltroxler, 442 chars, Fri Oct 25 23:20:37 1991
This is a comment to message 456.
--------------------------
Hmm. I was hoping that instead of using the floating point operators
directly, i could use a set of functions to do the operations, that are
protected against re-entrancy. But from what you're saying it sounds like
even passing and returning floats may be a problem ( and definetly,
implicit conversion would be). I see the problem. I wonder if it would work
if I could derive a special float class that overloads all the operators.
Larry
Read:
==========================
ibm.other/ctask #461, from ltroxler, 781 chars, Fri Oct 25 23:32:09 1991
This is a comment to message 458.
--------------------------
I've talked to rich a little on Compuserve, but in very general terms.
I know that there were some messages up there about his version crashing
on exit. I don't know if that was ever resolved.
I beleive I'm using the original CTask lib. Unfortunately I didn't save the
original .LIB from my download. Basically, my new and delete are:
void* operator new(size_t size ) {
if( ctask_active ) return tsk_alloc( size );
else return malloc( size );
}
operator delete( void *p ) {
if( ctask_active ) tsk_free(p);
else free(p);
}
To install and remove CTask, I use a global instance of a class where the
constructor and destructor do the jobs.
At this point, I don't really have it narrowed down much. It is possible that
it could have nothing to do with this.
Larry
Read:
==========================
ibm.other/ctask #462, from rkrampf, 342 chars, Sat Oct 26 18:14:40 1991
This is a comment to message 444.
There is/are comment(s) on this message.
--------------------------
As I later asked and have subsequently found there is
similar problem in tsksub.c - tsk_wait(). I ran into it while
waiting on a pipe(the timeout interval was not working
correctly. Can someone more knowledgable about CTask
confirm this. Applied the same fix and everything seems to
be working great. I sure am growing fond of CTask!!
Read:
==========================
ibm.other/ctask #463, from cblum, 163 chars, Sun Oct 27 13:14:57 1991
This is a comment to message 462.
There is/are comment(s) on this message.
--------------------------
Yes, those two places were missed. I generated the code mods and had them in
my code, but I missed them when I sent them to Thomas. Blame me, not him.
Chris Blum.
Read:
==========================
ibm.other/ctask #464, from mshiels, 159 chars, Sun Oct 27 14:49:33 1991
This is a comment to message 434.
--------------------------
I would love to see a list of functions available for the voice toolkit.
Do you have an address/phone number to contact to get a copy of
the toolkit? Thanx,
Read:
==========================
ibm.other/ctask #465, from rkrampf, 538 chars, Sun Oct 27 16:01:37 1991
--------------------------
I'm having a problem doing stream file i/o with CTask. I'm
opening two log files for append in one of my tasks and all
file i/o is done in that task. I get good handles to both files,
both fprintfs return ok, I do fflushes after each write which
return ok and both files are closed successfully before CTask
shuts down. Yet the first file opened doesn't get written to
and the second does. If I move the code around, same thing
happens, first file (used to be second file) no output, second
file opened - ok. I'm sure confused.
Read:
==========================
ibm.other/ctask #466, from rkrampf, 55 chars, Sun Oct 27 16:09:34 1991
This is a comment to message 463.
--------------------------
No blame intended. Just wanted to make sure. Thanks !!
Read:
==========================
ibm.other/ctask #467, from dgh, 324 chars, Sun Oct 27 16:19:13 1991
This is a comment to message 449.
--------------------------
Are you saying that you can't get an NDP, or you don't think one will worth
getting because of the floating point problems? If the latter, then you
should go ahead and get an NDP, because the FP problem has to do with the FP
emulator software. If the former, then you will have to do without floating
point.
|) /\ \/ | |)
==========================
ibm.other/ctask #469, from ron_ritchey, 182 chars, Sun Oct 27 23:36:36 1991
--------------------------
TITLE: Compile Switches for NDP
Anybody know if it makes any difference using NDP with CTASK if you use
in-line as opposed to regular function calls to the x87 library?
Ron_Ritchey
Read:
==========================
ibm.other/ctask #470, from pcquote, 450 chars, Mon Oct 28 02:05:59 1991
This is a comment to message 468.
--------------------------
What version of the ARTIC toolkit do you have? If I remember
correctly we received some sample code with our toolkit. Although, I
don't think it was very informative. I discovered alot be just
playing around with the card. BTW, I don't use the IBM supplied
drivers for OS/2 (no more DOS development with the ARTIC card here
anymore :-) ). I wrote my owun loader and interface to the realtime
kernel. I you want I can send you some sample code.
Rich
Read:
==========================
ibm.other/ctask #471, from ndws, 141 chars, Mon Oct 28 19:32:33 1991
This is a comment to message 464.
--------------------------
My Phone Number is 413-786-6658. I have a bbs that I
can put the files on for you to download. I am at that
number from 9am EST to 9PM Est.
Read:
==========================
ibm.other/ctask #472, from jmoritz, 49 chars, Tue Oct 29 08:40:37 1991
This is a comment to message 461.
--------------------------
Looks ok to me. Sorry I don't have much to add.
==========================
ibm.other/ctask #474, from jmoritz, 123 chars, Mon Nov 4 18:23:13 1991
There is/are comment(s) on this message.
--------------------------
TITLE: CTask versions
Is there more than one version of CTask 2.0 ? If so, what is the latest
version date.
Thanks.
James
Read:
==========================
ibm.other/ctask #475, from harrellfreeman, 124 chars, Tue Nov 5 16:26:26 1991
This is a comment to message 474.
--------------------------
I think the latest is 2.2b see message 308, with two fixes
see message 310 and 444. if anyone has more please post.
Harrell
==========================
ibm.other/ctask #477, from jfowler, 4673 chars, Thu Nov 21 09:43:00 1991
There is/are comment(s) on this message.
--------------------------
TITLE: Y.A.C.C.
Yet another CTask Convert...
(yes, another newbie...) I received CTask 2.2 yesterday as part of the EMS
C Utility PD/Shareware library. After printing the documentation, I decided
to join BIX to get the latest 'n greatest. Tiz been an informative morning,
to say the least. I downloaded ctupd22b.lzh (which I will unpack after I
get lha212.exe...) and captured all the messages in "ctask" since day 1.
After printing them out and browsing a bit, it seems I may have bit off more
than I've time to chew.
Heres what I am (and need to continue) using:
> Borland C++ / TASM (large model, command line protected mode compiler)
> Dos 5.0 (sometimes + EMM386.EXE)
> PC-Tools 7.1 PC-Cache
> VGA graphics & monochrome (dual monitors)
> floating point (with 386sx/387 & 486)
> hi speed serial I/O (9600 to 38.4 on mutilple ports, can use 16550s)
> Zinc User Interface Library, text (43/50 line) and graphics display
> Rogue Waves Tools.h++
> Mix C/Database Toolchest (don't laugh - this little package can do things
that I haven't found supported in any other library for Dos at ANY
price, and the manual alone is worth more than what Mix sells it for!)
> Brief 3.1 & BrieForC++ (FYI - not that it makes a difference to CTask)
> COMM-DRV from W.C.S.C. (obviously, I'll use CTasks serial I/O instead if
I use CTask...)
Hot Spots (things I'm planning on moving into first quarter 91)
> message passing between nodes of a peer-to-peer network (haven't selected
network type yet)
> Protected mode applications (or other means of getting past 640k)
> Windows 3.0 (maybe)
AND I don't have a lot of time to invest in learning curves. However, I am
(or was at one time) experienced in multi-tasking system programming (hailing
from a four year stint using QNX ('85-'89 - those were the days!)) so CTask
should not take a lot of "pardigmal adjustment". (like REALLY learning C++ !)
HOWEVER, though learning might be easy, it seems that I am doing a number of
things that CTask doesn't like (Dos 5.0, vga, floating point) and I need to
know how much heartburn these things will cause. I can live with all
floating point operations restricted to a single thread, (or use a co-proc.)
and I can also do ok WITHOUT pre-emptive switching. (other than serial I/O
interupts, but I don't think that counts as a context switch) I do need
wait opertions (on flags, serial I/O & pipe operations, etc) to work properly
in a purely cooperative system when my tasks yield. (Wouldn't think they
won't, just want some opinions from those who know...)
SO basically it all boils down to this... CTask looks like a really awesome
package. It also looks like more than I need, but that's fine IF it will
behave well as long as I don't push it. Basically, all I need is the
ability to have secondary threads handling serial I/O (I'm connecting to
Opto22 I/O boards through a RS232-485 converter and some other unheard of
devices) in the background.
I'd appreciate any feedback (if anyone is there - hasn't been much traffic
lately) from anyone who has used & abused CTask in similar situations. I'd
also like to hear about it if anyone has a robust cooperative system that
fits the bill.
|
\|ames
p.s. - If you haven't looked into the EMS shareware libraries, you might
want to take a peek - I oredered the C/C++ collection ($99.50). It came on
21 1.44 meg disks loaded with ZIP files, which adds up to about 50 MEG of
source code and utilities. Pretty good deal! If anyone wants more info,
just drop me a note or call EMS at (301)924-3594.
p.p.s. - Rogue Wave's Tools.h++ has a very interesting "shell" around the
2.0 version stream hierarchy. They provide 2.0 style support on top of
Zortech's "enhanced" 1.2 streams, allowing you to use 2.0 streams in a very
portable manner (theoretically). The other REALLY NEAT thing they do is
provide a very slick persistence mechanism which can store and retrieve
objects with a stream - AND they provide two special stream classes, one
that works with the Windows 3.0 clipboard and one that works with DDE. It
looks like you can "store" an object on a DDE stream in task A and then
reconstitute it on the other end of the DDE stream - for instance, in task B.
(I haven't tried this yet) Since source is provided, I would think that
it shouldn't be too difficult to create a stream that does the same with
CTask pipes or mailboxes, allowing you to swap essentially "live" objects
between tasks, as well as perform intertask communications via standard 2.0
stream syntax. Has anybody out there tried this? Is there anybody out
using Tools.h++ and CTask who might be interested?
Read:
==========================
ibm.other/ctask #478, from twagner, 794 chars, Thu Nov 21 12:08:51 1991
This is a comment to message 477.
--------------------------
Welcome to BIX and the wonderful world of CTask... ;-)
CTask should work with DOS 5.0. I don't think you'll normally be
affected by the strange recursive call reported here, at least one
CTask app of ours has been running well under 5.0 so far. VGA also
shouldn't be a problem, CTask doesn't do anything with video except
(optionally) serialize access to INT 10. The Zinc UI Lib might get
you into trouble, though, if you plan on doing screen-I/O from
different tasks. I wouldn't expect their stuff to be reentrant.
There have been a few messages on problems with high-speed serial I/O
using the CTask drivers. If you need several lines with 19.2 or more,
you'll probably have to rewrite at least part of the driver (for
example skip the pipes and use a shared memory block instead).
Thomas
==========================
ibm.other/ctask #479, from cblum, 449 chars, Fri Nov 22 08:33:16 1991
This is a comment to message 477.
--------------------------
I have used C-Task in the environment you are talking about... 386/387 20Mhz
controlling OPTO-22 I/O, serial comm at 38.4K baud ( with 16550A and mods to
C-Task serial code I gave to Thomas ), servo control, and real-time VGA
graphics ( ocilloscope-type! ). C-Task 387 support works fine, but I used my
own very tight code because of MASSIVE 387 use in a foreground process. Never
had problem with C-Task, just my own stupidity on occasion. Chris.
Read:
==========================
ibm.other/ctask #480, from cblum, 117 chars, Fri Nov 22 08:35:18 1991
This is a comment to message 478.
There is/are comment(s) on this message.
--------------------------
Thomas - the application I mentioned in msg #479 is running under DOS 5 with
no problems, just for your info. Chris.
Read:
==========================
ibm.other/ctask #481, from jfowler, 1448 chars, Fri Nov 22 17:20:47 1991
This is a comment to message 480.
--------------------------
Thanks for the info. I did some testing using the "spawn" utility. I
could run Breif, dos stuff, and one of my older diagnostics program that
ran serial I/O at 9600 baud from the spawned command.^[[C^[[C^[com, but as soon
as I tried to run a vanilla application I wrote using ZINC the system locked.
(well, not really... CTask kept updating stuff in the background fine! I just
couldn't break out of the ZINC-based program which was locked up quite tight)
I did some snooping and traced it down to the UI_BIOS_KEYBOARD constructor
which had some funky little assembly stuff (it all looks funcky to me...)
to determine whether or not your system supports enhanced bios calls for the
keyboard. I called Zinc tech support, and sure enough they had logged some
problem reports in that area. (although none were related to CTask) Another
zinc user uploaded a patch which they gave me and it works much better now.
I just got all this figured out a few minutes ago. There is still a problem
with the mouse (doesn't crash, just doesn't appear) but that may very well
be my fault, so I'm gonna try & fix it tommorow morning. Once I figure it
out, I'll upload the keyboard patch and anything else that helps Zinc
al^[[K/// along. They have this nasty habit of disabling interrupts because of
some problems keeping the mouse cursor and BGI graphics co-existing peacefully
which doesn't help much either. Anywayz, I gotta get home to me wife!
|
\|AMES
Read:
==========================
ibm.other/ctask #482, from jfowler, 5311 chars, Mon Nov 25 13:17:08 1991
There is/are comment(s) on this message.
--------------------------
TITLE: Zinc and CTask
(sorry, tommorrow on Friday is usually Monday)
(Warning - medium/long message follows)
Alas ...
(The following is dedicated to all who would mix Borland C++,
Ctask, and the Zinc User Interface Library)
The mouse was fine, (that bug was mine)
and so here is a simple line
or two, that fixed the keyboard err.
(I will not take the credit there)
It starts around line 84
in "keyboard.cpp", what's more
I'm not a poet anymore. (sigh)
Anyways, the following code is a replacement for the CheckEnhancedBios()
routine for the Borland version of the Zinc module "keyboard.cpp". The
original code got stuck in some kind of loop when CheckEnhancedBios()
was called with CTask running in the background. (See previous messages)
The replacement is:
// This fix submitted to Zinc by
// John T. Bell
// EdTech Associates
// 6006 Green Belt Road, #124
// Green Belt, MD 20770
//
static int CheckEnhancedBios()
{
union REGS in, out;
// This test works on the premise that al will be changed when
// int 16h function 12h is called only if an enhanced bios is present
in.x.ax = 0x12AA;
.More..
int86( 0x16, &in, &out );
if( out.h.al != 0xAA )
return 0x10;
// double check...
in.x.ax = 0x1255;
int86( 0x16, &in, &out );
if( out.h.al != 0x55 )
return 0x10;
return 0;
}
The original version follows, if anyone is interested in guessing why
it didn't work. (If anyone figures it out, let me know and I'll report
it back to Zinc! Thanx to Zinc for permission to post this code.)
static int CheckEnhancedBios()
{
asm {
.More..
movah, 5
movcx, 0FFFFH
int16H
oral, al
jnzNotEnhanced
movcx, 16
}
readLoop:
asm {
pushcx
movah, 10H
int16H
popcx
cmpax, 0FFFFH
jeEnhancedKeyboard
loopreadLoop
}
.More..
NotEnhanced:
return (0x00);
EnhancedKeyboard:
return (0x10);
}
There are still some nasty problems with Zinc, predominately in the way they
handle the mouse. They use a main "event loop" which Poll()s all devices
connected to the event handler. When a device, such as the keyboard, is
Poll()ed, it Put()s any data waiting for it into the even manager's event
queue. The mouse, however, calls Put() from within the mouse interrupt
service routine. Since the queue handling is not terribly reentrant,
they disable interrupts during event Put and Get operations.
That, however, is not the worst part. The event Get and Put are usually
quick enough to keep the system from losing data. (I'm running hi speed
serial I/O) What ruins everything is the screen output. There is a problem
.More..
(I don't know if it belongs to Zinc specifically or the Borland BGI in
general) with the mouse being active during graphic screen drawing **. Zinc
says that the standard mouse driver calls to disable the mouse cursor don't
work well with a lot of mice out there when using the BGI routines. What
happens (apparently) is that the BGI graphics primitives seem to get
confused if the mouse is moved at all (even when hidden) during a drawing
operation. This results in general random ick on the screen if you move
your mouse while the screen is painted. Zinc's solution: disable interrupts
when you need to hide the mouse. Wow, the mouse never corrupts the graphics!
Of course, I loose a character here and there when Zinc calls BGI to peform
a floodfill while I'm trying to run communications at 9600 baud. (do you
sense a little sarcasm, maybe?) For what it's worth, Zinc claims that this
problem doesn't show up using Zortech with it's Flash Graphics package.
Sure enough, the interrupt disables are #ifdef-ed to compile only with
Borland compilers. So, maybe it IS Borland's BGI - or maybe it's that
Zinc uses Zortech's mouse support package for the Zortech version and
"roll's thier own" for Borland. If anybody out there has the answer...
To top it all off, Zinc's says the new maintenance release (which was "two
weeks away" six months ago) is now shipping. They may have already fixed
.More..
some of this stuff, I'll keep you posted.
By the way, I'm looking at using Magma Software's MEWEL library
(a text-mode MS Windows SDK replacement) in conjunction with CNS's
C++/Views in an upcoming project. I saw something about somebody (Ferrari
something or other...) using MEWEL for fax related products. Am I wrong,
or is it a small world? If I'm right, is MEWEL a recommended addition
to my development library?
|
\|AMES
** - Most "event-driven-GUI" type packages (actually, any package that uses
the mouse and let's the mouse driver handle the cursor) will tell the
mouse to "hide" itself before they update the screen. Otherwise, the mouse
cursor (whether in text or graphics mode) could cause garbage on the display,
especially if the mouse is moved through an area being painted. Once the
update is done, the mouse is told it can romp freely once again. Basically,
.More..
the screen is manually treated as a "resource" which can only be used by
one task (your program or the mouse handler) at a time. Keep in
mind that the mouse driver is normally used in an "interrupt-driven" mode,
which makes it kind of like another task in the background that only
runs when the mouse does something. (Anyone who has ever had a graphics
program terminate without resetting the mouse interrupt vector knows exactly
what I'm talking about...)
Read:
==========================
ibm.other/ctask #483, from twagner, 750 chars, Mon Nov 25 15:15:44 1991
This is a comment to message 482.
There is/are comment(s) on this message.
--------------------------
Thanks for posting that fix. If I have some time (next year, maybe,
or next century...) I'll try to find out why it doesn't work with
CTask.
On MEWEL: It is a small world. Yes, it's my company using MEWEL for a
Fax program, and yes, I'd say MEWEL is recommended if you're into
both Windows and DOS. We're not using CTask in conjunction with
MEWEL, though. Our app is just a straight 1:1 recompile from the
Windows version, so we don't have any multitasking needs. MEWEL is a
bit weak on the graphics side, just like Zinc it relies on the
compiler RTL to output graphics - and that's slooooooow and not that
compatible to Windows. But in text mode, it runs just fine. Check out
the MAGMA conference, or send BIXmail to magma, for more info.
Thomas
.More..
Read:
==========================
ibm.other/ctask #484, from jfowler, 1237 chars, Mon Nov 25 16:54:25 1991
This is a comment to message 483.
--------------------------
I'm glad to hear it (that you recommend MEWEL)! I've been talking
with magma about using CNS - they seem to be good folk. As far as
MEWEL, I was planning on using it for text-only versions of Windows 3.0
based (actually, CNS C++/Views based) apps. I'm under the impression
that the graphics mode of MEWEL just draws the standard extended character
set characters up on the screen, so it looks like text mode except it is
slower and allows you to do your own graphics stuff. Have you seen
PC-Tools 7.1? They did some slick sleight of hand, using "text mode" but
redefining the extended character set to look more like "Windows" stuff.
They even provide a psuedo-graphial mouse cursor by using a few of the
ext. chars to "merge" the mouse arrow with the characters that would be
underneath. Pretty neat trick. Anyways....
BORLAND C++ 3.Oh No...
Would any of the CTask users out there who are using Borland happen to
.More..
be Borland beta-testers with an idea of what 3.0 does (or doesn't) do
ˇ˚
with CTask??? Double compilation speed, 2.1 compliance, and optimization
seem like desirable stuff (even for $125) but it doesn't do much for me
if it doesn't work with what I've gotta work with (CTask, Zinc, etc.).
|
\|AMES
==========================
ibm.other/ctask #485, from sworthington, 127 chars, Thu Nov 28 15:08:51 1991
--------------------------
TITLE: DOS Extenders
Has anybody done anything using a DOS extender and CTask? We
keep running out of heap...
Andrew Merton.
==========================
ibm.other/ctask #486, from jfowler, 555 chars, Thu Dec 5 10:03:51 1991
--------------------------
TITLE: HELLOOOOOOOO..............
I guess some of us aren't lucky enough to take a vacation.... Anybody home
out there? Current unanswered questions :
Borland C++ 3.0 - does it work with CTask?
Dos Extenders - any of them "" ""?
What's the current status of CTask under Windows 3.0?
Also, has anybody got a good C++ class wrapper around 2.2b? I've tried
an older port and it didn't do so well. I'm looking for a C++ shell
that calls the CTask functions, as opposed to actually moving all the functions
into C++ object methods.
|
\|AMES
==========================
ibm.other/ctask #487, from ron_ritchey, 110 chars, Thu Dec 5 20:56:02 1991
--------------------------
TITLE: 2.2B?
Does anybody know what the differences/improvements between CTASK 2.2 and 2.2b
are?
Ron_Ritchey
==========================
ibm.other/ctask #488, from cblum, 475 chars, Fri Dec 6 22:31:12 1991
--------------------------
TITLE: CTask Serial I/O support
Thomas - I just received my December issue of The C User's Journal... What a
prize! a PC UART device driver with *full* docs on the NS16550A UART and code
to match. If you are not in a real big hurry, I will be glad to blend in a few
of the niceties ( that my sleazy 16550 support should have had, but I tried
with no doc and got it to 'work' ). I can do it over the next few weeks, I
think. Interested? Go for it? Ignore it? Chris ( cblum ).
==========================
ibm.other/ctask #489, from ron_ritchey, 454 chars, Sun Dec 8 14:47:51 1991
--------------------------
TITLE: Dos Critical Error Handler
Can anybody point me in the right direction for some help in coding a
Dos Critical Error Handler for CTASK. I have a CTASK program that runs
round the clock. Unfortunately, if I get a hard disk error DOS comes up
with its Abort,Fail, Retry message and the program locks up until someone
notices and hits the retry option. I need to replace the routine with
one of my own. Any help greatly appreciated.
Ron_Ritchey
==========================
ibm.other/ctask #490, from bernardo, 131 chars, Mon Dec 9 12:53:43 1991
This is a comment to message 489.
There is/are comment(s) on this message.
--------------------------
[From ron_ritchey #489]
You can try replacing the interrupt vector for the interrupt 24h, the
critical error interrupt.
Bernardo.
Read:
==========================
ibm.other/ctask #491, from ron_ritchey, 38 chars, Mon Dec 9 19:51:24 1991
This is a comment to message 490.
--------------------------
Could you elaborate a little on that?
==========================
ibm.other/ctask #492, from twagner, 515 chars, Tue Dec 10 15:06:37 1991
This is a comment to message 488.
--------------------------
Well, if you have the time, go for it! Regrettably, I haven't had
the time to do much with the stuff you and others have mailed me. I'm
back to the University to finally finish my CS degree, so together
with my usual workload and the 1-2 hours of daily BIXing I'm running
at about 180% of my capacity. :-(
So if you finish something, please post it in listings rather than
sending it to me. I promise to go back to work on CTask, but it
probably won't be before the end of the semester (March/April '92).
Thomas
============
Mensaje from 'compuservice' (493)
The following code do the job :
int hardhandler (int errval, int ax, int, int) {
if(ax<0)
tsk_rprintf ("\r\nDEVICE ERROR #%d\r\n", errval);
else
tsk_rprintf ("\r\nDISK ERROR #%d in drive %c\n",errval, 'A'+ (ax & 0xFF));
return(RETRY);
}
main () {
...
harderr(hardhandler);
...
}
Good Luck!
-------------------------------------------------------
==========================
ibm.other/ctask #494, from dgh, 175 chars, Thu Dec 12 19:28:02 1991
This is a comment to message 493.
--------------------------
You might also want to use dosexterr() to get the DOS extended error
information and return FAIL for some operations, such as "Network device no
longer exists."
|) /\ \/ | |)
Read:
==========================
ibm.other/ctask #495, from cblum, 345 chars, Sat Dec 14 09:25:53 1991
This is a comment to message 492.
--------------------------
Thomas - When you reach 200%, you should slow down... that is approaching the
load rating on the motor ( heart? ). I wish you well in your scholastic
endeavors... I have not had the ambition to do the same, so am a little
envious of your determination. I shall do as you ask, and again, thanks for a
great effort in a beautiful package. Chris.
==========================
ibm.other/ctask #496, from markewilson, 1226 chars, Tue Dec 31 21:06:25 1991
--------------------------
TITLE: Cant DOWNLOAD
I recently added an Intel 9600EX modem to my Austin 486-33 EISA computer
and have the strange problem that I can't download software. I can
interact just fine with the BBS, sending and receiving at 9600, but when
I try to download a program, the system hangs for about 30 seconds, then
gives me the message "Transfer failed (INIT)". What's so special about
downloading that is so different than just real time interaction?
I've tried switching com ports, tried switching phone lines I get the
same problem with both my phone lines), tried switching modems, even tried
switching to another brand of modem. I've tried slower baud rates and I've
tried different transfer protocols. All without success. What gives?
I haven't tried switching computers because it's not so easy, only having
the one. I've also tried several different software packages. Generally,
I use PMcomm running under OS/2 2.0 beta 6.149. But I get the same problem
when I boot up read DOS 5.0 and use either the Windows communication program
or the Crosstalk program "Communications" that came with my modem.
I would be appreciative for any suggestions anyone can offer.
Thanks.
Mark Wilson (Markewilson) Boulder, Colorado
==========================
ibm.other/ctask #497, from jmoritz, 1752 chars, Mon Jan 27 21:22:22 1992
This is a comment to message 486.
There is/are comment(s) on this message.
--------------------------
Hi, James! You still reading this forum, or have you put ctask on the back
burner? I read this board about once every 2 months, it's so slow. I don't
really quite qualify as as a ctasker anymore, since I am presently finishing
up a port of 2.0 to C++ and am taking a few liberties with the design. I, too,
come from using QNX and am currently working in DOS with BC++ 3.0. I'm doing
the conversion because:
1. I hate C after using C++.
2. I need a multitasker for my embedded system.
3. It is easier to merge my existing C++ with a full port.
4. C++ improves the code and makes a lot of things much
more straightforward to implement and understand.
5. Porting the software is also a way of learning how it works.
6. I hate C after using C++.
On the subject of QNX: I am changing the message passing scheme to be more
QNX-like. Ctask 2.0 message passing is really not inter-task. The mailbox
event is still useful for interrupt message passing, which I currently have
no use for. Of course, comparing ctask and qnx message passing is kind of like
comparing apples and oranges, since ctask is a single executable (groups aside)
and intertask communication takes place at the data structure level. I like
qnx, and am adopting the server/message-passing scheme for my main project
(eg. I use a server task for controlling the serial ports on my [non-DOS]
system).
I got most of the way with pipes, but have been ignoring them for a while. I
don't see much advantage in using them over messages. Since I use server
tasks for i/o, I don't need them there. What do other people use them for?
Should I keep them?
Are there improvements to 2.0 in 2.2 that I must have? What's happening out
there?? Talk to me and I will talk to you!
James.
Read:
==========================
ibm.other/ctask #498, from ltroxler, 227 chars, Mon Jan 27 22:42:04 1992
This is a comment to message 497.
There are additional comments to message 497.
--------------------------
Out of curiosity, what's QNX? I've seen adds, but I don't remember
much about it.
If you have a non-DOS system, you could probably get rid of most of the
ctask slugihness that results from cooperating with DOS.
Larry
Read:
==========================
ibm.other/ctask #499, from twagner, 371 chars, Tue Jan 28 11:17:02 1992
This is a comment to message 497.
There is/are comment(s) on this message.
--------------------------
> I am changing the message passing scheme to be more QNX-like
Sounds interesting - what is QNX's message passing scheme like? I've
heard of QNX, but I never actually used it.
> Are there improvements to 2.0 in 2.2 that I must have?
A number of bug fixes (as usual), and some enhancements, mainly
DOS-related. I can mail you the list of changes if you'd like.
Thomas
Read:
==========================
ibm.other/ctask #500, from jmoritz, 1949 chars, Sun Feb 2 22:00:27 1992
This is a comment to message 499.
--------------------------
Thanks. About QNX: it was developed in Waterloo, Ontario, Canada as a
multitasking alternative to DOS, for use in realtime applications. There are
both real and protected mode versions. I'm told that it has been installed at
thousands of locations worldwide. It is aimed at the UNIX market (hence the
name) and has a similar command shell, but is much leaner. Version 4.0 is
Posix-compliant and touted as a true UNIX, but I suspect that its success will
depend more on new recruits than converts from QNX 3.x, for which support
continues. I will refer to 3.x.
QNX is a peer-to-peer network OS built on top of ARCNET. Messages are
network-transparent.
QNX messages are unstructured strings of up to 64K bytes that the OS copies from
the sender task's data space to that of the receiver, at locations designated
by the tasks concerned. When a message is sent, the sending task's operation is
suspended until the receiver sends a reply to it. Conversely, a message can
be requested from another task, in which case the requester will be suspended
until such message is sent to it (same protocol as any other send).
Replies don't produce suspensions. It is up to the tasks themselves to interpret
message structure.
Two administrator-level tasks provide additional support. One manages message
queues, while the other provides a network-wide task naming registry.
The latter permits tasks to locate each other by name for the purpose of
message communication.
To implement a similar scheme in ctask, I've placed send and receive task
queues in my task class to allow tasks to be send or receive suspended.
I've also added a message pointer for sending and receiving messages. To
process an incoming message, for instance, a task would look at the message
pointed to in the task object at the front of the send queue, reviving the
task at its leisure (this might depend on whether the message was a
giveaway/heap object or not).
James.
Read:
==========================
ibm.other/ctask #501, from r.beerman, 1496 chars, Mon Feb 10 01:07:41 1992
--------------------------
TITLE: Wanted:
Hello, all..
I am currently developing and coding software for the IBM, and could
definetly use the Ctask library and functions in my code. Unfortunately,
the deadline is coming close, and I have to spend time creating a script-
type language for use with this project.
In other words, I don't have time to hack with Ctask to install it, and I
don't have the time (or resources) to create my own Ctask.
This is what I need:
1) A sample application of Ctask (written for the HUGE memory module),
containing, let's say, 2 tasks that count upwards and downwards (at
different screen locations, etc..)
2) A text describing how to make IDENTICAL tasks run at the same time..
(for example, let's say that I wanted a {printf("hello\n");} routine
run 10 times simultaneously.
3) In the #1 (above) sample program, serial routines demonstrated.
(should be able to support >38.4k, if possible. I can work with that)
4) A "plug and play" "ctask.lib" (whatever) ready to plug and play into
my HUGE MEMORY MODULE code.
I will be very interested in someone supplying me with these, and will
pay $$. for something that would be very simple for someone who's already
experienced with CTASK.
Please leave Email to R.Beerman, BIX. (Or 71740,2134 Compuserve, R.Beerman
GEnie).. Quick responses would be very appreciated and very helpful. Please
leave E-Mail, instead responding to this message in this section.
Thank you very much!
-> Richard C. Beerman, Jr.
.\
Read:
==========================
ibm.other/ctask #502, from lperry, 707 chars, Thu Feb 13 14:03:02 1992
There is/are comment(s) on this message.
--------------------------
TITLE: Possible Bug
Has anyone noticed a problem with the "tsk_sprintf" family of routines. It seem
s that they do not put a null at the en
d of the target string, wreaking havoc when they are printed, etc. Also, we not
iced a problem in tskdos.asm. This b^[^[
appeared when trying to return to dos. The problem is in the code after the labe
l is_dos3. The INT 21H call clobbers th
e si register. This register is used in a c routine which calls this function. S
pecifically, it holds the flags paramte
^[^[which appears in the install_tasker call. What happens is that the INSTALL B
IOS flag is lost after the call to tsk_in
stall_dos. Therefore, the flags that are
suppose to be define in that routine are not.
Read:
==========================
ibm.other/ctask #503, from twagner, 454 chars, Thu Feb 13 17:43:30 1992
This is a comment to message 502.
--------------------------
Those are known bugs - they were fixed in version 2.2b. Please
download CTUPD22B.LZH from IBM.PC/LISTINGS to get the most recent
version (it's an update with just the changed files for 2.2 -> 2.2b).
Sorry - I realize that I still haven't uploaded the complete 2.2b
release, so new downloaders can easily miss the update. I promise
I'll finally fix that this weekend. But if you already downloaded
2.2, you'll be better off with just the update.
Thomas
Read:
==========================
ibm.other/ctask #505, from fjackson, 420 chars, Mon Feb 17 06:51:33 1992
There is/are comment(s) on this message.
--------------------------
1. Serendipity! Borland C++ 3.0 debugger appears NOT to crash debugging
CTask code the way all previous Turbo Debuggers and Codeviews have!
2. I need dword pipes, in order to pass long pointers. I cannot use
buffers for my pusposes because they do not work the same way priority-
wise, due to using the resource mechanism. Can you put this on the
list? I have had terrible luck trying to code this addition myself.
Read:
==========================
ibm.other/ctask #506, from twagner, 432 chars, Mon Feb 17 18:46:20 1992
This is a comment to message 505.
--------------------------
> Dword pipes
It should be relatively simple to modify word pipes to dword pipes.
You'd just have to change the division of the pipe buffer size by two
(>> 1) in the creation to a division by four (>> 2), change the
typecasts where necessary, and change the "wordptr wcontents" to a
"dwordptr dcontents" in the wpipe structure to create a dpipe struct.
If you can wait until Wednesday, I'll mail you a modified TSKWPIP.C.
Thomas
==========================
ibm.other/ctask #507, from twagner, 368 chars, Wed Feb 19 16:56:13 1992
--------------------------
TITLE: Ctask 2.2b finally in listings
CTASK22B.LZH is now installed in IBM.PC/LISTINGS. The old 2.2 files were
removed, but I'll leave CTUPD22B.LZH there for a while for those who already
downloaded 2.2 but missed the update to 2.2b.
If you previously downloaded 2.2 plus the update, don't download the new
file. There's nothing in it you don't already have.
Thomas
Read:
==========================
ibm.other/ctask #508, from sworthington, 393 chars, Thu Feb 20 15:57:19 1992
--------------------------
TITLE: Title: Bug in flush_?pipe.
CTask V2.2 (I do not have V2.2b) has a problem with the flush pipe
routines. It does not make tasks waiting to write to the pipe runable
when the pipe is flushed. In tskpip.c, add the line:
tsk_runable_all (&pip->wait_write);
just before the line:
tsk_runable_all (&pip->wait_clear);
and also the equivalent change in tskwpip.c.
Stephen Worthington
Read:
==========================
ibm.other/ctask #509, from sworthington, 1672 chars, Thu Feb 20 17:59:32 1992
--------------------------
TITLE: Title: CTask V2.2b differences from my version
We just downloaded the ctupd22b.lzh today, and I found some
differences between this and my version, apart from the flush_?pipe
problem previously mentioned:
1) In tsk_wait() in tsksub.c and in t_delay in tskutil.c, I have
tsk_timeout() around the last parameter. Is this correct? I do not
use the millisecond timing option, so I have probably never tested
this.
2) I do not have #include <dos.h> in my <tsk.h>, since it is only
required in a few CTask files. To reduce compile times, I only
#include it in those files.
3) In tskprf.asm, I have a number of changes:
a) Instead of using sti & cli for interrupt disable & reenable,
I use pushf/sti & popf. This makes the routines fully
re-entrant, even from within interrupt routines, permitting the
use of formatted print output from within hotkey routines. I
have then developed hotkey display routines to display snapshots
and other program data on an alternate display page. This is a
great debugging tool! I also have a routine that prints to the
printer instead of the screen.
b) I have also made the routines fully compatible with their
Turbo-C library equivalent's return values. This enables me to
do away with Turbo-C's routines and link only the CTask ones. I
use .RTLink/Plus commands to simply make the Turbo-C names
synonyms for the CTask versions.
Most of this work in 3) was done in a version of CTask that was
modified by another programmer, so I do not have a real V2.2b version
of that I could upload, but if anyone is interested, I could give you
what I have got.
Stephen Worthington
==========================
ibm.other/ctask #510, from rkrampf, 63 chars, Sun Feb 23 10:29:19 1992
This is a comment to message 509.
--------------------------
Hi. saw your msg and would like to get a copy of your changes.
Read:
==========================
ibm.other/ctask #511, from sworthington, 526 chars, Wed Feb 26 18:19:08 1992
There is/are comment(s) on this message.
--------------------------
TITLE: Hotkey debugging routines
I have uploaded my modified files for hotkey debugging routines as
CTHOTDBG.ZIP. The file HOTDBG.C is an example of how to use them.
Remember that they come from a modified CTask 2.2 (eg
install_tasker() does not have the same number of parameters), so you
will need to compare them with real CTask 2.2 to check for
differences.
I am leaving my present employer as of Friday and will not have
access to Bix, so I will have to leave you to fix any problems
yourselves.
Stephen Worthington
Read:
==========================
ibm.other/ctask #512, from twagner, 234 chars, Thu Feb 27 11:33:46 1992
This is a comment to message 511.
There is/are comment(s) on this message.
--------------------------
WHAT?? You're leaving us? Oh my - who's going to fix all the bugs in
the future? :-(
Your contributions have helped a lot in the development of CTask, and
I'd really miss your input. Will there be any other way to reach you?
Thomas
Read:
==========================
ibm.other/ctask #513, from sworthington, 158 chars, Thu Feb 27 17:17:30 1992
This is a comment to message 512.
--------------------------
Andrew here (Stephen's out at the moment)
There's no problem passing messages on to Stephen; he'll still be in
the same city, so I just have to ring him...
==========================
ibm.other/ctask #514, from pcquote, 58 chars, Sat Feb 29 00:21:52 1992
--------------------------
FWIW, Ctask now works under OS/2 2.0 (6.304e beta).
Rich
Read:
==========================
ibm.other/ctask #515, from pcquote, 58 chars, Sun Mar 1 03:10:35 1992
There is/are comment(s) on this message.
--------------------------
FWIW, Ctask now works under OS/2 2.0 (6.304e beta).
Rich
Read:
==========================
ibm.other/ctask #516, from ron_ritchey, 114 chars, Wed Mar 4 23:51:48 1992
This is a comment to message 515.
There is/are comment(s) on this message.
--------------------------
I know this is probably a stupid question, but doesn't OS/2 support
multitasking as part of the operating system.
Read:
==========================
ibm.other/ctask #517, from dave2, 91 chars, Thu Mar 5 01:05:41 1992
This is a comment to message 516.
There are additional comments to message 516.
--------------------------
OS/2's multitasking features are not accessible to programs running
in DOS windows. Yet.
Read:
==========================
ibm.other/ctask #518, from pcquote, 447 chars, Thu Mar 5 08:37:35 1992
This is a comment to message 516.
--------------------------
Yes, OS/2 does support multitasking. And, OS/2 programs themselves
can start multiple threads, which are the same as tasks under Ctask.
My point was that Ctask now runs in the DOS sessions of the current
beta of OS/2 2.0. The 2.0 version will be IMHO an unbeatable development
environment. The fact that Ctask will run in the DOS sessions shows
that DOS compatibility is very high! FWIW, I never could get Windows
3.0 to run Ctask reliably.
Rich
Read:
==========================
ibm.other/ctask #519, from llammert, 761 chars, Wed Mar 11 16:39:34 1992
There is/are comment(s) on this message.
--------------------------
Question - I just finished converting to CTASK2.2b (Thanks for the
help, Thomas -- I just now am getting TP up and running <g>), and
there seems to be a strange quirk in the read_key/wait_key:
2.0 returned an ASCII of 0 for gray arrow keys;
2.2b returns an ASCII of 224 for gray arrow keys.
My application is just using the arrow keys right now, but I was
wondering if this was an intentional change? If so, what was the
reason. I did a quick compare of the code, and didn't spot anything
obvious.
Should I tweak my own key handlers??
Lee Lammert
BTW - Thanks again Thomas, for getting us shipped a couple of weeks
ago. We never did get COM3 working, but we ended up using an external
COMM library, and it worked just fine.
Read:
==========================
ibm.other/ctask #520, from twagner, 439 chars, Wed Mar 11 17:11:03 1992
This is a comment to message 519.
--------------------------
Yes, the change is intentional. The wait_key/get_key code was changed
in version 2.1 to use the extended keyboard BIOS functions. Those
functions allow you to differentiate between the gray and standard
cursor keys. All "new" keys on the 101/102-key keyboards that
duplicate functions on the old XT one (the gray keys) have E0 instead
of 00 in the lower byte (there is no normal key that would ever
generate an ASCII code of E0).
Thomas
==========================
ibm.other/ctask #521, from llammert, 249 chars, Thu Mar 12 11:12:16 1992
This is a comment to message 520.
There is/are comment(s) on this message.
There are additional comments to message 520.
--------------------------
Thomas,
One can generate an ASCII code of E0 (using the ALT keys), but if
your modification uses the standard BIOS calls then I guess we have
entered the world of standard BIOS <g>.
Thanks for the quick reply.
Lee
Read:
==========================
ibm.other/ctask #523, from twagner, 269 chars, Thu Mar 12 15:52:07 1992
This is a comment to message 521.
--------------------------
Sure, you can enter E0 using ALT, but then the scancode (the upper
byte) will be 00. So you can still distinguish between ASCII E0 and
the extended keys. The calls indeed use the standard BIOS calls, I
just switched from using AL=00/01 to AL=10/11 with INT 16.
Thomas
Read:
==========================
ibm.other/ctask #524, from jlo, 257 chars, Sat Mar 14 16:25:55 1992
--------------------------
I have main() waiting on t_read_key(). Another task calls wake_task(NULL).
Back in main, t_read_key returns TIMEOUT. Did I [1] forget to apply a
fix, [2] mess up the kernal with my modifications, [3] misread CTASK.DOC,
or [4] none of the above?
James Lo
------------------------------Nuestro mensaje # 525
We are trying to run CTask with IBM's FBSS under DOS 4.0. It works fine until
we open some devices (like PIN PAD), then it dies. It also inhibit the switch
session hot key of FBSS that allow switching between DOS and a HOst session.
Any hints ? Any experience ? Any flags to change in the install_tasker call ?
Any experience with CTask and DOS 4.0 ? [FBSS runs *ONLY* under 4.0, neither
3.0 nor 5.0 ;-( ]
Thanks in advance
==========================
ibm.other/ctask #526, from jlo, 338 chars, Mon Apr 13 22:48:55 1992
--------------------------
What systems, if any, are people using with CTASK under ROMable code
configuration? I've just started modifying some of the microcontroller
hardware from work for one of my projects, but if a SBC is reasonably
cheap, I'd rather go that route. Also, does one need a special assembler,
or are there obj-to-hexfile converters?
James Lo
=============================
Mensaje #527 nuestro
releasing task's memory
Writing BBS software we have problems releasing a task's memory when the
task have to be killed by another task (usually a watchdog task that checks
the CD signal from the modems).
Here is our solution, it seems to work but we would like to listen
opinions, we are probably making big mistakes...
FILE: tsk_alloc.c
------------------------------------------------------------------------------
#define MALLOC_REPLACED TRUE
void *malloc (size_t size)
{
void *area;
if (ctask_active) {
request_cresource (&alloc_resource, 0L);
size += sizeof (void *);
}
area = xalloc (size);
if (ctask_active) {
*((void **)area) = (void *) curr_task ();
area = (void *) (((char *)area)+sizeof (void *));
release_resource (&alloc_resource);
}
return area;
}
int tsk_heapfree (tcbptr tcbp) {
int rc;
tcbptr ptr;
struct heapinfo hi;
request_cresource (&alloc_resource, 0L);
if ((rc=heapcheck ()) == _HEAPOK) {
for (hi.ptr = NULL; (rc=heapwalk (&hi)) == _HEAPOK; ) {
ptr = (tcbptr) (*(void **)hi.ptr);
if (hi.in_use && ptr != LNULL &&
ptr->cqueue.kind == TYP_TCB && ptr == tcbp)
{
free ((void *) hi.ptr);
/* need to start again, otherwise the heap get corrupted */
hi.ptr = NULL;
}
}
}
release_resource (&alloc_resource);
return rc;
}
long tsk_heapused (tcbptr tcbp) {
long bytes;
tcbptr ptr;
struct heapinfo hi;
request_cresource (&alloc_resource, 0L);
for (bytes = 0L, hi.ptr = NULL; heapwalk (&hi) == _HEAPOK; ) {
ptr = (tcbptr) (*(void **)hi.ptr);
if (hi.in_use && ptr != LNULL && ptr->cqueue.kind == TYP_TCB && ptr == tcbp)
bytes += hi.size;
}
release_resource (&alloc_resource);
return bytes;
}
------------------------------------------------------------------------------
Thanks in advance
==========================
ibm.other/ctask #528, from gworthey, 870 chars, Wed May 6 07:07:14 1992
There is/are comment(s) on this message.
--------------------------
TITLE: Spawn to Dos Question...
(pardon any typos, my backspace key doesn't work on BIX?!!!?)
I'm writing a multi-line bbs that spawns to dos. I'd like it to display a load
average even when spawened to dos. It
works fine when not spawn-- I just run a low proiotrity task that counts 1 time
per tick (and divide that by total tick
s passed)...
But apparently, when I spawn to dos, the dos command line is always elibgible to
run, so the lower priority tasks NEVER
run until I exit dos.
Its there a way that I can get rid of this busy-waiting loop in dos? And is the
re a better way to compute the load ave
rage?
Thanks in advance. You've written a very professional and well-documented apack
age. Keep up the GREAT work!!
One other question... Can you give me some hints on swapping the local data str
ucture to EMS for each line? I've neve
r used EMS.
Greg
Read:
==========================
ibm.other/ctask #529, from karenk, 179 chars, Wed May 6 23:02:15 1992
This is a comment to message 528.
--------------------------
> backspace key doesn't work on BIX
You might try pressing <ctrl><h>. BIX needs a true backspace (^h or 08h).
Most terminal's DELete keys and left arrow keys won't work.
Karen
==========================
ibm.other/ctask #530, from gworthey, 512 chars, Fri May 8 04:23:52 1992
There is/are comment(s) on this message.
--------------------------
TITLE: More on Dos Spawning
I've been plauing more with spawning to dos. It is properly intercepting the
int16 (outside dos) but for some reason, when I spawn dos, only processes
of equal or greater priority can run.
Does dos use something other than int16 for getting kb input? Is there
something I'm missing? Surely you don't have to wait for an entire tick
to pass before dos will give up its time slice??
What I'm trying to do is print a short status message on the screen while
dos is spawned.
Greg
Read:
==========================
ibm.other/ctask #531, from jlo, 301 chars, Sat May 9 10:46:18 1992
This is a comment to message 530.
--------------------------
I'm not sure this is relevant, but I've noticed that when one spawns to
DOS, the session inherits the priority of the task which spawned it.
That means if you do this from main () without altering main's default
high priority, the DOS session will take priority over lower priority
tasks.
James Lo
==========================
ibm.other/ctask #532, from gworthey, 230 chars, Tue May 12 04:08:01 1992
There is/are comment(s) on this message.
--------------------------
TITLE: that's true...
What I'm wondering, though... is why can't other processes of lower priority
run when dos is idle (sitting at prompt). Int16 is captured, so shouldn't
it release its time slice if there is no input??
Greg
Read:
==========================
ibm.other/ctask #533, from jlo, 241 chars, Wed May 13 00:02:20 1992
This is a comment to message 532.
There is/are comment(s) on this message.
--------------------------
TITLE: y'know, that's a really good point.
I had the same problem with a TSR I had written to do music processing
in the background. Could COMMAND.COM be re-initializing INT16?
I think Thomas must be taking finals right now. ;)
James Lo
Read:
==========================
ibm.other/ctask #534, from twagner, 713 chars, Wed May 13 18:12:31 1992
This is a comment to message 533.
There is/are comment(s) on this message.
There are additional comments to message 533.
--------------------------
I've read the messages - I just hoped someone else would have a more
intelligent answer than "well, I don't know" ;-)
From what you're reporting, it seems likely that DOS/COMMAND.COM
bypasses the blocking CTask INT 16 read. I've not yet traced through
it, but there are two possibilities: One would be that DOS chains
into INT 16 for some reason, and directly calls the original
interrupt vector instead of invoking the INT. This is not too likely,
though, since this would also bypass hooks like KEYBGR, which
obviously isn't the case. The other: DOS uses a polling loop on the
keyboard status, and only calls the keyboard read entry when a
character is available. If I only had the time to find out...
Thomas
.More..
Read:
==========================
ibm.other/ctask #535, from twagner, 713 chars, Thu May 14 14:37:16 1992
This is a comment to message 533.
--------------------------
I've read the messages - I just hoped someone else would have a more
intelligent answer than "well, I don't know" ;-)
From what you're reporting, it seems likely that DOS/COMMAND.COM
bypasses the blocking CTask INT 16 read. I've not yet traced through
it, but there are two possibilities: One would be that DOS chains
into INT 16 for some reason, and directly calls the original
interrupt vector instead of invoking the INT. This is not too likely,
though, since this would also bypass hooks like KEYBGR, which
obviously isn't the case. The other: DOS uses a polling loop on the
keyboard status, and only calls the keyboard read entry when a
character is available. If I only had the time to find out...
Thomas
Read:
==========================
ibm.other/ctask #536, from dgh, 166 chars, Fri May 15 04:35:14 1992
This is a comment to message 534.
--------------------------
DOS does indeed poll the keyboard (using INT 16h, AH=1). If a character is
available, it reads it (using INT 16h, AH=0), otherwise it does an INT 28h.
|) /\ \/ | |)
==========================
ibm.other/ctask #537, from marco.m, 314 chars, Sun May 17 13:43:48 1992
This is a comment to message 528.
--------------------------
How you can spawn to dos on a multiline system ? As I know, by experimenting
it on a similar project (months ago I've developed a multiline BBS system
but I've dropped the project due to the dos spawn problems) you can load
only one DOS program per task, beacuse it takes all the available memory for
itself.
Bye
==========================
ibm.other/ctask #538, from nicotra, 331 chars, Fri May 22 13:27:46 1992
--------------------------
TITLE: Fixup Errors
I tried recompiling ctask with Borland 3.0 and relinking
the test program and I get "Fixup overflow target=_TSK_JMPTAB
in library file ctasktc.lib module TSKINST." I'm working in
large model and have not changed anything in the make files
except to use tlib instead of lib. I'm curently using 2.2b.
Any clues?
Read:
==========================
ibm.other/ctask #539, from gworthey, 459 chars, Sat May 23 07:30:39 1992
There is/are comment(s) on this message.
--------------------------
TITLE: Recompile problem...
I had the same problem... check the tskconf.h file and make sure all the
defines are at the default values... I had the same problem comiling the
program as d/led from here. I guess Thomas forgot to reset the options
to their defaults before u/ling them (The files will NOT compile as u/led on
Turbo C anyway...)
Hope that helps...
Sure would like a solution to that dos keyboard-polling problem... Got any
time Thomas?
Greg
Read:
==========================
ibm.other/ctask #540, from twagner, 1934 chars, Sun May 24 13:26:06 1992
This is a comment to message 539.
--------------------------
> I guess Thomas forgot to reset the options to their defaults before u/ling
I did WHAT?? Goodness, the CODE_SHARING flag is set to TRUE, it
should be FALSE by default! Sorry for that glitch. I'll try to
be more careful next time.
About that keyboard polling - I think it was MP/M (the Z80 multiuser
CP/M) that had a trick to circumvent this problem: They counted the
number of times a task polled the keyboard per time slice, and if the
count reached a certain threshold, they put the task to sleep. The
gotcha is that you might lock out programs that poll the keyboard in
a relatively tight loop but still do something useful while waiting.
One not so drastic measure you might try yourself would be to insert
a call to "yield" in the CTask keyboard interrupt handler. Do this
call whenever someone polls the keyboard and no key is available. The
"yield" should make sure that the other tasks get their share of time
while not penalizing the polling task too much. It should look like
this: After @kbdentry, insert 4 lines after the test for AH=0:
or ah,ah
jz kbd_read
> cmp ah,1 << insert
> je kbd_poll
> cmp ah,11h
> je kbd_poll
and before the label kbd_keyhit, insert
kbd_poll:
cli
call cs:savkbd ; flags already on stack
jnz kbd_pollend ; exit if char available
callp tsk_switch_stack ; yielding does kill some regs
mov ax,entry_flags[bp] ; so we restore the right flags
mov caller_flags[bp],ax
callp yield ; give up this time slice
kbd_pollend:
ret 2
I didn't try this out myself, so please let me know if it helps. In
any case, the priority of the task that spawns a DOS program should
be reduced to PRI_STD or less! Since spawned programs usually aren't
CTask-aware, they might kill performance if they do busy waiting with
a high priority.
Thomas
Read:
==========================
ibm.other/ctask #541, from gworthey, 645 chars, Tue May 26 06:13:06 1992
--------------------------
TITLE: Ok, Thomas, I tried it out...
and... it didn't work (argh).
Specifically, it crashed, hard.
I don't know much about the internals of the tskkbd.asm file,but I did
experiment a little.
* Shouldn't interrupts be re-enabled in kbd_poll? (I tried that- no change)
* Should yield be called with call or callp?
* You need to place kbd_poll code ABOVE the @kbdentry code (else the jz kbd_read
is too far to compile)
* Need to declare yield using Globext yield at top of file to assemble.
* Should we be using "ret 2" to return from kbd_poll?
I hope you can figure this out!
(also, is bp "defined" before use in kbd_poll?
Thanks...
Greg
==========================
ibm.other/ctask #542, from twagner, 1622 chars, Wed May 27 13:16:16 1992
This is a comment to message 541.
--------------------------
Hmmm... it worked for me - probably moving the code up out of the
proc caused the 'ret' to be assembled into a *near* return, which
would explain the crash. Anyway, I re-checked, and the 'yield'
routine uses very little stack space and registers, so it likely is
not necessary to switch the stack. My code now looks like:
- At the top of the file, near the other externals, insert
Globext yield
- After the @kbdentry proc, replace
or ah,ah
jz kbd_read
with
or ah,ah
jnz kbdent1
jmp kbd_read
kbdent1:
cmp ah,1
je kbd_poll
cmp ah,11h
je kbd_poll
- Before *kbd_read*, insert
kbd_poll:
cli
call cs:savkbd
jnz kbd_poll_end
push ax
push bx
push ds
push es
mov ax,@CTASK_DATA
mov ds,ax
callp yield
pop es
pop ds
pop bx
pop ax
cmp ax,ax
kbd_poll_end:
retf 2
--------------------------------------
On your other questions:
- Interrupts will be enabled anyway on return from the original int handler.
- There's no difference between call and callp for parameterless functions.
- Yes, you must return with ret 2 (or, to be safe, retf 2) because
it's an interrupt handler, and so is called with the flags on the
stack. The caller flags must be discarded to pass the return flags
back to the caller.
- BP is defined after tsk_switch_stack. This routine not only
switches the stack, it also sets up DS and BP.
Thomas
Read:
==========================
ibm.other/ctask #543, from gworthey, 248 chars, Thu May 28 05:29:10 1992
There is/are comment(s) on this message.
--------------------------
TITLE: Most excellent, Thomas!
I just typed in your mod and it worked beautifully! Thanks much...
I used this will included in the next version of ctask? Or is there a
better way to do it?
BTW... when is the next version of ctask coming?
Greg
Read:
==========================
ibm.other/ctask #544, from twagner, 824 chars, Thu May 28 14:00:22 1992
This is a comment to message 543.
--------------------------
Yes, I think I'll put the mod into the next version, I don't think it
could break anything.
> BTW... when is the next version of ctask coming?
AAARRRGGGGHHH!!! What do you think I am, a soothsayer or what? ;-)
But really, I try to avoid predictions. Every time I promised some
release date, I was late by several months. Now if I don't tell
anyone, maybe I'll be on time... ;-)
I do have some ideas on what should be done for the next version, but
the simple things have all been done, leaving me with the complicated
matters, like safer DOS and Windows compatibility (urgh), which will
likely take weeks of tracing and debugging to get right. And the free
time I'll need for that is nowhere in sight. The university takes 60%
of my capacity, my job the other 60%, the family another 60%, and
then there's BIX...
Thomas
Read:
==========================
ibm.other/ctask #545, from gworthey, 435 chars, Fri May 29 05:03:20 1992
There is/are comment(s) on this message.
--------------------------
TITLE: Say...
I noticed in the dox for ctask you mentioned a debugger called periscope...
I've never heard of it. How much does it cost? And where can you get it? Is i
t very hard to learn?
So far, I've been able to trace all my bugs thru careful modular program,
and flags and the like to find problem points.
You go to school? Which one? You're not "normal" college age are you??
(if you are, I'll be quite discouraged!)
Greg
Read:
==========================
ibm.other/ctask #546, from twagner, 2038 chars, Sun May 31 17:15:21 1992
This is a comment to message 545.
--------------------------
> a debugger called periscope...
Periscope is available in several models, the least costly is the
software-only one. It's a great tool for debugging on the assembler
level, less useful for source-level HLL debugging. I've slowly
drifted away from Persicope, though. I had the hardware model IV, and
keeping the hardware up to date each time I changed my motherboard
would have cost me several k. Hardware breakpoints and backtrace are
a real boon, but it's simply too expensive if you don't really need
it that often. On the software side, Periscope is a bit weak. I
recently got Soft-ICE and Soft-ICE/W, software-only debuggers similar
to Periscope. The software they supply is a lot easier to use than
Periscope, and just as powerful, if not more. Also, Soft-ICE/W lets
you debug Windows internals, DOS-programs running under Windows,
Windows drivers etc., things Periscope can't handle. I don't have the
prices handy, I'd have to look that up next week when I'm back at the
office.
> You go to school? Which one? You're not "normal" college age are you??
No, at 38 I'm not really normal college age. I had never finished my
CS diploma at the Technical University of Berlin because I had to
take on freelance programming jobs to finance my studies, and was so
successful at it that no time was left to study. Well, then the kids
arrived, we rented a nice house, got a bigger car, the contracts kept
rolling in... But all the time I still was registered at the
University, and all the time I told myself I'd finish my studies - if
only I had the time. Last year the chance was there. For the first
time, the company I co-own made *real* money. The fax card we build
sold so well that we could afford to hire more people, and cut down a
bit on contract work, which gave me enough leeway to return to the
University. I hope to finish most of the courses I need for the
degree this semester, so I can wrap it all up with just a few more
hours in the Winter semester. Which *could* mean some free time to
work on CTask... :-)
Thomas
Read:
==========================
ibm.other/ctask #547, from saugus, 1499 chars, Mon Jun 1 23:03:13 1992
There is/are comment(s) on this message.
--------------------------
TITLE: multiple serial ports on a single interrupt
Hi all, I'm having a bit of a problem working with multiple serial
ports on a single interrupt which I hope you can help me with.
For several weeks now I've been trying to implement a Ctask program
on my AT compatible which communicates with up to four other
computers via modem at once. Everything is working nicely until
I try to open multiple serial ports on a single interrupt (for
example COM 1 and 3 sharing interrupt #4).
After a great deal of head scratching I've concluded that the
problem isn't in the software at all. It seems that when I have
more then one serial port sharing an interrupt line, the line isn't
being raised high enough by just one of them to generate a
processor interrupt.
I borrowed an Oscilloscope from work today and confirmed this
theory. When just one serial port is open I get a nice clean five
volt interrupt on my PC backplane, but open two and the interrupt
line only goes up to about one volt which isn't enough be
acknowledged by the CPU.
I know that this isn't really a Ctask problem (Ctask is working
wonderfully), but maybe someone else has encountered the same
problem and has some suggestions (I hope)? I know I could probably
put a pull up resister on my serial board or something, but I'd
like to avoid any hardware changes (I'd like to be able to use the
software on any off the shelf system without hardware
customizations).
Thanks everyone... Steve
Read:
==========================
ibm.other/ctask #548, from hfishman, 376 chars, Tue Jun 2 07:55:39 1992
This is a comment to message 547.
There are additional comments to message 547.
--------------------------
The answer is that generally speaking, you cannot get there from
here. In the ISA architecture, multiple adapters CANNOT share an
IRQ line. The only way seems to be to use a serial adapter with
multiple comm ports on a single card that all drive a common IRQ
line and then have the software poll to determine who needs
service. Of course them cards are not cheap.
Harvey
Read:
==========================
ibm.other/ctask #549, from tssi, 339 chars, Tue Jun 2 11:48:17 1992
--------------------------
TITLE: CTASK & BC++ 3.0
I have a application running with CTASK using BC 2.0 and DOS 5.0.
Has anyone had any problems with BC 3.0 and the CTASK.LIB after recompiling.
I am experiencing a problem with calling (biosprint) after removing the
tasker. Other wise my deepest gratitude to Thomas W. for his efforts.
Sincerly Kevin (DADDY_O).
?
Read:
==========================
ibm.other/ctask #550, from dgh, 187 chars, Tue Jun 2 19:00:54 1992
This is a comment to message 547.
There is/are comment(s) on this message.
--------------------------
This is an unsolvable problem. The only thing that will ever work is to get
a multi-port COMM card that is designed for interrupt sharing, such as the
ones from DigiBoard.
|) /\ \/ | |)
Read:
==========================
ibm.other/ctask #551, from saugus, 135 chars, Tue Jun 2 21:10:56 1992
This is a comment to message 550.
--------------------------
I was afraid you were going to say something like that.
Oh well, thanks anyway...
Steve
Read:
==========================
ibm.other/ctask #552, from gworthey, 441 chars, Wed Jun 3 07:34:58 1992
There is/are comment(s) on this message.
--------------------------
TITLE: Oh shoot
...
Are you guys sure? It seems to me that dlx allows you to use four modems withou
t
special hardware. I could be wrong (I hope I'm not!)
So how much do these 4-com port boards cost??
And finally, I don't completely understand the ctask dox concerning shared
irq h's with v24_modem handler... (I'm currently just using 2 lines) How di
difficult is to convert my 2-line setup to that of a Digi-board for example ??
Greg
Read:
==========================
ibm.other/ctask #553, from dgh, 541 chars, Fri Jun 5 00:31:14 1992
This is a comment to message 552.
There are additional comments to message 552.
--------------------------
"dlx" probably lets you use four modems by making you select a unique
interrupt for each one. You could leave COM1 and IRQ4, put COM2 at IRQ3,
set COM3 to IRQ5 and COM4 to IRQ7 and you have no trouble. The only time
you have trouble is when you try to have two COM ports share the same
interrupt--EXCEPT on multi-port cards that are designed for interrupt
sharing.
The lowest-cost DigiBoard 4-port COM board lists for $409. You should be
able to get it for about $300-$350 with some judicious Computer Shopper
spelunking.
|) /\ \/ | |)
Read:
==========================
ibm.other/ctask #554, from dgh, 541 chars, Fri Jun 5 00:42:35 1992
This is a comment to message 552.
There is/are comment(s) on this message.
--------------------------
"dlx" probably lets you use four modems by making you select a unique
interrupt for each one. You could leave COM1 and IRQ4, put COM2 at IRQ3,
set COM3 to IRQ5 and COM4 to IRQ7 and you have no trouble. The only time
you have trouble is when you try to have two COM ports share the same
interrupt--EXCEPT on multi-port cards that are designed for interrupt
sharing.
The lowest-cost DigiBoard 4-port COM board lists for $409. You should be
able to get it for about $300-$350 with some judicious Computer Shopper
spelunking.
|) /\ \/ | |)
Read:
==========================
ibm.other/ctask #555, from saugus, 1480 chars, Sat Jun 6 09:58:40 1992
This is a comment to message 554.
--------------------------
I have noticed that the IBM technical referecne manual for the AT contains
a section on shared interrupts. Much of it seems some what arcane, but the
main idea is that an interrupt line can be shared by two different boards
it they use it properly. Most boards hold the line low and raise it when an
interrupt comes in. The problem is, if you have more then one board holding
the line low then juct one of them wont be strong enough to raise it alone.
IBM suggests having each board hold the line high and pulse it low and then
high again when an interrupt comes in. Since the PIC is set up to trigger
on the interrupt's raising edge this should generate an interrupt. Even if
you have more then one board holding the line up, one should be able to
short it without any problem (I think, I'm a software guy not a hardware guy)
Of course the problem is that all the boards I was playing with hold the line
low and raise it on interrupt, and I don't think that they can be reconfigured.
speaking of the technical ref manual, that section on shared interrupts contai
a reference that I don't understand. They speak of 'rearming' the interrupt
by writing to an address 02fx where x corresponds to interrupt levels 3-9.
What's at address 02fx? I don't see anything in the IO map in the same
manual. If you have any ideas, I'd love to hear them (thats page 1-16 in
my IBM technical reference manual for the IBM AT).
Steve
==========================
ibm.other/ctask #556, from jlo, 406 chars, Tue Jun 16 00:01:04 1992
This is a comment to message 555.
--------------------------
Are there several versions or volumes of the AT tech ref? I took a
look through the one I have at work, and I think there is a picture
on page 1-16, or some overview type stuff. The IO address you mentioned
has something to do with serial port 2 (according to the PC sourcebook)
but I can't think of what that has to do with the PIC controller
registers at 20h, 21h, A0h, and A1h. Oh well....
James Lo
==========================
ibm.other/ctask #557, from nicotra, 179 chars, Wed Jul 1 00:20:15 1992
--------------------------
TITLE: Animation
Does it make sense to use ctask to allow one task to read info from
the disk while another is using the info to animate the screen?
Or is the overhead too great?
==========================
ibm.other/ctask #558, from mshiels, 217 chars, Thu Jul 2 07:15:54 1992
This is a comment to message 546.
There is/are comment(s) on this message.
--------------------------
Could you leave a little blurb about your fax card. We are looking
to support f^fax cards which are available in the Europeon communities
for our Imara Lite product which is a Windows based document imaging
solution
Read:
==========================
ibm.other/ctask #559, from mshiels, 180 chars, Thu Jul 2 07:17:27 1992
This is a comment to message 550.
--------------------------
If the cards are done correctly they can share IRQs but it would cost
extra and most people don't do it. If the cards are "tri" stated then
they will be able to share interrupts.
Read:
==========================
ibm.other/ctask #560, from twagner, 873 chars, Thu Jul 2 18:29:19 1992
This is a comment to message 557.
There is/are comment(s) on this message.
--------------------------
It depends... the overhead of CTask surely is not negligible,
especially in the DOS version. For a specialized app that has only
two tasks with very strict separation, you could probably reduce the
overhead a lot by eliminating some of the CTask safeguards around
DOS, but task switching still will take its time.
But then, the preemptive nature of CTask will probably make for
rather smooth animations. Any scheme that relies on polling or such
might get jerky, and doing animation in a timer interrupt handler
likely isn't that much fun to implement.
As with most general-purpose libraries, the choice isn't easy. CTask
gives you ease of use, and lots of power, but at a cost - overhead.
Doing everything yourself can result in an ultra-sleek, efficient
program, but also at a cost - more complex implementation. I really
can't say what's better in your case.
Thomas
Read:
==========================
ibm.other/ctask #561, from twagner, 636 chars, Thu Jul 2 18:29:55 1992
This is a comment to message 558.
There is/are comment(s) on this message.
--------------------------
Well, it has to be short or I'll run into trouble... :-)
The ferrariFAX card is processor based (NEC V25 running CTask) and
has a standard CAS interface, so you shouldn't have any trouble
supporting it. It's currently available in Germany only, but we'll
have PTT approval for Austria and Switzerland soon (in a few weeks
probably). The software we ship with the card runs under both Windows
and DOS (the same source code, BTW, thanks to MEWEL). Windows apps
can use a proprietary API for the Windows printer driver in addition
to CAS.
Enough info for your needs? If you want to know more, we should
probably move to BIXmail.
Thomas
Read:
==========================
ibm.other/ctask #562, from jwinn, 323 chars, Thu Jul 2 19:53:23 1992
There is/are comment(s) on this message.
--------------------------
TITLE: Co-Processor
Can someone explain the 80287 problem when used in multitasking?
I assume it has a re-entrancy problem, but how does it work in conjunction
with my 80286 ?
(2) Does the NDP option in CTASK22B solve all the problems ?
(3) If not, are there workarounds ?
thanks,
Jim ( in a wee bit over my head . . . )
Read:
==========================
ibm.other/ctask #563, from jwinn, 150 chars, Thu Jul 2 19:55:30 1992
There is/are comment(s) on this message.
--------------------------
TITLE: CSCAPE
Does anyone have any experience with CSCAPE 3.2 ? If so,
do you have any known killer bug fixes you could be persuaded
to share ?
Jim
Read:
==========================
ibm.other/ctask #564, from cmoran, 328 chars, Thu Jul 2 21:43:58 1992
This is a comment to message 547.
--------------------------
This is not really unusual. You've most likely now got
two outputs ^^onto the buss, one of which is "high" and the
other "low" (when one has an interrupt and the other doesn't)
Possible solution might be to use something like an AST 4Port
card or DigiBoard style device and move your ports to a single
device channel
Cheers,
Read:
==========================
ibm.other/ctask #565, from nicotra, 52 chars, Fri Jul 3 00:18:47 1992
This is a comment to message 560.
There is/are comment(s) on this message.
--------------------------
Care to point me to safeguards I could nix.
Thanks!
Read:
==========================
ibm.other/ctask #566, from cblum, 280 chars, Fri Jul 3 09:18:17 1992
This is a comment to message 563.
There is/are comment(s) on this message.
--------------------------
Jim - I use CSCAPE with Ctask under Borland C++ 3.0 compiler ( in C mode, not
C++ ) for industrial control apps. With latest fixes from Liant ( new CSCAPE
owners ) BBS, works great. I recompiled CSCAPE so it supports VRROOM overlays
and with care, all these work together. Chris.
Read:
==========================
ibm.other/ctask #567, from nicotra, 61 chars, Fri Jul 3 17:26:25 1992
There is/are comment(s) on this message.
--------------------------
TITLE: Overlays
Is there any way to use overlays with CTASK.
Read:
==========================
ibm.other/ctask #568, from jwinn, 2720 chars, Fri Jul 3 18:37:48 1992
This is a comment to message 566.
There is/are comment(s) on this message.
--------------------------
I have three systems at one industrial location. They are
80286s (one is 80386), with math co-processors, CTASK22
(soon to be CTASK22B on my next trip out), CSCAPE 3.2,
DOS 3.3, MS C 5.1, large models. They each utilize
CSCAPES keyboard software. And Thomas Wagner's sio
routines on COM1 and COM2 to talk to each other and the
"RTUs", which are Analog Devices uMAC 6000 (used primarily
in laboratories I am told). Not my configuration.
We unit checked 85% of the software and did MINIMAL system
integration testing here before they shipped and installed
all the hardware. This is the primary source of frustration.
It's real fun out there in the field now !
I am encouraged by your experience. Although I also had
downloaded CSCAPE's bug file, I've not until now been
ready to psychologically deal with it. A little background.
When I paid $500 for 3.2 and registered as a user on 2-27-91
I received the two libraries, source code, and benefits of
their THEN published policy of free technical help. When I
contacted them a couple of months ago, the rules have changed
to tech assistance for $250 a year - Policy applies to
all owners.
Bug fixed source files are NOT available. But the soon to be
announced ver 4.0 will have the fixes in them, along with
additional capabilities (which may induce new uncertainty
in some previously working functions ?) and we may upgrade
for their stated price.
I could have sworn that i was buying a car, free of engine
stalling, brake locking problems, etc., which the dealer
(vendor) would fix if such did occurr.
Well, if one chooses to play in the software arena today,
that's not reality, is it ? What else can I say . .
i'll say no more.
At any rate, I've taken another look at their 106 bugs list.
On first examination, only 21 items appear to apply to
DOS applications, where only sed's (no sleds, teds or other
type menus) have been used.
Six of these don't apply to me, even though they are
system crashers.
Of the 15 remaining, new code is given in the bug file for
4 items,
adequate English description of fixes is given for another
5 items,
and the remaining 6 items will require digging into the code
to understand the problem and hopefully the fix.
Well, there ain't no guarantees for software are there !
Thanks again for conveying a hopeful outcome.
Have a good 4th of July!
Jim
PS - One specific problem. A screen with multi row and
cols of data will have a random item go to garbage on
a sed_Repaint() cycle, and then return to good data on
the next sed_Repaint() a second later. The application is
not altering/accessing this variable. Smells like a
CSCAPE pointer. Have you seen this problem ?
Read:
==========================
ibm.other/ctask #569, from twagner, 718 chars, Sat Jul 4 17:38:32 1992
This is a comment to message 562.
--------------------------
The 80287 is a separate processor with its own set of registers.
When you have two tasks using it, then the complete state of the
thing has to be saved and restored upon switching tasks, just like
the registers and flags of the main CPU. The problem is that
a) you have to know whether there is an NDP installed, or the FPU
instructions will kill you,
b) you have to wait for the FPU to finish its current instruction, and
c) the different FPUs (8087, 80287, 80387, 80486) all have different
quirks and slightly different ways to communicate with the CPU.
The NDP option in 2.2b has been reported to work fine. I did some
minimal testing, but I'm not an expert at all when it comes to
floating point.
Thomas
Read:
==========================
ibm.other/ctask #570, from twagner, 513 chars, Sat Jul 4 17:38:50 1992
This is a comment to message 565.
--------------------------
Well, if you're really adventurous, set the "DOS" define in
tskconf.h to FALSE. This will eliminate all DOS reentrancy
protection. IBM should still be TRUE. Set EMS to FALSE, and check
that NDP is FALSE, too.
BUT... DO NOT attempt to do ANYTHING that could, even remotely, call
DOS in more than one task, this would kill you in no time if DOS is
FALSE.
To save some more code, and slightly speed up things, you can also
set GROUPS to FALSE and SINGLE_DATA to TRUE if you're creating a
Non-DOS version.
Thomas
Read:
==========================
ibm.other/ctask #571, from twagner, 768 chars, Sat Jul 4 17:39:06 1992
This is a comment to message 567.
There is/are comment(s) on this message.
--------------------------
> Is there any way to use overlays with CTASK.
The CTask scheduler doesn't know a thing about overlays, so if you
have a task in an overlay that has just been overlayed by other code,
and CTask tries to switch to that task, you'll get some very
interesting results. Since the scheduler is an extremely time
critical part, and can never use any DOS services, it couldn't read
the overlay back from disk even if it knew the task was gone.
So my advice is: don't try it. The only chance would be to use EMS
(the standard 64k page frame) to store overlayed code in, since CTask
does save and restore the EMS page mapping on a by-task basis. But I
don't think there is any overlay manager available that restricts
itself to EMS, so you'd be entirely on your own.
Thomas
Read:
==========================
ibm.other/ctask #572, from proy, 82 chars, Wed Jul 8 20:04:18 1992
There is/are comment(s) on this message.
--------------------------
TITLE: Latest Version
What is the latest version of Ctask and how would I get it?
Read:
==========================
ibm.other/ctask #573, from cblum, 348 chars, Wed Jul 8 22:13:52 1992
This is a comment to message 568.
--------------------------
I called the support number... Support access to BBS including source fixes
is still no charge if you're licensed. Talking to a warm body costs. I got
all the fixes from the BBS and have had no problems. Even recompiled all with
Borland C++ 3.0 ( in C mode ) to support VRROOM... works like a champ.
Have not seen your bug. Hope this helps. Chris.
Read:
==========================
ibm.other/ctask #574, from cblum, 417 chars, Wed Jul 8 22:17:53 1992
This is a comment to message 571.
There is/are comment(s) on this message.
--------------------------
Thomas - I have used CTask and Borland C++ 3.0 VRROOM overlays with good
results. I am careful to make sure that time-critical tasks are not in
overlays... basically by using two foreground tasks and one background, and
only overlaying the BG task ( all the file stuff, help screens, etc. ). This
has worked very well for me. Of course, caveat programmer... death and
destruction lies in wait for the unwary. Chris.
Read:
==========================
ibm.other/ctask #575, from twagner, 99 chars, Thu Jul 9 17:44:19 1992
This is a comment to message 572.
--------------------------
The latest version is 2.2b, it's posted in IBM.UTILS/LISTINGS under
the name CTASK22B.LZH.
Thomas
Read:
==========================
ibm.other/ctask #576, from twagner, 98 chars, Thu Jul 9 17:46:26 1992
This is a comment to message 574.
--------------------------
Oops.. CTask is in the *IBM.PC* listings area. You'll find the unpacker LHA
in ibm.utils.
Thomas
Read:
==========================
ibm.other/ctask #577, from dleney, 860 chars, Fri Jul 10 15:00:36 1992
There is/are comment(s) on this message.
--------------------------
TITLE: CTASK and DOS Extenders
I have been using CTASK for about a year and have developed several
industrial control projects based on it. Thanks, Thomas for a great
product. I have used it with Microsoft C 6.0 and several commercial
libraries. I protect the libraryi^[[D^^ accesses with resources. I've
also used floating point via the coprocessor with no problems once
I set the floating point flag in the main task (I think it defaults
to no NDP). I've also used the serial i/o extended to ten ports
(the two standard ports and eight on a dumb Digiboard PC/8).
Now to my question. Has anyone used CTASK with a DOS Extender?
I'm developing a new application which will not run int the 640K
available under standard DOS. I could use some form of overlay
or virtual memory type of approach but was thinking that a DOS
extender would be more efficient.
Read:
==========================
ibm.other/ctask #578, from proy, 267 chars, Mon Jul 13 19:17:47 1992
There is/are comment(s) on this message.
--------------------------
TITLE: MASM 6.0
I am trying to assemble the Ctask 2.2b code with MASM 6.0 (with the /Zm
switch). I get an error on the line in tsk.mac that reads
@code equ <CTASK_TEST>
error - symbol redefinition: @code
What does this mean? How can I get around this?
Thanks
Read:
==========================
ibm.other/ctask #579, from proy, 261 chars, Mon Jul 13 20:48:43 1992
This is a comment to message 577.
There is/are comment(s) on this message.
--------------------------
Could Ctask be modified to work with a 32 bit C compiler?
Would that get rid of the problem using overlays with Ctask?
The Intel code builder lets you create code that can access
up to 64 megabytes of memory without using a dos extender.
Is this a possibility?
Read:
==========================
ibm.other/ctask #580, from amargerison, 519 chars, Tue Jul 14 06:28:22 1992
There is/are comment(s) on this message.
--------------------------
TITLE: BC 3.1
I'm trying to recompile tsk.mac with the version of TASM that is supplied with B
C 3.1
we're using /w /mx /zi /JMASM51 /JQUIRKS as the command line.
We've tried using /UT300 for backwards compatility with 3.0 but It seems to make
no
difference.
This is the error we're getting
VPUSH(2) Illegal instruction
This appears to be caused by the following line
hash instr 1,<val>,<#>
and it looks like it's not evaluating val (a parameter to macro VPUSH) correctly
Anyone got any Ideas/Suggestions ??
Stephen
Read:
==========================
ibm.other/ctask #581, from cblum, 514 chars, Tue Jul 14 09:26:15 1992
This is a comment to message 580.
There is/are comment(s) on this message.
--------------------------
I have successfully recompiled with BCC 3.1 by using /uM510 *INSTEAD* of
/jMASM51. All other parms the same. I had that same error, and making the
parm change fixed it, no sweat. Also found a slight bug in the placement
of the BC_HUGE definition/check, if you want to do the huge model. Note that
the BC_HUGE and TC_HUGE defines do different things.
I added the lines
#if defined(BC_HUGE)
#define TC_HUGE
#endif
before the include of the config file. That fixed the huge model assemblies.
Chris.
Read:
==========================
ibm.other/ctask #582, from twagner, 723 chars, Wed Jul 15 06:15:11 1992
This is a comment to message 578.
--------------------------
> How can I get around this?
Don't use MASM 6... :-(
Seriously, I've deleted MASM 6.0 from my disk after it choked on
perfectly working code and produced erroneous code after adaptation in
some instances. So I'm not too eager to adapt the CTask assembler
parts to 6.0. Even Microsoft (the Windows group) recommends using 5.1
for development because 6.0 is broken.
If you can't get hold of MASM 5.1, get TASM, the Borland assembler,
instead. You'll have to use a different command line option than the
one used for earlier versions (see msg #581), but then it will work
fine.
It might be possible to get around 6.0's problems and quirks, but I
really can't help you in that respect, at least not right now.
Sorry
Thomas
Read:
==========================
ibm.other/ctask #583, from twagner, 790 chars, Wed Jul 15 06:15:36 1992
This is a comment to message 579.
--------------------------
> Could Ctask be modified to work with a 32 bit C compiler?
I'd say yes, in principle - but I don't really know how much work it
would be. The problem shouldn't be the C code, but what you'd have to
do on the Assembler side. The scheduler probably has to be rewritten
in 32-bit code so it can save the 32-bit registers, and the interrupt
handlers might have to be modified.
> access up to 64 megabytes of memory without using a dos extender.
I'm at a loss here. If you want to do DOS or BIOS calls, you have to
do it in 16-bit real mode code, and this requires translation of
32-bit protected mode addresses to real-mode ones, in some instances
copying of parameters, and all that. That's the main task of a DOS
extender. If they don't have such a beast, then how do they do it?
Thomas
Read:
==========================
ibm.other/ctask #584, from cblum, 392 chars, Thu Jul 16 09:57:18 1992
This is a comment to message 581.
--------------------------
My apologies, what a dummy! Never try to compose a msg in a hurry from a
faulty memory bank!
My changes to support the huge model under BC++ 3.1 were as follows:
In module TSK.MAC, just before the include of TSKCONF.H, I added the following:
IFDEF BC_HUGE
TC_HUGE = 1
ENDIF
...
include tskconf.h
That fixed up TASM complaints about pass-dependent constructions.
Chris
Read:
==========================
ibm.other/ctask #585, from mshiels, 210 chars, Fri Jul 17 23:19:41 1992
This is a comment to message 561.
--------------------------
Could you please send me some information regarding getting
an evaluation copy of your card/software. We are trying to find CAS
or class2 cards which are european ceritiff^^^^certified since the Intel
is not.
==========================
ibm.other/ctask #586, from jef, 337 chars, Mon Aug 3 07:48:49 1992
--------------------------
TITLE: CTask TSR
Is there anyone out there who already wrote a TSR using CTask ?
I did, and I have one question about it.
How can you minimise usage of conventional memory ?
My TSR now uses about 125K, CTask takes about 85K
If someone already modified the library to diminish that amount
I would be glad to hear about it.
Jo Demuynck.
==========================
ibm.other/ctask #588, from nicotra, 196 chars, Tue Aug 18 18:23:20 1992
There is/are comment(s) on this message.
--------------------------
TITLE: Timer
Why does the timer initialization not execute the scheduler the first
time it is called? What will happen if speed of the machine is too
fast, will it over run this some how?
-Chris
Read:
==========================
ibm.other/ctask #589, from twagner, 591 chars, Wed Aug 19 16:20:24 1992
This is a comment to message 588.
--------------------------
> ... timer initialization not execute the scheduler the first time
Well, tsk_install_timer waits for the first tick to occur in the
"wait_set" loop, so it can be sure that the timer is in synch.
Calling the scheduler during this initialization wouldn't be
catastrophic, but it wouldn't do anything useful, either. The system
isn't fully set up at this point, so preemption is disabled, and the
scheduler entry would simply return. For the same reason, it doesn't
matter whether the system is fast or slow, the critical kernel
variables are set up before the timer is initialised.
Thomas
-[mail from cblum about 16550]------------------------------------------------
Mail:1
Memo #92223
From: cblum
Date: Sat, 22 Aug 92 09:30:24 EDT
To: compuservice
Message-Id: <memo.92223>
In-Reply-To: <memo.90973>
Subject:
The 16550 code has no effect on earlier chips ( 16450, 8250 ). They work fine.
HOWEVER... be aware of an early model of the 16550 UART that had buffer bugs.
It was designated the 16550, not the 16550A. This code will NOT work on that
chip. Only used on early PS2s.
Chris.
-[end of cblum's mail]--------------------------------------------------------
==========================
ibm.other/ctask #590, from nicotra, 152 chars, Sat Aug 22 01:06:44 1992
--------------------------
TITLE: tick_factor
I have a 25 Millisecond clock in my ctask application and I am trying
to figure out what to program the tsk_glob_rec.tick_factor at.
==========================
ibm.other/ctask #591, from nicotra, 48 chars, Thu Sep 3 12:46:51 1992
This is a comment to message 590.
There is/are comment(s) on this message.
--------------------------
Can anyone help with this tick_factor question?
Read:
==========================
ibm.other/ctask #592, from getzinger, 803 chars, Thu Sep 3 18:10:14 1992
--------------------------
TITLE: PharLap & CTask?
Has anyone done work on CTask under the PharLap 386 (or 286) DOS-extender
system? I have been working on a project where I use >20 tasks, each
running a simulated CPU. I was looking for ways to increase my memory,
so I bought the PharLap 386|Dos-extender. I've been using it with BCC3.1
with some success, and wanted to see if I was going to waste my time
trying to develop the protected-mode kernal of CTask.
From my inspection of the extender, it looks as though grabbing the timer
tick interrupt is possible. If need be, I could go from protected mode to
real mode on that interrupt to switch tasks, but that seems too much
overhead. Is there anything specific to CTask that would need to stay in
real mode?
Any suggestions or comments are greatly appreciated!
Jim
.More..
Read:
==========================
ibm.other/ctask #593, from twagner, 762 chars, Thu Sep 3 18:12:03 1992
This is a comment to message 591.
There is/are comment(s) on this message.
--------------------------
I never really figured out how it works, I just know that it does
work. The routine was written by Chris Blum (bix cblum). The number
he used (14061) looks suspicously like the tick interval times 256:
1/18.2 = 54.945 msec * 256 = 14066. But if you look at the code for
the speedup, some sort of a fudge factor is added in before dividing
by 2 (the 0x80 >> (8 - speedup)), so I can't say whether the
similarity is just a coincidence.
Well, I just isolated the tsk_timeout routine and did some tests - if
you have a 25 msec timer, and use 6400 as a tick factor, then the
numbers come out about right. All values up to 37 (25 + 12.5) result
in one tick, and then it's an increase every 25. I still don't know
what this fudge factor does, though. Chris?
Thomas
.More..
Read:
==========================
ibm.other/ctask #594, from nicotra, 8 chars, Fri Sep 4 00:21:43 1992
This is a comment to message 593.
There are additional comments to message 593.
--------------------------
Thanks!
Read:
==========================
ibm.other/ctask #595, from nicotra, 58 chars, Fri Sep 4 00:55:48 1992
This is a comment to message 593.
There is/are comment(s) on this message.
There are additional comments to message 593.
--------------------------
Silly question, but the 6400 is a decimal number correct?
Read:
==========================
ibm.other/ctask #596, from twagner, 49 chars, Fri Sep 4 12:39:01 1992
This is a comment to message 595.
--------------------------
Sure. 25 * 256 = 6400 decimal, 1900 hex.
Thomas
Read:
==========================
ibm.other/ctask #597, from twagner, 253 chars, Fri Sep 4 12:39:11 1992
--------------------------
TITLE: Minor fixes in new CTask upload
I've just uploaded version 2.2c, which fixes the known minor bugs.
There's no need to download the new version if you already have 2.2b.
For newcomers: the file is CTASK22C.LZH, file area IBM.PC/LISTINGS.
Thomas
Read:
==========================
ibm.other/ctask #598, from nicotra, 457 chars, Sat Sep 5 23:07:23 1992
There is/are comment(s) on this message.
--------------------------
TITLE: Task Switching
We have a simple application with one task doing MIDI file playing
and the other doing animations. It all works pretty well, but every
once in a while we get hesitations in the music. I tried adding a number
of yield calls in the animation code since music glitches are worst
than animation glitches, but that seems to have little or no affect.
These are the only two tasks active. Not real sure where look for
the problem. Any ideas?
Read:
==========================
ibm.other/ctask #599, from twagner, 417 chars, Sun Sep 6 17:43:46 1992
This is a comment to message 598.
--------------------------
Are you reading the MIDI and animation data from the disk while
playing? If the two tasks just happen to go to DOS at the same time,
one will have to wait, which could explain the "hesitation". If I'm
on the right track with that assumption, you could split the disk
read and music playing into two tasks, with the disk read task
always reading ahead, and putting the data into a circular buffer (or
a pipe).
Thomas
Read:
==========================
ibm.other/ctask #600, from cblum, 332 chars, Mon Sep 7 12:10:33 1992
This is a comment to message 593.
--------------------------
Thomas - to tell you the ( embarrasing ) truth, I pulled the code out to look
at it again, and I don't remember what the fudge does, but I do remember
needing it for the code to work. I guess memory fails as we get older... that's
why it's better to comment your code ( a feature conspicuously absent from my
contribution ).
Chris
==========================
ibm.other/ctask #601, from nicotra, 564 chars, Fri Sep 11 00:40:11 1992
This is a comment to message 599.
--------------------------
No the MIDI was totally in memory. I made some changes to the MIDI
code to be a little friendlier. It now determines when the next event
is and t_delay's. Then I bumped the pri on the MIDI task by 1 and it is
working great now. The only problem I have is in some code that does
a wait for the vblank by polling. Due to the MIDI task being a higher
priority it is possible for the animation code to get preempted while
waiting for the vblank and then restarted after the vblank has occured.
I need to find some way to get vertical blank interrupts to work.
Thanks.
==========================
ibm.other/ctask #602, from jjanney, 1098 chars, Thu Sep 24 19:29:49 1992
--------------------------
TITLE: ctask and PC Support/400
Does anyone have any experience using ctask with IBM's PC Support for
the AS/400? I'm trying to communicate with a program on the AS/400
through the PC Support router, and am seeing two things that worry me.
The first is that calls to the router sometimes return a value of
APPCBusy, which is supposed to mean the the router is already in use
and is therefore not available (the router is not reentrant). Since
only one task in my program ever calls the router, I should not be
seeing this value. The second is that after I run my program, I start
getting a "General Failure" on the shared folders drive (drive I:).
PC Support is a set of several programs, some that are loaded from the
config.sys file and some that are loaded as TSRs. Together they
provide various network type functions, including a LU6.2 interface
and a virtual drive, through a twinax card installed in the PC.
Apparently it is in conflict with ctask in some way, but I don't know
how to go about finding the conflict. Are there any general
procedures that are useful in cases like this?
Read:
==========================
ibm.other/ctask #603, from gangelotti, 2750 chars, Fri Sep 25 10:21:23 1992
--------------------------
TITLE: Is there a bug in CTask primary/secondary kernels interactions?
I am new to BIX and new to CTASK. In July I downloaded an old version
of CTask from a local BBS playing with it for some time. Then I decided to
use it in a PC-based remote data acquisition project. So I joined BIX to find
more info about it and found vers. 2.2c with a lot!!! of messages talking of
all sort of bugs, fixes and enhancements. But few of them were about
applications using primary/secondary kernels.
.More..
I tried to build my appl. separating data collecting tasks
(linked with a primary kernel and spawning "COMMAND.COM"),
from interface tasks (the user could invoke them at the command level).
Here I experienced a problem with secondary invocation of CTask. It seems
that tasks linked with secondary kernel had *NOT* DS properly setted when
they get started.
Then I built a couple of small test programs to find the cause and to
experiment possible solutions, PRI.EXE and SEC.EXE (I can upload them,
if required).
.More..
Both tests are compiled with BORLAND C++ 3.0 (C-mode), large model.
Primary CTask was compiled with huge model and BC_HUGE defined, then linked
to PRI.C (large model).
It has various tasks; one of them, after pressing 'c' on the keyboard, spawns
COMMAND.COM.
tskconf.h has
#define CODE_SHARING TRUE
CODE_SHARING = TRUE
.More..
LOAD_DS = 1 ; ASM only
Secondary CTask was compiled with large model and linked to SEC.C
(large model).
It contains main() and
Taskfunc task1() {...} created by main;
Taskfunc task2() {...} created by main;
tskconf.h has
#define CODE_SHARING FALSE
CODE_SHARING = FALSE
; LOAD_DS = 1 ; ASM only **** COMMENTED OUT ****
If I run PRI.EXE, spawn COMMAND.com with 'c', run SEC.EXE,
get my machine hung. Debugging SEC.EXE with TD286, I discovered that
when task1 and task2 run, DS register contains DGROUP of PRI.EXE,
setted from the invocation to create_task(). I get round this fact declaring
task1 and task2 this way:
.More..
Taskfunc _loadds task1() {...}
Taskfunc _loadds task2() {...}
Is this correct??? Or am I wrong?
I haven't found any note regarding this declaration neither in DOC nor
in this conference. Has anybody experienced the same problem?
Another question.
Is it possible to compile the primary kernel in large model using
MICROSOFT definition of Farc in tsk.h under BORLAND (see below)?
.More..
#define Farc far _loadds /* for code sharing, _loadds is required */
I think yes and I tried it with my application and tests. They definitively
run.
And To Thomas:
In spite of these small problems, CTask is GREAT, a real gift. Thanks.
.More..
Giorgio Angelotti
==========================
ibm.other/ctask #604, from twagner, 1310 chars, Mon Sep 28 16:53:26 1992
This is a comment to message 603.
--------------------------
The problem with Borland is that they change the compiler every few
weeks... ;-) The _loadds keyword didn't work with Borland before
version 3.0, but it obviously does now. And yes, if it works, by all
means use the Microsoft definition.
The correct setup of DS isn't something CTask can accomplish. The
kernel just takes whatever is in the current DS and stuffs it into
the task control block, so that's the value that gets used when the
task is started. Now, if create_task is in a different program, and
loads a DS on entry that is different from the one the calling
program uses, then you'll be in trouble. But if you compile the task
function with _loadds, then the correct DS will be set up on entry to
the function, and used throughout the task, and for all functions
that this task calls.
So it isn't really a bug in CTask, more a documentation problem. I
should have mentioned that you'd get an incorrect DS if you call
create_task in the secondary with code sharing (I simply overlooked
that this would happen). So you should not only compile the kernel
with the "load ds on entry" option, but also your task functions and
any other functions in your code that are called from the kernel.
An alternative is to not share the create_task routine, i.e. define
it as "dstub" in tskstub.asm.
Thomas
==========================
ibm.other/ctask #605, from klrv, 596 chars, Mon Oct 5 12:07:29 1992
This is a comment to message 445.
There is/are comment(s) on this message.
--------------------------
I know this is a *very* late response to this question, but i just stumbled
into the same problem, AND i found out what the problem was!
The file TSK.MAC contains:
IF IBM
hotkey_scan db TYPE queue_head dup(?)
hotkey_noscan db TYPE queue_head dup(?)
ENDIF
This should be "IF HOTKEYS" instead of "IF IBM", since otherwise
the glob_rec structure is different in assembler and C! Surprisingly,
this turns out to be a problem ONLY at the end of the program, when
tsk_remove_groups is called in an infinte loop because
tsk_glob_rec.group.branch was overwritten during tsk_install_dos()...
.More..
Luc
Read:
==========================
ibm.other/ctask #606, from twagner, 102 chars, Mon Oct 5 16:38:51 1992
This is a comment to message 605.
--------------------------
Urgh... I thought I had already fixed this, but it's still in 2.2c.
Thanks for the reminder.
Thomas
==========================
ibm.other/ctask #607, from bernardo, 559 chars, Thu Oct 15 07:18:03 1992
There is/are comment(s) on this message.
--------------------------
TITLE: Problems Compiling CTASK with BC++ 3.1
i have problems trying to compile Ctask, version 2.2b and 2.2c, with Borland
C++ 3.1.
If i compile ctask qith BC++ 3.0 everything is ok, but with BC++ 3.1 i can't
compile version 2.2b, at least the assembler part. With Ctask 2.2c i can
compile all the sources, but when linking the libraries with the sources i
obtain a linker error: Segment Fixup Overflow. The problem is with the
assembler modules, so i think the problem is in TASM 3.1 ...
Does anyone successfully compile Ctask with BC++ 3.1 ??
Bernardo.
Read:
==========================
ibm.other/ctask #608, from twagner, 509 chars, Sat Oct 17 04:41:21 1992
This is a comment to message 607.
--------------------------
Version 2.2c *was* compiled with BC++ 3.1, and it works for me. Fixup
overflows usually result from mixing memory models - which memory
model do you use? And which configuration options in TSKCONF.H? Any
assembler modules of your own that call internal CTask functions?
The problem with compiling the Assembler modules with Tasm 3.1 was
discussed earlier in this topic - the old make files (2.2b and
earlier) used /JMASM51 on the Tasm command line. With the new Tasm,
you have to use /JM510 instead.
Thomas
Read:
==========================
ibm.other/ctask #609, from jwinn, 1597 chars, Fri Oct 23 16:40:18 1992
--------------------------
TITLE: CTASK22B ON 80286
Has anyone had problems moving from CTASK22 to CTASK22B, running
on a 286?
Right after turning on the tasks, I get COND READ WPIPE -
INVALID POINTER.
SYSTEM HALT.
The same application, with no changes, ran OK with CTASK22.
1 - Are there any 80386 assembly instructions in the asm files?
2 - Is there a particular problem with overlays, which we do
alot of.
3 - Are there significant differences twix 22B and 22C which
might make a difference ?
Any ideas or comments would be much appreciated.
My configuration is:
CTASK22B CSCAPE 3.2
MS C 5.10 COMPAQ DOS 3.31
80286 AT clone with DTK 286 BIOS 3.01 7/24/87. NO Co-Processor
640 k main memory, 384 K extended memory
EGA
tskconf.h settings are:
CODE_SHARING FALSE NEAR_CODE FALSE
LOCALS_FAR FALSE CALL_PASCAL FALSE
TSK_DYNAMIC TRUE TSK_DYNLOAD TRUE
IBM TRUE DOS TRUE
TSK_NAMED TRUE TSK_NAMEPAR TRUE
GROUPS TRUE CLOCK_MSEC FALSE
PRI_TIMER 0xf000 PRI_STD 100
PRI_INT8 (PRI_STD) AT_BIOS TRUE
INT8_EARLY FALSE INT8_LATE FALSE
SINGLE_DATA FALSE EMS TRUE
EMS_SAVE_SIZE 16 NDP TRUE
(also tried NPD FALSE)
HOTKEYS TRUE CHECKING TRUE
Read:
==========================
ibm.other/ctask #610, from bernardo, 311 chars, Sun Oct 25 08:01:33 1992
This is a comment to message 608.
--------------------------
[From twagner #608]
Thanks, now all is working ok.
TSKCONF.H had CODE_SHARING set to TRUE when using the Large model under
BC++ 3.1 and this generate the fixup overflow.
The other solution to my problem, related to TASM 3.1, was solved removing
the /mx parameter from the makefile.
Thanks for all.
Bernardo.
==========================
ibm.other/ctask #611, from bbordt, 1998 chars, Fri Oct 30 16:36:34 1992
--------------------------
TITLE: multiport
Subject: Problem using Ctask with multiport serial I/O cards.
I am trying to get Ctask to work with a 4-port serial card that can
cause extended interrupts. I currently have one port configured as COM3
at port address 0x3E8 and using hardware IRQ10. I know that the card is
working properly because I have tested it with the manufacturer's
loopback test software. It is indeed causing interrupts on IRQ10. I
have a simple Ctask test program written based upon the TSIO.C example
included with Ctask. The difference is that I use v24_define_port() to
dynamically define the port before using v24_install(). The system
constant TSK_DYNAMIC is true to allow for dynamic port definitions. I
even have the correct base address for the 16450 ACE stored at 0000:0404
before running the test program. A fragment from my main() function is
shown below.
if( v24_define_port( 0x3E8, 10, 0x78 ) == -1 )
{
remove_tasker();
tsk_printf( "Couldn't define COM-Port\n" );
= v24_install (PORizeof (rcvbuf), xmtbuf, sizeof (xmtbuf));
if (siop == NULL)
{
remove_tasker ();
tsk_printf ("Couldn't install COM-Port\n" e;op, BAUD);
v24_40, 60);
create_task (&tcb1, task1, stack1, STACKSIZE, PRI_STD, NULLTN("TASK1"));
create_task (&tcb2, task2, stack2, STACKSIZE, PRI_STD, NULL TN("TASK2"));
The problem is that only the first character of the message is
transmitted. I have verified with an oscilloscope that the serial card
caused an interrupt on IRQ10 after sending the first character. The
16450 ACE also indicates an interrupt pending after transmitting the
first character. In addition, I have verified that the correct segment
and offset for the tsksio_int10() interrupt handler are stored at
location 0000:01E0 in low RAM (segment and offset for interrupt 0x78).
I think the problem might be with the 8259 PIC. If you know of a
solution to this problem, would you please let me know.
Thank You,
Bruce Bordt (bbordt)
Read Ref:
==========================
ibm.other/ctask #612, from bbordt, 1961 chars, Fri Oct 30 16:50:10 1992
There is/are comment(s) on this message.
--------------------------
TITLE: multiport
Subject: Problem using Ctask with multiport serial I/O cards.
I am trying to get Ctask to work with a 4-port serial card that can
cause extended interrupts. I currently have one port configured as COM3
at port address 0x3E8 and using hardware IRQ10. I know that the card is
working properly because I have tested it with the manufacturer's
loopback test software. It is indeed causing interrupts on IRQ10. I
have a simple Ctask test program written based upon the TSIO.C example
included with Ctask. The difference is that I use v24_define_port() to
dynamically define the port before using v24_install(). The system
constant TSK_DYNAMIC is true to allow for dynamic port definitions. I
even have the correct base address for the 16450 ACE stored at 0000:0404
before running the test program. A fragment from my main() function is
shown below.
.More..
if( v24_define_port( 0x3E8, 10, 0x78 ) == -1 )
{
remove_tasker();
tsk_printf( "Couldn't define COM-Port\n" );
siop = v24_ins sizeof (rcvbuf), xmtbuf, sizeof (xmtbuf));
NULL)
{
remove_tasker ();
tsk_printf ("Couldn't install COM-Port\n"4_e4_protocol (siop, 0(&tcb1, task1, s
tack1, STACKSIZE, PRI_STD, NULL TN("TAS
K1"));
create_task (&tcb2, task2, stack2, STACKSIZE, PRI_STD, NULL TN("TASK2"));
The problem is that only the first character of the message is
transmitted. I have verified with an oscilloscope that the serial card
caused an interrupt on IRQ10 after sending the first character. The
.More..
16450 ACE also indicates an interrupt pending after transmitting the
first character. In addition, I have verified that the correct segment
and offset for the tsksio_int10() interrupt handler are stored at
location 0000:01E0 in low RAM (segment and offset for interrupt 0x78).
I think the problem might be with the 8259 PIC. If you know of a
solution to this problem, would you please let me know.
Thank You,
Bruce Bordt (bbordt)
Read Ref:
==========================
ibm.other/ctask #613, from klrv, 76 chars, Sat Oct 31 04:52:12 1992
This is a comment to message 612.
There is/are comment(s) on this message.
--------------------------
Why do you specify vector 0x78? I thought IRQ10 corresponded to 0x72...
Luc
Read Ref:
==========================
ibm.other/ctask #614, from getzinger, 450 chars, Sat Oct 31 22:57:15 1992
This is a comment to message 613.
--------------------------
Luc is correct. IRQ 10 is referenced by vector 0x72. The symptoms Bruce
mentioned are consistent with an incorrect vector assignment: I've worked
with a number of multi-port boards and was always hitting myself up along
side the head when it happened. Try the define port with 0x72. If it still
occurs, the problem may lie in your interrupt handler. (multiport boards
differ, so you may need to say which kind of board you are using.)
Jim
Read Ref:
No further comments to message #612. Reading next unread.
==========================
ibm.other/ctask #615, from jmccall, 298 chars, Mon Nov 2 09:59:25 1992
--------------------------
TITLE: Debugging CTask applications
I know that Thomas Wagner recommends Periscope for serious
debugging work. For various reasons we are considering Soft/ICE
from Nu-Mega Technologies. Does anyone have any experience of
using it on CTask applications? All printable suggestions
welcomed!
-- John
==========================
ibm.other/ctask #616, from twagner, 977 chars, Thu Nov 5 17:12:16 1992
This is a comment to message 609.
--------------------------
Well, every time I had an invalid pointer trap it turned out to be
real - the pointer was bad, the structure it pointed to had been
clobbered, or the initialisation (create_wpipe in this case) was
missing. You should be able to glean some more details from the
register dump - or better, uncomment the "int 3" instruction in
tsk_fatal_pmd to break into a debugger. It can be a bit tedious to
trace back through the stack if you don't have symbols, but it
shouldn't be too hard to find the offending pointer, and check what
it's really pointing to.
Why the problem would only show up in 2.2b and not in 2.2 escapes me.
I don't believe switching to 2.2c would change anything in this
respect. It could be just a secondary effect, things getting moved to
a different location in memory or some such.
Anyway, there are no '386 instructions anywhere in my code. Overlays
could very well be a problem, especially if you overlay data areas,
or if you overlay active tasks.
Thomas
Read:
==========================
ibm.other/ctask #617, from twagner, 745 chars, Thu Nov 5 17:12:37 1992
This is a comment to message 615.
--------------------------
I should add Soft-ICE to the list of recommended debuggers. I've
been using it for some time now, and in some respects it's even
better than Periscope, at least for software-only debugging. I miss
the hardware capabilities of Periscope IV (I couldn't afford to
update the hardware again after switching to a '486/33), but on the
software side Soft-ICE is more flexible. The only complaint I have is
that their memory manager is incompatible with Windows and some other
stuff, so I always have to reboot and switch configurations to use
it. Depending on what you want to debug, you might find Soft-ICE/W
easier to use, since it works with the standard memory managers. You
just can't debug TSRs as easily as with the DOS-based Soft-ICE.
Thomas
Read:
==========================
ibm.other/ctask #618, from bbordt, 1257 chars, Thu Nov 12 16:59:41 1992
There is/are comment(s) on this message.
--------------------------
TITLE: Multiple Serial Ports and Ctask
Is there any reason why Ctask can't support 4 serial ports running at
38400 baud simultaneously. I have a separate task for each port and one
additional display task running with preemption turned off. Periodically
the system crashes. The PC is a 386/25 MHz which I don't consider a slow
machine. Another problem is that I am trying to support RTS on all of the
ports. I am trying to turn on RTS before sending characters, and then turn
it off after the last character has been completely serialized. Since the
8250 UART cannot cause an interrupt upon TSRE, the RTS turn off must occur
by polling at the task level. This works fine most of the time, however,
occaisionally the turn off of the RTS line is delayed excessively due to
other tasks taking a while to complete. I have found that using a counter
to hold off the display task while the TSRE poll takes place helps out
tremendously, however, it doesn't completely fix the problem. Has anyone
been able to get this configuration to work, and also know how to speed up
the RTS turn off? Also, does Ctask really support serial ports that share
the same interrupt line? Any comments and suggestions would be greatly
appreciated.
Thanks. Bruce Bordt
Read:
==========================
ibm.other/ctask #619, from klrv, 1835 chars, Fri Nov 13 07:40:20 1992
This is a comment to message 618.
There is/are comment(s) on this message.
--------------------------
1. An asynch line running at 38400 baud generates an interrupt every
260 microseconds. Four lines generate an interrupt every 65 microseconds
To handle an interrupt, registers must be saved, and the 8250 must
be serviced. Even on a "fast" machine this uses up quite some CPU time...
If the line should run in full-duplex, you'll get an interrupt every
32.5 microseconds. Of course, the interrupt handling routine will handle
multiple interrupts during one activation if more than one is pending.
Since the sioint routine keeps running in a loop as long as interrupts
are pending, this might cause lost clock tick interrupts! Check your
DOS clock (using TIME) after your program has run for an extended
period of time...
2. As to the RTS problem, one solution could be to do it from the timer
interrupt routine. When you get the THRE interrupt,
you could set a variable which contains the time at which the timer
interrupt routine should drop the RTS signal. The value you put into
the variable would be the current clock value + 270 milliseconds.
Or, even simpler, you could directly poll the line status register
from the timer interrupt routine. But this could cause "loss" of other
status information (e.g. parity error), since some bits are reset
simply by reading the register...
3. I don't know what causes your machine to "hang", but you could try this:
in the "while" loop of the sioint routine, you increment the value of a
byte inside the video display memory (eg B800:0). This way, you could
at least see if the interrupt routine got stuck in an infinite loop,
causing your machine to lock-up... If the interrupt routine is _not_
looping, i guess the problem is not related to the interface board or
the IRQ. Perhaps re-entrancy problems?
Luc
Read:
==========================
ibm.other/ctask #620, from bbordt, 319 chars, Mon Nov 16 09:13:56 1992
This is a comment to message 619.
--------------------------
Luc,
Thanks for the suggestions regarding Ctask and operation of four serial
ports at 38400. Also thanks for the previous correction you gave me about
using interrupt vector 0x72 for IRQ10 instead of interrupt vector 0x78.
You were right. Changing from 0x78 to 0x72 fixed the problem. Thanks
again.
Bruce Bordt
Read:
==========================
ibm.other/ctask #621, from wvantilburg, 579 chars, Thu Nov 19 02:01:23 1992
This is a comment to message 552.
--------------------------
Ok, so this reply is a little late, but anybody looking for good, cheap
multiport boards might try PC House (in LA, Denver, Miami, and other large
cities). They have a 4-port board for $70 ($60 wholesale) and an 8-port
board for about $110. I have been using them for years with no problems
except that they will NOT share interrupts with other serial boards.
The difference between these and the kilobuck boards is that these have
no on-board coprocesser or buffer, but they are still fast enough that
I can run six terminals off a 286 with good q^Eresponse at 19,200 baud.
==========================
ibm.other/ctask #622, from gworthey, 2246 chars, Wed Nov 25 03:11:24 1992
--------------------------
TITLE: CTASK spawning question...
I'm written a CTASK program that spawns COMMAND.COM and continues to execute
tasks (call them A, B and C) in the background. My problem is that spawning
a program gives all available memory to the child (COMMAND.COM). Since tasks
continues to execute in the background, and occasionally need memory (call
tsk_alloc()), I need to "reserve" some memory for tasks A,B and C.
The solution that I came up with is to allocate a large chunk of memory
BEFORE spawning COMMAND.COM. I then have a high-priority task, called
guardian(), whose sole task is to deallocate that chunk of memory RIGHT after
the spawn is completed. This seems to work ok, but it seems awkward. Isn't
there a more "graceful" way to do this???
Also:
I need to monitor how much memory is available for tasks A,B, and C. I have a
task called status() which constantly displays the available memory by
calling coreleft(). Status works fine before spawning COMMAND.COM. But once
it has been spawned, the memory displayed by status() is stuck at the memory
available JUST before spawning. Status continues to run, it just never
changes the memory available display. In other words:
I have 300k free before I start my spawn. I tsk_alloc(50000) (my workspace
for the tasks A,B,C) and status then displays 250k free (correct). Then it
spawns COMMAND.COM, and then guardian() free's that 50k workspace. But
thereafter, status CONSTANTLY displays 250k, no matter what happens. If I
load a program in the spawned COMMAND.COM, the memory display doesn't change.
And if task A/B/C allocates some of their (50k of) memory, it still doesn't
change the memory display.
By the way, mem.exe (dos) displays the correct memory available in the spawned
COMMAND.COM task.
How do I get the memory available for tasks A,B,C? and how do I get the
memory available in the spawned task??
Also, I wrote a little loop in the background (unspawned) task that
incrementally takes all the "workspace" (50k) memory I reserved. Once it
passes 50k, it crashes. I expected a crash, but the error that CTASK gives
is STACK overflow. Why is this??
Once again, Thomas, I must commend you on an EXCELLENT package!
Greg.
==========================
ibm.other/ctask #623, from gangelotti, 1875 chars, Fri Nov 27 10:04:39 1992
--------------------------
TITLE: Spawning, PSP and SDA.
I have some trouble using wonderful CTASK with an application that make
an extensive use of spawning .exes (compiled with BORLAND C++ 3.0).
I traced the problem up to the cause (I think) but I need everybody's help
(oh, Thomas, if you had a bit of time ...) to find a good solution
to overcome it. Here is the description:
a) Application one installs Ctask (primary), creates and starts some tasks
and makes <t_delay(0);>. A task spawns application two.
b) Application two installs Ctask (secondary) and creates some others
tasks. Then makes <t_delay(0);> to get them running.
Sometimes happens that one or more of tasks of appl. two runs
having a lot of problems with files, creating them with an odd handle or
*not* accessing handles created by another task in the same group.
After configuring Ctask with alternate display debugging, I see
some task of appl. two running with PSP (current, in SDA) setted with
wrong values. These tasks have problems with files.
I think that this happens when a primary task is scheduled-out just before
a secondary task is scheduled-in for the firts time. In this case the latter
has TCB's field -t_new- setted to 1, so it doesn't initialize DOS SDA
and then work over the pre existing SDA. When it is scheduled-out, it
copyes the *wrong* copy of DOS SDA (different from the SDA of the
application) in his internal image. This one will be used next time.
So files operations get garbled.
I tried to overcome this problem forcing a sequence of task's
execution raising priorities of the secondary tasks and lowering them
after first schedule. But this is not *THE* solution: high priority
system tasks can run just before them, and things , less often, get
wrong.
Now the questions: is my interpretation correct? There is a better
solution?
Thanks in advance for your help.
Giorgio Angelotti.
==========================
ibm.other/ctask #624, from gangelotti, 316 chars, Mon Nov 30 04:25:33 1992
--------------------------
TITLE: TSKSNAP and Current PSP.
In my last message I forgot to report that, making a snapshot with DBPSP
defined, a wrong value for current PSP is displayed. I think that the cause is
in an incorrect offset in swap_area for it. So the right offset could be
[0x0E] and not [0x10]. Is'nt it?.
Bye.
Giorgio Angelotti.
==========================
ibm.other/ctask #625, from compuservice
--------------------------
TITLE: Zmodem
We would like to add zmodem support to our CTask/NetBIOS based bulletin
board. I'm working with Unix/VMS zmodem stuff (rzsz.c sz.c rz.c ... ) but
it has lot of global variables and it's not easy to encapsulate it within a
class. Anybody here has addressed the same problem? We think that we can make
it from scratch reading zmodem docs but we don't want to reinvent the wheel.
By the way...we are using Btrieve/N 4.11b as the record manager for the
system. Anybody else using CTask & Btrieve ?
Thanks in advance !
==========================
ibm.other/ctask #626, from thajjar, 409 chars, Sun Jan 10 22:02:46 1993
--------------------------
TITLE: 16550 FIFO UART AND MULTIPLE SERIAL PORTS
HAS ANYONE USED THE NEW 16550 UART'S WITH CTASK TO MINIMIZE THE NUMBER
OF INTERRUPTS SENT TO THE CPU ? ALSO COULD SOMEONE GIVE A SIMPLE DESCRIPTION
OF HOW TO USE A 16 CHANNEL SERIAL CARD WITH CTASK AND POSSIBLY A CODE EXAMPLE
I AM PRESENTLY USING CTASK FOR A MONITOR AND CONTROL NETWORK WHICH WILL R
REQUIRE MULTIPLE RS-422 CHANNELS.
THANK YOU **** thajjar .
==========================
ibm.other/ctask #627, from akarna, 929 chars, Sat Feb 20 14:53:48 1993
There is/are comment(s) on this message.
--------------------------
TITLE: Interrupt stuff
I'm thinking about putting together a setup as follows: an "engine" will be
written using Ctask, and it will go TSR so that the "engine" will effectively
be running as a "background task". No problem there. I want foreground
pgms (which might not be written in C) to be able to communicte with the
"engine" by calling an interrupt. One idea I had was to do the following:
I would install my own interrupt service routine for some unused interrupt. Whe
n
a pgm calls the interrupt, this service routine checks for values in the registe
rs.
The service routine will interpret what's in the registers, and put an
appropriate message in a mailbox for the "engine". The "engine" will know
what to do based on this mailbox message. This way, forground pgms can
get the "engine" to do certain tasks.
Now, I have a minor concern: is this possible? If so, what kinds of things
.More..
should I watch for?
Thanks!
Read:
==========================
ibm.other/ctask #628, from twagner, 685 chars, Sun Feb 21 16:27:31 1993
This is a comment to message 627.
--------------------------
I don't see any major problems, or anything special you'd have to
watch out for, in your approach. If the applications were written in
C, they could use the primary/secondary communication features, which
make it really easy to communicate with a background "engine". But
for non-C apps, the software interrupt probably is the best solution.
The "tskdos" module already has a few special functions (calling
schedule and yield, and getting the variable block address) hooked to
INT 21. If you want to avoid hunting for an unused interrupt vector,
you could add code for a special INT 21 function, and process it
similar to the current @special_function detection and handling.
Thomas
Read:
==========================
ibm.other/ctask #629, from sentex, 1369 chars, Mon Feb 22 13:08:00 1993
--------------------------
TITLE: v24_install()
I have an application which uses CTASK's serial communications facility.
The application (a DOS app.) had no problems with communications until
I tried to use it in Windows 3.1. The v24_install function would nearly
always return LNULL indicating failure.
The solution was to modify v24_install(). This function makes certain
validity checks including a test to determine the actuall presence of
the hardware. The part of v24_install() that examines the hardware makes
an assumption about one of the device registers that apparently can't
always be held. To determine the viability of the port being installed
v24_install reads the 'modemcontrol' register of the port. If the high
order 3 bits are zero then another test is made for writability.
According to the specifications, these 3 bits are unused and should
be zero when read. However in the Windows environment they are most of
the time set to 1 in each bit. (There was actually one time when the bits
were set to zero but never since then. Puzzling.) I modified v24_install()
.More..
to ignore the high order 3 bits and to only perform a read/write test
on the remaining bits. Since then I have had no problems with communications
in the Windows environment.
If anyone can provide an explanation for the way the modemcontrol
register behaves in the Windows environment I would be most grateful.
==========================
ibm.other/ctask #630, from dmcalvache, 356 chars, Mon Mar 8 15:11:00 1993
There is/are comment(s) on this message.
--------------------------
TITLE: DOS EXTENDERS
I am writing applications under CTASK and I am short of normal DOS
memory. There are alot of TSRs *3270 emulation, Btrieve, Drivers, etc...
which left only 350K of normal DOS memory and the program (which is 340K)
cannot execute.
There is anybody who tried any of the DOS extenders like Phar Lap?
Any suggestions?
Daniel {DMCALVACHE}
Read:
==========================
ibm.other/ctask #631, from klrv, 202 chars, Mon Mar 15 14:03:43 1993
There is/are comment(s) on this message.
--------------------------
TITLE: Turbo Pascal
We would like to use CTASK in a project where we will have a mix of (existing)
Turbo Pascal code and Borland C code. Did anyone ever try to run a Turbo
Pascal task under CTASK?
Luc
Read:
==========================
ibm.other/ctask #632, from twagner, 520 chars, Wed Mar 17 14:52:27 1993
This is a comment to message 631.
There is/are comment(s) on this message.
--------------------------
> Did anyone ever try to run a Turbo Pascal task under CTASK?
Not that I know of, but in theory it should work. However, don't you
have to use Pascal for the main program? I wonder how the C runtime
library functions are supposed to work, especially the memory
allocation routines. CTask is quite independent of the C RTL as long
as you don't use dynamic allocation, but a bit of fiddling might be
required. I've not touched Turbo Pascal for a long time, so my memory
is a bit rusty on the linkage conventions.
Thomas
Read:
==========================
ibm.other/ctask #633, from twagner, 1303 chars, Wed Mar 17 14:52:37 1993
This is a comment to message 630.
--------------------------
> There is anybody who tried any of the DOS extenders like Phar Lap?
No answer yet to your question, so probably no one has tried. I've
stated it earlier, and I don't know anything new: I doubt that it
will be possible to get CTask to work inside a DOS extender. First
off, the kernel would have to be rewritten in 32-bit code (at least
partially). Not that much work, but work still. Then there's the
problem of handling interrupts and task switching in protected vs.
real mode. The reentrancy of the extender kernel. Integration into
DPMI. Lots of questions I don't have any answer to.
Well, not yet, anyway. I recently received Watcom C/386 and Borland
Pascal 7.0, both of which include a DOS extender. When I can find
some spare time (not in the next few months, but maybe in the
Summer), I might try to experiment a bit. Until then, I'd appreciate
any hints and tips anyone with more insight into this area might
have.
But back to your problem: If you're running out of memory, how about
overlays? About a week ago I got an update notice for the new version
of RTLink, which is supposed to work with multitaskers that switch
the stack (which CTask does). I haven't received the update yet, so I
can't say whether CTask will or will not work with it, but it might
be worth looking into.
Thomas
Read:
==========================
ibm.other/ctask #634, from klrv, 328 chars, Thu Mar 18 08:37:01 1993
This is a comment to message 632.
--------------------------
In the meantime, i found out that it's *impossible* to link Turbo Pascal
and BCC routines in a single executable. I was advised to buy Stonybrook
Pascal+, which is supposed to be compatible with TP 6.0.
I find it almost unbelievable that Borland didn't address this "problem"
in the latest Borland Pascal release (7.0)...
Luc
Read:
==========================
ibm.other/ctask #635, from harrellfreeman, 264 chars, Thu Mar 18 15:50:30 1993
--------------------------
TITLE: netware lite
I am running 3 PC's with ctask and netware lite. Everything is ok if
the serrver is on one ant the other 2 are running cliant and ctask
but when I put ctask and server on same unit I have random crashes.
anyone had any experiance?? tnx Harrell
==========================
ibm.other/ctask #636, from klrv, 391 chars, Tue Mar 30 05:04:05 1993
--------------------------
Currently, I'm struggling with the f
ollowing problem:
When I run 2 tasks in a CTASK program, one task calling DOS function 0B
(keyboard status) in a loop, and t
he other one spawning to COMMAND.COM,
I get very regularly "memory allopcation error - system halted".
I'm using DOS 5.0 and
BCC++ 3.1.
I think it is some kind of re-ent
rancy problem, but I can't figure it out.
Any ideas?
Luc
==========================
ibm.other/ctask #637, from amargerison, 709 chars, Wed Apr 21 04:54:55 1993
This is a comment to message 630.
--------------------------
I tried getting CTASK to work with 286|DOS-Extender from Phar-Lap about 6 months
ago without success. I never figured
out exactly what was wrong but the
extended loader wouldn't even load a program that had been linked with the
CTASK libraries even if none of the functions were ever called!
Basically, as far as protected mode programs go CTASK is not 'well behaved'
which is not a criticism of CTASK but more a comment on the constraints of
DOS.
We are currently writing an application that uses CTASK and is over 700K big
and we are using Borland C++ v3.1 overlays. As long as you only overlay in
one task Borland C++ doesn't mind as the stack remains the same.
Michael
[email protected]
==========================
ibm.other/ctask #638, from klrv, 1094 chars, Thu May 13 06:32:16 1993
--------------------------
RE: TSRs calling INT 21 while INDOS is set
Here's a possible problem with TSRs that a) are activated while the
CTASK scheduler is active and b) issue some INT 21 call
1. The CTASK scheduler sets the INDOS flag itself (in TSKASM.ASM) while
being active.
2. If a TSR ignores this flag, and still calls INT 21, the code in TSKDOS.ASM
that traps an INT 21 is supposed to block the offending TSR (or, in my
case, an interrupt routine in my program), calling yield() in a loop while
waiting for the INDOS flag to become reset.
3. The scheduler also sets the in_sched flag while executing, and a call
to yield() will return to the caller immediately if the in_sched flag
is set.
All this will cause an infinite loop inside the CTASK kernel in case INT 21
is called while the scheduler is active: @wait_dos_free (in TSKDOS.ASM) will
call yield() continuously, but yield() returns immediately without any action
since the in_sched flag is set as well...
I don't see a _simple_ solution to this problem - except, of course, not
calling INT 21 from a TSR :-)
Anyone else?
Luc
==========================
ibm.other/ctask #639, from compuservice, 336 chars, Mon May 17 19:56:23 1993
There is/are comment(s) on this message.
--------------------------
TITLE: High level debug
Is there an easy way to map the Instrptr info from snapshot into a source
code line number for debugging purposes? I'm using Borland C++ 3.1.
I was playing around with TDUMP and the .TDS files from TDSTRIP but could
not find an easy way to acomplish my goal (or should I say 'any way' ;-)
Thanks in advance!
==========================
ibm.other/ctask #640, from klrv, 342 chars, Tue May 18 08:00:34 1993
This is a comment to message 639.
There are additional comments to message 639.
--------------------------
You could first generate a map with line numbers (using the /l switch in the
tlink program), then you could take (any) routine, and calculate the difference
between the actual address of the routine (at runtime), and the address of the
same routine in the link map. This difference will be the same for _all_
addresses in your program!
Luc
Read:
==========================
ibm.other/ctask #641, from twagner, 662 chars, Tue May 18 16:22:20 1993
This is a comment to message 639.
--------------------------
Luc's suggestion to use the line number map appears to be the
best solution. You could try to dig into the TD files, Borland
provides info about the format under their "open tools" strategy, but
I'd suspect it would be more trouble than it's worth. Do you want the
line number display to be on-line, or do you only need it after
termination? An on-line calculation could take way too much time and
memory to be of much use. If you just want to translate a particluar
CS:IP after termination, you could simply load the prog into TD, and
set the CS:IP of the CPU window to the address. TD should then be
able to show you the source line of that statement.
Thomas
==========================
ibm.other/ctask #642, from compuservice, 416 chars, Tue May 18 20:09:35 1993
This is a comment to message 639.
--------------------------
Thanks Luc and Thomas for the suggestions. I don't need an on-line
calculation so both solutions are ok. The problem I see at first sight
is that CS should change if I load the program under TD (it's a big one with
multiple Code Segments, Overlays, etc). Thank you again for the ideas,
I will test them and I will tell you.
PS.- As I reread this message I see 'Overlays'. Hmm...seems to be a
problem... ;-)
==========================
ibm.other/ctask #643, from klrv, 244 chars, Thu May 20 03:40:07 1993
This is a comment to message 642.
--------------------------
I don't think that CS changes if you use TD386 (and since you're talking
about a _big_ program, you probably _have_ to use TD386 :-)
As for the overlays, if you use a breakpoint at a specific moment, you
should be able to see your code...
Luc
Read:
==========================
ibm.other/ctask #644, from sentex, 291 chars, Fri May 21 15:29:11 1993
--------------------------
TITLE: comm 3 and comm 4 support
I got Ctask 2.2C to work with comm ports 3 and 4
The problem was with the shared access to the IRQ lines.
When using comm 3 I had to disable comm 1's access to the IRQ
by setting Out 2 in the Modem Control Register to a 0.
Ctask is working like a charm now.
==========================
ibm.other/ctask #645, from compuservice, 878 chars, Sat May 22 20:33:34 1993
This is a comment to message 643.
--------------------------
Luc, the _big_ program is a BBS running under CTask distributed in 5
machines, 4 ATs acting as Front End Processor handling for example 'echo',
'xmodem retries', 'zmodem', etc. and a 386 as the server, communicating over
NetBIOS sessions. (It has 22 dialup lines, 3 local terminals and some
'virtual sessions' over NetBIOS at the moment). It runs Ok but some times
(once a week or so) it starts to slow-down, down, down and then after a few
minutes going down it crashes. I've deviced a command to log succesive
'snapshots' just before it crashes. I want to restart the system, take
these snapshots logs and analyze them offline in another machine. I am not
running the 'production system' under TD386. I think that if I load the
program under TD386 (in the same or another machine) CS would change.
Am I wrong?
==========================
ibm.other/ctask #646, from klrv, 39 chars, Sun May 23 01:37:28 1993
This is a comment to message 645.
There are additional comments to message 645.
--------------------------
I'll check it out! "I'll be back!"
Luc
Read:
==========================
ibm.other/ctask #647, from klrv, 338 chars, Sun May 23 02:08:48 1993
This is a comment to message 645.
--------------------------
I just executed this program with and without TD386:
----------------------------------------------------
void alfa(void)
{
}
void main(void)
{
printf ("%p\n", alfa);
}
----------------------------------------------------
...and it printed "366C:000E" both times!
Of course, you won't be able to use TD386 if you're using EMS...
Luc
.More..
Read:
==========================
ibm.other/ctask #648, from klrv, 1111 chars, Sun May 23 02:09:20 1993
--------------------------
---warning for EMS users---
When using the EMM386.SYS that came with my Windows 3.1 (on an HP Vectra),
I found out that EMS_SAVE_SIZE in tskconf.h should be set to 20 (instead of
16)! Otherwise the CTASK kernel won't save/restore the EMS page registers!
Thomas, perhaps it would be wise to check the return value of tsk_install_ems()
(it returns -1 if EMS_SAVE_SIZE is too small) in tsk_install_main(), to
return -1 if it is -1, _and_ to check the return value of tsk_install_main()
in install_tasker()?
---Pascal, CTASK and EMS---
By the way, I'm using a set of tasks, some written in BCC 3.1, some in
Stony Brook Pascal, and this works out _very_ well. One of the advantages
I have in the Pascal tasks: I can put all "global" variables on the stack
by simply embedding the complete module in a PROCEDURE. This way, I
can start up the same task (being this procedure) multiple times, using
different stacks (which I put in EMS). Since all variables are on the
stack in EMS, and the code for each task is shared, I can start up a _lot_ of
tasks with plenty of stack space, without running out of memory!
Hit <RETURN> for next active conf/topic.
Read:649
==========================
ibm.other/ctask #649, from compuservice, 397 chars, Sun May 23 20:52:06 1993
This is a comment to message 647.
--------------------------
Thank you Luc for your help!
From CTASK.DOC
> All other data, and even the task's stack, may be in EMS
> (although having stacks in EMS is generally not recommended).
Did you experiment any kind of problems with the Stacks in EMS ?
I have avoided using stacks in EMS but it is really a solution for my 'memory
hungry' BBS. Hmm...very nice...I can even swap stacks to disk on stopped
tasks...
==========================
ibm.other/ctask #650, from compuservice, 2098 chars, Sun May 23 20:52:52 1993
--------------------------
TITLE: Cleaning up memory allocated by a task
I've modified tskalloc.c to allow easy cleanup of memory allocated by a task.
It is working fine and I want to share the code with you.
'malloc()' saves a pointer tu the current tcb in the first four bytes. It
retries one minute if there is no memory (in my application it is likely that
one user releases memory within one minute. Of course you can comment out
that loop).
void *malloc (size_t size)
{
int i;
void *area = (void *) 0;
if (ctask_active) {
request_cresource (&alloc_resource, 0L);
size += sizeof (void *);
area = xalloc (size);
for (i=0; i < 60 && area == (void *) 0; i++) {
release_resource (&alloc_resource);
t_delay (18L);
request_cresource (&alloc_resource, 0L);
area = xalloc (size);
}
if (area != (void *)0) {
*((void **)area) = (void *) curr_task ();
area = (void *) (((char *)area)+sizeof (void *));
}
release_resource (&alloc_resource);
}
else
area = xalloc (size);
return area;
}
int tsk_heapfree (tcbptr tcbp) {
int rc;
tcbptr ptr;
struct heapinfo hi;
request_cresource (&alloc_resource, 0L);
if ((rc=heapcheck ()) == _HEAPOK) {
for (hi.ptr = NULL; (rc=heapwalk (&hi)) == _HEAPOK; ) {
ptr = (tcbptr) (*(void **)hi.ptr);
if (hi.in_use && ptr != LNULL && ptr->cqueue.kind == TYP_TCB && ptr ==
tcbp) {
free ((void *) hi.ptr);
hi.ptr = NULL;
}
}
}
release_resource (&alloc_resource);
return rc;
}
long tsk_heapused (tcbptr tcbp) {
long bytes;
tcbptr ptr;
struct heapinfo hi;
request_cresource (&alloc_resource, 0L);
for (bytes = 0L, hi.ptr = NULL; heapwalk (&hi) == _HEAPOK; ) {
ptr = (tcbptr) (*(void **)hi.ptr);
if (hi.in_use && ptr != LNULL && ptr->cqueue.kind == TYP_TCB && ptr == tcb
p)
bytes += hi.size;
}
release_resource (&alloc_resource);
return bytes;
}
Of course I have MALLOC_REPLACED defined TRUE and I'm using BC++ 3.1 (the
code works Ok with 3.0)
==========================
ibm.other/ctask #651, from klrv, 344 chars, Tue May 25 05:03:03 1993
This is a comment to message 649.
--------------------------
I didn't experience _any_ problem at all... but I don't know why the message
in the manual is there! One possible problem I can see is usage of the stac
from an interrupt routine (at a moment the correct EMS page frame is not
ative)...
If you need help on EMS usage, it's very easy, so if you need help I'll
upload a small code fragment...
Luc
==========================
ibm.other/ctask #652, from dave2, 238 chars, Tue May 25 22:21:09 1993
There is/are comment(s) on this message.
--------------------------
TITLE: where it CTASK?
I was looking for the new version of CTASK - the last one I had was
from several years ago, and I've misplaced it. There's no listings
area in ibm.other, and I couldn't get a keyword hit in ibm.dos or
ibm.utils.
Read:
==========================
ibm.other/ctask #653, from klrv, 162 chars, Wed May 26 03:19:55 1993
This is a comment to message 652.
There is/are comment(s) on this message.
--------------------------
A "sear listing" command in this conference is very helpfull in this case :-)
IBM.PC/LISTINGS contains what you need. Look for all files starting with CT*.*
Luc
Read:
==========================
ibm.other/ctask #654, from twagner, 270 chars, Wed May 26 15:58:14 1993
This is a comment to message 650.
--------------------------
Many thanks for sharing. A great idea, especially while debugging a
program. You'd have to be careful when passing pointers between
tasks, though, or introduce some special "global malloc", if you're
going to call this cleanup automatically on task termination.
Thomas
Read:
==========================
ibm.other/ctask #655, from twagner, 512 chars, Wed May 26 15:58:22 1993
This is a comment to message 651.
There is/are comment(s) on this message.
--------------------------
> I don't know why the message in the manual is there!
Because I'm timid. ;-) My fear was (is?) that interrupt handlers in
TSRs might switch EMS pages without switching to a private stack
first. If your stack is in EMS and this happens, well... goodbye
system! TSRs of this kind might be network drivers (Invisible Net can
optionally run from EMS) or cachers with delayed write that hook the
timer.
However, I've never checked to see whether any TSR actually does such
a thing. Am I just too cautious?
Thomas
Read:
==========================
ibm.other/ctask #656, from klrv, 164 chars, Thu May 27 12:08:17 1993
This is a comment to message 655.
--------------------------
The only TSR I'm using is SMARTDRIVE, which uses EMS for disk caching. No
problems till now. Perhaps we should try Sidekick 1.0, a well-known
bad-behaved TSR?
Luc
Read:
==========================
ibm.other/ctask #657, from dave2, 9 chars, Sat May 29 02:32:13 1993
This is a comment to message 653.
--------------------------
Thanks!
==========================
ibm.other/ctask #658, from compuservice, 191 chars, Mon May 31 20:26:00 1993
This is a comment to message 654.
--------------------------
global malloc: you are right Thomas. I'm using the following code to setup a
global block of memory :
char *buf = malloc (xxxx);
long *plTaskId = (long *) buf;
*(--plTaskId) = 0L;
==========================
ibm.other/ctask #660, from klrv, 1907 chars, Sun Jun 20 03:10:11 1993
This is a comment to message 659.
--------------------------
/* Sorry for the late reply, I was on holiday for 2 weeks...*/
/* Here's some example code that shows how to allocate a 16 Kbyte stack
in EMS
*/
short ems_handle;
unsigned short result;
/* All EMS functions are accessed through INT 67 */
/* The function is given in AH */
/* To allocate a single block of 16K in EMS, set BX to 1 (number of pages
to allocate, 1 page = 16K)
Function=43
*/
asm {
mov bx,1;
mov ah,0x43;
int 0x67;
mov ems_handle,dx;
mov result,ax;
}
/* Now we can refer to this 16K block in other EMS functions by using the
"handle" returned in DX. Compare this to a file handle after opening a
file
*/
/* After INT 67, AH contains 0 on success, error status otherwise */
/* Now to use this 16K block, it must be "mapped" into the "EMS segment",
which is a single 64K segment which contains 4 windows of 16K bytes
into EMS space. Each window can be mapped to another EMS block through
function 44.
DX=handle, AL=0..3, indicate which window is to be mapped,
BX=logical page within the block indicated by DX (more than one 16K page
can be allocated at a time through function 43, so if you specify BX=n
in function 43, BX can have values in the range 0..n-1 for function 44.
*/
asm {
mov ax,0x4400;
mov bx,0;
mov dx,ems_handle;
int 0x67;
mov result,ax;
}
/* If you're sure you will always use an EMS window in segment E000, you're
ready to use it now!
*/
create_task (mytcb, mytask, (char *)0xe0000000L, 16000, PRI_STD, "xx" TN("TEST"
));
/* If you want to know the segment address of the EMS page frame, you can
also use function 41.
*/
asm {
mov ah,0x41;
int 0x67;
mov result,ax;
mov ems_page,BX
}
/* "The MS-DOS Encyclopedia" contains a LOT of information about these
functions!
I hope this is somewhat clear. Don't hesitate to ask in case etc. etc...
*/
Luc
==========================
ibm.other/ctask #661, from compuservice, 4079 chars, Fri Jul 23 19:27:09 1993
--------------------------
TITLE: Task stacks^^^^^
I've been experimenting a very dificult to trace bug that crashes the system
when I press a key but _only_ after the system has been running for a long
while (for example all night long). It never occurs after startup. Of course
it can be a high level bug but I have checked the code many times in the last
two months.
One thing that probably has no connection with my problem but still looks
strange is that after startup the FreeStack of the same task with multiple
instances has different values. Here is a snapshot of the system 5 or 6
seconds after startup :
Task List (VM=0000):
Name State Queue Timeout TCB-addr Stackptr FreeStack Instrptr Prior
>> Group CSNMAIN (57c2:6a64), C:-MAIN- (57c2:726a), B:0000:0000, L:0000:0000
-MAIN- Stop 0000:0000 - 57c2:726a 5f9b:0fc6 428 4df9:0d03 61439
-KILLER- Stop 0000:0000 - 57c2:7192 57c2:7180 494 4df9:12ec 100
-TIMER- Wait 57c2:7447 - 57c2:7342 57c2:6f4a 428 4df9:2074 61440
-INT8- Wait 57c2:741a - 57c2:6cba 57c2:6c88 446 4df9:2074 100
VCONSOLE Wait 57c2:497d - 60c8:0008 60d6:03b2 926 4df9:2074 100
CONS0000 Wait 6214:0008 - 69e5:0008 69f3:01fc 440 4df9:2074 100
CONS0001 Wait 631e:0008 - 6a23:0008 6a31:01fc 440 4df9:2074 100
CONS0002 Wait 6428:0008 - 6a61:0008 6a6f:01fc 476 4df9:2074 100
CONS0003 Wait 6532:0008 - 6a9f:0008 6aad:01fc 440 4df9:2074 100
USRTSK00 Run 57c2:6a00 - 6add:0008 6aeb:0910 1908 06b8:0930* 100
USRTSK01 Wait 865c:0008 - 6be8:0008 6bf6:0a5c 2612 4df9:2074 100
USRTSK02 Wait 86a5:0008 - 6cf3:0008 6d01:0a5c 2612 4df9:2074 100
USRTSK03 Wait 86ee:0008 - 6dfe:0008 6e0c:0a5c 2612 4df9:2074 100
USRTSK04 Wait 8737:0008 - 6f09:0008 6f17:0a5c 2612 4df9:2074 100
USRTSK05 Wait 8780:0008 - 7014:0008 7022:0a5c 2612 4df9:2074 100
USRTSK06 Wait 87c9:0008 - 711f:0008 712d:0a5c 2594 4df9:2074 100
USRTSK07 Wait 8812:0008 - 722a:0008 7238:0a5c 2612 4df9:2074 100
USRTSK08 Wait 885b:0008 - 7335:0008 7343:0a5c 2612 4df9:2074 100
USRTSK09 Wait 88a4:0008 - 7440:0008 744e:0a5c 2612 4df9:2074 100
USRTSK10 Wait 88ed:0008 - 754b:0008 7559:0a5c 2612 4df9:2074 100
USRTSK11 Wait 8936:0008 - 7656:0008 7664:0a5c 2612 4df9:2074 100
USRTSK12 Wait 897f:0008 - 7761:0008 776f:0a5c 2612 4df9:2074 100
USRTSK13 Wait 89c8:0008 - 786c:0008 787a:0a5c 2594 4df9:2074 100
USRTSK14 Wait 8a11:0008 - 7977:0008 7985:0a5c 2612 4df9:2074 100
USRTSK15 Wait 8a5a:0008 - 7a82:0008 7a90:0a5c 2612 4df9:2074 100
USRTSK16 Wait 8aa3:0008 - 7b8d:0008 7b9b:0a5c 2612 4df9:2074 100
USRTSK17 Wait 8aec:0008 - 7c98:0008 7ca6:0a5c 2612 4df9:2074 100
USRTSK18 Wait 8b35:0008 - 7da3:0008 7db1:0a5c 2612 4df9:2074 100
USRTSK19 Wait 8b7e:0008 - 7eae:0008 7ebc:0a5c 2612 4df9:2074 100
USRTSK20 Wait 8ca2:0008 - 7fb9:0008 7fc7:0a5c 2612 4df9:2074 100
USRTSK21 Wait 8bca:0008 - 80c4:0008 80d2:0a5c 2604 4df9:2074 100
USRTSK22 Wait 8c13:0008 - 81cf:0008 81dd:0a5c 2612 4df9:2074 100
USRTSK23 Wait 8c5c:0008 - 82da:0008 82e8:0a5c 2612 4df9:2074 100
SENDER Wait 57c2:0094 925 83e5:0008 83f3:0d4e 3386 4df9:2074 100
CONSRX00 Wait 84f9:0008 - 84ff:0008 850d:0292 638 4df9:2074 100
CONSRX01 Wait 8540:0008 - 8546:0008 8554:0292 638 4df9:2074 100
CONSRX02 Wait 8587:0008 - 858d:0008 859b:0292 638 4df9:2074 100
CONSRX03 Wait 85ce:0008 - 85d4:0008 85e2:0292 638 4df9:2074 100
SYNCTASK Delay 0000:0000 12 8cf6:0008 8d04:03ae 926 4df9:0d03 100
Note for example that CONS0002 is the same code as CONS0000, CONS0001 and
CONS0003 but they have different FreeStack.
The same occurs with USRTSK06, USRTSK13 and USRTSK21.
Any comments?
==========================
ibm.other/ctask #662, from klrv, 754 chars, Mon Jul 26 08:41:57 1993
This is a comment to message 661.
--------------------------
I wouldn't worry too much about the different "freestack" values for
different tasks. The "freestack" values indicates the MINIMUM free stack
space that was ever left on the stack during the execution of that task.
This has nothing to do with the _current_ free stack space!
So if two instances of the same task execute different code, the minimum
stack space left will be different.
Note that "freestack" is calculated at the moment you call snapshot().
Initially, all stacks are set to contain 0 1 2 3 4 5 6...
snapshot() simply checks where this sequence is broken.
Of course, this doesn't solve your problem, does it?
Perhaps you might call snapshot() from time to time from a separate
task, to check if the "freestack" continuously decreases?
Luc
Read:
==========================
ibm.other/ctask #663, from jjanney, 545 chars, Thu Jul 29 01:16:06 1993
There is/are comment(s) on this message.
--------------------------
Title: fixup errors
I know this has been discussed before, but I'm still having trouble
with it. When I build ctask with Borland C 3.1 and TASM 3.1 and
then link the test programs (or anything else), I get fixup errors having
something to do with tsk_jmptab. I located tsk_jmptab in the file
tskstub.asm but I don't know enough assembler to do anything with that.
This is with ctask 2.2c from the listings here.
I'm trying to build ctask so I can turn on CHECKING and see how much
stack my tasks are using. Is there another way to do this?
Read:
==========================
ibm.other/ctask #664, from klrv, 809 chars, Thu Jul 29 04:04:23 1993
This is a comment to message 663.
--------------------------
1. I use the LARGE memory model to compile my application AND the
CTASK kernel, and I don't have this problem.
My CTASK.TC file contains:
reqopt=-c -zCCTASK_TEXT -K -N- -ml -a- -u
And CTSUP.TC contains:
!if !$d(model)
model=l
!endif
2. If this doesn't help, you could always check the stack space used by
means of the same approach CTASK uses: initialise all your
stacks with the sequence 00 01 02 03 .. ff 00 01 02 ...
When you want to check the maximum space used ever, check where
the sequence is broken. The routine stack_free() in TSKSNAP.C
contains the code to check, the routine create_task() in TSKTASK.C
contains the code to initialize. But I guess you won't need an
example :-) :-)
Luc
PS: Did you check message #610?
==========================
ibm.other/ctask #665, from jjanney, 178 chars, Thu Jul 29 16:23:14 1993
This is a comment to message 664.
--------------------------
Somehow I managed to overlook message #610. Setting CODE_SHARING to
FALSE solved the fixup problem. Then I had to set TSK_DYNLOAD to TRUE
before my program would run.
Thanks.
==========================
ibm.other/ctask #666, from compuservice, 317 chars, Thu Jul 29 21:54:55 1993
This is a comment to message 662.
--------------------------
I've run snapshot just after startup. Most of the tasks with different free
stack were waiting for an event (i.e. a user to log) so they _should_ have
the same freestack. I understand the difference between _current_ free stack
and snapshot's output. It is very extrange. I am sure that I am doing
something wrong...
==========================
ibm.other/ctask #667, from jenney, 201 chars, Thu Aug 26 04:56:33 1993
There is/are comment(s) on this message.
--------------------------
TITLE: COMPILER VERSIONS
We have had some luck with MS C 5.1 and would like to move up to 6.0 or ??
Has anybody heard of 8.0 ?
Will future versions of CTASK require a minimum level of MS C ?
bill j
Read:
==========================
ibm.other/ctask #668, from jenney, 284 chars, Thu Aug 26 05:06:58 1993
There is/are comment(s) on this message.
--------------------------
TITLE: NEXT RELEASE ?
We are happy users of release 2.2d of ctask, about to embark on a new
project based upon it.
Is a major new release planned any time soon? We may be able to wait
if it would save rework later.
Thanks in advance for any plans, projections or thoughts.
bill j
Read:
==========================
ibm.other/ctask #669, from karenk, 130 chars, Thu Aug 26 18:18:18 1993
This is a comment to message 667.
There are additional comments to message 667.
--------------------------
MSC 8.0 is actually MS Visual C++ 1.0. It contains both a Windows IDE and
DOS command line version of the C/C++ compiler.
Karen
Read:
==========================
ibm.other/ctask #670, from twagner, 925 chars, Fri Aug 27 16:08:32 1993
This is a comment to message 667.
--------------------------
> Compiler versions
As Karen already said, MSC 8.0 is Visual C++ 1.0. You'll have no
problems compiling CTask with it. I don't think older MSC versions
are still available, and I'd avoid using them. C 8.0 is a very stable
quality compiler, while 6.0, and especially 7.0, had lots of bugs.
As for future CTask versions requiring a minimum level... I'll try to
avoid it. As in the past, I will support at least MS and Borland.
Actually, there *is* a minimum level. While 0.1 basically was K&R C,
CTask 1.x and later uses ANSI function prototypes (and some other ANSI
C features), so you have to have an ANSI compiler, which excludes MS
versions prior to 5, and old Turbo C versions. I don't expect C to
change in such a major way again. Minor changes, such as the "far"
keyword being canged into "_far" and then "__far", are handled with
the definitions in TSK.H, so you only have to adapt one file, not all
.More..
sources.
Thomas
Read:
==========================
ibm.other/ctask #671, from twagner, 285 chars, Fri Aug 27 16:08:40 1993
This is a comment to message 668.
--------------------------
> Is a major new release planned any time soon?
Ah, plans and reality... I had planned to go to work on some
enhancements this Summer, but the other projects didn't get finished
in time (as usual). And there's still no free time in sight. So don't
expect anything major soon.
Thomas
==========================
ibm.other/ctask #672, from jjanney, 1373 chars, Fri Sep 3 18:48:35 1993
There is/are comment(s) on this message.
--------------------------
I'm trying to include a screen saver in a ctask program, and ran into
some unexpected behaviour using hotkeys, wake_task, and t_wait_key.
The main task calls t_wait_key with a five second timeout. If too
many timeouts go by, it blanks the screen. When it sees a keystroke,
it redraws the screen and resets the timeout counter.
This works fine, except that you have to press a "real" key to redraw
the screen, and I want it to redraw the screen when you press a shift
or control key. I defined a hotkey to do a wake_task(LNULL) whenever
any key is pressed.
tlink ss_hotkey;
void Taskfunc wake_main() /* wake up the main task */
{
wake_task(LNULL);
}
main()
{
...
/* create a hot key entry to activate when any key is pressed */
create_hotkey_entry(&ss_hotkey, 0, 0, 0, 0, 0, 0, 0,
(farptr) wake_main, TKIND_PROC, 1);
while (1)
{
key = t_wait_key(91);
...
}
}
What I found is that the call to wake_task always returns -1,
indicating that the main task is not waiting, but the main task
doesn't return from t_wait_key until it times out or sees a real
keystroke.
I can get the effect I want by having the hotkey set a flag that the
main task waits for, but I'm curious. Is this the intended behaviour?
If I did the wake from a task instead of a hotkey, would that bump the
main task off the read?
Read:
==========================
ibm.other/ctask #673, from twagner, 1411 chars, Sat Sep 4 10:01:29 1993
This is a comment to message 672.
There is/are comment(s) on this message.
--------------------------
> the main task doesn't return from t_wait_key until it times out
> or sees a real keystroke.
If you look at the source for t_wait_key (in tsksec.asm), you'll see
why: t_wait_key (and t_read_key) first wait for a flag that's set by
the keyboard int handler. You can abort this wait by tsk_wake, but
then the routine checks whether a char actually is available, and
again puts itself to sleep if not. In earlier versions, the int
handler stuffed all keyboard input into a pipe, so the tsk_wake would
have worked. However, this caused compatibility problems for some
apps, and especially TSRs, so I had to change the logic. :-(
The only way to terminate t_wait_key prematurely is to stuff
something into the keyboard buffer (INT 16, AH=5, CX=scan/char), or to
modify the source to check for some other flag.
To get around this limitation, why not create a separate "screen
blanker" task? You could use a timed flag wait - if it times out, you
activate the blanker, if the flag is set, you simply wait again. You
don't even need a hotkey for this, you can use the standard flag
tsk_key_avail:
void Taskfunc blank_task ()
{
extern flag tsk_key_avail;
forever ()
{
while (!wait_flag_set (&tsk_key_avail, BLANK_TIMEOUT))
; // do nothing until wait times out
-- blank the screen --
wait_flag_set (&tsk_key_avail, 0L);
-- restore the screen --
}
}
Thomas
Read:
==========================
ibm.other/ctask #674, from jjanney, 693 chars, Sat Sep 4 13:42:20 1993
This is a comment to message 673.
There is/are comment(s) on this message.
--------------------------
Ah, that explains it. I was confused because ctask.doc lists WAKE as a
possible return value for t_wait_key--that must be left over from the
earlier versions.
Right now I'm using a hotkey that sets a flag. The main task waits for
the flag, and then calls t_keyhit to see if there is a character to
read. This works but might be made more elegant, if only by
eliminating the hotkey and using the standard flag instead. I will
look into using a separate task. The situation is actually more
complicated than I first described: there are some background tasks
that write to the screen, either redrawing the screen if it is blank or
postponing the timeout.
Thanks for the help.
Jim Janney
Read:
==========================
ibm.other/ctask #675, from twagner, 990 chars, Sun Sep 5 09:18:16 1993
This is a comment to message 674.
--------------------------
I just checked again... the documentation *is* right! What I missed
is the check on the return value of wait_flag_set - if it's not 0,
i.e. if you do a tsk_wake, the routine does not loop at all.
Actually, your problem is a race condition. The hotkey handler is
invoked *after* the tsk_key_avail flag is set, that's why you get an
error on tsk_wake (why didn't I notice this before?), and that's why
the wait_key routine loops - it never notices someone tried to wake it.
The solution still is the same - change the logic such that you don't
have to wake up the task doing the wait_key. Oh, and you'd better not
copy the sample code I gave verbatim - a few things are missing. To
avoid race conditions (though nonfatal), you have to wait for the
flag changing state in the first loop, and you'd also have to make
sure you don't miss a flag. So maybe using the original flag isn't
that great an idea after all... Anyway, I hope it did give you a few
ideas on alternate solutions.
Thomas
==========================
ibm.other/ctask #676, from compuservice, 220 chars, Tue Sep 21 14:23:25 1993
--------------------------
TITLE: CTASK & BTRIEVE
I am having some problems using CTASK and BTRIEVE. Although I am protecting
calls to BTRIEVE with resources it is having a extrange behaviour.
Anybody using this combination ?
Thanks in advance.
==========================
ibm.other/ctask #677, from svalente, 541 chars, Wed Sep 29 16:12:33 1993
There is/are comment(s) on this message.
--------------------------
TITLE: Reentrancy
We are going to use EICON card for synchronous communication and the
libraries of functions supplied wiht^^th the card in our program based on
CTask. Some of the library functions are not^n-reentrant. We have no
access to the sources and yew^t we want to use the libraries.
Can we use them in our CTask program? Is it enough to protect calls
to these non-reentrant functions with:
...tsk_dis_preempt();
function_call();
tsk_ena_preempt();...?
Has anybody had a similar problem? I'd ^^^Thank you for any comments.
Read:
==========================
ibm.other/ctask #678, from twagner, 501 chars, Thu Sep 30 16:06:36 1993
This is a comment to message 677.
--------------------------
Turning off preemption is ok if the function you call is short. If
the routines could take longer to execute, you should use resource
protection, or restrict access to the library to one task. You should
also be aware that tsk_dis_preempt does *not* prevent a task switch
caused by the current task having to wait for some event, for example
if any of the EICON functions call DOS, it only turns off the timer
tick switch. Is it actually necessary to call the functions from
different tasks?
Thomas
Read:
==========================
ibm.other/ctask #679, from svalente, 1568 chars, Fri Oct 8 10:15:55 1993
There is/are comment(s) on this message.
--------------------------
TITLE: CTask 2.2D
Our application has a task that receives messages from other tasks ans logs
them in data log files. There could be up to 10000 items logged per day.
The logging task creates subdirectories for each "information channel" group
and each of these directories holds daily log files for a gibe^^ven channel.
Our program used version 1.? of CTask (install tasker takes only two
parameters), but we had only the libraries ad ^^nd header files (no sources),
so
we wanted to upgrade to a newer version of CTask. Having compiled the
program with CTask v. 2.2D (Borland C++ v. 3.1 compiler, huge model), we
observed several severe problems:
- corrupted data subdirectories - after quiting the program we cannot acces
log files, as some directories are corrupted; we tried to install the tasker
with IFL_DISK flag, or without it - same problem; note: we haven't had this
problem with the older libraries.
- our communications task freezes when the external modem it is supposed to
.More..
talk to is not plugged in or is not on; it freezes when we try to initialize
the modem prior to dialing up; we noticed that the problem occurs when we
execute functions v_^24_change_xxx() (we tried to change the order of stopbits,
baud etc. and it always freezes on the first v24_change_xxx() function); the
older version gracefully displayed error message and continued to run.
Is it possible that there were changes to CTask, that could trigger the above
described problems? Is there a problem with huge model? We will appreciate
any comments.
Thanks,
Jack and Sergio
Read:
==========================
ibm.other/ctask #680, from twagner, 1317 chars, Sun Oct 10 18:06:01 1993
This is a comment to message 679.
--------------------------
I sure hope that the changes in CTask aren't directly responsible for
the problems you describe. There were a number of changes from 1.x to
2.2, but none that (to my knowledge) would cause such effects. Alas,
one can never be sure...
The first I'd do to narrow down the problems would be to set CHECKING
to TRUE in tskconf.h, and recompile the kernel. While uninitialised
structures or bad pointers could always spell disaster, the effects
would be different, and probably more spectacular, in 2.2. Running
with checking enabled would catch most, if not all, such problems.
Lost clusters or currupted directories might be caused by some
interaction with a disk cacher. I have heard that CTask may get into
trouble if SmartDrv is installed with write caching enabled. We are
using CTask 2.2 in a fax server program that is quite disk intensive,
and have not had any such problems. Still, if you are using SmartDrv,
.More..
try disabling the write caching, or try a different cache program.
Finally, there might still be a subtle bug in huge model handling. I
must admit that I did very little verification for the huge model
code - I assumed that there shouldn't be much of a difference, but I
might be wrong. Is there any chance to get a stripped-down version
of your program to run with a different memory model?
Thomas
Read:
==========================
ibm.other/ctask #681, from twagner, 982 chars, Sun Oct 10 18:06:12 1993
--------------------------
TITLE: How to get more help
A general note on problem reports...
Please, if you run into a problem with CTask, GIVE ME CODE to work
on! Most of the reports I'm getting are rather unspecific on the
circumstances under which the problem can be reproduced. Although I
may be able to give some general hints on the direction of the
search, I usually am not able to pinpoint some specific bug in your
or my code unless I can see it with my own eyes, and let my debugger
run through it.
Try to reduce the program to the smallest test suite that evokes the
problem, be specific in your system description (especially the
contents of TSKCONF.H, all compiler switches and the compiler
version, plus the device drivers and TSRs loaded during run-time), and
send me the source. I'll keep it confidential, of course. You can
attach an archive with your code to a BIXmail message, send me a
.More..
disk, or upload it to our BBS at (+49) 3328-438 048 (V.32bis up to
14.400bps, MNP5, V.42bis).
Thomas
==========================
ibm.other/ctask #681, from twagner, 982 chars, Sun Oct 10 18:06:12 1993
--------------------------
TITLE: How to get more help
A general note on problem reports...
Please, if you run into a problem with CTask, GIVE ME CODE to work
on! Most of the reports I'm getting are rather unspecific on the
circumstances under which the problem can be reproduced. Although I
may be able to give some general hints on the direction of the
search, I usually am not able to pinpoint some specific bug in your
or my code unless I can see it with my own eyes, and let my debugger
run through it.
Try to reduce the program to the smallest test suite that evokes the
problem, be specific in your system description (especially the
contents of TSKCONF.H, all compiler switches and the compiler
version, plus the device drivers and TSRs loaded during run-time), and
send me the source. I'll keep it confidential, of course. You can
attach an archive with your code to a BIXmail message, send me a
disk, or upload it to our BBS at (+49) 3328-438 048 (V.32bis up to
14.400bps, MNP5, V.42bis).
Thomas
Read:682
==========================
ibm.other/ctask #682, from twagner, 1636 chars, Thu Oct 14 04:46:30 1993
This is a comment to message 679.
--------------------------
Well, at least one problem is solved, thanks to Jack sending source
code. Without an opportunity to step through the code, I constantly
overlooked the culprit, with the source it jumped at me after just a
few minutes. I'm posting the result here in case someone else runs
into the same trap. The problem:
> our communications task freezes when the external modem it is supposed to
> talk to is not plugged in or is not on; [...] we noticed that the problem
> occurs when we execute functions v24_change_xxx() [...] the
> older version gracefully displayed error message and continued to run
The reason for this behaviour is that in the older versions, the
v24_change_xxx functions worked asynchronous to the sio operation,
that is, they did not check whether the chip was active transmitting
stuff. Since transmit is interrupt driven, this could easily lead to
output being garbled when changes to word length, parity, or baud
rate were made on-the-fly. To avoid this, the new version waits for
the transmit pipe to empty, and the chip to complete the
transmission, before touching the chip. Now if the modem is off, and
you have handshaking set, the chip will never transmit (CTS is off),
so the transmit pipe will never clear. Since you can't specify a
timeout on the _change_ functions (for compatibility to older
versions), the task will hang indefinitely.
The solution is simple: if you get a timeout from v24_send, do a
v24_flush_transmit to clear the transmit pipe. This also avoids that
old stuff is transmitted to the modem when the user turns it on,
while your program assumes the transmission didn't take place.
Thomas
Read:683
==========================
ibm.other/ctask #683, from twagner, 604 chars, Thu Oct 14 04:46:40 1993
--------------------------
TITLE: TSK.MAC and the /ml switch
I generally use /mx to assemble the CTask assembler parts, so I
missed a problem with TSK.MAC and Turbo Assembler 3.1 when you use /ml:
The predefined symbol "??version" is defined with a *small* v at the
start (the docs list it as "??Version", so that's what I used). This
will lead to errors with the Globalfunc/Localfunc macros.
The symbol "@FileName" is used as "@filename", which causes assembly
errors when CHECKING is set to TRUE.
If you change all instances of ??Version to ??version, and @filename
to @FileName, the /ml switch will work as expected.
Thomas
Read:684
==========================
ibm.other/ctask #684, from jjanney, 609 chars, Tue Nov 9 21:34:13 1993
There is/are comment(s) on this message.
--------------------------
I've been experimenting lately with running ctask programs inside an
OS/2 VDM. Everything seems to work fine, except for one thing. I
have ctask compiled with CHECKING turned on. When I do something
silly, like calling a ctask function before I've started the kernel, I
get a message on the screen and then entire machine locks up. Not
just the VDM but all of OS/2. I think one time I had to use the reset
button to get things going again.
I spent a little time looking at the source code but lost the trail
somewhere in the assembly code. What does the CHECKING option do that
could have this effect?
Read:685
==========================
ibm.other/ctask #685, from klrv, 623 chars, Sat Nov 13 04:53:48 1993
This is a comment to message 684.
--------------------------
If you're using a debugger, try putting a breakpoint in the routine
_tsk_fatal_pmd, which is called whenever the CTASK checking detects an
error. I also had cases (in a DOS environment) where this routine blew up.
If you're using a stack in EMS memory, the stack checking within CTASK won't
work: the CTASK kernel forgets to set up the correct EMS pages before
performing a stack check. This will cause continuous "stack overflow"
messages. I disabled stack checking by putting "CHECKING=FALSE" just
in front of the last "IF NOT CHECKING" in tskasm.asm. Perhaps Thomas
can provide us with a _decent_ fix for this :-)
Luc
==========================
ibm.other/ctask #686, from jjanney, 583 chars, Sun Nov 14 13:09:47 1993
This is a comment to message 685.
There are additional comments to message 685.
--------------------------
I've found that I can usually use control-ESC to get back to OS/2 and
then shut down the VDM from there. I found a problem with heap
corruption in my program that may account for the other cases (I'm
experimenting with C++ and shooting myself in the foot a lot).
I'd been wondering why ctask takes such a drastic action in response
to a CHECKING error, and then it occurred to me: you can't just exit
back to DOS when ctask is installed. I trashed the CMOS settings once
by doing that, and ended up with a PC that wouldn't boot. Just
halting everything may be the safest course.
Read:
==========================
ibm.other/ctask #687, from twagner, 995 chars, Mon Nov 15 16:11:35 1993
This is a comment to message 685.
There is/are comment(s) on this message.
--------------------------
> the CTASK kernel forgets to set up the correct EMS pages before
> performing a stack check
Aaaarrrghhh... why didn't anyone tell me before? Looks like there's
some homework for me...
I'll check into the stack checking, and verify tsk_fatal_pmd. I
haven't experienced a crash in the pmd, but I may have missed
something.
I hope I can come up with a fix RSN, but this week is a bit chaotic.
We had a burglary at our company this Sunday, and among the computers
they took was one of the file servers - and the computer the server
was backed up to. No one cared to make a tape backup. :-( Luckily,
they didn't touch my computer (it's spread out on the table, so they
.More..
didn't know what to do with it), and the other damage is relatively
minor, but I'll still have to help to get everything back up, which
likely means scanning in the printouts of the server data and running
them through an OCR program. I'd love to kick the guy in charge of
the server somewhere where it really hurts...
Thomas
Read:
==========================
ibm.other/ctask #688, from jjanney, 167 chars, Tue Nov 16 02:02:02 1993
This is a comment to message 687.
There is/are comment(s) on this message.
--------------------------
> stack checking isn't supported in EMS...
Since the documentation says something to the effect of "Don't put
stacks in EMS", perhaps this isn't _too_ surprising :-)
Read:
==========================
ibm.other/ctask #689, from klrv, 1548 chars, Tue Nov 16 11:47:33 1993
This is a comment to message 688.
There is/are comment(s) on this message.
--------------------------
Well, I can report that putting stacks into EMS _does_ work _very_ well,
except for this stack checking stuff.
We have an application with a few (Stony Brook) Pascal tasks. Since Pascal
(as opposed to C) allows to nest procedures into other procedures, it's
possible to make a "task" which is in fact a procedure with all other
procedures used by that task nested inside this large procedure. The
variables which would otherwise be global, are simply put inside the large
encapsulating procedure. This will cause them to be on the stack.
All this means that this task is now completely re-entrant, and you can
clone it as many times as you want. All "global" variables of the task
will be on the stack, and each clone will be working on its own set of
variables.
This is impossible (or does anyone have a suggestion) in C: all variables
that are common to all the routines in a specific module have to be global
and therefore will be allocated on a fixed (fixed after relocation this is)
adress.
Our application includes a 3270 terminal emulator which is cloned 32 times,
to support up to 2 sessions on 16 lines in parallel. Once we had it running
in single line, single session mode, we didn't have to change a line to the
Pascal code: we just called create_task multiple times with the same task,
but with a different (EMS) stack of 16Kbytes. The code was shared between the
32 copies.
By the way, Stony Brook Pascal works _very_ well in combination with CTASK,
and the code generated will run circles around any C-compiler generated code.
Luc
Read:
==========================
ibm.other/ctask #690, from jjanney, 704 chars, Tue Nov 16 21:55:01 1993
This is a comment to message 689.
There is/are comment(s) on this message.
--------------------------
> putting "global" variables on the stack
I've been experimenting in C++ with defining tasks as objects:
class mytask
{
// declare task-local variables and the routines that need to
// access them here
public:
void run(); // the real task function
};
The function that you pass to create_task() looks like
void far taskfunc()
{
mytask instance;
instance.run();
}
This puts all the task-local variables on the stack and makes them
easily accessible to the task routines. I was interested in this
mostly for notational convenience, but I think it would also work well
with EMS. So far I haven't been pressed for memory, but it's nice to
know that EMS is an option.
Read:
==========================
ibm.other/ctask #691, from jjanney, 1404 chars, Tue Nov 16 21:55:29 1993
--------------------------
While ctask programs seem to run well inside OS/2 VDMs, I've found
that one of my programs (which constantly polls a device driver when
it has nothing else to do) makes everything else on the system run at
a crawl. In case anyone is interested, here is a way to fix that.
int dpmi_yield()
{
union REGS regs;
if (ctask_active)
preempt_off();
regs.x.ax = 0x1680;
int86(0x2f, &regs, &regs);
if (ctask_active)
preempt_on();
return (regs.h.al == 0);
}
Dpmi_yield yields the rest of the current VDM's time slice to the DPMI
scheduler. It returns 1 for success, 0 for failure. Failure probably
means that you're not running in a DPMI environment. The calls to
preempt_off() and preempt_on() are pure paranoia on my part: I don't
know if they're needed, and I don't want to find out the hard way.
A task is a handy way to get the program to call dpmi_yield() on a
regular basis.
void far yield_task()
{
while (1)
{
yield();
yield(); /* make sure we're really idle */
yield(); /* really really idle */
dpmi_yield();
}
}
After starting ctask, I call dpmi_yield() once: if it returns 1, I
start a task with yield_task() as its function. The priority of the
task and the number of times it yields before calling dpmi_yield()
could probably be adjusted more carefully: but I notice a dramatic
difference between having the yield task and not having it.
Read:
==========================
ibm.other/ctask #692, from klrv, 115 chars, Wed Nov 17 11:15:55 1993
This is a comment to message 690.
--------------------------
Thanks for this suggestion! I'll start learning C++ right away (when I'll
have some time to spare, that is :-)
Luc
==========================
ibm.other/ctask #693, from compuservice, 788 chars, Thu Dec 2 15:00:25 1993
There is/are comment(s) on this message.
--------------------------
TITLE: CTask and 5250 emulation
Anybody used CTask with IBM's 5250 emulation program ?
After several hours of correct operation we are getting a timeout error
message from an AS/400. The Ctask application continues running ok
and the emulation only restarts after we get out of the CTask program.
Running again the Ctask program (without booting or reinstalling the
emulation program TSR) restablishes the AS/400 session (after a new logon)
We tried (for months...) to find out any pattern in the problem without
luck. We reduced the CTask program to a minimum working set and the problem
is still there. We tried with IFL_STD, then with IFL_STD | IFL_INT8_DIR
but the problem is still there.
Any idea on what to do ?
PS.- ( we're using DP5250.COM; tried with DE5250, same thing ;-( )
==========================
ibm.other/ctask #694, from cblum, 608 chars, Fri Dec 3 09:05:22 1993
This is a comment to message 693.
There are additional comments to message 693.
--------------------------
Although not with Ctask, I helped a friend with a problem sounding similar.
It was in a hospital using PCs and a system 38 ( they didn't want to go to
the AS400 yet ). It seemed that there was some VERY timing sensitive code in
the IBM 5250 stuff... we could not get things to initialize in 'turbo' mode
on the PC ( 386, btw ). I wrote a speed shifter they run to slow down the
PC when loading the 5250 stuff, then speeding back up - worked fine. This
speed shift was an actual modification of system crystal frequency by flipping
bits in the chip control registers of the motherboard circuitry.
Chris Blum
Read:
==========================
ibm.other/ctask #695, from jjanney, 1060 chars, Fri Dec 3 17:44:22 1993
This is a comment to message 693.
There are additional comments to message 693.
--------------------------
I have a "telephone teller" application that uses ctask and 5250
emulation. It normally runs 24 hours a day and is in use at several
dozen sites. I had some problems with bad documentation for the
emulator, but nothing that sounds like what you describe. On the
other hand, I remember corresponding with someone who found that the
emulator would lock up as soon as the ctask kernel was started.
I do have one trick that I've found handy. You can't hotkey to the
emulator session while ctask is running. However, a task can safely
transfer to the emulator session, by setting on bit one at offset 0x178
and then issuing an interrupt 9. The task that does this is suspended
until you hotkey back to the DOS session, but the other tasks keep
running normally. I have the main task programmed so that when I hit
the F1 key, it sets a flag that prevents the other tasks from writing
to the screen, and then transfers to the emulator session. This lets
me watch the emulator session while the application is running -- very
handy for testing and debugging.
Read:
==========================
ibm.other/ctask #696, from klrv, 85 chars, Sat Dec 4 01:10:15 1993
This is a comment to message 693.
--------------------------
Did you try re-compiling Ctask with INT8_LATE set to TRUE? Just a wild
guess :-)
Luc
==========================
ibm.other/ctask #697, from compuservice, 367 chars, Sat Dec 4 10:28:16 1993
This is a comment to message 693.
--------------------------
Thank you guys for your help. jjanney's hint on debugging is really
appreciated (as we have experienced the same problem our work around
-until now- was to have a debugging task copying the emulator screen
once a second and showing it in a virtual ctask screen).
jjanney, can you tell us which flags are you using when you call
install_tasker ?
Thanks in advance!
Read:698
==========================
ibm.other/ctask #698, from compuservice, 1175 chars, Sat Dec 4 10:29:37 1993
This is a comment to message 690.
--------------------------
We're working with CTask and C++ for about two years. We have developed a set
of classes to use CTask, Resources, Counters, Flags, Pipes, WPipes, etc.
A task function receives as a parameter, a reference to its own class. You
define a task function as :
void MyTask (CTask& t) {
...
...
}
You can access any data on the 't' instance of class CTask. You can also
derive classes from CTask so the task functions receive a reference to the
derived intance (with all the local variables you need for the task).
class CTask also handle stacks in EMS, task restart, etc. (things that were
commented in this conference)
There is also a class 'VConsole' that sits on top of 'tskprf' to handle
unlimited 'Virtual Consoles' that can be accesed via hot-key. They are very
easy to use, for example :
pvcDebug = new VConsole (K_AF1); // You access it with Alt-F1
pvcDebug->printf ("Hello\r\n");
pvcDebug->attr (LHIGHLIGHT);
pvcDebug->getstr ("Sample prompt>", szBuf, MAXLEN);
I would be very glad to share this code with you. I need a couple of days to
put comments in english and prepare some sample code and I can upload it to
'ibm.other/listings' or wherever you want.
j ibm.other/ctask
Joining conference 'ibm.other', topic 'ctask'. 1 new message.
Read:
==========================
ibm.other/ctask #699, from jjanney, 68 chars, Sat Dec 4 22:21:27 1993
This is a comment to message 697.
--------------------------
The install_tasker flags are IFL_DISK | IFL_INT8_DIR | IFLR_PRINTER
==========================
ibm.other/ctask #700, from compuservice, 624 chars, Mon Dec 27 22:46:46 1993
--------------------------
TITLE: SPAWN & CORELEFT
I am having problems spawning a simple 'fax-convert' EXE from CTask. The
problem is that after several [unpredictable number of] times I spawn
the command, the CTask application runs out of 'coreleft ()' and every
malloc fails (including mallocs that probably issue the spawn function code).
There is only one task spawning DOS and (one of the last changes I did) I
am calling 'request_cresource (&allocrsc, 0L)' just before the call to
spawn function, and release_resource (&allocrsc) after.
I've tried with two completely different Fax-Convert programs; same
result.
Any idea ?
aTdHvAaNnKcSe
ibm.other/ctask#701, from cblum, 917 chars, Tue Dec 28 17:15:27 1993
This is a comment to message 700.
--------------------------
I don't really have a suggestion on your difficulty other than I suspect
the 'alloc_cresource' for the allocation resource has no real use around
the spawn call... each spawned task manages its own totally separate
heap, even in large code models. It is more likely you have a 'memory leak'
in your code somewhere ( i.e. a malloc without a corresponding free ). As
to tracking it down, maybe a malloc tracker ( I have seen a couple around
that wrap malloc-free with tracking info and will isolate this problem
fairly well ). If you have multilple tasks using malloc-free ( a common
thing ), then it is possible you have a problem there, as most C systems
use the DOS calls to get and free DOS memory blocks. One would hope that
the DOS filter in Ctask would prevent a problem there ( and indeed in my
experience it works quite well ). Again, I suspect mismatched malloc-free
pairs are biting you somehow.
Chris Blum
last
==========================
ibm.other/ctask #702, from compuservice, 702 chars, Wed Dec 29 20:48:22 1993
This is a comment to message 701.
--------------------------
You're probably right, it is a more than 100000 lines program and these kind
of bugs can exist. The extrange thing is that I have a task showing
'coreleft ()' and it drops from about 100k free to less than 20k after
several spawns
If I comment out the 'spawn' call the system operates without problems.
Coreleft goes down a little bit as the system runs but it always return
to the same value when all lines are waiting for calls (it is an Audiotex
system).
I think I can write a 'malloc tracker' (I like the idea and I think it's
a MUST) but probably you can point me out to a public domain source to
look for.
Thanks in advance and I wish all of you CTaskers a Happy New Year !!
--
Alejandro
==========================
ibm.other/ctask #703, from cblum, 277 chars, Thu Dec 30 01:00:51 1993
This is a comment to message 702.
There are additional comments to message 702.
--------------------------
I'll have to look around... I think I saw one on CompuServe. BTW, don't
forget to acquire the allocation resource around the coreleft call -
it runs the memory chain and could get hosed ( technical term ) if a
task manages to change it while you're looking at it.
Chris Blum
Read:
==========================
ibm.other/ctask #704, from cblum, 492 chars, Thu Dec 30 14:57:49 1993
This is a comment to message 702.
There are additional comments to message 702.
--------------------------
Further thoughts... Make sure you have front-ended ALL malloc routines in
your run-time library so that they get the Ctask allocation resource. If
you are just using tsk_malloc routines, then routines within your run-time
library that internally use malloc are not serialized. Are you using
Microsludge C or the real C ( Borland... ha ha )? If Borland, I can give
you some code I did which allowed me to use 3rd party libs ( C-Scape in
particular ) without any mods to the libs.
Chris Blum
Read:
==========================
ibm.other/ctask #705, from klrv, 222 chars, Sat Jan 1 07:47:06 1994
This is a comment to message 702.
--------------------------
Don't forget that the fopen() routine calls malloc() internally to allocate
a 512 byte buffer (which gets released at fclose() time). Possibly,
spawn() could call this internally to load the executable into memory...
Luc
==========================
ibm.other/ctask #706, from compuservice
--------------------------
I have 'MALLOC_REPLACED'. I am not protecting 'coreleft ()' (I will do so).
I have another little system with the same problem that only shows
'coreleft ()' on request so coreleft () should not be the problem.
I think I am having the same problem 'gworthey' told us in message #622.
I've tried his solution (allocating some memory before spawn and freeing
it with a high priority task). Things seems to work a little bit better
(more time running) but I still run out of coreleft ().
Thank you for your help
==========================
ibm.other/ctask #707, from cblum, 798 chars, Wed Jan 5 10:38:26 1994
This is a comment to message 702.
There are additional comments to message 702.
--------------------------
Further further info:
Under Borland, all of the spawn routines use malloc to build the command
line for the spawning process ( I checked the RTL source code ), so it is
imperative to front-end all malloc routines. I found that the 'standard'
code was not adequate for the Borland stuff, and developed my own version
of 'malloc-replaced' code for BC++ 3.1 ( and now 4.0 ). I shall put it
together in coherent form and post it here for you. I have had no trouble
with spawns in the protected environment. BTW if you are using any directory
calls ( findfirst / findnext ), you should also create a resource and wrap
them... the DOS filter protects within the actual directory code, but the
RTL routines set and restore the DTA, which can cause grief if you do dir
calls in multiple tasks.
Chris Blum
Read:
==========================
ibm.other/ctask #708, from cblum, 985 chars, Wed Jan 5 11:32:16 1994
This is a comment to message 702.
There are additional comments to message 702.
--------------------------
Well... hoof-in-mouth. As I research further, things become muddy. In the
Borland run-time library, coreleft() [ really farcoreleft() in large model ]
does NOT run the memory chain... it merely looks at two heap control variables
and returns the difference. This is fine, even if you are tasking, as all
tasks use the same heap. However, when you spawn, a new heap is created, and
coreleft() does not reflect any activity in the new heap, because the heap
variables looked at are not updated by the spawned program. A ( possible, but
crude ) solution would be to use allocmem() or _dos_allocmem() to try to
allocate an impossibly large DOS memory block via DOS call 0x48. This will
return the largest DOS block size currently available, which is system-wide,
not just within the C heap management. This call should be already serialized
by the Ctask DOS filter. I suspect the values returned by coreleft() you are
looking at do not reflect the actual status of your system.
Chris Blum
Read:
==========================
ibm.other/ctask #709, from cblum, 1247 chars, Wed Jan 5 14:46:27 1994
This is a comment to message 702.
There are additional comments to message 702.
--------------------------
Well, here goes again...
CAVEAT: ALL COMMENTS HERE APPLY TO BORLAND C RUN-TIME LIBRARY 4.0 ( but
probably 3.1 also ) *****
It looks like the situation can be handled using the sbrk() function. In the
large model, this changes the data segment allocation size to DOS via DOS
function 0x4A. The heap is within this segment, above the stack. Issuing
sbrk(30000) will reserve 30000 bytes in the heap ( not actually allocate,
just reserve ) for use by the unspawned program. The spawned program will
get the remaining memory to use until it returns. From looking at the code,
it seems this will take care of the problem, but please post whether this
is true or not. Also, note the parm for sbrk() is an int, and negative vals
reduce the heap size. Also, always use a multiple of 16 bytes ( paragraph
size ) when calling sbrk(). It seems to me the procedure should be:
sbrk(30720); /* two calls to get 50K reserved */
sbrk(20480);
.More..
spawn....
sbrk(-20480);
sbrk(-30720); /* un-reserve the 50K - normal management again */
The run-time adjusts the DOS block at brk()/sbrk() time, not at spawn time,
but that should not make a difference to us here. I'll be really interested
in the results... please post!
Chris Blum
Read:
==========================
ibm.other/ctask #710, from cblum, 841 chars, Thu Jan 6 08:02:11 1994
This is a comment to message 702.
There is/are comment(s) on this message.
--------------------------
Well... all 4 hooves in mouth! Spent more time analyzing Borland run time.
The code internally issues a brk() every time the allocated memory crosses
a 1K boundary. It remembers the highest available heap address to save time
on later calls. This means that what I said in previous messages will not
work unless no malloc's / free's are done while a task is spawned... not a
good thing, eh? Fixing this ( rather, making it work - can't call it a bug
as the Borland run-time is not designed for multi-tasking ) will require a
malloc replacement for Ctask which handles memory ( slightly ) diffrently
to allow tolerance of things changing underfoot. I will look into what I
can do, as I will need it also, and if I can generate something soon, I'll
sure post it for all ( and I'll sure try to make it MicroSludge compatable,
too ).
Chris Blum
Read:
==========================
ibm.other/ctask #711, from klrv, 148 chars, Fri Jan 7 04:31:04 1994
This is a comment to message 710.
--------------------------
Wait wait! I solved this already! Perhaps you can use my kludge :-)
I'll upload it asap (I'll try to put a few useful comments in the code ;-)
Luc
==========================
ibm.other/ctask #712, from klrv, 345 chars, Sat Jan 8 05:36:21 1994
This is a comment to message 710.
There is/are comment(s) on this message.
--------------------------
OK, I just uploaded MYALLOC.C to BORLAND/LISTINGS. Don't know if it works
for MicroSludge. Perhaps you could verify? Let me know if you find bugs.
***warning*** I know you'll be tempted to call InitHeap(). DON'T!
It should be fairly easy to modify the routines to implemented a
non-contiguous heap (i.e. one consisting of multiple areas).
Luc
Read:
==========================
ibm.other/ctask #713, from klrv, 520 chars, Sun Jan 9 05:48:41 1994
This is a comment to message 712.
There is/are comment(s) on this message.
--------------------------
I forgot to mention something: the malloc() and free() routines in MYALLOC.C
are _NOT_ re-entrant! It's extremely easy to make them re-entrant, however,
by adding request_resource() and release_resource() calls.
Once again, remeber that malloc() is called BEFORE your main program is
executed. So, you should use a flag which you set in the main program to
indicate that the resource has been created, and that CTASK has started.
If the flag isn't set, you shouldn't be calling the request and release
routines...
Luc
Read:
==========================
ibm.other/ctask #714, from gangelotti, 1142 chars, Tue Jan 11 05:48:32 1994
--------------------------
TITLE: Spawning and critical error handler.
I have some problems in interactions between CTASK22C and a
home-made int24h handler. The handler is like the following:
_int24handler PROC FAR
ASSUME CS:@code
push ax
push bx
push cx
push es
mov ah, 59h
xor bx, bx
int 21h
pop es
pop cx
pop bx
pop ax
mov al,3 ; return FAIL
iret
and is intended to return FAIL to dos and nothing else.
Main program with handler, compiled with BORLAND C++ 3.1 spawns
another one, installing a secondary copy of CTASK. When I
simulate
an error (drive A: door open on access, for instance) all goes
right,
until we reenter from spawn.
Main program, after executing "wait_dos_free" and a schedule
with "yeld", loops in function "tsk_scheduler", module
TSKASM.ASM, label "wait_elig". Maybe I made some dangerous
assumption. What is going wrong? Any help would be appreciated.
.More..
Thanks.
Read:
==========================
ibm.other/ctask #715, from klrv, 512 chars, Tue Jan 11 15:13:58 1994
This is a comment to message 713.
--------------------------
By the way, it takes a while before a file that's uploaded in listings
actually appears in listings, due to the time it takes the moderator
to "check" the file (against viruses, I presume). So you'll have to be
patient a little bit. I just checked, and MYALLOC.C still didn't appear :-(
Since I uploaded the source, and no binary, it should be easy to check there's
no virus ;-) Anyway, if by Thursday it still didn't appear in borland/
listings, I'll post it as a message here (it's only about 150 lines).
Luc
==========================
ibm.other/ctask #717, from klrv, 5148 chars, Thu Jan 13 03:42:00 1994
--------------------------
/* myalloc.c : "private" heap implementation of malloc() and free() */
/* Since the Borland moderator seems to have fallen into a deep coma,
I'm uploading myalloc.c here as a message. I hope Thomas won't kill me
for this :-)
*/
/* Tested with BCC 3.1 */
/*
Each block of the heap has the same structure:
byte TAG (used, free or begin/end of heap)
long SIZE
char data[SIZE]
long SIZE
byte TAG
TAG is used to check if block that is being freed can be collapsed
with preceeding or following block.
There's _no_ list of "free" blocks. Instead, the current "top" of
the heap (i.e. the last free block) is remembered in the variable
HeapIndex. If the free block at offset HeapIndex is not large enough
to accomodate the size being requested, malloc() will start scanning
through the blocks (free _and_ allocated) till it finds one that's
large enough
*/
#include <stdio.h>
#include <dos.h>
/* Tag types which are set at beginning and ending of block:*/
#define TAG_USED 1 /* Used block */
#define TAG_FREE 2 /* Free block */
#define TAG_END 3 /* Begin or end of heap */
#define HEAPSIZE 40000L
static unsigned long HeapIndex = 0xffffffffL;
static char *myheap;
/* Alternatively, this could be defined as myheap[HEAPSIZE]*/
/*-----------------*/
void Init_Heap(void)
/*-----------------*/
{
/* DON'T CALL THIS ROUTINE! It's called automatically from the first
malloc(), which probably will take place _before_ the main program
is executed, when the runtime library startup code is opening standard
input
*/
/* We want the heap at a specific place in memory */
myheap = MK_FP(0xd600,0);
/* Set "end" TAG at beginning and end of heap */
myheap[0] = myheap[HEAPSIZE-1] = TAG_END;
/* Initially, heap contains single free block */
myheap[1] = myheap[HEAPSIZE-2] = TAG_FREE;
*((unsigned long *)&myheap[2]) =
*((unsigned long *)&myheap[HEAPSIZE-6]) = HEAPSIZE-12;
HeapIndex = 1;
}
/*------------------*/
void *malloc(size_t size)
/*------------------*/
{
unsigned long i, this_size;
long remainder;
if (HeapIndex == 0xffffffffL)
Init_Heap();
if ((HeapIndex+size)>=(HEAPSIZE-21)) {
/* Not enough free space at end of heap. Search for hole that's
large enough */
i = 1;
do
{
this_size = *((unsigned long *)&myheap[i+1]);
if ((myheap[i]==TAG_FREE) && (this_size >= size)) {
/* Found free block of good size. Is it much too large? */
remainder = this_size - size -10;
if (remainder > 100L) {
/* Yes, it is. Let's split it! */
*((unsigned long *)&myheap[i+this_size+5])=
*((unsigned long *)&myheap[i+size+11]) = remainder;
myheap[i+size+10] = TAG_FREE;
}
else
/* No, don't split. Just allocate larger block than requested,
to prevent fragmentation */
size = this_size;
*((unsigned long *)&myheap[i+1]) =
*((unsigned long *)&myheap[i+size+5]) = size;
myheap[i] = myheap[i+size+9] = TAG_USED;
if (HeapIndex==i)
/* Last block on heap allocated! Adjust HeapIndex */
HeapIndex = i+size+10;
return &myheap[i+5];
}
i += this_size + 10;
}
while (i < (HEAPSIZE-1));
if (i != (HEAPSIZE-1))
printf("Corrupt heap!\n");
return (void *)0L;
}
i = HeapIndex;
HeapIndex += size+10;
/* Free block becomes smaller */
myheap[i+size+10] = TAG_FREE;
*((unsigned long *)&myheap[i+size+11]) =
*((unsigned long *)&myheap[HEAPSIZE-6]) = HEAPSIZE-11-HeapIndex;
myheap[i] = myheap[i+size+9] = TAG_USED;
*((unsigned long *)&myheap[i+1]) =
*((unsigned long *)&myheap[i+size+5]) = size;
return &myheap[i+5];
}
/*------------------*/
void free(void *block)
/*------------------*/
{
char *p;
unsigned long size;
unsigned long size_prev;
unsigned long size_next;
if ((block<&myheap[6]) || (block>&myheap[HEAPSIZE-7])) {
printf ("Illegal ptr: out of range\n");
return ;
}
p = block;
size = *((unsigned long *)(p-4));
if ((*(p-5)!=TAG_USED) ||
(*(p+size+4)!=TAG_USED) ||
(size != *((short *)(p+size)))) {
printf ("Illegal ptr: size incorrect (%d,%d) or invalid tag (%d,%d)\n",
size,(*((unsigned long *)(p+size))),
*(p-5), *(p+size+4));
return ;
}
*(p-5) =
*(p+size+4)= TAG_FREE;
/* Collapses with previous? */
if (*(p-6)==TAG_FREE) {
/* Yes! */
size_prev = *((unsigned long *)(p-10));
*((unsigned long *)(p-size_prev-14)) =
*((unsigned long *)(p+size)) = size_prev+10+size;
p = p-size_prev-10;
size += size_prev+10;
}
/* Collapses with next ?*/
if (*(p+size+5)==TAG_FREE) {
/* Yes! */
size_next = *((unsigned long *)(p+size+6));
*((unsigned long *)(p+size+10+size_next)) =
*((unsigned long *)(p-4)) = size_next+size+10;
size += size_next+10;
}
/* Was this the last block allocated? */
if ((p+size+5)==&myheap[HEAPSIZE-1]) {
/* Yes. We can lower heapindex! */
HeapIndex = p - &myheap[5];
}
}
Read:
==========================
ibm.other/ctask #718, from dgh, 132 chars, Fri Jan 14 00:09:26 1994
This is a comment to message 714.
--------------------------
You need to save BP, SI, DI, and DS as well, because the get extended error
code call destroys those registers.
,
|) /\ \/ | +)
==========================
ibm.other/ctask #719, from klrv, 217 chars, Tue Jan 18 02:00:50 1994
This is a comment to message 713.
There is/are comment(s) on this message.
--------------------------
I found out that it's necessary to post a message to the borland moderator
to make sure that an uploaded file appears in listings. I
appeared in the borland/listings area :-)
By the way, did you try the routines?
Luc
Read:
==========================
ibm.other/ctask #720, from cblum, 159 chars, Tue Jan 18 16:56:16 1994
This is a comment to message 719.
--------------------------
Just got the message from here with the code... looking at it. Also writing
up a complete description of the 'problem' as I understand it to post here.
Chris.
Read:
==========================
ibm.other/ctask #721, from gangelotti, 218 chars, Thu Jan 20 05:05:57 1994
This is a comment to message 718.
There is/are comment(s) on this message.
--------------------------
Thanks for your suggestion, dgh. I have made changes to the
code to save all registers, but program hangs-up in the *same*
way. Have you or anybody else suffered similar problems with
critical error handler and CTASK?
Read:
==========================
ibm.other/ctask #722, from klrv, 1178 chars, Thu Jan 20 08:29:55 1994
This is a comment to message 721.
--------------------------
Bad news: I don't know what's causing your problem.
Good news: I have some (wild :-) guesses.
1. Try to do without your own critical error handler, by using a
feature (undocumented, but works since DOS 3.??) of COMMAND.COM.
In your CONFIG.SYS, you add a "/f" switch to the startup
of command.com, like this:
shell=c:\dos\command.com c:\dos\ /p /e:600 /f
This will cause all "abort retry ignore fail" questions to be answered
by default by "fail".
Perhaps this does what you want it to do?
2. I don't know what kind of program you spawn, but if you spawn command.com
it will replace int 24 by its own.
3. Instead of writing your INT24 replacement in ASM, you could write it
in C:
void interrupt myint24
(unsigned bp,unsigned di,unsigned si,unsigned ds,
unsigned es,unsigned dx,unsigned cx,unsigned bx,
unsigned ax)
{
ax = (ax &0xff00) | 3;
}
and install it with
setvect(0x24,myint24);
I have tried myint24 with CTASK, and it doesn't seem to give any problems.
4. I don't think it has anything to do with this, but did you read my
message #605? Perhaps it's worthwile to apply this small patch to
TSK.MAC...
Luc
Read:
==========================
ibm.other/ctask #723, from ori, 62 chars, Wed Jan 26 02:01:06 1994
There is/are comment(s) on this message.
--------------------------
TITLE: Ctask program
Where can I find the Ctask program?
Ori
Read:
==========================
ibm.other/ctask #724, from klrv, 77 chars, Wed Jan 26 08:06:49 1994
This is a comment to message 723.
--------------------------
It's in IBM.PC/LISTINGS: ctask22d.lzh (you'll need LHARC to decompress)
Luc
==========================
ibm.other/ctask #725, from compuservice, 420 chars, Wed Feb 2 21:58:43 1994
This is a comment to message 722.
--------------------------
Thanks all of you for your help. I will try to use your 'mymalloc' in
my code. I must be able to free memory allocated by a given task (see my
message #527) so I must make some changes in your code (I'm thinking on
using a diferent heap [probably in EMS] for each task).
Also thank you for the hint on 'findfirst/findnext', I have some
background tasks scanning spool directories so I must protect them with
resources.
==========================
ibm.other/ctask #726, from klrv, 330 chars, Thu Feb 3 03:40:27 1994
This is a comment to message 725.
--------------------------
Just in case you overlooked this: if you put the heap in EMS, you can't
pass a pointer to an allocated block from one task to another (because
the address could be the same, but the heaps different), and you can't access
a block in the heap from an interrupt routine (since the wrong heap might
be present in the EMS window)
Luc
==========================
ibm.other/ctask #727, from compuservice, 307 chars, Sat Feb 12 23:41:57 1994
There is/are comment(s) on this message.
--------------------------
TITLE: MALLOC_REPLACED
I have MALLOC_REPLACED but found that BC++ (3.1 at least) is calling
'farmalloc' directly (which is not protected with alloc_resource).
'operator new' is calling 'malloc' but '_vector_new' is calling 'farmalloc'
directly. 'strdup' seems to be calling 'farmalloc' too.
Be carefull.
==========================
ibm.other/ctask #728, from cblum, 515 chars, Sun Feb 13 14:09:24 1994
This is a comment to message 727.
--------------------------
Indeed, BC++ 3.1 and 4.0 both need a little more than the 'standard'. You
need to serialize farfree, farmalloc and farrealloc in addition to free,
malloc and realloc... BUT you also need to make sure ctask has initialized
before serializing. If ctask is not ( yet ) active, you should bypass the
serialization. You do NOT need to worry about calloc or farcalloc, as they
just call malloc. I just test the 'ctask_active' flag in my modified version
of TSKALLOC.C ( which I will post here if others are interested ).
ibm.other/ctask #729, from compuservice
Here is my modified version of tskalloc.c; You'll see code to support a
task garbage collector (see message#527). Also malloc (and now farmalloc)
never returns a NULL pointer if CTask is active. It loops forever releasing
alloc_resource, waiting one second and trying again. This approach saves me
a lot of error checking (though it is probably not suited for certain
applications).
---tskalloc.c---
/*
--- Version 2.0 90-10-12 10:33 ---
TSKALLOC.C - CTask - Dynamic memory allocation interface
Public Domain Software written by
Thomas Wagner
Ferrari electronic Gmbh
Beusselstrasse 27
D-1000 Berlin 21
Germany
This file is new with Version 1.1
This module contains the memory allocation functions that are needed
if TSK_DYNAMIC is defined.
Version 2.1 adds the tsk_calloc and tsk_realloc functions, and
provides an option to compile direct malloc replacements. This
option may be used if the C-runtime library functions have been
renamed, so that all external functions using the allocation
routines arrive here. If you have the runtime library source code,
it is relatively painless to change the names. Without the source,
you will have to resort to a binary editor to patch the entry names
directly.
*/
#include "tsk.h"
/* [compuservice] I use the following counters just for debugging purposes */
long lcMalloc = 0L;
long lcFree = 0L;
long lcRealloc = 0L;
#if (TSK_TURBO)
#include <alloc.h>
#else
#include <malloc.h>
#endif
/*
Define MALLOC_REPLACED TRUE if you replaced the C run-time library
entries for malloc/free/realloc with UPPERCASE names, as suggested
in the manual.
*/
#define MALLOC_REPLACED TRUE
/*
You can replace the following definitions to use different
allocation routines if desired.
*/
#if (!MALLOC_REPLACED)
#define xalloc malloc
#define xcalloc calloc
#define xrealloc realloc
#define xfree free
#else
extern void *MALLOC (size_t size);
extern void *REALLOC (void *buffer, size_t size);
extern void *FREE (void *buffer);
extern void far * _Cdecl FARMALLOC(unsigned long size);
extern void far * _Cdecl FARREALLOC(void far *area, unsigned long size);
extern void _Cdecl FARFREE (void far *area);
#define xalloc MALLOC
#define xcalloc calloc
#define xrealloc REALLOC
#define xfree FREE
#endif
resource Neardata alloc_resource;
#if (!MALLOC_REPLACED)
farptr Globalfunc tsk_alloc (word size)
{
farptr ptr;
request_resource (&alloc_resource, 0L);
ptr = (farptr)xalloc (size);
release_resource (&alloc_resource);
return ptr;
}
farptr Globalfunc tsk_calloc (word item, word size)
{
farptr ptr;
request_resource (&alloc_resource, 0L);
ptr = (farptr)xcalloc (item, size);
release_resource (&alloc_resource);
return ptr;
}
farptr Globalfunc tsk_free (farptr item)
{
request_resource (&alloc_resource, 0L);
xfree ((void *)item); /* Ignore warning in small model */
release_resource (&alloc_resource);
return LNULL;
}
farptr Globalfunc tsk_realloc (farptr item, word size)
{
farptr ptr;
request_resource (&alloc_resource, 0L);
ptr = (farptr)xrealloc ((void *)item, size); /* Ignore warning in small model */
release_resource (&alloc_resource);
return ptr;
}
#else
void far * _Cdecl farmalloc(unsigned long size) {
void *area;
size += sizeof (void *);
if (ctask_active) {
request_cresource (&alloc_resource, 0L);
area = FARMALLOC (size);
while (area == (void *) 0) {
release_resource (&alloc_resource);
t_delay (18L);
request_cresource (&alloc_resource, 0L);
area = FARMALLOC (size);
}
*((void **)area) = (void *) curr_task ();
release_resource (&alloc_resource);
}
else {
area = FARMALLOC (size);
if (area != (void *)0)
*((void **)area) = (void *) 0;
}
if (area != (void *)0)
area = (void *) (((char *)area)+sizeof (void *));
lcMalloc++;
return area;
}
void *malloc (size_t size) {
return farmalloc ((unsigned long) size);
}
void far * _Cdecl farrealloc(void far *item, unsigned long size) {
void *area;
if (ctask_active)
request_cresource (&alloc_resource, 0L);
if (FP_OFF (item) != 0x08)
area = FARREALLOC (item, size);
else {
area = (void *) (((char *)item)-sizeof (void *));
area = FARREALLOC (item,size+sizeof (void *));
area = (void *) (((char *)area)+sizeof (void *));
}
if (ctask_active)
release_resource (&alloc_resource);
lcRealloc++;
return area;
}
void *realloc (void *item, size_t size) {
return farrealloc (item, (unsigned long) size);
}
void farfree (void *area) {
if (ctask_active)
request_cresource (&alloc_resource, 0L);
lcFree++;
if (FP_OFF (area) == 0x08)
area = (void *) (((char *)area)-sizeof (void *));
FARFREE (area);
if (ctask_active)
release_resource (&alloc_resource);
}
void free (void *area) {
farfree (area);
}
int tsk_heapfree (tcbptr tcbp) {
int rc;
tcbptr ptr;
struct heapinfo hi;
request_cresource (&alloc_resource, 0L);
if ((rc=heapcheck ()) == _HEAPOK) {
for (hi.ptr = NULL; (rc=heapwalk (&hi)) == _HEAPOK; ) {
ptr = (tcbptr) (*(void **)hi.ptr);
if ( *((int *)hi.ptr) == 0x08 && hi.in_use && ptr != LNULL && ptr->cqueue.kind == TYP_TCB && ptr == tcbp) {
lcFree++;
xfree ((void *) hi.ptr);
hi.ptr = NULL;
}
}
}
release_resource (&alloc_resource);
return rc;
}
long tsk_heapused (tcbptr tcbp) {
long bytes;
tcbptr ptr;
struct heapinfo hi;
request_cresource (&alloc_resource, 0L);
for (bytes = 0L, hi.ptr = NULL; heapwalk (&hi) == _HEAPOK; ) {
ptr = (tcbptr) (*(void **)hi.ptr);
if (hi.in_use && (tcbp == LNULL ? 1 : ptr->cqueue.kind == TYP_TCB) && ptr == tcbp)
bytes += hi.size;
}
release_resource (&alloc_resource);
return bytes;
}
farptr Globalfunc tsk_alloc (word size)
{
return (farptr)malloc (size);
}
farptr Globalfunc tsk_calloc (word item, word size)
{
return (farptr)calloc (item, size);
}
farptr Globalfunc tsk_free (farptr item)
{
free (item);
return LNULL;
}
farptr Globalfunc tsk_realloc (farptr item, word size)
{
return (farptr)realloc (item, size);
}
#endif
---eof tskalloc.c---
==========================
ibm.other/ctask #730, from jolasky, 802 chars, Sat Feb 19 22:52:08 1994
There is/are comment(s) on this message.
--------------------------
TITLE: ctask / Novell IPX problem
I have been using CTask for part of a distributed application running on
a Novell LAN. The application consists of two parts. One part is a single-taskin
g
program that runs on a number of dedicated single-board 486SX PCs in a CUBIX
chassis, and the other part is a multi-tasking control program written using
the CTask library, that runs on a separate dedicated 486 workstation. All of
the PCs communicate using IPX, and in addition the control program also receives
commands from a user over an RS-232 li
ne.
Everything is working well now, except that when I close down the control progra
m, after all the tasks have ended and I
have de-installed the tasker, when I try to close my IPX sockets the program ha
ngs.I check whether any of the Event Co
ntrol Blocks are
Read:
==========================
ibm.other/ctask #731, from barryn, 268 chars, Sun Feb 20 11:42:46 1994
This is a comment to message 730.
--------------------------
Jason, do you open your IPX sockets as "long-lived" sockets
or "short-lived" sockets? If you'll post a message containing
a fragment of your code, showing the context in which the program
hangs (near the IpxCloseSocket() calls?), I'll be glad to look
at the code.
==========================
ibm.other/ctask #732, from jolasky, 1239 chars, Mon Feb 21 22:33:48 1994
This is a comment to message 731.
There is/are comment(s) on this message.
--------------------------
Barry - What seems to be happening is that my program can close about 8 or 10
of the 14 open sockets and then it freezes up completely,
v24_remove (siop, 1);
remove_tasker ();
tsk_rprintf ("all tasks have ended\n");
----------------------------------------------------------------------------
Barry - The program hangs sometime in the middle of the following loop.
Apparently around eight to ten of the fourteen open sockets are successfully
closed, then the PC locks up.
----------------------------------------------------------------------------
for (server = 1; server <= MAXSERVER; server++)
if serverTable[server-1].onoff == ON)
{
if (sendECB[server-1]->inUseFlag)
{
tsk_rprintf ("sendECB in use for server %d, cancelling event\n", server);
IPXCancelEvent ((ECB *) sendECB[server-1]);
}
if (receiveECB[server-1]->inUseFlag)
{
tsk_rprintf ("receiveECB in use for server %d, cancelling event\n", server);
IPXCancelEvent ((ECB *) receiveECB[server-1]);
}
tsk_rprintf ("closing socket %x\n", BASE+server);
IPXCloseSocket (flipword(BASE+server));
}
settextmode (25);
return 0;
}
Read:
==========================
ibm.other/ctask #733, from barryn, 652 chars, Tue Feb 22 09:27:38 1994
This is a comment to message 732.
--------------------------
I don't see anything wrong with your code, Jason. However, here's
a small change you can try to see if the program behaves differently.
This approach takes advantage of the fact that CloseSocket() cancels
any events (ECBs) that are associated with the socket you close.
Instead of issuing the IpxCancelEvent() function, just close the
14 or so sockets. Let the Event Service Routine for your send and
receive operations handle the return code of 0xFC they'll get as
a result of the cancel.
Your code fragment doesn't indicate exactly when it executes, but
be aware that you shouldn't call IpxCloseSocket() from within an
Event Service Routine.
==========================
ibm.other/ctask #735, from jolasky, 478 chars, Fri Mar 4 17:44:41 1994
This is a comment to message 733.
There is/are comment(s) on this message.
--------------------------
Barry - I posted the same problem on the Compuserver Novell developer's
forum, and someone suggested that I fill the event control blocks with
zeros after performing the IPXCancelEvent calls. This works, but why
is not clear. As to not doing the IPXCancelEvent calls, originally I
was not doing them, just doing the CloseSockets. I added the IPXCancelEvent
calls when my application started hanging, on the chance that that might
be the solutio, but the hangs kept on occuring.
Read:
==========================
ibm.other/ctask #736, from barryn, 497 chars, Fri Mar 4 17:52:26 1994
This is a comment to message 735.
--------------------------
And the crash occurs in or near the calls to CloseSocket()?
Interesting. How about trying this: insert some calls to
IpxRelinquishControl()...perhaps five of them?...right after the
program closes the IPX sockets. If you have a delay (sleep) routine
you can call, sprinkle a few of those into the code, too. Perhaps
this will give IPX a chance to process each IpxCloseSocket() call
without interference from other calls. You could also wait for the
completion code in the ECB after each call.
==========================
ibm.other/ctask #737, from gplourde, 632 chars, Mon Mar 21 11:27:13 1994
--------------------------
TITLE: NDP TRUE and DOS FALSE
I've been using NDP TRUE on a DOS system fine.
^[^DI've got an embedded application which I would like CTask to save and
restore the 8087 registers for me. When NDP is TRUE and DOS is FALSE there
is a compilation error which occurs in tskasm.asm. t_new is undefined.
This flag is used to determine if this is a new task in which the first
time this task is swapped in the 8087 registers will not be restored.
t_new is defined inside of ifdef DOS syntax in the file tsk.h. Has anyone
out there seen this? Can I draw upon your experience and suggestions
before I start dorking code?
Thanks. G Plourde
==========================
ibm.other/ctask #738, from jjanney, 760 chars, Fri Mar 25 08:12:27 1994
There is/are comment(s) on this message.
--------------------------
Title: internal stack overflow, system halted
... is the error message that one of my customers reports seeing on
his screen when his PC locks up while running a ctask program. He's
running PC Support through an ethernet connection with Novell Netware.
I've searched the ctask source without success--does anyone know if
this is a message from ctask, or from Netware, or the Borland 3.1
runtime, or DOS, or the BIOS, or little green men ... :-)
Also, looking through old messages in this topic I see that preemptive
multitaskers like ctask can sometimes cause problems with the DOS
STACKS command, and that this can sometimes be fixed by setting
STACKS=0,0. Could anyone explain in more detail what the problem is,
and under what circumstances it appears?
Read:
==========================
ibm.other/ctask #739, from barryn, 182 chars, Fri Mar 25 09:11:07 1994
This is a comment to message 738.
There is/are comment(s) on this message.
--------------------------
The message "internal stack overflow, system halted" is from
DOS, as I recall. You might try a "stacks=9,256" entry in the
CONFIG.SYS file of the machine the problem happens on.
Read:
==========================
ibm.other/ctask #740, from twagner, 845 chars, Fri Mar 25 14:15:42 1994
This is a comment to message 737.
--------------------------
Ooops... you're right, NDP support won't work if DOS is FALSE. The
correction is simple (I hope, I haven't tested it):
In TSKASM.ASM, eliminate the test for t_new, and
insert the following proc at the end:
IF NDP
Localfunc tsk_get_ndp,<uses di, tcbp:far ptr>
les di,tcbp
wait
fsave es:ndpsave[di]
ret
tsk_get_ndp endp
ENDIF
Then, in TSKTASK.C, insert
.More..
#if (NDP)
extern void Localfunc tsk_get_ndp (tcbptr task);
#endif
somewhere around the tsk_get_dosswap definition, and add a call to
tsk_get_ndp to the ndp init code in create_task:
#if (NDP)
if (tsk_use_ndp && GLOBDATA ndp_present)
{ <<-- add
task->flags |= F_USES_NDP;
tsk_get_ndp (task); <<-- add
} <<-- add
#endif
Let me know whether this works.
Thomas
Read:
==========================
ibm.other/ctask #741, from dgh, 1144 chars, Sat Mar 26 12:39:49 1994
This is a comment to message 739.
There is/are comment(s) on this message.
--------------------------
STACKS=9,256 is the default value used if CONFIG.SYS does not have a STACKS
command.
The STACKS command is used by DOS to determine how many interrupt stacks to
use, and how large each should be. STACKS=9,256 tells DOS to use 9 stacks,
each with 256 bytes.
When you get the internal stack overflow message, it means one of two things
(listed in order of frequency):
1) DOS determined that the size of the current stack is too small.
2) DOS ran out of stacks.
For the first case, increase the number of bytes in each stack.
STACKS=9,512 works for me in most cases.
.More..
In the second case, either try increasing the number of stacks
(STACKS=12,256) or setting them to 0 (STACKS=0,0).
When set to 0, DOS does not change stacks when entering software or hardware
interrupt routines. Instead, DOS relies on each application program and TSR
having enough stack space to handle any and all interrupts that come along.
Sometimes, using STACKS=0,0 will fix problems that increasing the number of
stacks and/or their sizes does. Other times, it makes the problem worse.
The only way to find out what works is to experiment.
,
|) /\ \/ | +)
Read:
==========================
ibm.other/ctask #742, from jjanney, 769 chars, Sun Mar 27 16:01:40 1994
This is a comment to message 741.
There is/are comment(s) on this message.
--------------------------
Thanks for the information. Knowing that the message is from DOS is
particularly helpful. I have been trying different settings of STACKS
with inconclusive results. With no entry or with STACKS=9,256 it
locks up with the error message. With STACKS=9,512 it locks up, but
without any message. I've got him trying STACKS=0,0 now. The program
will typically run for three or four days before locking up, so it
takes a while to run through the possibilities.
Why does DOS need more than one stack? Does it use a separate stack
for each interrupt? Where in memory does it allocate them? Is there
any reason not to try ridiculously large values, like STACKS=24,4096?
I may also try turning off preemption in ctask, since I don't think the
program really needs it.
Read:
==========================
ibm.other/ctask #743, from klrv, 1110 chars, Mon Mar 28 03:26:18 1994
This is a comment to message 742.
There is/are comment(s) on this message.
There are additional comments to message 742.
--------------------------
Here's what the Microsoft MSDOS Encyclopedia says about internal stacks:
Each time certain hardware interrupts occur (02H, 08-0EH, 70H, 72-77H),
MSDOS switches to an internal stack before transferring control to the handler
that will service the interrupt. In the case of nested interrupts,
MS-DOS checks to ensure that both interrupts do not get the same stack.
After the interrupt has been processed, the stack is released.
The STACKS command configures the number and size of the internal stacks
available for interrupt handling, and thus controls the number of interrupts
that can exist only partially processed while still alowing another interrupt
to occur
The number of stacks must be in the range 8..64, the size between 32..512
If too many interrupts occur too quickly, and the pool of internal stack
frames is exhausted, the system halts with the message Internal Stack Overflow.
.More..
Increasing the number of stacks usually corrects the problem.
==> Perhaps you could check if you don't have a _lot_ of timer interrupt (08)
processing. Or perhaps playing around with INT8_EARLY/LATE might help?
Luc
Read:
==========================
ibm.other/ctask #744, from jjanney, 318 chars, Tue Mar 29 00:38:11 1994
This is a comment to message 743.
There is/are comment(s) on this message.
--------------------------
So to run out of stacks with nine stacks, you would need more than
nine different interrupts to occur close together? I would expect an
ethernet card to generate a single interrupt very frequently, rather
than a lot of different interrupts. Could ctask cause MS-DOS to
become confused about which stacks are in use?
Read:
==========================
ibm.other/ctask #745, from klrv, 335 chars, Tue Mar 29 00:46:31 1994
This is a comment to message 744.
--------------------------
No, no. If I understand this correctly, DOS will set up a new stack for
each interrupt, even if the same interrupt occurs again before the
previous invokation of the interrupt routine returns. So, if an interrupt
routine takes a _long_ time, and interrupts are re-enabled already,
the same interrupt could cause this. (I think ;-)
Luc
Read:
==========================
ibm.other/ctask #746, from dgh, 551 chars, Tue Mar 29 02:35:31 1994
This is a comment to message 742.
--------------------------
The whole story behind STACKS is quite complex and beyond my memory.
However, there have been occasional discussions and one or two in-depth
explanations over in ibm.dos/secrets through ibm.dos/secrets.4. If you
do a SEarch on STACKS in those topics (working backwards from 4), you're
sure to find it.
There is an upper limit for STACKS, but I don't remember if it's just "can't
exceed 64K" or if there are explicit limits on the two numbers. (Multiply
the two numbers to figure out how much DOS memory is used for the stacks.)
,
|) /\ \/ | +)
Read:
==========================
ibm.other/ctask #747, from jjanney, 818 chars, Mon Apr 4 12:02:53 1994
--------------------------
Title: create_counter before install_tasker
I'm starting to write C++ classes that have ctask elements imbedded in
them, like resources and counters. The obvious way to initialize an
imbedded ctask element is in the constructor for the class, but this
leads to a problem: if I declare a global object of that class, the
constructor will run before ctask has been initialized (it will call
create_counter before install_tasker has been called). I could check
ctask_active in the constructor, but then I need a way to initialize
the elements before I actually use them.
1) Is it safe to call functions like create_resource or create_counter
before install_tasker has been called? I looked at the source and
didn't see anything obviously wrong with it.
2) If not, does anyone know a clean way to handle this?
==========================
ibm.other/ctask #748, from twagner, 932 chars, Mon Apr 4 18:34:14 1994
This is a comment to message 747.
There is/are comment(s) on this message.
--------------------------
The problem with calling create_counter etc. before install_tasker
is the name list. The name list is initialised in install_tasker, and
any elements you try to add before initialisation will a) get lost,
and b) may cause trouble during insertion.
I still haven't started to do anything serious with C++, so I don't
know whether this works, but would it be possible to define some sort
of "base class" that is "constructed" before anything else, and
contains those parts of install_tasker that are necessary to init the
global variables, including the name chain? I just checked
install_tasker, and the order of inits doesn't matter that much (on
first glance, I even think I got something backwards in the group
init). Creating the system tasks, and initting the int vectors, could
be split from the variable initialisation, and done at a later time.
.More..
With this split, you should be on the safe side. Does this idea help?
Thomas
==========================
ibm.other/ctask #752, from cblum, 242 chars, Thu Jun 23 19:25:36 1994
--------------------------
TITLE: Message on other service
Thomas, I sent you several things via your CIS id 10023,2042 and I just wanted
to make sure you got them. You don't need to reply, but if you don't sign on
very often, you might want to check there.
Chris Blum
Read:
==========================
ibm.other/ctask #753, from klrv, 85 chars, Tue Jun 28 01:54:55 1994
There is/are comment(s) on this message.
--------------------------
TITLE: Ctask and BC 4.0
Did anyone actually try BC 4.0 with Ctask?
Any problems?
Luc
Read:
==========================
ibm.other/ctask #754, from cblum, 645 chars, Tue Jun 28 09:29:47 1994
This is a comment to message 753.
--------------------------
I have used C-Task extensively with BC 4.0 with no problems. It does require
recompile, because some run-time-library and internal helper routines changed
with BC 4.0 and you will get unresolved references at link time if you do not
recompile C-Task under the new compiler, but this is true of any 3rd party
library. I am looking at trying to use C-Task under the PowerPack DOS
extenders, but it will require some ( read as'quite a bit' ) of work. The
PowerPack does include bi-modal interrupt support, so the timer and serial
routines should be workable. Just getting into looking, have not received
PowerPack or Service Update yet.
Chris Blum
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment