I don't think we want to switch the global flag on every int21 call,
that's fairly ugly IMO. If int21 needs OEM then it should use OEM
explicitly, which is pretty much what it's doing already AFAICS. I see
no reason to change that.
I do think it's as ugly as duplicating all the A => W calls from ke
Eric Pouech <[EMAIL PROTECTED]> writes:
> I'd suggest changing the oem_files_api to a krnl_file_api_codepage (or
> something like this) which would be set to either CP_ANSI or CP_OEM
> and use this variable in most of file related A functions (instead of
> our current CP_ANSI). Then we would set O
Use wide characters and manual wide character conversions.
DOS routines use OEM code page and not ANSI code page and
Wine uses wide characters as default character set, anyway.
Regarding this part, I think we'd better rely for int21 support to the
SetFileApisToOEM and SetFileApisToANSI APIs (and or
On Mon, Nov 10, Eric Pouech wrote:
> half of what you (rightfully) suggest to fix had been broken for very
> long in msdos/int21.c (so don't blame me too much... at least not for
> that half)
Yes, I know msdos/int21.c contains lots of broken code and
I'm pretty sure your patch did not add any ne
Jukka Heinonen wrote:
A few comments about this patch by Eric Pouech.
Structure DosHeap must not be moved to winedos.
There already exists per drive media ID byte which
should be used and biosdate, while it may be needed
by some programs, won't do any good in a separate 16-bit
segment. Also, INT2
A few comments about this patch by Eric Pouech.
Structure DosHeap must not be moved to winedos.
There already exists per drive media ID byte which
should be used and biosdate, while it may be needed
by some programs, won't do any good in a separate 16-bit
segment. Also, INT21_CreateHeap is unnece
