--* From postmaster%watson.vnet.ibm.com@yktvmv.watson.ibm.com Wed Aug 25 12:39:11 1993 --* Received: from yktvmv2.watson.ibm.com by radical.watson.ibm.com (AIX 3.2/UCB 5.64/900524) --* id AA18581; Wed, 25 Aug 1993 12:39:11 -0400 --* X-External-Networks: yes --* Received: from watson.vnet.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) --* with BSMTP id 1105; Wed, 25 Aug 93 12:43:04 EDT --* Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.0" --* id --* for asbugs@watson; Wed, 25 Aug 93 12:43:04 -0400 --* Received: from bernina.ethz.ch by watson.ibm.com (IBM VM SMTP V2R3) with TCP; --* Wed, 25 Aug 93 12:43:01 EDT --* Received: from neptune by bernina.ethz.ch with SMTP inbound id <22501-0@bernina.ethz.ch>; Wed, 25 Aug 1993 18:42:57 +0200 --* From: Manuel Bronstein --* Received: from rutishauser.inf.ethz.ch (rutishauser-gw.inf.ethz.ch) by neptune id AA13236; Wed, 25 Aug 93 18:42:53 +0200 --* Date: Wed, 25 Aug 93 18:42:51 +0200 --* Message-Id: <9308251642.AA15939@rutishauser.inf.ethz.ch> --* Received: from ru7.inf.ethz.ch.rutishauser by rutishauser.inf.ethz.ch id AA15939; Wed, 25 Aug 93 18:42:51 +0200 --* To: smwatt@watson.ibm.com --* Subject: building aslib on DOS --* Cc: asbugs@watson.ibm.com --@ Fixed by: PI Fri Mar 11 14:22:46 EST 1994 --@ Tested by: none --@ Summary: see file last ports. On my 486 machine I can run both the compiler and the interpreter in a Dos box under Windows in protect mode. The tools for building the library now are really simple, the user should only set the MACHINE env. var. in the autoexec.bat Note: if gcc gives troubles under a Dos box, this is a gcc problem. There is a utility dpmifix to fix gcc and the library. Hi, I'm not sure whether asbugs@watson.ibm.com, but here are some comments and problems I encountered trying to rebuild libfoam and aslib. 1. gzip -d runt.gz only created runt.g, did not unpack the separate files, and it took a lot of work to extract all the files by hand with a text editor. 2. libfoam won't build on the Sun since sun-cc doesn't allow prototypes with arguments, so I'll try later on DOS at home and will let you know. 3. I tried to build aslib on DOS using minor modifications of mklaslib.bat and doasharp.bat, and ran into more serious problems: 3.1 In a DOS shell started from Windows, any invocation of asharp.exe produces this message: CPU must be in REAL mode (not V86 mode) to run this program. This is quite an inconvenience, since the only way to get to real mode is to quit windows. I guess this may be due to the dos extender used inside asharp.exe, but there are several reasons to build an asharp.exe that runs in extended mode: a) with Windows NT, DOS shells will only run in extended mode, b) extended-mode DOS shells allow the output to be captured and viewed later, a very convenient feature when being bombarded with messages c) extended DOS shells use DPMI to access all the RAM available d) the Microsoft C7 compiler does _not_ run in real mode! Point d) is the worst, since it means the compile cycle is as follows: - in normal DOS, run asharp producing .aso and .c files - start Windows and a DOS shell - compile and link the .c files using MSC. and so it prevents A# from generating .o files with MSC in one pass. 3.2 basic.as failed to compile, producing an Exception 13 after more than 20 minutes. I suspect that A# ran out of memory. I'm a using a 486/33 with 4Mb RAM,which I'd expect to be sufficient. I'll try again with the optimizations turned off. 3.3 All the other .as files produced .aso and .c files ok, although on some of the big .as files (e.g. float.as) the compile speed dropped to below 100 lines/minute. Again I suspect the lack of memory to be the cause. It took about 35 minutes to compile all the .as files, except basis.as. 3.4 During the .c to .o compile, files.c generated the following warning: files.c files.c(923) : warning C4307: '*' : integral constant overflow; result truncated line 923 is: l0->X1_command = ((FiWord*) mainArgv)[(FiWord) -1]; I don't think this is a problem. 3.5 During the .c to .o compile, float.c generated the following error: float.c float.c(8195) : fatal error C1050: 'CODE' : code segment too large This is more of a problem: 16-bit compiler have a limit of 64Kbytes of code per c file. I had to split float.c into 2 files by hand and compile them separately. It would be useful to have an option to tell the compiler a limit on the number of lines to generate in a c file, and have it automatically generate several c files if needed. I realize that this DOS version was meant for GCC, but typical windows users and developpers will be running in extended mode, and using one of the windows C compilers, the most popular of which being MSC or Borland. -- manuel