Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

user32.dll (Announce)

posted by kerravon E-mail, Ligao, Free World North, 04.07.2021, 02:20

> To get the discussion further, I took a sizable binary (the fullscreen
> textmode IDE fp.exe) and looked at its user32.dll dependencies with MS
> dependency walker, the result is at. Note that this is for FPC 3.2.2, older
> versions might have less:
>
> https://pasteboard.co/K9uqGZb.png
>
> The resulting functions fall in a few categories:
> 1 basic charset conversions (anything with charupper/lower oemto etc) in
> it.
> 2 clipboard related stuff (the textmode IDE allows to copy/paste from/to
> windows)
> 3 a few functions for console input like getKeyboardlayout and
> vkKeyscanexa), as to be expected in a full screen textmode program.
> 4 a few functions for GUI popup boxes of exceptions (messagebox,
> messagebeep, maybe also enumwindows)
> 5 a few misc functions (getsystemmetrics, enumwindows again,
> getwindowthreadprocessid
>
> For the first (1) set of calls , keep in mind that the Windows console is
> in a different (OEM) encoding than the api (ANSI). How do you handle that
> difference (OEM vs Ansi) in your program?
I'm not sure I understand the issue, I know that
OEM means "Other Equipment Manufacturer", but I
would be surprised if Pascal 83-0 was so complicated.

Bearing in mind that there is currently no known
ability to produce a public domain Pascal-derived
Win32 executable, no matter how trivial your
Pascal program is, I don't care if it the
upper/lower is restricted to ASCII unless you
recompile the program. PDPCLIB is restricted to
plain ASCII and sort-of-plain EBCDIC too, although
it is my intention to expand locales at some
point, and I've even been eying control characters
(I need 6 of them) to be confiscated for use by
the Vietnamese language.

> Otherwise simply make a few
> functions that map them as 1:1 output=input to
> eliminate them, but keep the
> functionality.
Ok, I still don't understand that, but my interest
is in making Pascal conform to PDOS/386 (as C
already does), not the other way around.

You can consider it to be "just another target".
It's probably more capable than the Zx.

> Clipboard (2) and console input (3) stuff is in advanced units that are not
> necessary if you keep to basic ansi screen control only. Not necessary for
> the early stuff
I don't yet have ANSI working on PDOS/386,
but it is my intention to add that. Windows
10 recently added that, and my msvcrt.dll
(but probably not Microsoft's) activates that.

If an ANSI-using executable isn't working on
Windows 10, you know where to go. (you just
need to replace Microsoft's version with mine).

I am thinking that ANSI interpretation belongs
in the BIOS layer rather than PDOS proper, but
I'm not sure.

> The GUI Popup(4) stuff is in case the program turns GUI (which can be a
> runtime decision). You can probably easily comment these calls without much
> problems.
>
> Leaves (5) which have to be evaluated on a case by case basis. Some might
> also not be in the basic RTL (e.g. enumwindows and
> getwindowthreadprocessid), but for the more complex app only (like
> getsystemmetric which is afaik used to query console dimensions)
>
> None of these have equivalents in msvcrt.dll
Probably no equivalent in Pascal83-0 either.

Let me see if I can get this really basic
functionality working first. So far I can't
even link an executable. I don't know what
to do about strong versus weak references,
or "fakes". I didn't encounter any of this
stuff with my C work. Not on Windows, or
MVS, or AmigaOS, or MSDOS, or OS/2.

I'll see if I can get ldwin to ignore the
link errors and give me an executable
regardless so that I see if I have something
that I actually understand.

BFN. Paul.

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22632 Postings in 2109 Threads, 402 registered users, 425 users online (1 registered, 424 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum