Rev | Line | |
---|
[4] | 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
|
---|
[3432] | 7 | into account. According to the Control Program Programming Guide, DosSetMem
|
---|
[4] | 8 | should do this automatically.
|
---|
[1230] | 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
|
---|
[3432] | 13 |
|
---|
| 14 | FP13:
|
---|
| 15 | - DosQuerySysState bug when object information is requested. Probably a
|
---|
| 16 | problem which occurs in _LDRSysMteInfo when qsCheckCache is calle before
|
---|
| 17 | writing object info. The result is that the cache flushed and the attempt
|
---|
| 18 | of updating the qsLrec_t next and object pointer is not done. This used to
|
---|
| 19 | work earlier and on Aurora AFAIK.
|
---|
| 20 |
|
---|
| 21 | The fix for this problem is to check if the pObjInfo is NULL while the
|
---|
| 22 | number of objects isn't 0 and correct this. pNextRec will also be NULL at
|
---|
| 23 | this time. This will be have to corrected before we exit the loop or moves
|
---|
| 24 | to the next record. There is also a nasty alignment of the object info...
|
---|
| 25 | Hope I got it right. (This aligment seems new to FP13.)
|
---|
| 26 |
|
---|
Note:
See
TracBrowser
for help on using the repository browser.