| 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 | - Workaround added for coordinate problem when a window | 
|---|
| 19 | looses focus and SelectClipRgn is called. GpiSetClipRegion | 
|---|
| 20 | resets the window origin for some unknown reason | 
|---|
| 21 | (TODO: figure out why) | 
|---|
| 22 |  | 
|---|
| 23 | FP13: | 
|---|
| 24 | - DosQuerySysState bug when object information is requested. Probably a | 
|---|
| 25 | problem which occurs in _LDRSysMteInfo when qsCheckCache is calle before | 
|---|
| 26 | writing object info. The result is that the cache flushed and the attempt | 
|---|
| 27 | of updating the qsLrec_t next and object pointer is not done. This used to | 
|---|
| 28 | work earlier and on Aurora AFAIK. | 
|---|
| 29 |  | 
|---|
| 30 | The fix for this problem is to check if the pObjInfo is NULL while the | 
|---|
| 31 | number of objects isn't 0 and correct this. pNextRec will also be NULL at | 
|---|
| 32 | this time. This will be have to corrected before we exit the loop or moves | 
|---|
| 33 | to the next record. There is also a nasty alignment of the object info... | 
|---|
| 34 | Hope I got it right. (This aligment seems new to FP13.) | 
|---|
| 35 |  | 
|---|