| 1 | OS/2 bugs:
|
|---|
| 2 | - Dlls are terminated in the order in which they're present in the modules
|
|---|
| 3 | name lookup table instead of taking dependencies into account
|
|---|
| 4 |
|
|---|
| 5 | - DosSetMem doesn't seem to do what it's supposed to;
|
|---|
| 6 | the size parameter has to be adjusted to take page boundary crossing
|
|---|
| 7 | into account. According to the Control Program Programming Guide, DosSetMem
|
|---|
| 8 | should do this automatically.
|
|---|
| 9 |
|
|---|
| 10 | - DosSetMem does not alter the 16 bit selectors so if you change memory
|
|---|
| 11 | attributes and then access the memory with a 16 bit API (such as DosRead),
|
|---|
| 12 | it will have the old (alloc time) attributes
|
|---|
| 13 |
|
|---|
| 14 | - If you allocate memory without PAG_EXECUTE and use DosSetMem to commit and
|
|---|
| 15 | set that flag, then DosQueryMem does not return that flag.
|
|---|
| 16 | If you allocate it with PAG_EXECUTE set, then DosQueryMem does what it's supposed to.
|
|---|
| 17 |
|
|---|
| 18 | FP13:
|
|---|
| 19 | - DosQuerySysState bug when object information is requested. Probably a
|
|---|
| 20 | problem which occurs in _LDRSysMteInfo when qsCheckCache is calle before
|
|---|
| 21 | writing object info. The result is that the cache flushed and the attempt
|
|---|
| 22 | of updating the qsLrec_t next and object pointer is not done. This used to
|
|---|
| 23 | work earlier and on Aurora AFAIK.
|
|---|
| 24 |
|
|---|
| 25 | The fix for this problem is to check if the pObjInfo is NULL while the
|
|---|
| 26 | number of objects isn't 0 and correct this. pNextRec will also be NULL at
|
|---|
| 27 | this time. This will be have to corrected before we exit the loop or moves
|
|---|
| 28 | to the next record. There is also a nasty alignment of the object info...
|
|---|
| 29 | Hope I got it right. (This aligment seems new to FP13.)
|
|---|
| 30 |
|
|---|
