WASM changes

[Bartosz Polednia]

Hi,

As there was no direct objections about Paul proposed changes I have
submitted them into Perforce.

Bartosz.

[Paul Edwards]

"Bartosz Polednia" <bart...@op.pl> wrote in message news:ekrqqg$k5n$1...@www-1.scitechsoft.com...

> As there was no direct objections about Paul proposed changes I have
> submitted them into Perforce.

Thanks Bartosz. I'll wait for the daily snapshot and verify that
all the changes are in.

BFN. Paul.

[Michal Necasek]

Excellent - I see you have volunteered to be the new wasm maintainer.
And you know wasm well enough that you don't need any of those boring
regression tests I was asking for.

No doubt you will swiftly resolve the problem that Peter reported. FYI
the problem is this: assembling a file containing only '.model small'
with -ms produces several "Label is already defined" errors.

Michal

[Bartosz Polednia]

Next lesson taken. DO NOT HELP.

I have been waiting 3 days for bug reports.

Paul, you need to find someone else to make submits.

Bartosz.

[Mat Nieuwenhoven]

On Sun, 03 Dec 2006 20:46:39 +0100, Bartosz Polednia wrote:

>Next lesson taken. DO NOT HELP.
>
>I have been waiting 3 days for bug reports.

You mean you put something in without checking it first yourself? What was
stopping you from doing a full clean/build with Paul's patches?

Mat Nieuwenhoven

[Bartosz Polednia]

Frankly writing: nothing.

I do not say that I am innocent.

Bartosz.

[Paul Edwards]

"Michal Necasek" <mic...@prodigy.net> wrote in message news:ekunlg$rrn$1...@www-1.scitechsoft.com...

> Bartosz Polednia wrote:
> > Hi,
> >
> > As there was no direct objections about Paul proposed changes I have
> > submitted them into Perforce.
> >
> Excellent - I see you have volunteered to be the new wasm maintainer.

It's a team effort.

> And you know wasm well enough that you don't need any of those boring
> regression tests I was asking for.

The tests were already failing, as you noted.

> No doubt you will swiftly resolve the problem that Peter reported. FYI
> the problem is this: assembling a file containing only '.model small'
> with -ms produces several "Label is already defined" errors.

Thanks for simplifying the problem. I think I know what the
problem is, let me resolve it.

BFN. Paul.

[Paul Edwards]

"Bartosz Polednia" <bart...@op.pl> wrote in message news:ekv9hs$32e$1...@www-1.scitechsoft.com...

> Next lesson taken. DO NOT HELP.

It's a minor problem. WASM is now significantly more usable.

> Paul, you need to find someone else to make submits.

This should be the last one.

BFN. Paul.

Index: direct.c
===================================================================
RCS file: j:\cvsroot/ow/bld/wasm/c/direct.c,v
retrieving revision 1.9
retrieving revision 1.10
diff -c -r1.9 -r1.10
*** direct.c 3 Dec 2006 21:04:44 -0000 1.9
--- direct.c 3 Dec 2006 21:52:48 -0000 1.10
***************
*** 2075,2080 ****
--- 2075,2085 ----
TypeInfo[TOK_EXT_PTR].value = MT_DWORD;
break;
}
+ /* If the equates have already been defined, don't redefine them */
+ if (ModuleInfo.init == TRUE)
+ {
+ return;
+ }
/* Set @CodeSize equate */
switch( type ) {
case MOD_MEDIUM:

[Bartosz Polednia]

Paul Edwards napisał(a):

> "Bartosz Polednia" <bart...@op.pl> wrote in message news:ekv9hs$32e$1...@www-1.scitechsoft.com...
>> Next lesson taken. DO NOT HELP.
>
> It's a minor problem.

It is a MAJOR problem.

I could submit code once more if and only if:

1. you prepare new regression tests,
2. you prepare results of all regression tests,
3. you verify that new & old tests give same results even if they fail,
3. I will receive acceptance from other submitters.

Bartosz.

[Michal Necasek]

Paul Edwards wrote:

>> And you know wasm well enough that you don't need any of those boring
>> regression tests I was asking for.
>
> The tests were already failing, as you noted.
>

Yes, but the build wasn't, and the wasm test failures were unrelated
to the changes you suggested.

>> No doubt you will swiftly resolve the problem that Peter reported. FYI
>> the problem is this: assembling a file containing only '.model small'
>> with -ms produces several "Label is already defined" errors.
>
> Thanks for simplifying the problem. I think I know what the
> problem is, let me resolve it.
>

My post - in case there was some uncertainty - was not aimed at you.
You designed fixes that you needed, but it is the responsibility of the
person checking in a change to make sure that the change is correct and
will not cause any build breaks (plus hopefully won't break other
people's code either).

In this particular case, the problem was not clear-cut at all, there
was a conflict between the -mxxx switch and the .model directive. I'm
not surprised that you hadn't anticipated the conflict. But it is the
job of the person checking in changes to expect the unexpected.

Also, because wasm is always freshly built at the start of a full
build, any problems with wasm will cause build breaks rather quickly. I
do not expect you to know that, but I expect the person checking in
changes to wasm to know that, and act accordingly.

Thanks for the wasm updates BTW, the assembler definitely needs it.
The text parsing and some of the semantics are wrong (ie. not like
MASM). Anything that brings wasm closer to MASM is a good thing.

Michal

[Paul Edwards]

"Michal Necasek" <mic...@prodigy.net> wrote in message news:el10jp$ihq$1...@www-1.scitechsoft.com...

> Paul Edwards wrote:
>
> >> And you know wasm well enough that you don't need any of those boring
> >> regression tests I was asking for.
> >
> > The tests were already failing, as you noted.
> >
> Yes, but the build wasn't, and the wasm test failures were unrelated
> to the changes you suggested.

Sure. I had noticed that someone said they were going to update
the testcases and make them get run as part of the build, so I was
waiting for that to happen so that I could make sure the .log file
was all "OK". I wasn't in a rush.

> >> No doubt you will swiftly resolve the problem that Peter reported. FYI
> >> the problem is this: assembling a file containing only '.model small'
> >> with -ms produces several "Label is already defined" errors.
> >
> > Thanks for simplifying the problem. I think I know what the
> > problem is, let me resolve it.
> >
> My post - in case there was some uncertainty - was not aimed at you.
> You designed fixes that you needed, but it is the responsibility of the
> person checking in a change to make sure that the change is correct and
> will not cause any build breaks (plus hopefully won't break other
> people's code either).

Understood, but I feel guilty anyway. :-)

> In this particular case, the problem was not clear-cut at all, there
> was a conflict between the -mxxx switch and the .model directive. I'm
> not surprised that you hadn't anticipated the conflict. But it is the
> job of the person checking in changes to expect the unexpected.

Well, I was hoping someone would do the build anyway,
as I don't appear to have the ability to do that. I can build
wasm, but there are many errors in the rest of the build on
my system, at least appearing on my screen. I haven't
investigated any log files.

> Also, because wasm is always freshly built at the start of a full
> build, any problems with wasm will cause build breaks rather quickly. I
> do not expect you to know that, but I expect the person checking in
> changes to wasm to know that, and act accordingly.

Ok.

> Thanks for the wasm updates BTW, the assembler definitely needs it.
> The text parsing and some of the semantics are wrong (ie. not like
> MASM). Anything that brings wasm closer to MASM is a good thing.

No problem. I just hope I can get it in 1.6 so that I don't need to
maintain separate source code.

BFN. Paul.

[Michal Necasek]

Paul Edwards wrote:

> Well, I was hoping someone would do the build anyway,
> as I don't appear to have the ability to do that. I can build
> wasm, but there are many errors in the rest of the build on
> my system, at least appearing on my screen. I haven't
> investigated any log files.
>

That has probably something to do with you running Win98... if you can
figure out why the behaviour on Win9x is less than useful, we can fix
that. It's just that most people (myself included) don't even have a
Win9x setup around anymore.

> No problem. I just hope I can get it in 1.6 so that I don't need to
> maintain separate source code.
>

I'm sure that would be preferable for everyone involved...

Michal

[Mat Nieuwenhoven]

On Mon, 04 Dec 2006 08:40:59 +0100, Bartosz Polednia wrote:

>Paul Edwards napisa (a):

It would help already if Paul himself did a full clean/build before he
published his patches.

Mat Nieuwenhoven

[Paul Edwards]

"Michal Necasek" <mic...@prodigy.net> wrote in message news:el1gba$qjq$1...@www-1.scitechsoft.com...

> Paul Edwards wrote:
>
> > Well, I was hoping someone would do the build anyway,
> > as I don't appear to have the ability to do that. I can build
> > wasm, but there are many errors in the rest of the build on
> > my system, at least appearing on my screen. I haven't
> > investigated any log files.
> >
> That has probably something to do with you running Win98... if you can
> figure out why the behaviour on Win9x is less than useful, we can fix
> that. It's just that most people (myself included) don't even have a
> Win9x setup around anymore.

Ok, I've found a build.log, and this is the first error I have:

================ 19:40:32 j:\devel\ow\bld\sdk\rc\rc\prebuild ================
wrc -q -bt=windows -Ij:\devel\ow\bld\watcom\h -zk0 -r -ad -I../h ..\rc.rc -fo=wrc.res
usage.rc(1): Fatal Error! 55: Unknown preprocessor directive
Error(E14): Cannot execute (wrc): No error
Error(E42): Last command making (wrc.res) returned a bad status
Error(E02): Make execution terminated
Can not open 'j:\devel\ow\bld\sdk\rc\rc\prebuild\wrce.exe' for reading: No such file or directory
<acopy wrce.exe j:\devel\ow\bld\build\binnt/bwrc.exe> => non-zero return: 1

Given that I'm using version 1.5 of OW, I am surprised that I have this
error, as wrc is coming from there. Anyway, here is the first line of
usage.rc:

#-1), "Usage: %s {options} input-filename {options} [output-filename] {options}"

Any ideas?

BFN. Paul.

[Paul Edwards]

"Mat Nieuwenhoven" <mni...@dontincludethis.zap.a2000.nl> wrote in message
news:zavrhjqbagvapyhqrguvf...@news.openwatcom.org...

> It would help already if Paul himself did a full clean/build before he
> published his patches.

I had already attempted to do that, but I got a lot of errors, but
I didn't investigate further as I assumed the build process
required something I didn't have. Since wasm was compiling
fine I was able to test my changes.

BFN. Paul.

[Michal Necasek]

Paul Edwards wrote:
> Ok, I've found a build.log, and this is the first error I have:
>
> ================ 19:40:32 j:\devel\ow\bld\sdk\rc\rc\prebuild ================
> wrc -q -bt=windows -Ij:\devel\ow\bld\watcom\h -zk0 -r -ad -I../h ..\rc.rc -fo=wrc.res
> usage.rc(1): Fatal Error! 55: Unknown preprocessor directive
>

The file usage.rc is autogenerated. The first line is supposed to look
like this:

(MSG_USE_E_BASE+1-1), "Usage: %s {options} input-filename {options}
[output-filename] {options}"

I suspect there are problems caused either by brain damaged
command.com command line parsing or possibly command line limitations.
The error you're seeing isn't caused by wrc at all, it's caused by
incorrectly generated source file.

Michal

[Hans-Bernhard Bröker]

Michal Necasek wrote:

> I suspect there are problems caused either by brain damaged command.com
> command line parsing or possibly command line limitations. The error
> you're seeing isn't caused by wrc at all, it's caused by incorrectly
> generated source file.

Suspicion seconded. The wsplice command line that build wrc.res
contains some pretty fearsome quoting (for a Windows command shell, that
is). It's certainly fragile enough for the difference between
command.com (Win9x) and cmd.exe (NT family) to break it. Command.com's
treatment of tightly packed sequences of backslashes and double-quotes
is FUBAR.

[japheth]

> I suspect there are problems caused either by brain damaged command.com
> command line parsing or possibly command line limitations. The error
> you're seeing isn't caused by wrc at all, it's caused by incorrectly
> generated source file.

I remember there once was a problem with 0x0A line ends missing the 0x0D. Has
this issue been solved now?

[Paul Edwards]

"Michal Necasek" <mic...@prodigy.net> wrote in message news:el24u2$2kb$1...@www-1.scitechsoft.com...

Ok, I checked out a fresh build and tried again, just trying to build in
the sdk\rc\rc directory to see if I could isolate the error. After a bit
of stuffing around, I now have a new "first error".

============== 09:13:58 J:\devel\ow\bld\sdk\rc\wres\dosi86\mc ===============
cc loadstr.obj
...
cc wrmergdi.obj
%create wres.lbc
bwlib -q -zld -b-n -s-t -p=16 wres.lib @wres.lbc
Error(E14): Cannot execute (bwlib): No such file or directory
Error(E42): Last command making (wres.lib) returned a bad status
Error(E02): Make execution terminated
============== 09:14:03 J:\devel\ow\bld\sdk\rc\wres\dosi86\mh ===============

I don't have a "bwlib", but I don't know which makefile this is
coming from so that I can find out if bwlib is an error in itself.

Any idea?

BFN. Paul.

[Hans-Bernhard Bröker]

Paul Edwards wrote:

> Ok, I checked out a fresh build and tried again, just trying to build in
> the sdk\rc\rc directory to see if I could isolate the error. After a bit
> of stuffing around, I now have a new "first error".

Not really. This is not really a first error, it's just the first after
some random point at which you jumped into the middle of the full
'builder build' process.

> I don't have a "bwlib", but I don't know which makefile this is
> coming from so that I can find out if bwlib is an error in itself.

bwlib is the freshly built version of wlib.

I recommend you don't try to second-guess 'builder'. It knows what to
do in which order better than you do at this point.

[Paul Edwards]

"Hans-Bernhard Bröker" <bro...@physik.rwth-aachen.de> wrote in message news:4574A8B7...@physik.rwth-aachen.de...

> Paul Edwards wrote:
>
> > Ok, I checked out a fresh build and tried again, just trying to build in
> > the sdk\rc\rc directory to see if I could isolate the error. After a bit
> > of stuffing around, I now have a new "first error".
>
> Not really. This is not really a first error, it's just the first after
> some random point at which you jumped into the middle of the full
> 'builder build' process.

Ok, my experience with wasm was that I didn't need to build
the whole world, and that it would recompile the needed stuff
on its own.

> > I don't have a "bwlib", but I don't know which makefile this is
> > coming from so that I can find out if bwlib is an error in itself.
>
> bwlib is the freshly built version of wlib.

Ok.

> I recommend you don't try to second-guess 'builder'. It knows what to
> do in which order better than you do at this point.

I wasn't trying to second-guess it, I was just trying to build the
bit that was failing, so that I could try to find out why it wasn't
working on Win98.

BFN. Paul.

[Paul Edwards]

Ok, here are the code changes, plus build fix, plus new regression
test, plus new regression tests results. These code changes are all
against the latest (2006-12-04) source.

I have run all the wasm regression tests, and only one of them had
a difference, and that difference (adding DATA to tiny) was expected,
and I have updated the test results to reflect that.

I am unable to run the wcc regression test cases because I am
unable to build wcc. I am unable to test that the build works,
because I am unable to build the build. Can someone help me
out in doing both of these tasks? I would very much like to get
these changes into 1.6 so that I don't need to maintain separate
source code.

Thanks. Paul.

Index: ow/bld/builder/master.mif
diff -c ow/bld/builder/master.mif:1.1.1.1 ow/bld/builder/master.mif:1.2
*** ow/bld/builder/master.mif:1.1.1.1 Wed Nov 29 12:58:38 2006
--- ow/bld/builder/master.mif Wed Nov 29 13:39:00 2006
***************
*** 47,53 ****
$(cl) $(clflags) $<
!ifndef __$(host_os)__ # Don't copy unless host_os=build_os
!else ifndef __UNIX__ # Avoid "text file busy".
! copy $^. $(%OWBINDIR)\ > nul # MS-influenced command noisy
!endif
!endif

--- 47,53 ----
$(cl) $(clflags) $<
!ifndef __$(host_os)__ # Don't copy unless host_os=build_os
!else ifndef __UNIX__ # Avoid "text file busy".
! copy $^. $(%OWBINDIR) > nul # MS-influenced command noisy
!endif
!endif

***************
*** 57,63 ****
!else ifdef __UNIX__
cp $^. $(%OWBINDIR)/$^& # Remove .exe from working name
!else
! copy $^. $(%OWBINDIR)\ > nul # MS-influenced command noisy
!endif

# runasdos will run itself under dosemu. Copy once for each program that still
--- 57,63 ----
!else ifdef __UNIX__
cp $^. $(%OWBINDIR)/$^& # Remove .exe from working name
!else
! copy $^. $(%OWBINDIR) > nul # MS-influenced command noisy
!endif

# runasdos will run itself under dosemu. Copy once for each program that still
Index: ow/bld/wasm/c/asmline.c
diff -c ow/bld/wasm/c/asmline.c:1.1.1.3 ow/bld/wasm/c/asmline.c:1.7
*** ow/bld/wasm/c/asmline.c:1.1.1.3 Mon Dec 04 19:31:00 2006
--- ow/bld/wasm/c/asmline.c Mon Dec 04 20:22:44 2006
***************
*** 151,157 ****
skip = TRUE;
break;
case '\n':
- #if 0
/* Paul Edwards */
/* if continuation character found, pass over newline */
if( (got_something == TRUE) && (*(ptr - 1) == '\\') ) {
--- 151,156 ----
***************
*** 160,166 ****
LineNumber++;
continue; /* don't store character in string */
}
- #endif
*ptr = '\0';
// fall through
case '\0':
--- 159,164 ----
Index: ow/bld/wasm/c/asmscan.c
diff -c ow/bld/wasm/c/asmscan.c:1.1.1.1 ow/bld/wasm/c/asmscan.c:1.3
*** ow/bld/wasm/c/asmscan.c:1.1.1.1 Wed Nov 29 12:59:14 2006
--- ow/bld/wasm/c/asmscan.c Tue Dec 05 06:21:02 2006
***************
*** 614,620 ****
CurrString = string;
output_ptr = stringbuf;

! for( ptr = string; ; ) {
AsmBuffer[buf_index]->string_ptr = output_ptr;

while( isspace( *ptr ) ) {
--- 614,626 ----
CurrString = string;
output_ptr = stringbuf;

! ptr = string;
! /* skip initial spaces and expansion codes */
! while( isspace( *ptr ) || (*ptr == '%') ) {
! ptr++;
! }
!
! for( ; ; ) {
AsmBuffer[buf_index]->string_ptr = output_ptr;

while( isspace( *ptr ) ) {
Index: ow/bld/wasm/c/direct.c
diff -c ow/bld/wasm/c/direct.c:1.1.1.3 ow/bld/wasm/c/direct.c:1.13
*** ow/bld/wasm/c/direct.c:1.1.1.3 Mon Dec 04 19:31:00 2006
--- ow/bld/wasm/c/direct.c Mon Dec 04 20:25:38 2006
***************
*** 2043,2049 ****
InputQueueLine( get_sim_code_end( buffer, Options.text_seg ) );

/* Generates codes for data segment */
! if( type != MOD_TINY ) {
InputQueueLine( SimCodeBegin[bit][SIM_DATA] );
InputQueueLine( SimCodeEnd[SIM_DATA] );
}
--- 2043,2049 ----
InputQueueLine( get_sim_code_end( buffer, Options.text_seg ) );

/* Generates codes for data segment */
! if( 1 ) { /* type != MOD_TINY */
InputQueueLine( SimCodeBegin[bit][SIM_DATA] );
InputQueueLine( SimCodeEnd[SIM_DATA] );
}
***************
*** 2053,2060 ****
switch( type ) {
case MOD_TINY:
strcat( buffer, Options.text_seg );
! InputQueueLine( buffer );
! break;
case MOD_SMALL:
case MOD_COMPACT:
case MOD_MEDIUM:
--- 2053,2060 ----
switch( type ) {
case MOD_TINY:
strcat( buffer, Options.text_seg );
! strcat( buffer, ", ");
! /* fall through */
case MOD_SMALL:
case MOD_COMPACT:
case MOD_MEDIUM:
***************
*** 2066,2073 ****
}
ModelAssumeInit();

- #if 0
/* Paul Edwards */
{
int modelnum = -1;
/* Fix up PTR size */
--- 2066,2073 ----
}
ModelAssumeInit();

/* Paul Edwards */
+ if (ModuleInfo.init == FALSE)
{
int modelnum = -1;
/* Fix up PTR size */
***************
*** 2136,2142 ****
InputQueueLine( buffer );
}
}
- #endif
}

void ModuleInit( void )
--- 2136,2141 ----
***************
*** 2753,2759 ****
case TOK_PROC_VARARG:
return( 0 );
default:
- #if 0
if ( type == TOK_EXT_PTR ) {
if( ( ModuleInfo.model == MOD_COMPACT )
|| ( ModuleInfo.model == MOD_LARGE )
--- 2752,2757 ----
***************
*** 2762,2768 ****
}
else return ( 2 );
}
- #endif
return( ERROR );
}
}
--- 2760,2765 ----
Index: ow/bld/wasm/h/directd.h
diff -c ow/bld/wasm/h/directd.h:1.1.1.3 ow/bld/wasm/h/directd.h:1.4
*** ow/bld/wasm/h/directd.h:1.1.1.3 Mon Dec 04 19:30:42 2006
--- ow/bld/wasm/h/directd.h Mon Dec 04 20:22:10 2006
***************
*** 62,71 ****
fix( TOK_EXT_SBYTE, "SBYTE", MT_BYTE, 0 ),
fix( TOK_EXT_WORD, "WORD", MT_WORD, 0 ),
fix( TOK_EXT_SWORD, "SWORD", MT_WORD, 0 ),
- #if 0
- /* Paul Edwards */
fix( TOK_EXT_PTR, "PTR", MT_WORD, 0 ),
- #endif
fix( TOK_EXT_DWORD, "DWORD", MT_DWORD, 0 ),
fix( TOK_EXT_SDWORD, "SDWORD", MT_DWORD, 0 ),
fix( TOK_EXT_PWORD, "PWORD", MT_FWORD, 0 ),
--- 62,68 ----
Index: ow/bld/wasm/test/test1/beep.esm
diff -c ow/bld/wasm/test/test1/beep.esm:1.1.1.1 ow/bld/wasm/test/test1/beep.esm:1.2
*** ow/bld/wasm/test/test1/beep.esm:1.1.1.1 Wed Nov 29 12:59:12 2006
--- ow/bld/wasm/test/test1/beep.esm Tue Dec 05 06:26:30 2006
***************
*** 1,13 ****
.387
! DGROUP GROUP _TEXT
_TEXT SEGMENT WORD PUBLIC USE16 'CODE'
ASSUME CS:DGROUP, DS:DGROUP, SS:DGROUP
! mov ah,2
! mov dl,7
! int 21H
! mov ah,2
! mov dl,7
! int 21H
! ret
_TEXT ENDS
END
--- 1,15 ----
.387
! DGROUP GROUP _TEXT,_DATA
_TEXT SEGMENT WORD PUBLIC USE16 'CODE'
ASSUME CS:DGROUP, DS:DGROUP, SS:DGROUP
! mov ah,2
! mov dl,7
! int 21H
! mov ah,2
! mov dl,7
! int 21H
! ret
_TEXT ENDS
+ _DATA SEGMENT WORD PUBLIC USE16 'DATA'
+ _DATA ENDS
END
Index: ow/bld/wasm/test/test3/makefile
diff -c ow/bld/wasm/test/test3/makefile:1.1.1.1 ow/bld/wasm/test/test3/makefile:1.2
*** ow/bld/wasm/test/test3/makefile:1.1.1.1 Wed Nov 29 12:59:12 2006
--- ow/bld/wasm/test/test3/makefile Tue Dec 05 06:47:54 2006
***************
*** 44,49 ****
--- 44,50 ----
sse3 &
struct1 &
structdd &
+ support &
tbyte &
testequ &
tst1
***************
*** 57,61 ****
--- 58,63 ----
asm_flags_callcnv5 = -zcm
asm_flags_jmpshrt = -zcm
asm_flags_retiret = -zcm
+ asm_flags_support = -zcm -Dmemodel=large

!include ../test.mif
Index: ow/bld/wasm/test/test3/support.asm
diff -c /dev/null ow/bld/wasm/test/test3/support.asm:1.1
*** /dev/null Tue Dec 05 08:58:58 2006
--- ow/bld/wasm/test/test3/support.asm Tue Dec 05 06:51:08 2006
***************
*** 0 ****
--- 1,240 ----
+ ; support.asm - assembler support functions for DOS
+ ;
+ ; This program written by Paul Edwards
+ ; Released to the public domain
+
+ % .model memodel, c
+
+ assume cs:_TEXT, ds:DGROUP
+
+ _DATA segment word public 'DATA'
+ _DATA ends
+ _BSS segment word public 'BSS'
+ _BSS ends
+
+ _TEXT segment word public 'CODE'
+
+ public int86
+ int86 proc uses ax bx cx dx si di ds es, \
+ intnum:word, regsin:ptr, regsout:ptr
+
+ if @DataSize
+ lds si, regsin
+ else
+ mov si, regsin
+ endif
+
+ mov ax, word ptr [si + 0]
+ mov bx, word ptr [si + 2]
+ mov cx, word ptr [si + 4]
+ mov dx, word ptr [si + 6]
+ mov di, word ptr [si + 10]
+ mov si, word ptr [si + 8]
+
+ push bp
+
+ cmp intnum, 08h
+ jne not8
+ int 08h
+ jmp fintry
+ not8:
+
+ cmp intnum, 09h
+ jne not9
+ int 09h
+ jmp fintry
+ not9:
+
+ cmp intnum, 010h
+ jne not10
+ int 010h
+ jmp fintry
+ not10:
+
+ cmp intnum, 013h
+ jne not13
+ int 013h
+ jmp fintry
+ not13:
+
+ cmp intnum, 015h
+ jne not15
+ clc ; interrupt doesn't set it it seems
+ int 015h
+ jmp fintry
+ not15:
+
+ cmp intnum, 016h
+ jne not16
+ int 016h
+ jmp fintry
+ not16:
+
+ cmp intnum, 020h
+ jne not20
+ int 020h
+ jmp fintry
+ not20:
+
+ cmp intnum, 021h
+ jne not21
+ int 021h
+ jmp fintry
+ not21:
+
+ fintry:
+
+ pop bp
+ push si
+
+ if @DataSize
+ lds si, regsout
+ else
+ mov si, regsout
+ endif
+
+ mov [si + 0], ax
+ mov [si + 2], bx
+ mov [si + 4], cx
+ mov [si + 6], dx
+ mov [si + 10], di
+ pop ax ; actually si
+ mov [si + 8], ax
+ mov word ptr [si + 12], 0
+ jnc flagclear
+ mov word ptr [si + 12], 1
+ flagclear:
+ pushf
+ pop ax
+ mov word ptr [si + 14], ax
+
+ ret
+ int86 endp
+
+
+
+ public int86x
+ int86x proc uses ax bx cx dx si di ds es, \
+ intnum:word, regsin:ptr, regsout:ptr, sregs:ptr
+
+ push ds; for restoration after interrupt
+
+ if @DataSize
+ lds si, sregs
+ else
+ mov si, sregs
+ endif
+
+ mov es, [si + 6]
+ push es ; new value for ds
+
+ mov es, [si + 0]
+
+ if @DataSize
+ lds si, regsin
+ else
+ mov si, regsin
+ endif
+
+ mov ax, word ptr [si + 0]
+ mov bx, word ptr [si + 2]
+ mov cx, word ptr [si + 4]
+ mov dx, word ptr [si + 6]
+ mov di, word ptr [si + 10]
+ mov si, word ptr [si + 8]
+
+ pop ds; load previously saved value for ds
+
+ cmp intnum, 08h
+ jne xnot8
+ int 08h
+ jmp xfintry
+ xnot8:
+
+ cmp intnum, 09h
+ jne xnot9
+ int 09h
+ jmp xfintry
+ xnot9:
+
+ cmp intnum, 010h
+ jne xnot10
+ int 010h
+ jmp xfintry
+ xnot10:
+
+ cmp intnum, 013h
+ jne xnot13
+ int 013h
+ jmp xfintry
+ xnot13:
+
+ cmp intnum, 015h
+ jne xnot15
+ clc ; interrupt doesn't set it it seems
+ int 015h
+ jmp xfintry
+ xnot15:
+
+ cmp intnum, 016h
+ jne xnot16
+ int 016h
+ jmp xfintry
+ xnot16:
+
+ cmp intnum, 021h
+ jne xnot21
+ int 021h
+ jmp xfintry
+ xnot21:
+
+ xfintry:
+
+ push es
+ push ds
+ push si
+ push ax
+ push bp
+
+ mov bp, sp
+ mov ax, [bp+10]; restore ds immediately, can't move without it
+ pop bp
+ mov ds, ax
+
+ if @DataSize
+ lds si, regsout
+ else
+ mov si, regsout
+ endif
+
+ pop ax
+ mov [si + 0], ax
+ mov [si + 2], bx
+ mov [si + 4], cx
+ mov [si + 6], dx
+ mov [si + 10], di
+ pop ax
+ mov [si + 8], ax ; si
+ mov word ptr [si + 12], 0
+ jnc xflagclear
+ mov word ptr [si + 12], 1
+ xflagclear:
+
+ if @DataSize
+ lds si, sregs
+ else
+ mov si, sregs
+ endif
+
+ pop ax
+ mov [si + 6], ax; restore ds
+ pop ax
+ mov [si + 0], ax ; restore es
+
+ pop ds ; restore value saved over interrupt (but accessed directly already)
+ ret
+ int86x endp
+
+ _TEXT ends
+
+ end
Index: ow/bld/wasm/test/test3/support.esm
diff -c /dev/null ow/bld/wasm/test/test3/support.esm:1.1
*** /dev/null Tue Dec 05 08:58:58 2006
--- ow/bld/wasm/test/test3/support.esm Tue Dec 05 06:46:00 2006
***************
*** 0 ****
--- 1,200 ----
+ .387
+ PUBLIC _int86
+ PUBLIC _int86x
+ DGROUP GROUP _DATA
+ support_TEXT SEGMENT WORD PUBLIC USE16 'CODE'
+ support_TEXT ENDS
+ _DATA SEGMENT WORD PUBLIC USE16 'DATA'
+ _DATA ENDS
+ _BSS SEGMENT WORD PUBLIC USE16 'BSS'
+ _BSS ENDS
+
+ _TEXT SEGMENT WORD PUBLIC USE16 'CODE'
+ ASSUME CS:_TEXT, DS:DGROUP, SS:DGROUP
+ _int86:
+ push bp
+ mov bp,sp
+ push ax
+ push bx
+ push cx
+ push dx
+ push si
+ push di
+ push ds
+ push es
+ lds si,dword ptr 8[bp]
+ mov ax,word ptr [si]
+ mov bx,word ptr 2[si]
+ mov cx,word ptr 4[si]
+ mov dx,word ptr 6[si]
+ mov di,word ptr 0aH[si]
+ mov si,word ptr 8[si]
+ push bp
+ cmp word ptr 6[bp],8
+ jne L$1
+ int 8
+ jmp L$8
+ L$1:
+ cmp word ptr 6[bp],9
+ jne L$2
+ int 9
+ jmp L$8
+ L$2:
+ cmp word ptr 6[bp],10H
+ jne L$3
+ int 10H
+ jmp L$8
+ L$3:
+ cmp word ptr 6[bp],13H
+ jne L$4
+ int 13H
+ jmp L$8
+ L$4:
+ cmp word ptr 6[bp],15H
+ jne L$5
+ clc
+ int 15H
+ jmp L$8
+ L$5:
+ cmp word ptr 6[bp],16H
+ jne L$6
+ int 16H
+ jmp L$8
+ L$6:
+ cmp word ptr 6[bp],20H
+ jne L$7
+ int 20H
+ jmp L$8
+ L$7:
+ cmp word ptr 6[bp],21H
+ jne L$8
+ int 21H
+ jmp L$8
+ L$8:
+ pop bp
+ push si
+ lds si,dword ptr 0cH[bp]
+ mov word ptr [si],ax
+ mov word ptr 2[si],bx
+ mov word ptr 4[si],cx
+ mov word ptr 6[si],dx
+ mov word ptr 0aH[si],di
+ pop ax
+ mov word ptr 8[si],ax
+ mov word ptr 0cH[si],0
+ jae L$9
+ mov word ptr 0cH[si],1
+ L$9:
+ pushf
+ pop ax
+ mov word ptr 0eH[si],ax
+ pop es
+ pop ds
+ pop di
+ pop si
+ pop dx
+ pop cx
+ pop bx
+ pop ax
+ pop bp
+ retf
+ _int86x:
+ push bp
+ mov bp,sp
+ push ax
+ push bx
+ push cx
+ push dx
+ push si
+ push di
+ push ds
+ push es
+ push ds
+ lds si,dword ptr 10H[bp]
+ mov es,word ptr 6[si]
+ push es
+ mov es,word ptr [si]
+ lds si,dword ptr 8[bp]
+ mov ax,word ptr [si]
+ mov bx,word ptr 2[si]
+ mov cx,word ptr 4[si]
+ mov dx,word ptr 6[si]
+ mov di,word ptr 0aH[si]
+ mov si,word ptr 8[si]
+ pop ds
+ cmp word ptr 6[bp],8
+ jne L$10
+ int 8
+ jmp L$16
+ L$10:
+ cmp word ptr 6[bp],9
+ jne L$11
+ int 9
+ jmp L$16
+ L$11:
+ cmp word ptr 6[bp],10H
+ jne L$12
+ int 10H
+ jmp L$16
+ L$12:
+ cmp word ptr 6[bp],13H
+ jne L$13
+ int 13H
+ jmp L$16
+ L$13:
+ cmp word ptr 6[bp],15H
+ jne L$14
+ clc
+ int 15H
+ jmp L$16
+ L$14:
+ cmp word ptr 6[bp],16H
+ jne L$15
+ int 16H
+ jmp L$16
+ L$15:
+ cmp word ptr 6[bp],21H
+ jne L$16
+ int 21H
+ jmp L$16
+ L$16:
+ push es
+ push ds
+ push si
+ push ax
+ push bp
+ mov bp,sp
+ mov ax,word ptr 0aH[bp]
+ pop bp
+ mov ds,ax
+ lds si,dword ptr 0cH[bp]
+ pop ax
+ mov word ptr [si],ax
+ mov word ptr 2[si],bx
+ mov word ptr 4[si],cx
+ mov word ptr 6[si],dx
+ mov word ptr 0aH[si],di
+ pop ax
+ mov word ptr 8[si],ax
+ mov word ptr 0cH[si],0
+ jae L$17
+ mov word ptr 0cH[si],1
+ L$17:
+ lds si,dword ptr 10H[bp]
+ pop ax
+ mov word ptr 6[si],ax
+ pop ax
+ mov word ptr [si],ax
+ pop ds
+ pop es
+ pop ds
+ pop di
+ pop si
+ pop dx
+ pop cx
+ pop bx
+ pop ax
+ pop bp
+ retf
+ _TEXT ENDS
+ END

[Paul Edwards]

"Michal Necasek" <mic...@prodigy.net> wrote in message news:el24u2$2kb$1...@www-1.scitechsoft.com...

> Paul Edwards wrote:
> > Ok, I've found a build.log, and this is the first error I have:
> >
> > ================ 19:40:32 j:\devel\ow\bld\sdk\rc\rc\prebuild ================
> > wrc -q -bt=windows -Ij:\devel\ow\bld\watcom\h -zk0 -r -ad -I../h ..\rc.rc -fo=wrc.res
> > usage.rc(1): Fatal Error! 55: Unknown preprocessor directive
> >
> The file usage.rc is autogenerated. The first line is supposed to look
> like this:
>
> (MSG_USE_E_BASE+1-1), "Usage: %s {options} input-filename {options}
> [output-filename] {options}"

I copied the following line:
wsplice -kENGLISH -kIS_RC -knt -t8 -f "%+(MSG_USE_E_BASE+%#-1), \"%s\"" ../usage.sp usage.rc

into a batch file, then I changed the "%" to "%%" and ran it,
and got the same (ie correct) results you did.

Where is the makefile that has this command in it? I'll try
changing the makefile to include two % to see if that fixes
the problem.

BFN. Paul.

[Paul Edwards]

"Paul Edwards" <kerr...@nosppaam.w3.to> wrote in message news:el2cje$5g2$1...@www-1.scitechsoft.com...

> I copied the following line:
> wsplice -kENGLISH -kIS_RC -knt -t8 -f "%+(MSG_USE_E_BASE+%#-1), \"%s\"" ../usage.sp usage.rc
>
> into a batch file, then I changed the "%" to "%%" and ran it,
> and got the same (ie correct) results you did.
>
> Where is the makefile that has this command in it? I'll try
> changing the makefile to include two % to see if that fixes
> the problem.

I've found the makefile with the command in it, master.mif.
I've put some debug into wsplice and can see that the parameter
gets through fine when run as a batch file, but the first portion
of the "-f" parameter gets lost when run from wmake.

I'm now attempting to put some debug info into wmake to see
if it is actually sending out the full "-f" parameter.

BFN. Paul.

[Arkady V.Belousov]

Hi!

Paul Edwards 05.12.06 2:10 wrote:

> --- ow/bld/wasm/test/test3/support.asm Tue Dec 05 06:51:08 2006
> ***************
> *** 0 ****
> --- 1,240 ----
> + ; support.asm - assembler support functions for DOS

[...]

> + public int86
> + int86 proc uses ax bx cx dx si di ds es, \
> + intnum:word, regsin:ptr, regsout:ptr
> + if @DataSize
> + lds si, regsin
> + else
> + mov si, regsin
> + endif
> + mov ax, word ptr [si + 0]
> + mov bx, word ptr [si + 2]
> + mov cx, word ptr [si + 4]
> + mov dx, word ptr [si + 6]
> + mov di, word ptr [si + 10]
> + mov si, word ptr [si + 8]

> + push bp

> + cmp intnum, 08h
> + jne not8

[...]
> + int86 endp

> + public int86x
> + int86x proc uses ax bx cx dx si di ds es, \
> + intnum:word, regsin:ptr, regsout:ptr, sregs:ptr

[...]
> + int86x endp

This is not good implementation:

- too fat;
- handles only part of all interrupt numbers;
- handles not all registers;
- doesn't allows to specify carry flag on input.

Recently, I prepare callint() and callint386() functions for Blair's CLIB.
Below 5 files:

- x86.h: definition of register structures and flags names;
- segread.c/segrd32.c: implementation of _segread()/_segread32() functions,
which read current segment registers into structure;
- callint.c/callin32.c: call any interrupt number (including INT25/26) with
any user specified register (except SS/SP/CS) and flags (including carry
flag). [Note, there is bugs in OW: "#pragma aux" doesn't allows to use
labels as offsets and it silently ignores "bp" in "modify[]" clause; this
all workarounded.]

Implementation details described in head comments (sorry for my bad
English); after implementation present code, which shows functions usage.
These functions are short, and they may be shortened even more, but Blair
thinks, that source readability is more important, than lesser size with
string instructions. Because of using #pragma aux, porting these C functions
to plain assembler shouldn't be hard.

[Paul Edwards]

"Arkady V.Belousov" <a...@mos.ru> wrote in message news:el2ou1$90q$1...@www-1.scitechsoft.com...

> > + public int86x
> > + int86x proc uses ax bx cx dx si di ds es, \
> > + intnum:word, regsin:ptr, regsout:ptr, sregs:ptr
> [...]
> > + int86x endp

BTW, this is a testcase, it's not part of OW. :-)

> This is not good implementation:

I'm not an x86 expert as you can probably tell. :-)

> - too fat;
> - handles only part of all interrupt numbers;
> - handles not all registers;
> - doesn't allows to specify carry flag on input.

Ok.

> Recently, I prepare callint() and callint386() functions for Blair's CLIB.

I would like assembler code to be in an assembler file, not C.
And I need public domain code. If you would like to send me
a replacement support.asm (basically same interface), that is
public domain, I will use it in PDOS.

http://sourceforge.net/projects/pdos/

BFN. Paul.

[Paul Edwards]

"Paul Edwards" <kerr...@nosppaam.w3.to> wrote in message news:el2hnm$6hh$1...@www-1.scitechsoft.com...

> I'm now attempting to put some debug info into wmake to see
> if it is actually sending out the full "-f" parameter.

I've tracked down the bug, it appears that Watcom is calling
an undocumented CreateProcessA(), which is causing the
string to be lost in Win98. Since it is undocumented, I can't
see if there is a reason for this. My own C library (PDPCLIB)
uses the documented CreateProcess(), and it doesn't have a
problem sending the string through. I'm about to try changing
sysnt.c to use CreateProcess() instead of CreateProcessA()
and see if that fixes the problem.

BFN. Paul.

[Arkady V.Belousov]

Hi!

Paul Edwards 05.12.06 6:44 wrote:

>>> + int86x endp
> BTW, this is a testcase, it's not part of OW. :-)

But it tests not (in)efficiency of code, so why include such code, when
there exist better one?

>> Recently, I prepare callint() and callint386() functions for Blair's CLIB.
> I would like assembler code to be in an assembler file, not C.

Problem with external assembler files is, that they should be compiled
by (1) _additional_ external (for C/C++ compiler) assembler (which may not
be present) and that (2) it harder to support code correctness.

> And I need public domain code.

Blair's CLIB, for which I wrote callint(), is PD.

> If you would like to send me
> a replacement support.asm

Just compile given sources for each of 7 memory models (wcc -d1-m...
callint.c), then disassemble (wdis -a-fi-s callint.obj) - and you have pure
assembler sources. :)

> (basically same interface),

Issue with existing int86*() interface, which you try to imitate, is
that it itself too limited (not all registers, like BP, are present - but
this need, for example, for INT10/11xx functions; int86()/int86x() are
separate and duplicated), and that order of fields is incompatible with
PUSHALL/POPALL instructions. This is why structures was designed from scratch.

> that is
> public domain, I will use it in PDOS.

I myself prefer GPL, but in given case it may be used as PD.

[Paul Edwards]

"Arkady V.Belousov" <a...@mos.ru> wrote in message news:el2s2h$9pv$1...@www-1.scitechsoft.com...

> >>> + int86x endp
> > BTW, this is a testcase, it's not part of OW. :-)
>
> But it tests not (in)efficiency of code, so why include such code, when
> there exist better one?

It's not testing efficiency of code, it's testing to see whether
masm can handle line continuations, macro expansions and
different memory models.

> >> Recently, I prepare callint() and callint386() functions for Blair's CLIB.
> > I would like assembler code to be in an assembler file, not C.
>
> Problem with external assembler files is, that they should be compiled
> by (1) _additional_ external (for C/C++ compiler) assembler (which may not
> be present) and that (2) it harder to support code correctness.

I like my C code to be standard, ie not using compiler extensions,
and my assembler to also be standard.

> > And I need public domain code.
>
> Blair's CLIB, for which I wrote callint(), is PD.

Can you give me a link to this please? I'd like to take some of the
math functions for use in PDPCLIB.

> > If you would like to send me
> > a replacement support.asm
>
> Just compile given sources for each of 7 memory models (wcc -d1-m...
> callint.c), then disassemble (wdis -a-fi-s callint.obj) - and you have pure
> assembler sources. :)

I'm after a single assembler source file which is aware of the
different memory models, using the features that have been
available in WASM now for almost -1 days. :-)

> > that is
> > public domain, I will use it in PDOS.
>
> I myself prefer GPL, but in given case it may be used as PD.

I want commercial companies to be able to use my code with no
strings attached. For your code to be PD it needs to have an explicit
PD notice on it. Code is copyrighted by default.

BFN. Paul.

[Blair Campbell]

> > Blair's CLIB, for which I wrote callint(), is PD.
>
> Can you give me a link to this please? I'd like to take some of the
> math functions for use in PDPCLIB.

If you're talking about math.h functions, that's one header I haven't started on. And you should know that all of the modules that would need to be memory-model specific are only for the small memory model at present. But the url (although slightly outdated by now, some bugfixes and extra functions have been added since then) is http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/libs/clib/fdclib.zip . Also bear in mind that in its current state it is highly OpenWatcom-specific and that in most of the cases where assembler is used, it is #pragma aux style. Oh and btw, some of the functions (like strtol) are borrowed from PDPCLIB :-).

[Arkady V.Belousov]

Hi!

Paul Edwards 05.12.06 7:38 wrote:

>> Problem with external assembler files is, that they should be compiled
>> by (1) _additional_ external (for C/C++ compiler) assembler (which may not
>> be present) and that (2) it harder to support code correctness.
> I like my C code to be standard, ie not using compiler extensions,
> and my assembler to also be standard.

External assembler files are even more evil using "compiler
extensions". "More evil" because extension is external for compiler and even
less controllable by you. For example, there even harder to control calling
conventions correctness, especially if you plan to port source to different
compiler (else why to move inline assembler to external files?).

>>> And I need public domain code.
>> Blair's CLIB, for which I wrote callint(), is PD.
> Can you give me a link to this please? I'd like to take some of the
> math functions for use in PDPCLIB.

You should ask Blair for this, he develop and maintain CLIB.

>>> If you would like to send me
>>> a replacement support.asm
>> Just compile given sources for each of 7 memory models (wcc -d1-m...
>> callint.c), then disassemble (wdis -a-fi-s callint.obj) - and you have pure
>> assembler sources. :)
> I'm after a single assembler source file which is aware of the
> different memory models, using the features that have been
> available in WASM now for almost -1 days. :-)

Who prevents you to glue abovementioned sources through conditional
compilation and "simplified directives"?

>>> that is
>>> public domain, I will use it in PDOS.
>> I myself prefer GPL, but in given case it may be used as PD.
> I want commercial companies to be able to use my code with no
> strings attached. For your code to be PD it needs to have an explicit
> PD notice on it. Code is copyrighted by default.

I give you permission to insert PD notice in head if files. :) Also
note, copyright is different thing, than licensing.

[Paul Edwards]

"Blair Campbell" <bl...@ified.ca> wrote in message news:20061204211344...@ified.ca...

> > > Blair's CLIB, for which I wrote callint(), is PD.
> >
> > Can you give me a link to this please? I'd like to take some of the
> > math functions for use in PDPCLIB.
>
> If you're talking about math.h functions, that's one header I haven't started on.

Damn. :-) Well Dave Wade has done most of the work already,
if you get the latest version of PDPCLIB out of CVS. He's just
missing atan2() and a proper implementation of modf(). So you
can use his stuff if you want. A new release is imminent, just
waiting on some MVS code to be added.

> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/libs/clib/fdclib.zip .

Ok, thankyou! You might want to add a readme.txt to it. Glad to
see you have an explicit PD notice on the code.

> Also bear in mind that in its current state it is highly
> OpenWatcom-specific and that in most of the cases where
> assembler is used, it is #pragma aux style.

Ok.

> Oh and btw, some of the functions (like strtol) are borrowed from PDPCLIB :-).

Glad to see you found something of use from it. :-)

Good to see people now have a number of options for a PD C
runtime library. Another one is PDCLIB (as opposed to PDPCLIB).

BFN. Paul.

[Paul Edwards]

"Arkady V.Belousov" <a...@mos.ru> wrote in message news:el2vv7$b28$1...@www-1.scitechsoft.com...

> Hi!
>
> Paul Edwards 05.12.06 7:38 wrote:
>
> >> Problem with external assembler files is, that they should be compiled
> >> by (1) _additional_ external (for C/C++ compiler) assembler (which may not
> >> be present) and that (2) it harder to support code correctness.
> > I like my C code to be standard, ie not using compiler extensions,
> > and my assembler to also be standard.
>
> External assembler files are even more evil using "compiler
> extensions". "More evil" because extension is external for compiler and even
> less controllable by you. For example, there even harder to control calling
> conventions correctness, especially if you plan to port source to different
> compiler (else why to move inline assembler to external files?).

Not sure why you say that. tasm/masm/wasm all enable the
standard stack conventions. I can mix and match assemblers
and compilers. E.g. I'm planning on using wasm as my
assembler and tc++ as my compiler, which are both free and
available as 16-bit DOS programs. But a company can choose
to use MASM instead and get proper support. I think this is
the correct way to do it. Assembler is a language, and C is a
language, and they need separate tools.

> > I'm after a single assembler source file which is aware of the
> > different memory models, using the features that have been
> > available in WASM now for almost -1 days. :-)
>
> Who prevents you to glue abovementioned sources through conditional
> compilation and "simplified directives"?

Nothing. I just need to do the work of figuring out how to
make it fit in with the existing interface, and supporting
multiple memory models.

> >>> that is
> >>> public domain, I will use it in PDOS.
> >> I myself prefer GPL, but in given case it may be used as PD.
> > I want commercial companies to be able to use my code with no
> > strings attached. For your code to be PD it needs to have an explicit
> > PD notice on it. Code is copyrighted by default.
>
> I give you permission to insert PD notice in head if files. :)

Ok.

> Also note, copyright is different thing, than licensing.

Yeah, but with PD there is no further licensing restrictions.
Companies shouldn't have to wade through the 52 licencing
conditions of GPL to see if they are violating any of them.
Or Open Watcom for that matter.

BFN. Paul.

[Mat Nieuwenhoven]

I'll pick the Win98 games PC from my children and see if I can get the
build going.

Mat Nieuwenhoven

[Bartosz Polednia]

It was my change to use CreateProcessA inside sysnt.c.

My investigations showed that Microsoft'a API defines

blahblahA as ANSI string version of blahblah
blahblahW as UNICODE string version of blahblah.

You can find info or exapmles here:

http://support.microsoft.com/kb/129796
or
http://www.andreavb.com/tip020004.html
or
http://source.winehq.org/source/dlls/kernel32/process.c
or
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createprocess.asp

Bartosz.

[Michal Necasek]

Paul Edwards wrote:

> I've tracked down the bug, it appears that Watcom is calling
> an undocumented CreateProcessA(), which is causing the
> string to be lost in Win98. Since it is undocumented, I can't
> see if there is a reason for this. My own C library (PDPCLIB)
> uses the documented CreateProcess(), and it doesn't have a
> problem sending the string through. I'm about to try changing
> sysnt.c to use CreateProcess() instead of CreateProcessA()
> and see if that fixes the problem.
>

No, you are slightly confused. There is no CreateProcess API. There is
CreateProcessA and CreateProcessW. CreateProcess is a *macro* which
expands to either CreateProcessA or CreateProcessW.

Michal

[Paul Edwards]

"Michal Necasek" <mic...@prodigy.net> wrote in message news:el38ue$e0d$1...@www-1.scitechsoft.com...

> Paul Edwards wrote:
>
> > I've tracked down the bug, it appears that Watcom is calling
> > an undocumented CreateProcessA(), which is causing the
> > string to be lost in Win98. Since it is undocumented, I can't
> > see if there is a reason for this. My own C library (PDPCLIB)
> > uses the documented CreateProcess(), and it doesn't have a
> > problem sending the string through. I'm about to try changing
> > sysnt.c to use CreateProcess() instead of CreateProcessA()
> > and see if that fixes the problem.
> >
> No, you are slightly confused. There is no CreateProcess API. There is

I was just going by what they published here:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createprocess.asp

> CreateProcessA and CreateProcessW. CreateProcess is a *macro* which
> expands to either CreateProcessA or CreateProcessW.

Ok.

Regardless, I don't yet know why OW's implementation of system()
is different from mine, other than it is clearly able to run batch files,
so presumably somehow running the command processor.

I'll try to investigate further.

BFN. Paul.

[Arkady V.Belousov]

Hi!

Paul Edwards 05.12.06 8:57 wrote:

>> External assembler files are even more evil using "compiler
>> extensions". "More evil" because extension is external for compiler and even
>> less controllable by you. For example, there even harder to control calling
>> conventions correctness, especially if you plan to port source to different
>> compiler (else why to move inline assembler to external files?).
> Not sure why you say that. tasm/masm/wasm all enable the
> standard stack conventions.

In Watcom there is different calling convention. And if you forget to
explicitly specify "cdecl" calling convention (and, thus, making worser
code), you under trouble.

>>> I'm after a single assembler source file which is aware of the
>>> different memory models, using the features that have been
>>> available in WASM now for almost -1 days. :-)
>> Who prevents you to glue abovementioned sources through conditional
>> compilation and "simplified directives"?
> Nothing. I just need to do the work of figuring out how to
> make it fit in with the existing interface, and supporting
> multiple memory models.

Just read sources: here supported memory models (see #if defined) and
porting to plain assembler is easy (just remove quotes around instructions
in #pragma aux). There remains only one task: convert one-line callint()
C-function to assembler function, and correctness of this conversion you may
test by code inside #ifdef TEST/#endif.

>> Also note, copyright is different thing, than licensing.
> Yeah, but with PD there is no further licensing restrictions.
> Companies shouldn't have to wade through the 52 licencing
> conditions of GPL to see if they are violating any of them.

There is not "52 licensing conditions". All easy: if you make
derivative work (your program based on GPL-ed _sources_), then your program
also should be GPL-ed (ie., released in sources and there shouldn't be
restrictions in accessing and (re)distributing both program executable(s)
and sources). If your program just _uses_ (calls) GPLed program, then there
is no restrictions, how you may license your program.

[Michal Necasek]

Paul Edwards wrote:
> I was just going by what they published here:
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createprocess.asp
>

Right near the bottom: "Implemented as CreateProcessW (Unicode) and
CreateProcessA (ANSI)." Microsoft probably assumes that what I said
earlier about the A/W functions is common knowledge and everyone is
aware of it. It's something I probably read in some book 10+ years ago
but I have no idea where MSDN documents that little tidbit.

> Regardless, I don't yet know why OW's implementation of system()
> is different from mine, other than it is clearly able to run batch files,
> so presumably somehow running the command processor.
>

See my other post (yes, it does run the command processor). And it's
not just batch files, it's internal shell commands too.

Michal

[Peter C. Chapin]

"Arkady V.Belousov" <a...@mos.ru> wrote in

news:el3bvk$g00$1...@www-1.scitechsoft.com:

> In Watcom there is different calling convention. And if you

> forget to...

I'm not sure why there is this big discussion regarding regression test
cases... unless I'm misunderstanding something. The point of a regression
test is to exercise some certain aspect of the program under test... not to
write realistic or useful code. In fact, writing inefficient or "stupid"
code is probably good to do now and then in a regression test suite. After
all, real users write such code and wasm should be able to assemble it.

In the OWSTL test suite I try to use various approaches in the code. Some
techniques are not very smart, but they are all legal. However, if I always
used the same methods, the breadth of the test suite would be reduced and
its quality as a test suite would be less.

Peter

[Peter C. Chapin]

"Mat Nieuwenhoven" <mni...@dontincludethis.zap.a2000.nl> wrote in

news:zavrhjqbagvapyhqrguvf...@news.openwatcom.org:

> I'll pick the Win98 games PC from my children and see if I can get the
> build going.

To be honest, I wouldn't suggest spending a lot of time getting the build
to work on Windows 9x. In addition to being obsolete, those systems are
dead ends. Supporting the build on 32-bit DOS is more useful in my view,
even though DOS is older, because DOS is still used in situations where no
other system will do.

I'd hate to see the build get more complicated, less understandable, or
less extensible in the future (to new systems) in an effort to support
Windows 9x. To my mind that would be a step backwards.

Peter

[Michal Necasek]

Sorry, I have not managed to apply your patch. I had to fix up the
source files that were screwed up and put them into the state they were
in last week.

Please re-create the patch against current source and re-send it, *or*
simply send me the modified files (ZIP archive is preferable). Make very
sure there are no hard tabs in C source files. Maybe I just can't use
patch or the diff got mangled somehow during transfer, but I will
probably have easier time diffing the files myself. I'm almost sure
there were some hard tabs in the patch that didn't make it, so if you
zip up the patch too, it might work better.

Michal

[Bartosz Polednia]

Michal Necasek napisał(a):

>
> Sorry, I have not managed to apply your patch. I had to fix up the
> source files that were screwed up and put them into the state they were
> in last week.
>

The word "WERE" is in the proper tense as wasm was working again
before your changes.

Bartosz.

[Rod Pemberton]

"Paul Edwards" <kerr...@nosppaam.w3.to> wrote in message

news:el30vt$bcm$1...@www-1.scitechsoft.com...

> "Blair Campbell" <bl...@ified.ca> wrote in message
news:20061204211344...@ified.ca...
> > > > Blair's CLIB, for which I wrote callint(), is PD.
> > >
> > > Can you give me a link to this please? I'd like to take some of the
> > > math functions for use in PDPCLIB.
> >
> > If you're talking about math.h functions, that's one header I haven't
started on.
>

Paul,

For PD math functions, you could also look at Libnix's math functions (avoid
MorphOS versions - copyrights) or Fred Fish's math library. IIRC, the Mingw
C library is PD but it's been mostly converted to assembly. I don't recall
if MINGW contained some of Sun Microsystems copyleft FDLIBM.

PD Libnix sources:
http://sourceforge.net/projects/libnix/
http://zapek.com/software/libnix/

Fred Fish's PD math library net.sources 1987, shr archives:
0 http://groups.google.com/group/net.sources/msg/3e8a75e4831c0f8c?hl=en
1b http://groups.google.com/group/net.sources/msg/f09b3693745439c2?hl=en
2 http://groups.google.com/group/net.sources/msg/e943062492e05539?hl=en
3 http://groups.google.com/group/net.sources/msg/6167d8c8a3abc669?hl=en
4 http://groups.google.com/group/net.sources/msg/f710a479c21cec64?hl=en
5 http://groups.google.com/group/net.sources/msg/8157266fe1c32dc2?hl=en
6 http://groups.google.com/group/net.sources/msg/8ee586fa7bf4354a?hl=en

Rod Pemberton

[Paul Edwards]

"Rod Pemberton" <do_no...@bitfoad.cmm> wrote in message news:el41qq$r8b$1...@www-1.scitechsoft.com...

> PD Libnix sources:
> http://sourceforge.net/projects/libnix/

Thankyou! I now have atan2 and modf, which means I have
something for every function, even if it isn't properly
implemented.

BFN. Paul.

[Paul Edwards]

"Michal Necasek" <mic...@prodigy.net> wrote in message news:el409j$qc2$1...@www-1.scitechsoft.com...

>
> Sorry, I have not managed to apply your patch. I had to fix up the
> source files that were screwed up and put them into the state they were
> in last week.

There was no need to change anything. That patches I gave you
were against the latest source.

> Please re-create the patch against current source and re-send it, *or*
> simply send me the modified files (ZIP archive is preferable). Make very
> sure there are no hard tabs in C source files. Maybe I just can't use
> patch or the diff got mangled somehow during transfer, but I will
> probably have easier time diffing the files myself. I'm almost sure
> there were some hard tabs in the patch that didn't make it, so if you
> zip up the patch too, it might work better.

I checked, and there were no hard tabs in the source code I
sent you. There were only hard tabs in the diff headers and
the disassembly output.

Anyway, I will send you new diffs against the latest source
as a zip file. It'll take about an hour to import the latest
source and recheck it, so stand by. :-)

BFN. Paul.

[Paul Edwards]

"Paul Edwards" <kerr...@nosppaam.w3.to> wrote in message news:el2a3p$4u2$1...@www-1.scitechsoft.com...

> I am unable to run the wcc regression test cases because I am
> unable to build wcc.

Now that I have found out that wcc resides in
dos386.386\wcc386c.exe rather than nt386, I have been able
to run the wcc regression tests and they all pass.

> I am unable to test that the build works,
> because I am unable to build the build.

And while I get lots of errors building the build, I still manage
to produce a wcc386c.exe, so it would appear that my wasm
changes have not broken the build.

BFN. Paul.

[Mat Nieuwenhoven]

On Tue, 5 Dec 2006 10:53:16 +1100, Paul Edwards wrote:

<snip>

I think wsplice supports the @filename argument, where it takes the
arguments fro a file. That would remove any dependency on the command
processor.

Mat Nieuwenhoven

[Mat Nieuwenhoven]

Indeed it does, there are a number of .mif files which already do this,
like bld\wic\mif\master.mif. If in bld\sdk\rc\rc\mif\master.mif I replace

wsplice -kENGLISH -kIS_RC -k$(host_os) $(splice_opts) -t8 -f
"%+(MSG_USE_E_BASE+%$#-1), \"%s\"" ../usage.sp usage.rc

with two lines

@%write usagee.tmp -kENGLISH -kIS_RC -k$(host_os) $(splice_opts) -t8 -f
"%+(MSG_USE_E_BASE+%$#-1), \"%s\"" $< $^@
wsplice @usagee.tmp

then the generated file looks OK and the Win98 build passes this part. It
still gives errors later on, which I don't have time to look at tonight.
Also, there are some other .mif / makefiles that require the same
treatment: bdiff\master.mif, wasm\mif\master.mif, wtouch\master.mif,
wv\master.mif, wstrip\master.mif , maybe cc\master.mif .

Mat Nieuwenhoven

[Mat Nieuwenhoven]

On Tue, 5 Dec 2006 12:31:15 +0000 (UTC), Peter C. Chapin wrote:

>"Mat Nieuwenhoven" <mni...@dontincludethis.zap.a2000.nl> wrote in
>news:zavrhjqbagvapyhqrguvf...@news.openwatcom.org:
>
>> I'll pick the Win98 games PC from my children and see if I can get the
>> build going.
>
>To be honest, I wouldn't suggest spending a lot of time getting the build
>to work on Windows 9x. In addition to being obsolete, those systems are
>dead ends. Supporting the build on 32-bit DOS is more useful in my view,
>even though DOS is older, because DOS is still used in situations where no
>other system will do.

Like FreeDos? Or do you mean things like HXDOS? Too bad I allocated my
FreeDos partition way too small for that. I'll take a look after the Win98
thing.

>I'd hate to see the build get more complicated, less understandable, or
>less extensible in the future (to new systems) in an effort to support
>Windows 9x. To my mind that would be a step backwards.

I (for now) don't think it will require many changes to get it working
under Win98. Some of these changes might be required for DOS as well, like
using "wsplice @filename" to bypass shell peculiarities.

Mat Nieuwenhoven

[Peter C. Chapin]

"Mat Nieuwenhoven" <mni...@dontincludethis.zap.a2000.nl> wrote in
news:zavrhjqbagvapyhqrguvf...@news.openwatcom.org:

> I (for now) don't think it will require many changes to get it working

> under Win98. Some of these changes might be required for DOS as well,
> like using "wsplice @filename" to bypass shell peculiarities.

Yes, if the changes actually make the build *more* general then that
certainly seems like a good thing. I'd just hate to see Win9x specific
oddities added that might later cause problems. Win9x just isn't worth it
in my view.

Peter

[Mat Nieuwenhoven]

Indeed. However, if making a Win98 build working gets someone going on
re-creating wgml .... :-)

Mat Nieuwenhoven

[Arkady V.Belousov]

Hi!

Rod Pemberton 05.12.06 18:05 wrote:

> Fred Fish's PD math library net.sources 1987, shr archives:
> 0 http://groups.google.com/group/net.sources/msg/3e8a75e4831c0f8c?hl=en
> 1b http://groups.google.com/group/net.sources/msg/f09b3693745439c2?hl=en

"
It appears that Part 1 of 6 of the pml posting was truncated or lost
because it exceeded 64000 characters; *NOT* 64K (???). Anyway, I've
split the contents up into two postings, Part 1a and Part 1b.
"

Looks like you miss one URL. I was (shortly) try to find 1a post, but
without success. :(

[Arkady V.Belousov]

Hi!

Arkady V.Belousov 08.12.06 16:21 wrote:

>> Fred Fish's PD math library net.sources 1987, shr archives:
>> 0 http://groups.google.com/group/net.sources/msg/3e8a75e4831c0f8c?hl=en
>> 1b http://groups.google.com/group/net.sources/msg/f09b3693745439c2?hl=en

Oops, accidentally I found missed URL for 1a/6 post:

http://groups.google.com/group/net.sources/msg/acba331beb2d55d0?hl=en

[Rod Pemberton]

"Arkady V.Belousov" <a...@mos.ru> wrote in message
news:elbq2m$r9g$1...@www-1.scitechsoft.com...

Yes, good job.

Sorry, I assumed 1b was a complete repost.

1b is Message-ID: 3...@mcdsun.UUCP so 1a is 3...@mcdsun.UUCP in Google Groups
advanced search.

One more .shr to extract ... :(

Rod Pemberton

[Paul Edwards]

"Michal Necasek" <mic...@prodigy.net> wrote in message news:el409j$qc2$1...@www-1.scitechsoft.com...

Michal, I have tested the 2006-12-09 daily snapshot, and it is
working for my purposes.

I also ran through small/large/flat tests of 386 and non-386 to
check that the offsets were the same as masm.

I also tested that lengthof worked.

Thanks for helping me with this. Your code changes were
much neater than mine. I look forward to the official 1.6
release, but there's no rush - probably better to wait for that
"restrict" change to come through so that OW is more
useful to others.

BFN. Paul.

[Michal Necasek]

Paul Edwards wrote:

> Michal, I have tested the 2006-12-09 daily snapshot, and it is
> working for my purposes.
>

Good.

> Thanks for helping me with this. Your code changes were
> much neater than mine.
>

You're welcome. I may know the Open Watcom source better than most.
But you have a very important ability that seems surprisingly rare among
programmers: the ability to drill down in a large project and locate the
piece of code responsible for certain behaviour.

Out of curiosity, how do you navigate the code? Do you use some sort
of static analysis tools? The debugger? Something else?

> I look forward to the official 1.6
> release, but there's no rush - probably better to wait for that
> "restrict" change to come through so that OW is more
> useful to others.
>

I'm not waiting for that or it'd get never released - it's late enough
as it is, and it's only supposed to be a bugfix release :) See
http://www.openwatcom.org/ftp/devel/ (RC3).

Michal

[Paul Edwards]

"Michal Necasek" <mic...@prodigy.net> wrote in message news:elepu8$38l$1...@www-1.scitechsoft.com...

> > Thanks for helping me with this. Your code changes were
> > much neater than mine.
> >
> You're welcome. I may know the Open Watcom source better than most.
> But you have a very important ability that seems surprisingly rare among
> programmers: the ability to drill down in a large project and locate the
> piece of code responsible for certain behaviour.

Yes, I don't like to be beaten by the machine. I live in fear
of the bug that will exceed my capability to find.

> Out of curiosity, how do you navigate the code? Do you use some sort
> of static analysis tools? The debugger? Something else?

Nope, just micro-emacs and grep on the command line. I
didn't get organized enough to find out how to switch on
the debugger in the makefiles, so I just used printfs.

I would have got organized with the debugger had I got a
core dump. That would have been worth the effort.

> > I look forward to the official 1.6
> > release, but there's no rush - probably better to wait for that
> > "restrict" change to come through so that OW is more
> > useful to others.
> >
> I'm not waiting for that or it'd get never released - it's late enough

Late? There was over a 1 year gap between 1.3 and 1.4.
1.5 was only released in May.

> as it is, and it's only supposed to be a bugfix release :) See

Ok.

> http://www.openwatcom.org/ftp/devel/ (RC3).

Ok. So this is still another beta? When is the official 1.6
due out?

BFN. Paul.

[Arkady V.Belousov]

Hi!

Paul Edwards 09.12.06 21:17 wrote:

>> I'm not waiting for that or it'd get never released - it's late enough
> Late? There was over a 1 year gap between 1.3 and 1.4.
> 1.5 was only released in May.

Michal was decide to earlier release of 1.6, because he feels, that in
1.5 too many things was broken, and he remark in announces for RC1, that it
will be mainly bugfix release.

[Arkady V.Belousov]

Hi!

Michal Necasek 09.12.06 19:58 wrote:

> I'm not waiting for that or it'd get never released - it's late enough
> as it is, and it's only supposed to be a bugfix release :) See
> http://www.openwatcom.org/ftp/devel/ (RC3).

Congratulations. .ihp files in RC2 was broken - either WHELP 1.5 and
WHELP 1.6 are freeze with them. .ihp from RC3 are handled fine.

[Steve Adam]

Paul Edwards wrote:

> Yes, I don't like to be beaten by the machine. I live in fear
> of the bug that will exceed my capability to find.

Do you find that the hardest bugs to find are
those you've created yourself?

My record is 6 months to find one of my own
bugs. The reason I found it hard to find
this bug was simply that I never challenged
one of my own assumptions.

The code in question controls a milling machine
for Printed Circuit Boards. It cuts the PCBs
out of the panel they're made on. I rewrote
the code in February because it badly needed
improvement. I got it working in August.

During testing I noticed two seemingly minor
problems. One was that the motion of the
machine milling segmented arcs was slightly
jerky when it should have been smooth. That
indicated that a change in acceleration was
much higher than it should have been.

The other problem was that sometimes, the machine
would visibly overshoot the end of a cut by .010
inches or sometimes completely miss a vertex.
(Actually the same problem).

I tried lots of ways to fix this problem,
and none of them worked, though my several
rewrites did fix some other bugs.

In the end the code started working only when
I commented out a check for a keypress.

My wrong assumption was that it never occurred
to me that checking for a keypress could take
20 milliseconds or more. My assumed limit was
less than 1 millisecond.

The code runs under DOS4GW on Win95. I stopped
worrying about it when the code started working,
but I guess the problem was a context switch
forced by calling _bios_keybrd().

Never has a forehead been thwacked more forcefully.
I nearly knocked myself out ;)

// Now just wait for the breakpoint bit to set
while (TRUE) {
if (GetStatusByte(&active_axis[curr_chkaxis]) & LM628_BREAKPOINT_REACHED)
break;
// if (_bios_keybrd(_NKEYBRD_READY)) { // Exit on keypress
// _bios_keybrd(_NKEYBRD_READ);
// PauseDrill = TRUE;
// curr_chkaxis = -1; // Force exit of while loop
// break;
// }
}

[Arkady V.Belousov]

Hi!

> Congratulations. .ihp files in RC2 was broken - either WHELP 1.5 and
> WHELP 1.6 are freeze with them. .ihp from RC3 are handled fine.

Issues with RC3 installer:

- installer shows "2,047MB available" when more than 2Gb free.
- "Drive D: ******KB required" shows wrong value (1.5-2 times bigger).
- "Copying files" progress bar is with white background.
- installer removes command "win" from AUTOEXEC.BAT and creates
CONFIG.W95, equal to original CONFIG.SYS.

[Michal Necasek]

Paul Edwards wrote:

>> I'm not waiting for that or it'd get never released - it's late enough
>
> Late? There was over a 1 year gap between 1.3 and 1.4.
> 1.5 was only released in May.
>

And that gap was highly undesirable. Version 1.4 contained a large
number of changes and also a large number of bugs, because the changes
were not widely tested.

>> http://www.openwatcom.org/ftp/devel/ (RC3).
>
> Ok. So this is still another beta? When is the official 1.6
> due out?
>

When it's ready. If there are no showstopper bugs in RC3, it will be
the final release. When I call it Release Candidate, I mean it :)

Michal

[Michal Necasek]

Arkady V.Belousov wrote:
> Issues with RC3 installer:
>
> - installer shows "2,047MB available" when more than 2Gb free.
> - "Drive D: ******KB required" shows wrong value (1.5-2 times bigger).
>

Maybe the calculation takes cluster size into account?

> - "Copying files" progress bar is with white background.
> - installer removes command "win" from AUTOEXEC.BAT and creates
> CONFIG.W95, equal to original CONFIG.SYS.
>

Anyone gonna fix this within 24 hours? If not, none of the above will
change for 1.6.

Michal

[Frank Beythien]

On Sun, 10 Dec 2006 06:32:12 UTC "Arkady V.Belousov" <a...@mos.ru>
wrote:

> Issues with RC3 installer:
>
> - installer shows "2,047MB available" when more than 2Gb free.

I think this is correct, if you look at the comma as the grouping
character for thousands:

2,047,000,000 == 2,047MB == 2.047Gb

Though I must admit having my difficulties with decimal point versus
decimal comma, too.

> - installer removes command "win" from AUTOEXEC.BAT and creates
> CONFIG.W95, equal to original CONFIG.SYS.

Don't see this with OS/2.

CU/2
--
Frank Beythien fBeythien AT gmx.de

[Arkady V.Belousov]

Hi!

Michal Necasek 10.12.06 15:35 wrote:

>> - installer shows "2,047MB available" when more than 2Gb free.
>> - "Drive D: ******KB required" shows wrong value (1.5-2 times bigger).
> Maybe the calculation takes cluster size into account?

With my selections installer shows "Drive D: 151,680KB required,
2,047MB available", whereas after installation there 84,760,432 bytes used
with 7,010,448 bytes in slacks (ie., real space on disk is 91,770,880). So,
even if installer counts clusters size, then it counts wrong clusters size.

>> - "Copying files" progress bar is with white background.
>> - installer removes command "win" from AUTOEXEC.BAT and creates
>> CONFIG.W95, equal to original CONFIG.SYS.
> Anyone gonna fix this within 24 hours? If not, none of the above will
> change for 1.6.

docs\readme_installer.txt
"
Although Open Watcom is an Open Source project and freely available, SciTech
Software has invested considerable time, energy and capital to make this
project a reality. For this reason SciTech Software has retained the rights
to the Open Watcom installer source code.
"

So, only employers of SciTech (including you), which have access to
installer sources, may fix installer.

[Arkady V.Belousov]

Hi!

Frank Beythien 10.12.06 15:47 wrote:

>> - installer shows "2,047MB available" when more than 2Gb free.
> I think this is correct, if you look at the comma as the grouping
> character for thousands:
> 2,047,000,000 == 2,047MB == 2.047Gb

How about 3,050,000,000 of real free space? How about 10,024,000,000 of
real space? I say not "when 2Gb free", I say "when _more than_ 2Gb free".

>> - installer removes command "win" from AUTOEXEC.BAT and creates
>> CONFIG.W95, equal to original CONFIG.SYS.
> Don't see this with OS/2.

Here installer doesn't creates CONFIG.OS2 for you?

[Andreas Kohl]

"Arkady V.Belousov" schrieb:

> > Don't see this with OS/2.
>
> Here installer doesn't creates CONFIG.OS2 for you?

The created CONFIG.OS2 from RC3-Installer is correct.
It modifies the path variables correctly and adds the following statements:
SET INCLUDE=X:\WATCOMF\H\OS2;X:\WATCOMF\H
SET FINCLUDE=X:\WATCOMF\SRC\FORTRAN;X:\WATCOMF\SRC\FORTRAN\OS2
SET WATCOM=X:\WATCOMF
SET EDPATH=X:\WATCOMF\EDDAT
RUN=X:\WATCOMF\BINP\NMPBIND.EXE

I think the FINCLUDE should also be mentioned in the FREADME.TXT.
The RC3 F77 installer doesn't install the file WEDITVIW.DLL which is needed for
the Win-IDE.
Could this be fixed?
The C/C++ installer copies both the WEDITCW.DLL and WEDITVIW.DLL.

The installation routine asks for copying the file NET.DLL ( I think only if Win
3.x Host is selected) because it finds an NET.DLL from IBM JRE 1.3.1 in the
PATH.

Regards,
Andreas Kohl

[Michal Necasek]

Andreas Kohl wrote:
>
> I think the FINCLUDE should also be mentioned in the FREADME.TXT.
>

If someone understands what the variable exactly does and updates the
text...

> The RC3 F77 installer doesn't install the file WEDITVIW.DLL which is needed for
> the Win-IDE.
> Could this be fixed?
>

I don't do F77, sorry.

> The installation routine asks for copying the file NET.DLL ( I think only if Win
> 3.x Host is selected) because it finds an NET.DLL from IBM JRE 1.3.1 in the
> PATH.
>

Not sure what to do about that. There *is* a naming conflict and I
don't think warning about it is a bad thing. Or are you suggesting to
change the name of the DLL?

Michal

[Michal Necasek]

Arkady V.Belousov wrote:
> docs\readme_installer.txt

>
> So, only employers of SciTech (including you), which have access to
> installer sources, may fix installer.
>

As usual, you are totally off base. That readme was obsolete and I
have just deleted it. Seeing that it references version 1.3 could have
tipped you off. The "new" installer sources are available with the rest
of the source code.

Michal

[Andreas Kohl]

Hello,

Michal Necasek schrieb:

> Andreas Kohl wrote:
> >
> > I think the FINCLUDE should also be mentioned in the FREADME.TXT.
> >
> If someone understands what the variable exactly does and updates the
> text...

Just add the FINCLUDE statement to the recommended BAT and CMD files should be enough.

>
> > The RC3 F77 installer doesn't install the file WEDITVIW.DLL which is needed for
> > the Win-IDE.
> > Could this be fixed?
> >
> I don't do F77, sorry.

I think it's an issue of the installer.
Who is building the installer programs for F77?
And is WEDITCW.DLL still needed in C/C++?

>
> > The installation routine asks for copying the file NET.DLL ( I think only if Win
> > 3.x Host is selected) because it finds an NET.DLL from IBM JRE 1.3.1 in the
> > PATH.
> >
> Not sure what to do about that. There *is* a naming conflict and I
> don't think warning about it is a bad thing. Or are you suggesting to
> change the name of the DLL?

This isn't a real conflict (os2 dll vs. win3 dll).

Thanks,
Andreas

[Michal Necasek]

Andreas Kohl wrote:

>> I don't do F77, sorry.
>
> I think it's an issue of the installer.
> Who is building the installer programs for F77?
>

I am building the F77 installers - but only building whatever is in
the source tree.

> And is WEDITCW.DLL still needed in C/C++?
>

It appears to be still distributed. I have some doubts that anyone
actually uses it.

>> Not sure what to do about that. There *is* a naming conflict and I
>> don't think warning about it is a bad thing. Or are you suggesting to
>> change the name of the DLL?
>
> This isn't a real conflict (os2 dll vs. win3 dll).
>

Are you saying that if OS/2 finds a Win16 DLL, it won't attempt to
load it, and vice versa?

Michal

[Mat Nieuwenhoven]

On the partition I installed RC3 with 3.5 G free, it correctly showed the
amount of free space (OS/2 installer).

Mat Nieuwenhoven

[Roman Trunov]

Steve Adam wrote:

> The code runs under DOS4GW on Win95. I stopped
> worrying about it when the code started working,
> but I guess the problem was a context switch
> forced by calling _bios_keybrd().

First, running time critical application in DOS window of Win95 was bad
idea. As for your particular case, repeated calls to int16/ah=1
(keypress check, exactly what _bios_keybrd(_NKEYBRD_READY) do) make
Windows think that your application is in idle state and decrease time
slice.

Instead of calling _bios_keybrd(_NKEYBRD_READY), try to directly compare
head and tail of keyboard buffer, located in BIOS data area at addresses
0000:041A and 0000:041C (16-bit words). I think DOS4GW has method to
access memory in first megabyte directly. If values in these location
differs, a key is present in keyboard buffer and you can read and
process it. This method works fine under plain dos, Windows and OS/2. It
does not work under DesqView, but I think it's not a problem for you.

Roman

[Michal Necasek]

Roman Trunov wrote:
>
> Instead of calling _bios_keybrd(_NKEYBRD_READY), try to directly compare
> head and tail of keyboard buffer, located in BIOS data area at addresses
> 0000:041A and 0000:041C (16-bit words). I think DOS4GW has method to
> access memory in first megabyte directly.
>

The first megabyte of linear address space maps to the first megabyte
of DOS memory. So 0040:001A can be accessed as offset 0x41A in DOS/4GW
and compatibles.

Michal

[Arkady V.Belousov]

Hi!

Michal Necasek 10.12.06 23:35 wrote:

>> docs\readme_installer.txt
>> So, only employers of SciTech (including you), which have access to
>> installer sources, may fix installer.
> As usual, you are totally off base. That readme was obsolete and I

This is contradiction: either I "off base" or readme obsolete.

> have just deleted it. Seeing that it references version 1.3 could have
> tipped you off. The "new" installer sources are available with the rest
> of the source code.

In which directory?

[Arkady V.Belousov]

Hi!

Mat Nieuwenhoven 11.12.06 0:57 wrote:

>> Issues with RC3 installer:
>> - installer shows "2,047MB available" when more than 2Gb free.

> On the partition I installed RC3 with 3.5 G free, it correctly showed the
> amount of free space (OS/2 installer).

Probably, this is because OS/2-related code in installer is more correct?

[Steve Adam]

Roman Trunov wrote:
> First, running time critical application in DOS window of Win95 was bad
> idea.

I agree, but that's just the way the thing evolved.
I think the only reason it's running on Win95 is
because that was the easiest way someone found to
get the network working on the controller PC.

The best solution for us is probably to move
more intelligence into the hardware and simplify
the controller interface. But that's a longer
term solution, and probably won't happen for a while.

> Instead of calling _bios_keybrd(_NKEYBRD_READY), try to directly compare
> head and tail of keyboard buffer, located in BIOS data area at addresses
> 0000:041A and 0000:041C (16-bit words). I think DOS4GW has method to
> access memory in first megabyte directly. If values in these location
> differs, a key is present in keyboard buffer and you can read and
> process it. This method works fine under plain dos, Windows and OS/2. It
> does not work under DesqView, but I think it's not a problem for you.

Thanks for the information, I'll probably implement
that some time.

Steve.

[Roman Trunov]

Arkady V.Belousov wrote:

>>> Issues with RC3 installer:
>>> - installer shows "2,047MB available" when more than 2Gb free.

DOS? Standard DOS call to get free space cannot return more then 2 Gb.

Roman

[Mat Nieuwenhoven]

Setupgui

Mat Nieuwenhoven

[Bartosz Polednia]

Steve Adam napisał(a):

> Roman Trunov wrote:
>
>>First, running time critical application in DOS window of Win95 was bad
>>idea.
>
>
> I agree, but that's just the way the thing evolved.
> I think the only reason it's running on Win95 is
> because that was the easiest way someone found to
> get the network working on the controller PC.

Hi,

Have you tried Microsoft Client for MS-DOS ?
I have used it with success.

Bartosz.

[Wilton Helm]

Its also a good candidate for something like the Lantronix DSTNi CPU. Grid
connect has an EX chip with memory on a DIMM stick, so the developer doesn't
have to mess with the busses. It has two 10/100 Ethernets, one with phy on
chip. Can be done with no OS or with an RTOS. They provide protocol stack
and RTOS. I ported an OW trap to it. Its real mode, no FPU but has 16 MB
addressing by making segments 256 bytes instead of 16, which OW also now
supports.

Wilton

[Arkady V.Belousov]

Hi!

Mat Nieuwenhoven 11.12.06 19:28 wrote:

>>> have just deleted it. Seeing that it references version 1.3 could have
>>> tipped you off. The "new" installer sources are available with the rest
>>> of the source code.
>> In which directory?
> Setupgui

I try search there word "Drive" (from message "Drive D: 151,680KB
required, 2,047MB available") and not found it. Same for word "required". I
was try to search "install Open Watcom C/C++" (text from first installer
dialogs) across all source tree - also without success. What wrong?

[Arkady V.Belousov]

Hi!

Roman Trunov 11.12.06 17:35 wrote:

>>>> Issues with RC3 installer:
>>>> - installer shows "2,047MB available" when more than 2Gb free.
> DOS? Standard DOS call to get free space cannot return more then 2 Gb.

Current installer is Win32 application, DOS functions here not relate.

[Steve Adam]

Thanks for the suggestions. I'll pass them
on to the boss when I get a chance (he's the
hardware guy). Right now it's not a high
priority as long as the machine is working.
I imagine his preference would be for a
single board computer.

Steve.

[Mozzissypid Mozziss]

<a href="https://789maxbet.com/"><strong>maxbet</strong></a> Web Casino Today, the popularity may change a lot. Forget the old pictures of big casinos that have to travel to play because the web casinos that we know will come in a more modern and comfortable format. Many people still understand that to play casinos that we have to travel far to foreign countries or is difficult to access, nowadays web casinos will come in the form online casino Also known as online gambling is a form of gambling in the digital system.

[nuansa slot]

https://nuansagaming.blogspot.com/
https://159.89.36.73/?ref=avalon
https://172.105.178.219/?ref=avalon
https://beacons.ai/nuansagaming
https://flow.page/nuansagaming
https://heylink.me/nuansagaming/
https://linktr.ee/qqslotgacor
https://133slot.net/
https://133slot.org/
https://133slot.xyz/
https://133slot.com/
https://133slotonline.co/
https://slotpulsacuan.co/
https://slotonlinecuan.co/
https://slotpulsagacor.co/
https://pulzatanpapotongan.xyz/
https://tanpapotonganpulsa.xyz/
https://sefuslot88.co/
https://sefuslot88.net/
https://sefuslot88.org/
https://sefuslot5000.com/
https://sefuslotgacor.com/
https://sefuslot88.online/
https://playclean.org/
https://gositusslot.com/
https://mandanlibrary.org/
https://scabbydonkey.com/
https://nicefreedatingall.com/
https://croatiasoccershop.com/
https://changeoftomorrow.com/
https://authenticnikejetstore.com/
https://officialredskinslockerroom.com/
https://meta-togel.com/
https://nuansagaming.blogspot.com/2022/01/deposit-judi-togel-pulsa-5000-pasaran-resmi-wla.html
https://nuansagaming.blogspot.com/2022/01/tips-meningkatkan-judi-jackpot-di-permainan-slot-online-pakai-pulsa.html
https://nuansagaming.blogspot.com/2022/01/pilihan-slot-game-lengkap-dari-agen-judi-slot-gacor-resmi.html
https://nuansagaming.blogspot.com/2022/01/link-alternatif-slot-deposit-pulsa-tanpa-potongan-paling-gacor.html
https://nuansagaming.blogspot.com/2022/01/keuntungan-bermain-di-situs-judi-slot-pulsa-tanpa-potongan.html
https://nuansagaming.blogspot.com/2022/01/keuntungan-bergabung-bersama-agen-judi-slot-terpercaya-di-indonesia.html
https://nuansagaming.blogspot.com/2022/01/agen-slot-online-dengan-deposit-pulsa-tanpa-potongan.html
https://nuansagaming.blogspot.com/2022/01/manfaat-ketika-bertransaksi-slot-deposit-pulsa-menggunakan-telkomsel.html
https://nuansagaming.blogspot.com/2022/02/keunggulan-transaksi-judi-slot-pulsa-paling-populer.html
https://nuansagaming.blogspot.com/2022/02/nuansa-judi-qq-slot-online-gacor-terpercaya.html
https://nuansagaming.blogspot.com/2022/02/situs-slot-gacor-pulsa-nuansa-gaming-terbaik.html
https://nuansagaming.blogspot.com/2022/02/situs-slot-gacor-pulsa-5000-gampang-menang-untuk-pemula.html
https://nuansagaming.blogspot.com/2022/02/keuntungan-bermain-slot-pulsa-telkomsel-dan-xl-tanpa-potongan.html
https://nuansagaming.blogspot.com/2022/02/mengenal-situs-judi-slot-pulsa-terpercaya-2022.html
https://nuansagaming.blogspot.com/2022/02/konsep-menang-dari-judi-slot-pulsa.html
https://nuansagaming.blogspot.com/2022/02/daftar-agen-slot-gacor-terpercaya-nuansa-gaming.html
https://nuansagaming.blogspot.com/2022/02/beragam-jenis-agen-slot-gacor-online.html
https://nuansagaming.blogspot.com/2022/02/agen-slot-pulsa-5000.html
https://nuansagaming.blogspot.com/2022/02/agen-slot-dana.html
https://nuansagaming.blogspot.com/2022/02/situs-agen-slot-gacor-dan-togel-4d.html
https://nuansagaming.blogspot.com/2022/02/cara-daftar-judi-togel-online-resmi-di-nuansa-slot.html
https://nuansagaming.blogspot.com/2022/03/bermain-judi-togel-di-nuansa-slot-online.html
https://nuansagaming.blogspot.com/2022/03/agen-judi-slot-online.html
https://nuansagaming.blogspot.com/2022/03/daftar-akun-di-situs-slot-gacor-pulsa.html
https://www.vclouds.com.au/nuansa-gaming-situs-judi-slot-terpercaya/
https://pandemicmemes.com/uncategorized/2022/01/29/nuansa-gaming-situs-informasi-slot-online-gacor-hari-ini/
https://enriquecer.co/nuansa-gaming-judi-slot-pulsa-terpercaya-2022/
https://nhunghuouhuongson.com/panduan-pembayaran-judi-slot-pulsa-24-jam-terpercaya/
http://diclofenac.us.org/nuansa-gaming-situs-judi-slot-pulsa-5000-terpercaya/
https://okcheartandsoul.com/news/daftar-situs-judi-slot-pulsa-tanpa-potongan-paling-gacor-2022/
https://apoyemosaguascalientes.com/daftar-situs-slot-online-deposit-pulsa-termurah-di-indonesia/
https://nuansagaming.medium.com/nuansa-gaming-situs-judi-slot-deposit-pulsa-tanpa-potongan-535056f73d5
https://moodle.recitfga.ca/blog/index.php?entryid=32105
https://ou.vsu.edu.ph/blog/index.php?entryid=940
https://www.datacademy.africa/blog/index.php?entryid=12646
https://sites.google.com/view/judi-slot-pulsa-nuansa-gaming
http://pratika-insegnanti.net/blog/index.php?entryid=5260
https://learninghub4hrh.org/blog/index.php?entryid=226431
http://32.jerudaica.org/blog/index.php?entryid=240468
http://platforma.ksztalceniezawodowe.eu/blog/index.php?entryid=31529
https://designfils.eba.gov.tr/blog/index.php?entryid=71138
https://platform.blocks.ase.ro/blog/index.php?entryid=762
https://www.debwan.com/blogs/314990/Daftar-Artikel-Judi-Online-Terpercaya
https://360.hayatadestek.org/blog/index.php?entryid=37922
https://nhunghuouhuongson.com/cara-mudah-menemukan-link-alternatif-slot-pulsa-tanpa-potongan/
https://nuansagaming.blogspot.com/2022/03/daftar-agen-judi-slot-pulsa.html
http://diclofenac.us.org/situs-judi-slot888-terbesar-deposit-pulsa-tanpa-potongan/
https://okcheartandsoul.com/entertainment/pusat-permainan-agen-judi-online-slot-888-terbaik-dan-terpercaya/
https://apoyemosaguascalientes.com/situs-judi-online-terpercaya-di-indonesia
https://shobeklobek.com/tersedia-link-judi-slot888-deposit-pulsa-online-tanpa-potongan/