[16-bit DOS] Cannot link properly Borland-based static library #528

Th3rdSergeevich · 2019-03-24T13:30:38Z

Th3rdSergeevich
Mar 24, 2019

I'm working on migrating my code project for 80188-based controller i7188EX. So far the project had being successfully compiled with BC3.1, but currently I've got a need to use the compiler compatible with 64-bit host systems. Unfortunately, when I tried to compile and link the project (while using the same settings from Borland compiler - target processor, memory model, include directories, etc.), all I got were numerous "Undefined reference" errors.

Consider this simple template program, for instance:

#include <icpdas.h>

void main(void)
{
        InitLib();
        Print("Welcome to MiniOS7 Studio!");
}

The header file in the include line to several system headers (stdio, stdlib, dos, math, mem, string, ctype, conio) and a lib header chosen by defined model name (i7188EX, in my case). Functions InitLib() and Print() are included in 7188EL.LIB, the library the program was supposed to link to. Here is the process log:

cd C:\WATCOM\project
wmake -f C:\WATCOM\project\noname.mk -h -e C:\WATCOM\project\noname.exe
wcc main.c -i="C:\WATCOM/h;C:/ICPDAS/MiniOS7_Studio/Lib" -w4 -e25 -di7188EX -zq -od -d2 -1 -bt=dos -fo=.obj -ml
wlink name noname d all sys dos op m libp C:/WATCOM/286lib;C:/ICPDAS/MiniOS_Studio/Lib op maxe=25 op symf @noname.lk1
Open Watcom Linker Version 2.0 beta Nov  1 2017 20:56:49 (64-bit)
Copyright (c) 2002-2017 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
loading object files
searching libraries
Error! E2028: InitLib_ is an undefined reference
Error! E2028: Print_ is an undefined reference
creating map file
creating a DOS executable
file main.obj(C:\WATCOM\project\main.c): undefined symbol InitLib_
file main.obj(C:\WATCOM\project\main.c): undefined symbol Print_
Error(E42): Last command making (C:\WATCOM\project\noname.exe) returned a bad status
Error(E02): Make execution terminated
Execution complete

While looking and researching for solution, I found out the conflict may be caused by different naming conventions used by Borland C and Open Watcom. I added parameter -ecc to compiler command line, and got this instead:

cd C:\WATCOM\project
wmake -f C:\WATCOM\project\noname.mk -h -e C:\WATCOM\project\noname.exe
wcc main.c -i="C:\WATCOM/h;C:/ICPDAS/MiniOS7_Studio/Lib" -w4 -e25 -di7188EX -zq -ecc -od -d2 -1 -bt=dos -fo=.obj -ml
wlink name noname d all sys dos op m libp C:/WATCOM/286lib;C:/ICPDAS/MiniOS_Studio/Lib op maxe=25 op symf @noname.lk1
Open Watcom Linker Version 2.0 beta Nov  1 2017 20:56:49 (64-bit)
Copyright (c) 2002-2017 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
loading object files
searching libraries
Error! E2028: _vsprintf is an undefined reference
creating map file
creating a DOS executable
file \ICPDAS\MiniOS7_Studio\Lib\i7188E\7188EL.LIB(PRINT): undefined symbol _vsprintf
Error(E42): Last command making (C:\WATCOM\project\noname.exe) returned a bad status
Error(E02): Make execution terminated
Execution complete

The function InitLib() passed succesfully, while Print(), on the other hand, threw an error: the linker cannot find the definition of vsprintf (described as _vsprint because of cdecl) inside lib file. I attempted to compile my project as well, and there were several undefined references "_malloc" and "_free".

Is there any way to resolve the naming conflict so I can utilize controller libs? As I've mentioned before, they link perfectly fine in Borland C.

Any help regarding this matter would be appreciated.

jmalak · 2019-03-24T19:20:08Z

jmalak
Mar 24, 2019
Maintainer

Do you have full source code for all libraries used by your code except C run-time?

0 replies

Th3rdSergeevich · 2019-03-24T22:07:20Z

Th3rdSergeevich
Mar 24, 2019
Author

Sadly, I do not have source code for those libraries. But I do have listing files generated from 7188EL library both by WLIB and TLIB (Borland library manager).

Also linker referred to the reference located in module PRINT, so I extracted it from the library, then disassembled it. I've got this result:

.387
		PUBLIC	_Print
		EXTRN	_vsprintf:BYTE
		EXTRN	_Puts:BYTE
DGROUP		GROUP	_DATA,_BSS
PRINT_TEXT		SEGMENT	BYTE PUBLIC USE16 'CODE'
		ASSUME CS:PRINT_TEXT, DS:DGROUP, SS:DGROUP
_Print:
	push		bp
	mov		bp,sp
	sub		sp,6
	lea		ax,0aH[bp]
	mov		word ptr -2[bp],ss
	mov		word ptr -4[bp],ax
	push		word ptr -2[bp]
	push		ax
	push		word ptr 8[bp]
	push		word ptr 6[bp]
	push		ds
	push		offset DGROUP:L$1
	call		far ptr _vsprintf
	add		sp,0cH
	mov		word ptr -6[bp],ax
	push		ds
	push		offset DGROUP:L$1
	call		far ptr _Puts
	add		sp,4
	mov		ax,word ptr -6[bp]
	leave
	retf
PRINT_TEXT		ENDS
_DATA		SEGMENT	WORD PUBLIC USE16 'DATA'
_DATA		ENDS
_BSS		SEGMENT	WORD PUBLIC USE16 'BSS'
    ORG 0
L$1    LABEL	BYTE
    ORG 100H
_BSS		ENDS

		END

0 replies

jmalak · 2019-03-25T06:13:45Z

jmalak
Mar 25, 2019
Maintainer

The problem is that OW use registry based calling convention for 16-bit C run-time library
but Borland use stack based calling convention C run-time library.
There can be a problem with some internal C run-time Borland library which doesn't exists in OW C run-time library due to different startup code and internal code generator supported procedures.

Potential solution could be to compile C code with standard OW setup and create auxiliary library with thunks to emulate C run-time library functions used by these libraries.
You should have header files for these Borland libraries.
By example thunks for Print could see as

extern int Borland_Print( int p1, char *p2 );
#pragma aux (__cdecl) Borland_Print "_Print"

extern int OW_Print( int p1, char *p2 );
#pragma aux OW_Print "Print_"

int Borland_Print( int p1, char *p2 )
{
    return( OW_Print( p1, p2 ) );
}

int OW_Print( int p1, char *p2 )
{
    return( Borland_Print( p1, p2 ) );
}

and disassembled code of translation thunks is

.387
                PUBLIC  _Print
                PUBLIC  Print_
                EXTRN   _small_code_:BYTE
DGROUP          GROUP   CONST,CONST2,_DATA
_TEXT           SEGMENT BYTE PUBLIC USE16 'CODE'
                ASSUME CS:_TEXT, DS:DGROUP, SS:DGROUP
_Print:
        push            bp
        mov             bp,sp
        mov             ax,word ptr [bp+4]
        mov             dx,word ptr [bp+6]
        call            near ptr Print_
        pop             bp
        ret
Print_:
        push            bx
        push            cx
        push            dx
        push            ax
        call            near ptr _Print
        add             sp,4
        pop             cx
        pop             bx
        ret
_TEXT           ENDS
CONST           SEGMENT WORD PUBLIC USE16 'DATA'
CONST           ENDS
CONST2          SEGMENT WORD PUBLIC USE16 'DATA'
CONST2          ENDS
_DATA           SEGMENT WORD PUBLIC USE16 'DATA'
_DATA           ENDS
                END

You should create thunks for calling Open Watcom code from Borland code and for calling Borland code from Open Watcom code in dependency on what happen.
Generaly you must have thunks for calling Open Watcom code C run-time library function from Borland code and thunks for calling Borland library functions from Open Watcom code.

This doesn't requires change in code only you must create thunks libraries and link them with application and original Borland libraries (not C run-time library, it will use Open Watcom C run-time library).

But take into account it is only concept which you must check before use it for your solution.
There can be a problem with callback functions too.

0 replies

jmalak · 2019-03-25T06:34:47Z

jmalak
Mar 25, 2019
Maintainer

Use of -ecc compiler option simplify things that thunks for calling Borland code from Open Watcom code will not be necessary because OW will generate __cdecl calling directly, but C run-time library uses OW registry calling convention that thunk for calling OW C run-time library function from Borland code is necessary.

0 replies

jmalak · 2019-03-25T06:40:16Z

jmalak
Mar 25, 2019
Maintainer

Next posibility is to create OW 16-bit C run-time library with __cdecl calling convention, modify OW header files to use __cdecl calling convention and use -ecc compiler option. It should resolve it generaly but it requires to create special version of C run-time library and appropriate header files.

I think the previous solution is better for compatibility for future code.

0 replies

Th3rdSergeevich · 2019-03-25T12:15:37Z

Th3rdSergeevich
Mar 25, 2019
Author

OK, so I've performed conversion of InitLib() and Print() function, compiled the object file, added to a custom library, linked it to target... And voila! - executable file is created, definitions are resolved.

BUT! I uploaded .exe file into controller memory and attempted to run it. All I got was "Stack Overflow!" error message. The same program compiled with BC works as intended - it prints a string into console.

Is it possible that my workaround caused a call loop? I assume those functions calling each other may cause a recursion...

0 replies

jmalak · 2019-03-25T13:14:26Z

jmalak
Mar 25, 2019
Maintainer

You can not use both thunks together as in my sample. It was only for demonstration in one source.
Look on linker map file to see how it is linked together.
Best is to use -ecc option for compiling C code by OW and use only thunks for unresolved C run-time library functions from Borland code (in libraries). It prevents recursion.

0 replies

jmalak · 2019-03-25T13:17:15Z

jmalak
Mar 25, 2019
Maintainer

Next problem could be startup code, if your controler has no Operating system.
Do you have some?

0 replies

jmalak · 2019-03-25T13:26:11Z

jmalak
Mar 25, 2019
Maintainer

If I take your previous info then you need only _vsprintf thunk for your sample if -ecc option will be used.

extern int Borland_vsprintf( char *__s, const char *__format, __va_list __arg );
#pragma aux (__cdecl) Borland_vsprintf "_vsprintf"

extern int OW_vsprintf( char *__s, const char *__format, __va_list __arg );
#pragma aux OW_vsprintf "vsprintf_"

int Borland_vsprintf( char *s, const char *format, __va_list arg )
{
    return( OW_vsprintf( s, format, arg ) );
}

0 replies

Th3rdSergeevich · 2019-03-25T15:17:34Z

Th3rdSergeevich
Mar 25, 2019
Author

My bad. I suspected it would be weird to set up thunks like that.

With the solution mentioned above I was able to compile and link project successfully with no errors. All I needed to do was to add .c as a source file - no need for assembling a separate lib. Here's map:

Open Watcom Linker Version 2.0 beta Nov  1 2017 20:56:49 (64-bit)
Copyright (c) 2002-2017 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Created on:       19/03/25 18:09:14
Executable Image: noname.exe
creating a DOS executable


                        +------------+
                        |   Groups   |
                        +------------+

Group                           Address              Size
=====                           =======              ====

DGROUP                          018f:0000            00000ae0



                        +--------------+
                        |   Segments   |
                        +--------------+

Segment                Class          Group          Address         Size
=======                =====          =====          =======         ====

main_TEXT              CODE           AUTO           0000:0000       00000037
thunk_print_TEXT       CODE           AUTO           0000:0037       00000036
_TEXT                  CODE           AUTO           0000:006e       000016bb
INITLIB_TEXT           CODE           AUTO           0000:1729       00000145
PRINT_TEXT             CODE           AUTO           0000:186e       00000039
PUTS_TEXT              CODE           AUTO           0000:18a7       00000025
PUTCH_TEXT             CODE           AUTO           0000:18cc       0000001e
FAR_DATA               FAR_DATA       AUTO           018e:000a       00000000
_NULL                  BEGDATA        DGROUP         018f:0000       00000020
_AFTERNULL             BEGDATA        DGROUP         0191:0000       00000002
CONST                  DATA           DGROUP         0191:0002       0000003e
CONST2                 DATA           DGROUP         0195:0000       00000000
_DATA                  DATA           DGROUP         0195:0000       0000006c
XIB                    DATA           DGROUP         019b:000c       00000000
XI                     DATA           DGROUP         019b:000c       0000000c
XIE                    DATA           DGROUP         019c:0008       00000000
YIB                    DATA           DGROUP         019c:0008       00000000
YI                     DATA           DGROUP         019c:0008       00000000
YIE                    DATA           DGROUP         019c:0008       00000000
STRINGS                DATA           DGROUP         019c:0008       00000000
DATA                   DATA           DGROUP         019c:0008       00000000
_BSS                   BSS            DGROUP         019c:0008       00000207
STACK                  STACK          DGROUP         01bd:0000       00000800


                        +----------------+
                        |   Memory Map   |
                        +----------------+

* = unreferenced symbol
+ = symbol only referenced locally

Address        Symbol
=======        ======

Module: main.obj(C:\WATCOM\project\main.c)
0000:0000      main_
Module: thunk_print.obj(C:\WATCOM\project\thunk_print.c)
0000:0037      _vsprintf
Module: C:\WATCOM\lib286\dos\clibl.lib(stk086.asm)
0000:0073      __STK
0000:0093*     __STKOVERFLOW_
Module: \ICPDAS\MiniOS7_Studio\Lib\i7188E\7188EL.LIB(INITLIB)
0000:184f*     _EnableCpuClockB
0000:1846*     _EnableCpuClockA
0000:183d*     _DisableCpuClockAB
0000:1729*     _CheckCpuSpeed
018f:007e*     _DealyTimerPort
018f:007c*     _bNeedDisableHighRam
018f:007a*     _STD_PORT
018f:0078*     __CpuSpeed
018f:0074*     ___BaudDiv__
018f:0072*     _bNeedSetSpeed
018f:0070*     _DelayCnt_ms2
018f:006e*     _DelayCnt_ms1
018f:006c*     _DelayCnt_ms
018f:006a*     _Unit_ms2
018f:0068*     _Unit_ms1
018f:0066*     _Unit_ms
018f:0062*     ____OsType__
0000:1858      _InitLib
Module: \ICPDAS\MiniOS7_Studio\Lib\i7188E\7188EL.LIB(PRINT)
0000:186e      _Print
Module: C:\WATCOM\lib286\dos\clibl.lib(cstart)
018f:0000*     __nullarea
018f:0082*     __ovlflag
018f:0083*     __intno
018f:0084*     __ovlvec
0000:00b0      _cstart_
0000:0183*     _Not_Enough_Memory_
0000:02b5      __exit_
0000:02d2      __do_exit_with_msg__
0000:032b      __GETDS
Module: C:\WATCOM\lib286\dos\clibl.lib(cmodel.asm)
0000:0336      _big_code_
0000:0336*     CodeModelMismatch
Module: C:\WATCOM\lib286\dos\clibl.lib(vsprintf.c)
0000:034f      vsprintf_
Module: C:\WATCOM\lib286\dos\clibl.lib(xmsg.c)
0000:037a*     __exit_with_msg_
0000:037f      __fatal_runtime_error_
Module: C:\WATCOM\lib286\dos\clibl.lib(crwdata)
018f:0088      __curbrk
018f:0090      __STACKLOW
018f:0092      __STACKTOP
018f:0094      __cbyte
018f:0096      __child
018f:0098      __no87
018f:00a5      ___FPE_handler
018f:008a      __psp
018f:0099      __get_ovl_stack
018f:009d      __restore_ovl_stack
018f:00a1      __close_ovl_file
018f:00a9      __LpCmdLine
018f:00ad      __LpPgmName
018f:008c      __osmajor
018f:008d      __osminor
018f:008e      __osmode
018f:008f      __HShift
Module: \ICPDAS\MiniOS7_Studio\Lib\i7188E\7188EL.LIB(PUTS)
0000:18a7      _Puts
Module: C:\WATCOM\lib286\dos\clibl.lib(cmain086.c)
0000:039a      __CMain
Module: C:\WATCOM\lib286\dos\clibl.lib(initrtns.c)
0000:03f5      __InitRtns
0000:03f5*     __FInitRtns
0000:0450      __FiniRtns
0000:0450*     __FFiniRtns
Module: C:\WATCOM\lib286\dos\clibl.lib(uselfn.c)
018f:00b2      ___uselfn
Module: C:\WATCOM\lib286\dos\clibl.lib(dosseg)
0000:04b4      __DOSseg__
Module: C:\WATCOM\lib286\dos\clibl.lib(prtf.c)
0000:04b5      __prtf_
Module: C:\WATCOM\lib286\dos\clibl.lib(enterdb.c)
0000:128f      __EnterWVIDEO_
018f:00b4+     ___WD_Present
Module: \ICPDAS\MiniOS7_Studio\Lib\i7188E\7188EL.LIB(PUTCH)
0000:18cc      _Putch
018f:00b6*     _bLfMode
Module: C:\WATCOM\lib286\dos\clibl.lib(___argc.c)
018f:01d8      ____Argv
018f:01dc      ____Argc
Module: C:\WATCOM\lib286\dos\clibl.lib(exit.c)
0000:12b3+     __null_int23_exit_
0000:12b4      exit_
0000:12cc*     _exit_
018f:00b8+     ___int23_exit
018f:00bc+     ___FPE_handler_exit
Module: C:\WATCOM\lib286\dos\clibl.lib(sgdef086)
018f:00cc      __Start_XI
018f:00d8      __End_XI
018f:00d8      __Start_YI
018f:00d8      __End_YI
Module: C:\WATCOM\lib286\dos\clibl.lib(wctomb.c)
0000:12e8      wctomb_
Module: C:\WATCOM\lib286\dos\clibl.lib(itoa.c)
0000:1311+     utoa_
0000:136e      itoa_
Module: C:\WATCOM\lib286\dos\clibl.lib(i4m.asm)
0000:1392*     __I4M
0000:1392      __U4M
Module: C:\WATCOM\lib286\dos\clibl.lib(strupr.c)
0000:13aa      strupr_
Module: C:\WATCOM\lib286\dos\clibl.lib(noefgfmt.c)
018f:00c0      ___EFG_printf
018f:00c4*     ___EFG_scanf
Module: C:\WATCOM\lib286\dos\clibl.lib(mbisdbcs.c)
018f:00c8      ___IsDBCS
Module: C:\WATCOM\lib286\dos\clibl.lib(mbislead.c)
0000:13dc*     _ismbblead_
018f:01de      ___MBCSIsTable
Module: C:\WATCOM\lib286\dos\clibl.lib(lltoa.c)
0000:13f8      ulltoa_
0000:14dd*     lltoa_
Module: C:\WATCOM\lib286\dos\clibl.lib(ltoa.c)
0000:153f      ultoa_
0000:15ae*     ltoa_
Module: C:\WATCOM\lib286\dos\clibl.lib(alphabet.c)
0000:15dd      ___Alphabet
Module: C:\WATCOM\lib286\dos\clibl.lib(mbinit.c)
0000:166f      __mbinit_
018f:00ca+     ___MBCodePage


                        +--------------------+
                        |   Libraries Used   |
                        +--------------------+

\ICPDAS\MiniOS7_Studio\Lib\i7188E\7188EL.LIB
C:\WATCOM\lib286\dos\clibl.lib


                        +-----------------------+
                        |   Linker Statistics   |
                        +-----------------------+

Stack size:  0800 (2048.)
Memory size:  23d0 (9168.)
Entry point address: 0000:00b0
Link time: 00:00.21

Unfortunately, I won't be able to test the sample program on controller until tomorrow. For now I will attempt to create a complex thunk for all i7188EX functions that throw "Undefined symbol" error with -ecc flag.

0 replies

Th3rdSergeevich · 2019-03-25T15:26:39Z

Th3rdSergeevich
Mar 25, 2019
Author

Regarding the controller's OS: i7188EX has a DOS-based operating system called MiniOS7. It operates just like any DOS system and has its own C API. The controller's manufacturer provides specialized IDE (MiniOS7 Studio) for making C/C++ executable programs for their hardware.

The default compiler IDE uses is Borland C++ 3.1. During the compile step it takes -1 and -ml flags, which is reasonable, given that the controller is 80188-based. Instructions on setting up compatible compilers are providing the same flags.

0 replies

jmalak · 2019-03-25T17:06:45Z

jmalak
Mar 25, 2019
Maintainer

Linker map looks OK. _vsprintf is taken from thunk code and vsprintf_ is taken from OW C run-time library.
Controller realy use DOS executable format that OW C run-time startup code is OK.
How you debug code on controller?
if OS is DOS compatible then you could use OW remote debugging over serial port.
Only two files serserv.exe and std.trp (from OW binw subdirectory) must be copied to controller and you must start remote debug server (serserv.exe) on controller. Details you can find in debugger guide in section about remote debugging.
But it suppose IBM PC handling of serial port.

0 replies

Th3rdSergeevich · 2019-03-25T19:59:00Z

Th3rdSergeevich
Mar 25, 2019
Author

I got that part with serial ports covered. I use COM1 connection for uploading programs and monitoring them through IBM PC host. Even though, I had no tools for a proper debugging at my disposal till now, so it might be worth taking a shot.

0 replies

jmalak · 2019-03-28T08:51:51Z

jmalak
Mar 28, 2019
Maintainer

I have some communication with ICPDAS technical support about MiniOS7 and DOS functions necessary for OW debugger are not supported by MiniOS7 therefore use of OW remote debugging is not possible.
Also use of DOS LFN is not possible etc. DOS implementation is based on Borland C run-time library DOS use. It could be a problem for some OW C run-time functions which use some DOS service not implemented by MiniOS7. But if I know what function has problem I can modify code in C run-time library to use different DOS service available in MiniOS7.

0 replies

Th3rdSergeevich · 2019-03-28T09:44:34Z

Th3rdSergeevich
Mar 28, 2019
Author

Sad to hear about the debugger. I couldn't make it work anyway. Yeah, MiniOS7 is DOS-based, yet it doesn't fuction as the real DOS system. In fact, it has its own command set for controller operating.

Sorry for not responding for a while - got some work unrelated to this issue to do. The good news is that I managed to run the sample program succesfully. It outputs the designated string into the monitor as intended. The bad news is that I've failed to build my project due to linker throwing the error "__turboFloat is an undefined reference" with no note about reference source.

I was able to find the symbol in Borland's MATHL library, though. There's a bunch of functions from 7188E library used in my project that may be connected to MATHL, so I've got to find out which one is strictly tied to it.

0 replies

jmalak · 2019-03-28T17:58:36Z

jmalak
Mar 28, 2019
Maintainer

Good news. Thunks currently used can be lower then maximum, that if you add all to auxiliary library you can use it for other projects without change where can be used more thunks. Linker select only thunks which are actualy used by program.
to __VPRINTER symbol, it is good to know where it is used in 7188EL.LIB, because it should be used only by standard C run-time library not by application or application libraries.

0 replies

jmalak · 2019-03-28T18:30:04Z

jmalak
Mar 28, 2019
Maintainer

Anyway I got following info from ICPDAS technical support.

The following is a list of all INT 21h services handled by MiniOS7:
02H
06H
0EH
07H
08H
0BH
30H
25H
35H
26H
3fH
40H
42H
48H
49H
4AH
58H
4400H
31H

It could be useful for you.

0 replies

Th3rdSergeevich · 2019-03-29T13:53:01Z

Th3rdSergeevich
Mar 29, 2019
Author

A-a-and it crashed. That's the output I got from the monitor.

Formally my program compiled w/ thunks without any error, but couldn't even launch it on controller. On the other hand, executable files compiled via BC 3.1 and BC 5.02 are working just fine.

Guess I will just call it quits from here on. In theory, it's possible to build project previously based on Borland C, the simple iterations even might work. But with so many x-ref calls addressed to Borland libraries it is hard to compare and edit the source for OW, let alone solving those naming conventions.

0 replies

jmalak · 2019-03-29T14:48:02Z

jmalak
Mar 29, 2019
Maintainer

The problem is not on C language level there is no reason to change anything.
The problem can be simple. It is necessary to identify part of code which crash.
In crash report is CS:IP address where it hapens, you can identify from map file where it is if in Borland Library or OW C run-time library or simply in OW copiled C code and next fix what is wrong.
I don't know if you use correct floating-point option for OW compiler with regards to Borland compiler setup. You can try to run compiled code on native DOS if it crash on the same address or not. Or you can try to debug DOS executable on native DOS

I can not help you much if I have no access to appropriate hardware.

0 replies

jmalak · 2019-04-02T16:27:37Z

jmalak
Apr 2, 2019
Maintainer

I was contacted by ICPDAS technical support with interest to create test Open Watcom version of libraries for MiniOS7 (see bellow). I don't know if you are interesting in get OW version of appropriate libraries for direct compile and link C code for controllers without need to use Borland version of libraries with appropriate code thunks etc.
If you are interested in then contact me directly [email protected]

Hi Jiri,

We are going to improve the MiniOS7 libraries to make it to be compatible with Watcom C/C++ compiler, and it will take a couple of months to complete this task.
We wish to know which library you are actually using and which API functions you specifically using, so we will provide a beta version of function library for you to test.

Best regards
Liam Lin

ICP DAS CO., LTD.
Email Address: [email protected]
Web Site: http://www.icpdas.com

0 replies

Th3rdSergeevich · 2019-04-02T17:11:28Z

Th3rdSergeevich
Apr 2, 2019
Author

Glad to hear that. I wouldn't ask for specific libraries, but i7188EL.LIB and X304.LIB (libraries for the controller and I/O add-on) would be useful. The functions I mostly use are analog read/write functions and LED indicator's functions.

0 replies

jmalak · 2019-04-02T17:45:05Z

jmalak
Apr 2, 2019
Maintainer

Pleas contact me directly to include you in direct communication with ICP DAS.
I can not help them with any testing because I didn't have any hardware.

0 replies

udovichenkoAlexander · 2019-04-12T09:17:52Z

udovichenkoAlexander
Apr 12, 2019

I have successfully used openwatcomv2 with i7188XB (same family with i7188EX) controller

Several issues that I had to resolve:

In ICPDAS header add __cdecl to function declarations
example:
int __cdecl Print(const char *fmt, ...);
because ICPDAS compiled with borland, where __cdecl is default
ICPDAS library uses malloc internally (or maybe other libc functions in your case)
and this calls are made with cdecl but watcom libc malloc uses watcall conventions. So we need a wrapper

void * __cdecl __saveregs malloc_wrapper(unsigned size)
{
    return malloc(size);
}
#pragma aux malloc_wrapper "_malloc"

void __cdecl __saveregs free_wrapper(void *ptr)
{
    free(ptr);
}
#pragma aux free_wrapper "_free"

I need to repack (extract objects and create new library) X508.lib with watcom wlib.
Because without it watcom cannot link the library
If I start using floating point,
watcom startup starts to initialize and check FPU support
during this checking watcom executes __chk8087() and then fninit instruction

open-watcom-v2/bld/clib/fpu/a/ini87086.asm

Line 58 in 38bcff8

fninit ; use default infinity mode

but i7188XB controller reboots when executing fninit. I did not find how to disable this behavior with command switches (I tried all the switches related to fp support)
and create workaround

void __chk8087() {}

With empty __chk8087() watcom assumes that FP is not presented (which is actually true)

0 replies

jmalak · 2019-04-12T11:58:43Z

jmalak
Apr 12, 2019
Maintainer

Thanks for your info.
Point 1 is equivalent to use -ecc option (you don't need to change any source)
Point 2 is OK
Point 3 is strange, what exactly problem is, do you get some message?
Point 4, better way is define following in C code, it is used by OW if we want ignore any FPU stuff

unsigned char   _8087 = 0;
unsigned char   _real87 = 0;

0 replies

jmalak · 2019-04-12T12:03:05Z

jmalak
Apr 12, 2019
Maintainer

Please, could you send me copy of X508.lib to check linker stuff for OMF libraries and fix it.

0 replies

udovichenkoAlexander · 2019-04-12T13:43:23Z

udovichenkoAlexander
Apr 12, 2019

-ecc option it's good, but I want watcall for my app.
Anyway ICPDAS can add __cdecl to header files to be more portable.
Yes _8087=0 and _real87 = 0 it’s better, I don’t know why I didn’t do that)

I send needed files to reproduce trouble with X508.lib
(strange but it's bad link to X508 library on official site)

i try it with wcl main.c X508.lib I get error: undefined symbol _X508_Init

steps to repack and build

wlib X508.lib :X508
wlib X508_repack.lib +X508.o
wcl main.c X508_repack.lib

0 replies

jmalak · 2019-04-14T10:19:42Z

jmalak
Apr 14, 2019
Maintainer

It looks like the library uses non-standard library header or header is damaged.
Therefore OW linker can not find any symbol from this library.

0 replies

jmalak · 2019-04-14T11:18:52Z

jmalak
Apr 14, 2019
Maintainer

It looks like Borland TLIB bug, incorrect file offset to symbol dictionary.
You fixed it correctly by WLIB.
I will try to change OW linker to do simple scan over library if library symbol dictionary can not be process.

0 replies

jmalak · 2019-04-14T15:41:14Z

jmalak
Apr 14, 2019
Maintainer

I add wlink message about damaged library by commit 4d4e3bb

0 replies

jmalak · 2019-04-15T08:04:38Z

jmalak
Apr 15, 2019
Maintainer

It is not possible to fix it because Borland library has also damaged symbols dictionary.
Only solution is to rebuild library as you did by OW librarian.

0 replies

[16-bit DOS] Cannot link properly Borland-based static library #528

Th3rdSergeevich Mar 24, 2019

Replies: 38 comments

jmalak Mar 24, 2019 Maintainer

Th3rdSergeevich Mar 24, 2019 Author

jmalak Mar 25, 2019 Maintainer

jmalak Mar 25, 2019 Maintainer

jmalak Mar 25, 2019 Maintainer

Th3rdSergeevich Mar 25, 2019 Author

jmalak Mar 25, 2019 Maintainer

jmalak Mar 25, 2019 Maintainer

jmalak Mar 25, 2019 Maintainer

Th3rdSergeevich Mar 25, 2019 Author

Th3rdSergeevich Mar 25, 2019 Author

jmalak Mar 25, 2019 Maintainer

Th3rdSergeevich Mar 25, 2019 Author

jmalak Mar 28, 2019 Maintainer

Th3rdSergeevich Mar 28, 2019 Author

jmalak Mar 28, 2019 Maintainer

jmalak Mar 28, 2019 Maintainer

Th3rdSergeevich Mar 29, 2019 Author

jmalak Mar 29, 2019 Maintainer

jmalak Apr 2, 2019 Maintainer

Th3rdSergeevich Apr 2, 2019 Author

jmalak Apr 2, 2019 Maintainer

udovichenkoAlexander Apr 12, 2019

jmalak Apr 12, 2019 Maintainer

jmalak Apr 12, 2019 Maintainer

udovichenkoAlexander Apr 12, 2019

jmalak Apr 14, 2019 Maintainer

jmalak Apr 14, 2019 Maintainer

jmalak Apr 14, 2019 Maintainer

jmalak Apr 15, 2019 Maintainer

Th3rdSergeevich
Mar 24, 2019

jmalak
Mar 24, 2019
Maintainer

Th3rdSergeevich
Mar 24, 2019
Author

jmalak
Mar 25, 2019
Maintainer

jmalak
Mar 25, 2019
Maintainer

jmalak
Mar 25, 2019
Maintainer

Th3rdSergeevich
Mar 25, 2019
Author

jmalak
Mar 25, 2019
Maintainer

jmalak
Mar 25, 2019
Maintainer

jmalak
Mar 25, 2019
Maintainer

Th3rdSergeevich
Mar 25, 2019
Author

Th3rdSergeevich
Mar 25, 2019
Author

jmalak
Mar 25, 2019
Maintainer

Th3rdSergeevich
Mar 25, 2019
Author

jmalak
Mar 28, 2019
Maintainer

Th3rdSergeevich
Mar 28, 2019
Author

jmalak
Mar 28, 2019
Maintainer

jmalak
Mar 28, 2019
Maintainer

Th3rdSergeevich
Mar 29, 2019
Author

jmalak
Mar 29, 2019
Maintainer

jmalak
Apr 2, 2019
Maintainer

Th3rdSergeevich
Apr 2, 2019
Author

jmalak
Apr 2, 2019
Maintainer

udovichenkoAlexander
Apr 12, 2019

jmalak
Apr 12, 2019
Maintainer

jmalak
Apr 12, 2019
Maintainer

udovichenkoAlexander
Apr 12, 2019

jmalak
Apr 14, 2019
Maintainer

jmalak
Apr 14, 2019
Maintainer

jmalak
Apr 14, 2019
Maintainer

jmalak
Apr 15, 2019
Maintainer