Discussion:
32-bit compact memory model ACPI device-driver for RDOS doesn't run anymore
(too old to reply)
Leif Ekblad
2012-04-26 18:45:06 UTC
Permalink
It seems like some change during the last few weeks have broken something in
the 32-bit RDOS device-driver target. My main problem is that the fault
appears to happen during initialization time, so it doesn't really help to
remove everything from main-procedure. Even more strange is that another
32-bit device driver also written in C seems to work.

Comparing the working and non-working version, it seems there is some small
difference in which files are brought in from CLIB.

This is the last modules in the old version that works:

Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(getenv.c)
0001:00049b40 getenv_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(alphabet.c)
0002:00005560 ___Alphabet
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(environ.c)
0002:0000f280 ___env_mask
0002:0000f286 _environ
0002:0000f28c* __wenviron
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbterm.c)
0001:00049c40 _mbterm_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbsnextc.c)
0001:00049c80 _mbsnextc_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbcupper.c)
0001:00049cc0 _mbctoupper_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbsinc.c)
0001:00049ce0 _mbsinc_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(setenvp.c)
0001:00049d20 __setenvp_
0001:00049d30 __freeenvp_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbisdbcs.c)
0002:0000f2a8 ___IsDBCS
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbislead.c)
0001:00049db0* _ismbblead_
0002:0000f2ac ___MBCSIsTable
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbinit.c)
0001:00049e09 __mbinit_
0002:00000c88 ___MBCodePage
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbdtoupp.c)
0001:00049e70 _mbdtoupper_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(clearenv.c)
0001:00049e90 clearenv_

This is the last modules in the version that doesn't work:

Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(getenv.c)
0001:00049b40 getenv_
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(alphabet.c)
0002:0000555c ___Alphabet
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(environ.c)
0002:0000f270 ___env_mask
0002:0000f276 _environ
0002:0000f27c* __wenviron
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(setenvp.c)
0001:00049c10 __setenvp_
0001:00049d90 __freeenvp_
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(clearenv.c)
0001:00049e10 clearenv_

It appears that the version that works bring in a set of mb*.c files, while
the version that doesn't work don't.

The device-driver that works with the new version doesn't have the mb*.c
files either, but then neither does the previous build of it.

Anybody know which of the last changes might have introduced this bug?

Leif Ekblad
Jiri Malak
2012-04-27 17:07:21 UTC
Permalink
Leif,

I am sorry I somehow missed your change #37121 in my change #37206 which do environment related
functions more granular.
I fixed it by change #37247.
Missing reference to multibyte functions is result of change #37206 where
I removed wide-environment processing because RDOSDEV clib doesn't use it any way.

Please check if change #37247 fix your problem.

Jiri
It seems like some change during the last few weeks have broken something in the 32-bit RDOS
device-driver target. My main problem is that the fault appears to happen during initialization
time, so it doesn't really help to remove everything from main-procedure. Even more strange is
that another 32-bit device driver also written in C seems to work.
Comparing the working and non-working version, it seems there is some small difference in which
files are brought in from CLIB.
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(getenv.c)
0001:00049b40 getenv_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(alphabet.c)
0002:00005560 ___Alphabet
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(environ.c)
0002:0000f280 ___env_mask
0002:0000f286 _environ
0002:0000f28c* __wenviron
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbterm.c)
0001:00049c40 _mbterm_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbsnextc.c)
0001:00049c80 _mbsnextc_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbcupper.c)
0001:00049cc0 _mbctoupper_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbsinc.c)
0001:00049ce0 _mbsinc_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(setenvp.c)
0001:00049d20 __setenvp_
0001:00049d30 __freeenvp_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbisdbcs.c)
0002:0000f2a8 ___IsDBCS
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbislead.c)
0001:00049db0* _ismbblead_
0002:0000f2ac ___MBCSIsTable
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbinit.c)
0001:00049e09 __mbinit_
0002:00000c88 ___MBCodePage
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbdtoupp.c)
0001:00049e70 _mbdtoupper_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(clearenv.c)
0001:00049e90 clearenv_
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(getenv.c)
0001:00049b40 getenv_
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(alphabet.c)
0002:0000555c ___Alphabet
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(environ.c)
0002:0000f270 ___env_mask
0002:0000f276 _environ
0002:0000f27c* __wenviron
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(setenvp.c)
0001:00049c10 __setenvp_
0001:00049d90 __freeenvp_
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(clearenv.c)
0001:00049e10 clearenv_
It appears that the version that works bring in a set of mb*.c files, while the version that
doesn't work don't.
The device-driver that works with the new version doesn't have the mb*.c files either, but then
neither does the previous build of it.
Anybody know which of the last changes might have introduced this bug?
Leif Ekblad
Leif Ekblad
2012-04-27 19:19:57 UTC
Permalink
Indeed it did. We were one the same track, obviously.

I provided a new fix for the problem that uses another function to read the
environment that works at device-driver initialization time. The reason it
malfunctioned was because a process specific function was used before the
process environment was initialized.

And it is correct that wide-environment should not be included since I've
decided to only support UTF-8, and not wide character strings.

Leif Ekblad
Post by Jiri Malak
Leif,
I am sorry I somehow missed your change #37121 in my change #37206 which
do environment related functions more granular.
I fixed it by change #37247.
Missing reference to multibyte functions is result of change #37206 where
I removed wide-environment processing because RDOSDEV clib doesn't use it any way.
Please check if change #37247 fix your problem.
Jiri
Post by Leif Ekblad
It seems like some change during the last few weeks have broken something
in the 32-bit RDOS device-driver target. My main problem is that the
fault appears to happen during initialization time, so it doesn't really
help to remove everything from main-procedure. Even more strange is that
another 32-bit device driver also written in C seems to work.
Comparing the working and non-working version, it seems there is some
small difference in which files are brought in from CLIB.
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(getenv.c)
0001:00049b40 getenv_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(alphabet.c)
0002:00005560 ___Alphabet
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(environ.c)
0002:0000f280 ___env_mask
0002:0000f286 _environ
0002:0000f28c* __wenviron
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbterm.c)
0001:00049c40 _mbterm_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbsnextc.c)
0001:00049c80 _mbsnextc_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbcupper.c)
0001:00049cc0 _mbctoupper_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbsinc.c)
0001:00049ce0 _mbsinc_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(setenvp.c)
0001:00049d20 __setenvp_
0001:00049d30 __freeenvp_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbisdbcs.c)
0002:0000f2a8 ___IsDBCS
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbislead.c)
0001:00049db0* _ismbblead_
0002:0000f2ac ___MBCSIsTable
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbinit.c)
0001:00049e09 __mbinit_
0002:00000c88 ___MBCodePage
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbdtoupp.c)
0001:00049e70 _mbdtoupper_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(clearenv.c)
0001:00049e90 clearenv_
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(getenv.c)
0001:00049b40 getenv_
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(alphabet.c)
0002:0000555c ___Alphabet
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(environ.c)
0002:0000f270 ___env_mask
0002:0000f276 _environ
0002:0000f27c* __wenviron
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(setenvp.c)
0001:00049c10 __setenvp_
0001:00049d90 __freeenvp_
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(clearenv.c)
0001:00049e10 clearenv_
It appears that the version that works bring in a set of mb*.c files,
while the version that doesn't work don't.
The device-driver that works with the new version doesn't have the mb*.c
files either, but then neither does the previous build of it.
Anybody know which of the last changes might have introduced this bug?
Leif Ekblad
Jiri Malak
2012-04-27 19:45:50 UTC
Permalink
It is fine to hear it is OK.
If you plan to use UTF-8 in environment strings you should probably introduce
wide-version of environment because it is simpler to processing.
Another posibility is to introduce UTF-8 as one of CRTL multi-byte encodings and
use multi-byte oriented function for UTF-8 processing.
Now only Far East double-byte encodings are implemented.

Jiri
Post by Leif Ekblad
Indeed it did. We were one the same track, obviously.
I provided a new fix for the problem that uses another function to read the environment that works
at device-driver initialization time. The reason it malfunctioned was because a process specific
function was used before the process environment was initialized.
And it is correct that wide-environment should not be included since I've decided to only support
UTF-8, and not wide character strings.
Leif Ekblad
Post by Jiri Malak
Leif,
I am sorry I somehow missed your change #37121 in my change #37206 which do environment related
functions more granular.
I fixed it by change #37247.
Missing reference to multibyte functions is result of change #37206 where
I removed wide-environment processing because RDOSDEV clib doesn't use it any way.
Please check if change #37247 fix your problem.
Jiri
It seems like some change during the last few weeks have broken something in the 32-bit RDOS
device-driver target. My main problem is that the fault appears to happen during initialization
time, so it doesn't really help to remove everything from main-procedure. Even more strange is
that another 32-bit device driver also written in C seems to work.
Comparing the working and non-working version, it seems there is some small difference in which
files are brought in from CLIB.
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(getenv.c)
0001:00049b40 getenv_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(alphabet.c)
0002:00005560 ___Alphabet
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(environ.c)
0002:0000f280 ___env_mask
0002:0000f286 _environ
0002:0000f28c* __wenviron
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbterm.c)
0001:00049c40 _mbterm_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbsnextc.c)
0001:00049c80 _mbsnextc_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbcupper.c)
0001:00049cc0 _mbctoupper_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbsinc.c)
0001:00049ce0 _mbsinc_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(setenvp.c)
0001:00049d20 __setenvp_
0001:00049d30 __freeenvp_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbisdbcs.c)
0002:0000f2a8 ___IsDBCS
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbislead.c)
0001:00049db0* _ismbblead_
0002:0000f2ac ___MBCSIsTable
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbinit.c)
0001:00049e09 __mbinit_
0002:00000c88 ___MBCodePage
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbdtoupp.c)
0001:00049e70 _mbdtoupper_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(clearenv.c)
0001:00049e90 clearenv_
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(getenv.c)
0001:00049b40 getenv_
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(alphabet.c)
0002:0000555c ___Alphabet
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(environ.c)
0002:0000f270 ___env_mask
0002:0000f276 _environ
0002:0000f27c* __wenviron
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(setenvp.c)
0001:00049c10 __setenvp_
0001:00049d90 __freeenvp_
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(clearenv.c)
0001:00049e10 clearenv_
It appears that the version that works bring in a set of mb*.c files, while the version that
doesn't work don't.
The device-driver that works with the new version doesn't have the mb*.c files either, but then
neither does the previous build of it.
Anybody know which of the last changes might have introduced this bug?
Leif Ekblad
Leif Ekblad
2012-04-27 20:01:13 UTC
Permalink
I don't want double byte encodings because they mess up the basic character
types. UTF-8 is nicer
since it can be used with any function that expects single-byte characters,
which include environment
strings.

What I would like is tool support for inserting and displaying UTF-8
(editor, debugger), and a
way of making the compiler(s) ignore the intial UTF-8 marking that many
editors insert when
you save files in UTF-8. :)

Leif Ekblad
Post by Jiri Malak
It is fine to hear it is OK.
If you plan to use UTF-8 in environment strings you should probably introduce
wide-version of environment because it is simpler to processing.
Another posibility is to introduce UTF-8 as one of CRTL multi-byte encodings and
use multi-byte oriented function for UTF-8 processing.
Now only Far East double-byte encodings are implemented.
Jiri
Post by Leif Ekblad
Indeed it did. We were one the same track, obviously.
I provided a new fix for the problem that uses another function to read
the environment that works at device-driver initialization time. The
reason it malfunctioned was because a process specific function was used
before the process environment was initialized.
And it is correct that wide-environment should not be included since I've
decided to only support UTF-8, and not wide character strings.
Leif Ekblad
Post by Jiri Malak
Leif,
I am sorry I somehow missed your change #37121 in my change #37206 which
do environment related functions more granular.
I fixed it by change #37247.
Missing reference to multibyte functions is result of change #37206 where
I removed wide-environment processing because RDOSDEV clib doesn't use it any way.
Please check if change #37247 fix your problem.
Jiri
Post by Leif Ekblad
It seems like some change during the last few weeks have broken
something in the 32-bit RDOS device-driver target. My main problem is
that the fault appears to happen during initialization time, so it
doesn't really help to remove everything from main-procedure. Even more
strange is that another 32-bit device driver also written in C seems to
work.
Comparing the working and non-working version, it seems there is some
small difference in which files are brought in from CLIB.
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(getenv.c)
0001:00049b40 getenv_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(alphabet.c)
0002:00005560 ___Alphabet
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(environ.c)
0002:0000f280 ___env_mask
0002:0000f286 _environ
0002:0000f28c* __wenviron
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbterm.c)
0001:00049c40 _mbterm_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbsnextc.c)
0001:00049c80 _mbsnextc_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbcupper.c)
0001:00049cc0 _mbctoupper_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbsinc.c)
0001:00049ce0 _mbsinc_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(setenvp.c)
0001:00049d20 __setenvp_
0001:00049d30 __freeenvp_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbisdbcs.c)
0002:0000f2a8 ___IsDBCS
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbislead.c)
0001:00049db0* _ismbblead_
0002:0000f2ac ___MBCSIsTable
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbinit.c)
0001:00049e09 __mbinit_
0002:00000c88 ___MBCodePage
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbdtoupp.c)
0001:00049e70 _mbdtoupper_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(clearenv.c)
0001:00049e90 clearenv_
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(getenv.c)
0001:00049b40 getenv_
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(alphabet.c)
0002:0000555c ___Alphabet
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(environ.c)
0002:0000f270 ___env_mask
0002:0000f276 _environ
0002:0000f27c* __wenviron
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(setenvp.c)
0001:00049c10 __setenvp_
0001:00049d90 __freeenvp_
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(clearenv.c)
0001:00049e10 clearenv_
It appears that the version that works bring in a set of mb*.c files,
while the version that doesn't work don't.
The device-driver that works with the new version doesn't have the
mb*.c files either, but then neither does the previous build of it.
Anybody know which of the last changes might have introduced this bug?
Leif Ekblad
Jiri Malak
2012-04-27 20:55:11 UTC
Permalink
I am not sure if we talk about same thing.
I mean thet you must be able processed UTF-8 string as array of characters not bytes.
Generaly UTF-8 is multi-byte encoding that you cannot simply read by example forth
character of string, because each character can have diffent byte length.
It is reason for using wide-characters.

Jiri
I don't want double byte encodings because they mess up the basic character types. UTF-8 is nicer
since it can be used with any function that expects single-byte characters, which include
environment
strings.
What I would like is tool support for inserting and displaying UTF-8 (editor, debugger), and a
way of making the compiler(s) ignore the intial UTF-8 marking that many editors insert when
you save files in UTF-8. :)
Leif Ekblad
Post by Jiri Malak
It is fine to hear it is OK.
If you plan to use UTF-8 in environment strings you should probably introduce
wide-version of environment because it is simpler to processing.
Another posibility is to introduce UTF-8 as one of CRTL multi-byte encodings and
use multi-byte oriented function for UTF-8 processing.
Now only Far East double-byte encodings are implemented.
Jiri
Post by Leif Ekblad
Indeed it did. We were one the same track, obviously.
I provided a new fix for the problem that uses another function to read the environment that
works at device-driver initialization time. The reason it malfunctioned was because a process
specific function was used before the process environment was initialized.
And it is correct that wide-environment should not be included since I've decided to only
support UTF-8, and not wide character strings.
Leif Ekblad
Post by Jiri Malak
Leif,
I am sorry I somehow missed your change #37121 in my change #37206 which do environment related
functions more granular.
I fixed it by change #37247.
Missing reference to multibyte functions is result of change #37206 where
I removed wide-environment processing because RDOSDEV clib doesn't use it any way.
Please check if change #37247 fix your problem.
Jiri
It seems like some change during the last few weeks have broken something in the 32-bit RDOS
device-driver target. My main problem is that the fault appears to happen during
initialization time, so it doesn't really help to remove everything from main-procedure. Even
more strange is that another 32-bit device driver also written in C seems to work.
Comparing the working and non-working version, it seems there is some small difference in
which files are brought in from CLIB.
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(getenv.c)
0001:00049b40 getenv_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(alphabet.c)
0002:00005560 ___Alphabet
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(environ.c)
0002:0000f280 ___env_mask
0002:0000f286 _environ
0002:0000f28c* __wenviron
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbterm.c)
0001:00049c40 _mbterm_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbsnextc.c)
0001:00049c80 _mbsnextc_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbcupper.c)
0001:00049cc0 _mbctoupper_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbsinc.c)
0001:00049ce0 _mbsinc_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(setenvp.c)
0001:00049d20 __setenvp_
0001:00049d30 __freeenvp_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbisdbcs.c)
0002:0000f2a8 ___IsDBCS
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbislead.c)
0001:00049db0* _ismbblead_
0002:0000f2ac ___MBCSIsTable
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbinit.c)
0001:00049e09 __mbinit_
0002:00000c88 ___MBCodePage
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbdtoupp.c)
0001:00049e70 _mbdtoupper_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(clearenv.c)
0001:00049e90 clearenv_
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(getenv.c)
0001:00049b40 getenv_
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(alphabet.c)
0002:0000555c ___Alphabet
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(environ.c)
0002:0000f270 ___env_mask
0002:0000f276 _environ
0002:0000f27c* __wenviron
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(setenvp.c)
0001:00049c10 __setenvp_
0001:00049d90 __freeenvp_
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(clearenv.c)
0001:00049e10 clearenv_
It appears that the version that works bring in a set of mb*.c files, while the version that
doesn't work don't.
The device-driver that works with the new version doesn't have the mb*.c files either, but
then neither does the previous build of it.
Anybody know which of the last changes might have introduced this bug?
Leif Ekblad
Leif Ekblad
2012-04-27 21:09:13 UTC
Permalink
Yes, but even for wide character strings, you cannot assume that a character
is always two bytes, as
there are more than 64k unicode characters. IOW, the problem is similar for
UTF-16 / wide character
strings, at least if you want to support full unicode.

At the places where character lengths matters, for instance in the graphics
interface, I have some
conversion functions between UTF-8 and unicode.

BTW, I recently ported FreeType (a free font engine in C), and I'm running
it as the second C
based device-driver (ACPICA being the first).

Leif Ekblad
Post by Jiri Malak
I am not sure if we talk about same thing.
I mean thet you must be able processed UTF-8 string as array of characters not bytes.
Generaly UTF-8 is multi-byte encoding that you cannot simply read by example forth
character of string, because each character can have diffent byte length.
It is reason for using wide-characters.
Jiri
Post by Leif Ekblad
I don't want double byte encodings because they mess up the basic
character types. UTF-8 is nicer
since it can be used with any function that expects single-byte
characters, which include environment
strings.
What I would like is tool support for inserting and displaying UTF-8
(editor, debugger), and a
way of making the compiler(s) ignore the intial UTF-8 marking that many
editors insert when
you save files in UTF-8. :)
Leif Ekblad
Post by Jiri Malak
It is fine to hear it is OK.
If you plan to use UTF-8 in environment strings you should probably introduce
wide-version of environment because it is simpler to processing.
Another posibility is to introduce UTF-8 as one of CRTL multi-byte encodings and
use multi-byte oriented function for UTF-8 processing.
Now only Far East double-byte encodings are implemented.
Jiri
Post by Leif Ekblad
Indeed it did. We were one the same track, obviously.
I provided a new fix for the problem that uses another function to read
the environment that works at device-driver initialization time. The
reason it malfunctioned was because a process specific function was
used before the process environment was initialized.
And it is correct that wide-environment should not be included since
I've decided to only support UTF-8, and not wide character strings.
Leif Ekblad
Post by Jiri Malak
Leif,
I am sorry I somehow missed your change #37121 in my change #37206
which do environment related functions more granular.
I fixed it by change #37247.
Missing reference to multibyte functions is result of change #37206 where
I removed wide-environment processing because RDOSDEV clib doesn't use it any way.
Please check if change #37247 fix your problem.
Jiri
Post by Leif Ekblad
It seems like some change during the last few weeks have broken
something in the 32-bit RDOS device-driver target. My main problem is
that the fault appears to happen during initialization time, so it
doesn't really help to remove everything from main-procedure. Even
more strange is that another 32-bit device driver also written in C
seems to work.
Comparing the working and non-working version, it seems there is some
small difference in which files are brought in from CLIB.
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(getenv.c)
0001:00049b40 getenv_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(alphabet.c)
0002:00005560 ___Alphabet
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(environ.c)
0002:0000f280 ___env_mask
0002:0000f286 _environ
0002:0000f28c* __wenviron
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbterm.c)
0001:00049c40 _mbterm_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbsnextc.c)
0001:00049c80 _mbsnextc_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbcupper.c)
0001:00049cc0 _mbctoupper_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbsinc.c)
0001:00049ce0 _mbsinc_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(setenvp.c)
0001:00049d20 __setenvp_
0001:00049d30 __freeenvp_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbisdbcs.c)
0002:0000f2a8 ___IsDBCS
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbislead.c)
0001:00049db0* _ismbblead_
0002:0000f2ac ___MBCSIsTable
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbinit.c)
0001:00049e09 __mbinit_
0002:00000c88 ___MBCodePage
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(mbdtoupp.c)
0001:00049e70 _mbdtoupper_
Module: C:\rdos\watcom\rel2/lib386/rdosdev\clib3r.lib(clearenv.c)
0001:00049e90 clearenv_
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(getenv.c)
0001:00049b40 getenv_
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(alphabet.c)
0002:0000555c ___Alphabet
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(environ.c)
0002:0000f270 ___env_mask
0002:0000f276 _environ
0002:0000f27c* __wenviron
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(setenvp.c)
0001:00049c10 __setenvp_
0001:00049d90 __freeenvp_
Module: C:\ow\openwatcom\rel2/lib386/rdosdev\clib3r.lib(clearenv.c)
0001:00049e10 clearenv_
It appears that the version that works bring in a set of mb*.c files,
while the version that doesn't work don't.
The device-driver that works with the new version doesn't have the
mb*.c files either, but then neither does the previous build of it.
Anybody know which of the last changes might have introduced this bug?
Leif Ekblad
Loading...