os232sdk/toolkt20/read.me - view

File: [OS/2 SDKs] / os232sdk / toolkt20 / read.me
Revision 1.1.1.1 (vendor branch): download - view: text, annotated - select for diffs
Thu Aug 9 12:26:30 2018 UTC (7 years, 9 months ago) by root
Branches: msft, MAIN
CVS tags: os2sdk-1990, HEAD

Microsoft OS/2 SDK 2.0 05-30-1990

As the SDK represents Beta-level code, there will be bugs that we discover as we further test the code prior to shipping each release. Below are the items we have found to date. Also listed is advice on developing applications with this release of the SDK. SYSTEM CONFIGURATION NOTES: a. If your system has a secondary partition formatted with HPFS before you install, the System Install does not automatically add the proper support to your disk. You will need to add following line to your CONFIG.SYS (for an HPFS partition "D:"): IFS=C:\OS2\HPFS.IFS /C:64 /AUTOCHECK:D b. You may notice that the DIR command is slow in this pre-release of the system. A temporary workaround is to add the following two lines to your CONFIG.SYS: CODEPAGE=437,850 DEVINFO=KBD,US,C:\OS2\KEYBOARD.DCP c. The install process does not automatically configure your system to support XMS extended memory in the DOS boxes. To add this support, insert this line into your CONFIG.SYS: DEVICE=C:\OS2\MDOS\VXMS.SYS This line must come after the line DEVICE=C:\OS2\MDOS\VEMM.SYS NETWORK SUPPORT NOTES: a. Certain systems configurations and network cards will not work with the SDK. Configurations that are known to work are: PS/2 Model 80, 3Com EtherlinkMC card, NetBEUI transport Compaq 386/20, 3Com EtherlinkII card, NetBEUI transport Compaq 386/16, Ungermann-Bass 16-bit card, XNS monolithic transport Compaq 386/20, Ungermann-Bass 8-bit net card, XNS PS/2 Model 80, Ungermann-Bass NUI card, XNS Northgate 33Mhz, Ungermann-Bass 16-bit net card, XNS PS/2 Model 80, IBM Token Ring Adapter A, NetBEUI Configurations that are known to not work are: PS/2 Model 80, Ungermann-Bass NICps/2 card, XNS monolithic transport Compaq 386/20e, 3Com Etherlink II card, XNS NDIS transport For this pre-release, we have not tested a large number of combinations of network cards and server software. If you run into a configuration that you think should be supported but fails, please report the problem via Microsoft Online. b. The workstation software in this pre-release of the SDK will not communicate with IBM Lan Servers over an IBM Baseband or Broadband network. c. On machines using the FAT file system, the network support install may set the DISKCACHE at too high a level for your machine, leaving you with too little memory for the OS/2 system. One symptom is that the NET START WORKSTATION command will fail with an "Access Denied" error. If you suspect you may be experiencing this error, change the line in CONFIG.SYS to DISKCACHE = 128 and try rebooting your system. API NOTES: a. When IMPORTing a system API into your source code, you should do so using only the ORDINAL for the function, not the name. Ordianals for each API are given in the file BSEORD.H This rule will be fully enforced in a future release of the SDK. b. The 32-bit MLE (Multi-Line Edit) APIs are not fully implemented in this release of the SDK. c. The 32-bit version of the WinAddSwitchEntry API is not working in this release of the SDK. d. The constants used for the INCL_DOSDEVICES class of API in bsedos.h and bsedos16.h have been changed since the first SDK, as promised in the earlier readme file. The definitions are now equivalent to those used in the OS/2 1.2 Toolkit. e. If an application is to remain 16-bit, it should be compiled and linked with the 1.2 toolkit header files and libraries. If it is compiled with a 16-bit compiler (c5.1/c5.2/c6.0) and OS/2 2.0 SDK header files, and linked with the 2.0 SDK's libraries, it is probable that the application will have references to API's that are not in the same system DLL in the 2.0 system that they were in the 1.2 system. This will cause the 1.2 system to refuse to load the application because it is unable to resolve the dynamic links. f. The DosQuerySysInfo API is not fully implemented. You cannot get information on shared and private memory available to the calling process. g. DosStartSession: if the SessionType field of the STARTDATA structure is 0 for "allow the system to decide", a PM application will not be started correctly. If it is a 3, specifying a PM app explicitly, the application will start correctly. QUICKHELP NOTES: a. To reduce the number of open file handles in QuickHelp, you can concatenate the files adg20.hlp, api1.hlp, and api2.hlp into a single database called msos20.hlp. To do so type COPY /B API1.HLP+API2.HLP+ADG20.HLP MSOS20.HLP b. We have noticed some errors in accessing option information in the MASM386.HLP database under QuickHelp. If the topic you are seeking is positioned at the top of the screen when you click on it with the mouse, the reference won't take you to the right spot in the database. The workaround is to simply position the topic further down on the screen before you click on it. CV386 NOTES: a. Debugging floating point programs on a 386 system without a 387 The system emulator currently does not single-step correctly. This means that users who are single stepping at assembly level will see more than one instruction executed when they single-step under CV386. More precisely, if the cursor is on a floating point instruction, hitting F8 or F10 to single-step will result in the execution of the current instruction and following until a non floating point instruction is executed and Cursor-> FADD... FSTP... MOV AX,.... MOV DX,.... If you single step at this point on a system without a 387, you will end up on the "mov dx" instruction. (FADD and FSTP are both floating point instructions.) b. If you are single-stepping in assembler mode and execute an instruction which cases a fatal protection fault (gp fault or page fault), the CS:EIP will be off in the exception dispatcher, not in user code. If the user knows that this has happened, the user can just do a "GO" and CV386 will display a message that a protection fault has occurred and place CS:EIP at the right place. If the user is single stepping at source level mode, there is no problem. Another solution besides doing a "GO" is to "View" your previous source code and do a GO UNTIL on the next instruction. This will get you a proper reporting of the GP fault. Source level single stepping works better: it reports a GP fault and leave the CS:IP pointing at the offending instruction. c. If you are debugging an .EXE which is loaded from a floppy, any breakpoints you set will apply to all instances of that program on the system, not just the instance running under CV386. You may copy the .EXE to your hard disk to avoid this. d. The Restart command on the Run menu (equivalent to the "l" command) can cause the system to crash. UTILITIES NOTES: a. MEP will not execute background compiles. We recommend opening a second window and using the command line to execute a compile. Under certain conditions (such as attempting to execute a background compile) MEP will hang when it runs out of stack space. To free up stack space, delete or edit out file name entries in the MEP.TMP file. b. LIB and LINK386 currently do not accept long file names for library files. c. When LINK386 encounters fixups for a page of code or data that is otherwise unitialized, it writes incorrect fixup information to the executable, which causes fixups for the page to be ignored by the loader. This will only occur in some instances of linking 16- bit object modules in 32-bit EXEs (mixed model programming). If you are using mixed model and suspect this problem, verify by running "exehdr -v <exefile>". If the file contains ZEROED pages with fixups (i.e. if a non-zero physical page number is associated with a ZEROED page), you will see: no. virtual virtual page file flags address size map pages ... 0005 00050000 00000002 00000007 00000001 READABLE, WRITEABLE, NONSHARED, LOADONCALL, NONRESOURCE, DISCARDABLE, VALID-PAGES, SWAPPABLE, 16:16 ALIAS, 16-bit, NOIOPL logical physical flags page page 00000001 00000008 ZEROED and if the following message appears while dumping fixup records, EXEHDR: fatal U1140: out of memory then this problem is likely the cause of the failure. Workaround: Add an assembler module to append some initialized data to the group that defines the ZEROED page (object number 5 in the above example). Look in the map file to determine the name and class name of the last segment in the group. Use the below asm file, replacing <segname> and <classname> with the names from the map file, and make sure the alignment (dword) and other attributes (public, use32) are the same as the map file segment. Link the resulting .obj file with the rest of the objects, by putting the new .obj file at the END of the .obj file list. .386 <segname> segment dword public use32 '<classname>' dw 1234h <segname> ends end d. MKMSGF: This tool has the following known problems: i. No message text file checking. MKMSGF used to check for header id, message numbers, out of sequence msg IDs, missing messages, and repeated messages. With this version, very little if any checking is done. The user is warned that syntax errors in the input text file most likely will not be found. ii. There is a maximum of about 5000 messages allowed. iii. No checking for naming the same file name for both input and output file. Using the same name will put the output on top of the input file. iv. The new switches /C,/A, and /I are not supported. v. The codepage support is not fully active, even though it is listed for MKMSGF /?. e. H2INC: This tool has several known limitations which keep it from being a good general-purpose tool for converting C headers to MASM include files. Its purpose in this SDK is to convert the system headers in the OS2H directory into system include files. To do so, simply run the MAKEINC command file found in the MASM\OS2INC directory of the Toolkit. SYSTEM USER NOTES: a There is no BOOT command in OS/2 2.0. b. If you want to create a new DOS session in the Task Manger list, you must code the PATH to be C:\OS2\MDOS\COMMAND.COM This will allow you to select "DOS Window" or "DOS Full Screen" for the Program Type. c. The OS/2 System Editor ("E") has some known problems in working with this release of the System: i. If you use the Help buttons on the Find, Set font, or Set colors dialog boxes the editory will GP fault. ii. The editor will not correctly handle wild card file names when invoked from the command line. iii. The editor occasionally locks up when accessing files on an HPFS file system. d. If you RECOVER from diskette a file that has diskette read errors in it, the file will be recovered with the errors. Normally the recover operation should fail and an error message written to the screen. e. The SPEEDKEY device driver does not function reliably on this release. f. When running the system with a BGA (8514A) video driver, the MVDM sessions do not support DOS applications running in BGA mode. They will run lower- resolution DOS applications. g. Running programs in several DOS sessions simultaneously can cause hangs in individual DOS sessions. Printing and using the math coprocessor from the DOS sessions appear to be affected by this bug. APPLICATION COMPATIBILITY The OS/2 2.0 system is intended to run all OS/2 1.2 applications unmodified. It is also intended to run all DOS applications with the exception of those which use block device drivers (such as network drivers), those which directly manipulate disk hardware, and those which use DOS extenders other than EMM and XMS. If you discover an application which should run under OS/2 2.0 but doesn't, please report this to Microsoft Product Support Services so we can correct the problem in a future SDK. DOCUMENTATION NOTES a. Writing Mixed Model Programs: This document contains an error on p. 8, where it states, "you can use link386 to re-link a 16-bit DLL or application without any changes." If the 16-bit code was compiled with the -Gw switch, then it must be recompiled using the _loadds keyword where appropriate (or use -Au instead). Also in this document, the _far16 code examples should have #define INCL_16 in the sources. This pulls the right API prototypes from the OS/2 header files. In writing mixed-mode C programs, it is important to initialize a pointer dynamically rather than initializing it when defined: PCH p = "Hello World" /*PCH is a pointer type*/ will cause a fault in a statement like i = strlen(p); whereas the following code will work: PCH p; ... p = "hello world" i = strlen(p); b. Language Release Notes: The section on the use of FLAT model in MASM386 should be ammended to say "You should not make direct use of the FS and GS registers, as these are reserved for use by the OS/2 2.0 exception handler. c. Programming Reference: The DosQueryProcType API is missing from the printed documentation and the QH database; it is available in the IPF database. To print from the IPF database, you must individially mark the sections you wish to print. d. Link386 Online help: This incorrectly states a maximum stacksize of 64K. Larger stacksizes can be specified on the LINK386 command line or in the .DEF file; however, there will be some performance degradation with stacksizes close to or greater than 64K. e. The information provided in this Software Developer's Kit is preliminary and may contain inaccuracies or omissions. This information is subject to change in both format and content.

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.