Viking
Joined: 29 Sep 2006
Posts: 44
Location: Sweden
Posted: Fri May 25, 2007 2:11 am
Hi
I was curious about FreePM and how PM programs interact. Have anyone tried to compile it?
Is the whole thing built into a exe file?
I looked in the makefiles and it needs icc to compile. Which I don't have and creating makefiles
for watcom seems to be a lot of work. The version I downloded is from october last year (cvs).
/Viking
Building FreePM?
FreePM compiles with Open Watcom, but buggy
Viking
Joined: 29 Sep 2006
Posts: 44
Location: Sweden
Posted: Mon Jun 18, 2007 1:46 am
Just an update about my attempts with FreePM. I can compile it now with Open Watcom. I created
makefiles for OW, based on the previous one. The guy which worked on FreePM doesn't have touched
the code since july 2003.
But I ran into really strange bugs, such as when a thread is created with _beginthread it crashes because
of some uninitialized stack? Or something similar. I'm testing FreePM with OS/2 warp 3 and fixpack 38. Is
that version buggy with threads?
The thread related bug, disappeared when I added some code to change the stackpointer manually, which
did'nt work, so I commented it out. After that not even a simple DosSleep worked but the thread stuff did
work. Stuff like this can really test your patience. So I have put it aside and started looking at SDIOS and
get my "tiny" Lx loader to work with it.
The good side though, I have been more familiar with the watcom tools, the compiler, linker and makefiles.
I even looked at the runtime start code which OW creates for LX executables, saw that it reads from the TIB
(Thread Information Block?) via the FS selector register and calls DosQuerySysInfo for the minor and major
version OS number. Which brings me to a question.
How do I get a selector value from an pointer to a compatible structure for TIB? In SDIOS06 I mean.
Greetings /Viking
Joined: 29 Sep 2006
Posts: 44
Location: Sweden
Posted: Mon Jun 18, 2007 1:46 am
Just an update about my attempts with FreePM. I can compile it now with Open Watcom. I created
makefiles for OW, based on the previous one. The guy which worked on FreePM doesn't have touched
the code since july 2003.
But I ran into really strange bugs, such as when a thread is created with _beginthread it crashes because
of some uninitialized stack? Or something similar. I'm testing FreePM with OS/2 warp 3 and fixpack 38. Is
that version buggy with threads?
The thread related bug, disappeared when I added some code to change the stackpointer manually, which
did'nt work, so I commented it out. After that not even a simple DosSleep worked but the thread stuff did
work. Stuff like this can really test your patience. So I have put it aside and started looking at SDIOS and
get my "tiny" Lx loader to work with it.
The good side though, I have been more familiar with the watcom tools, the compiler, linker and makefiles.
I even looked at the runtime start code which OW creates for LX executables, saw that it reads from the TIB
(Thread Information Block?) via the FS selector register and calls DosQuerySysInfo for the minor and major
version OS number. Which brings me to a question.
How do I get a selector value from an pointer to a compatible structure for TIB? In SDIOS06 I mean.
Greetings /Viking
valerius
Joined: 03 Apr 2005
Posts: 50
Location: Elizovo, Kamchatka, Russia
Posted: Tue Jun 19, 2007 5:47 pm
2Viking: Acoording the stack. Maybe the problem is with variables on stack crossing the guard page boundary?
Then an option for wcc386 "-sg" may help "generate code to grow the stack. It touches the guard page to grow
the stack for the stack to contain all variables on this stack.
_________________
WBR,
Valery V. Sedletski
Joined: 03 Apr 2005
Posts: 50
Location: Elizovo, Kamchatka, Russia
Posted: Tue Jun 19, 2007 5:47 pm
2Viking: Acoording the stack. Maybe the problem is with variables on stack crossing the guard page boundary?
Then an option for wcc386 "-sg" may help "generate code to grow the stack. It touches the guard page to grow
the stack for the stack to contain all variables on this stack.
_________________
WBR,
Valery V. Sedletski
Re: Building FreePM?
Viking
Joined: 29 Sep 2006
Posts: 44
Location: Sweden
Posted: Tue Jun 19, 2007 6:35 pm
2Valerius: Guard page? I did not think of that. I will try it. Thanks for the advice.
/Viking
Joined: 29 Sep 2006
Posts: 44
Location: Sweden
Posted: Tue Jun 19, 2007 6:35 pm
2Valerius: Guard page? I did not think of that. I will try it. Thanks for the advice.
/Viking
Viking
Joined: 29 Sep 2006
Posts: 44
Location: Sweden
Posted: Thu Jun 21, 2007 2:29 pm
2Valerius: FreePM now works with that change!
It seems that FreePM mostly prints out messages about which messages it receives in the server
and in the client part (the server and client is in separate exe files). The communication between
the server and the client goes through a named pipe with a certain protocol. Such as a command
token and following data. The core part of the server is in "FreePM/src_s/Fs_main.cpp" in the function
"Fs_ClientWork". I see that there is quite a bit with code which deals with synchronization, Evgen has
done a lot of work with that part. The server creates a PM window (with some graphics art) and
monitors the messages it gets from that. If you move the mouse cursor above it or change the size,
the server prints out stuff about that. The window is created in the server file: "FreePM/src_s/Fs_PMdev.cpp".
The client is wrapped around an ordinary PM program, in "FreePM/src_c/WIN1.cpp". All the calls in that
file is implemented and sent to the server through the named pipe. For example "WinInitialize" is in
"FreePM/src_c/FreePM_win.cpp" which sets up the connection to the server and get's the HAB (?) for
this client.
To start it you first first start the server in "FreePM/src_s/FreePms.exe" and then the client in
"FreePM/src_c/Freepm.exe". Both the server and client creates a logfile in their directories:
"FreePM/src_s/Freepm.log" and "FreePM/src_c/Freepm.log".
The server does not seem to react to window-creating-requests from the client. I guess there
is a lot of work with that part. Just imagine where is the proper level to start ? Just send window
request to ordinary PM? That don't sound like a good solution, in my sense. Maybe send windows
requests to a lower level, like a graphics engine. So that windows is painted and can be sent to
different output "devices". But how? How does PM do it? Has anyone some ideas about this?
There is a lot more in there but this is what I have found out as of now.
Greetings Viking
Joined: 29 Sep 2006
Posts: 44
Location: Sweden
Posted: Thu Jun 21, 2007 2:29 pm
2Valerius: FreePM now works with that change!
It seems that FreePM mostly prints out messages about which messages it receives in the server
and in the client part (the server and client is in separate exe files). The communication between
the server and the client goes through a named pipe with a certain protocol. Such as a command
token and following data. The core part of the server is in "FreePM/src_s/Fs_main.cpp" in the function
"Fs_ClientWork". I see that there is quite a bit with code which deals with synchronization, Evgen has
done a lot of work with that part. The server creates a PM window (with some graphics art) and
monitors the messages it gets from that. If you move the mouse cursor above it or change the size,
the server prints out stuff about that. The window is created in the server file: "FreePM/src_s/Fs_PMdev.cpp".
The client is wrapped around an ordinary PM program, in "FreePM/src_c/WIN1.cpp". All the calls in that
file is implemented and sent to the server through the named pipe. For example "WinInitialize" is in
"FreePM/src_c/FreePM_win.cpp" which sets up the connection to the server and get's the HAB (?) for
this client.
To start it you first first start the server in "FreePM/src_s/FreePms.exe" and then the client in
"FreePM/src_c/Freepm.exe". Both the server and client creates a logfile in their directories:
"FreePM/src_s/Freepm.log" and "FreePM/src_c/Freepm.log".
The server does not seem to react to window-creating-requests from the client. I guess there
is a lot of work with that part. Just imagine where is the proper level to start ? Just send window
request to ordinary PM? That don't sound like a good solution, in my sense. Maybe send windows
requests to a lower level, like a graphics engine. So that windows is painted and can be sent to
different output "devices". But how? How does PM do it? Has anyone some ideas about this?
There is a lot more in there but this is what I have found out as of now.
Greetings Viking
prokushev
Site Admin
Joined: 25 Nov 2003
Posts: 103
Posted: Fri Jun 22, 2007 5:05 am
Good work, Viking!
How about reuse Nitpicker project for PM server realization?
http://www.inf.tu-dresden.de/index.php? ... 2005120001
Usage of such project allow to reuse low-level things (like z-ordering and primitive
windows (views)) for more complex development.
Site Admin
Joined: 25 Nov 2003
Posts: 103
Posted: Fri Jun 22, 2007 5:05 am
Good work, Viking!
How about reuse Nitpicker project for PM server realization?
http://www.inf.tu-dresden.de/index.php? ... 2005120001
Usage of such project allow to reuse low-level things (like z-ordering and primitive
windows (views)) for more complex development.
Viking
Joined: 29 Sep 2006
Posts: 44
Location: Sweden
Posted: Fri Jun 29, 2007 2:53 am
Nitpicker seems very intresting. They also bring access permissions to the window system,
so an application can be refused to spy on other programs running on the same screen.
I have been reading about PM in the inf files from http://www.warpspeed.com.au/book/books.htm
and have a small bit of picture how PM interact with the graphics engine and the presentation driver.
I was thinking about to create some simple version of a presentation driver which would paint windows,
with the help of GD (a graphics toolkit which came with FreePM), to a image file. The problem is, I haven't
wrote an such driver before and it's really hard to get started. I wanted to try it out, so to have an interface
to work with. Has anyone some source code examples of presentation drivers?
Greetings Viking
Joined: 29 Sep 2006
Posts: 44
Location: Sweden
Posted: Fri Jun 29, 2007 2:53 am
Nitpicker seems very intresting. They also bring access permissions to the window system,
so an application can be refused to spy on other programs running on the same screen.
I have been reading about PM in the inf files from http://www.warpspeed.com.au/book/books.htm
and have a small bit of picture how PM interact with the graphics engine and the presentation driver.
I was thinking about to create some simple version of a presentation driver which would paint windows,
with the help of GD (a graphics toolkit which came with FreePM), to a image file. The problem is, I haven't
wrote an such driver before and it's really hard to get started. I wanted to try it out, so to have an interface
to work with. Has anyone some source code examples of presentation drivers?
Greetings Viking
valerius
Joined: 03 Apr 2005
Posts: 50
Location: Elizovo, Kamchatka, Russia
Posted: Fri Jun 29, 2007 1:55 pm
Yes, Nitpicker is very interesting because it allows several windowing systems to coexist on
the same screen, like PM along with X Window system from L4Linux. The security features are
also very interesting. The problem with it that is intended to be used with L4/Fiasco and l4env,
but we selected to use Pistachio. I think, we must either port Nitpicker and services it depends
on to Pistachio, or, better, to select Fiasco instead of Pistachio. Fiasco has also the important
features for OS/2 subsystem, like LDT/GDT manipulation from usermode. For this reason,
imho, Fiasco is more suitable for us than Pistachio.
For presentation drivers creation example you must, probably, get a copy of OS/2 Warp Toolkit.
The problem is that it is now not avaliable on IBM's ftp's But you can find it on independent FTP's
(I'll try to find a link for you)
As I understand, Nitpicker is using its own graphics driver (VBE 2.0 or alike). I am now can't clearly
imagine how must be the the dependencies of subsystems organized. Must be our own version of Nitpicker
based on underlying OS/2-like GRADD model graphics driver, or, conversely, PM graphics driver must
depend on Nitpicker's graphics support?
_________________
WBR,
Valery V. Sedletski
Joined: 03 Apr 2005
Posts: 50
Location: Elizovo, Kamchatka, Russia
Posted: Fri Jun 29, 2007 1:55 pm
Yes, Nitpicker is very interesting because it allows several windowing systems to coexist on
the same screen, like PM along with X Window system from L4Linux. The security features are
also very interesting. The problem with it that is intended to be used with L4/Fiasco and l4env,
but we selected to use Pistachio. I think, we must either port Nitpicker and services it depends
on to Pistachio, or, better, to select Fiasco instead of Pistachio. Fiasco has also the important
features for OS/2 subsystem, like LDT/GDT manipulation from usermode. For this reason,
imho, Fiasco is more suitable for us than Pistachio.
For presentation drivers creation example you must, probably, get a copy of OS/2 Warp Toolkit.
The problem is that it is now not avaliable on IBM's ftp's But you can find it on independent FTP's
(I'll try to find a link for you)
As I understand, Nitpicker is using its own graphics driver (VBE 2.0 or alike). I am now can't clearly
imagine how must be the the dependencies of subsystems organized. Must be our own version of Nitpicker
based on underlying OS/2-like GRADD model graphics driver, or, conversely, PM graphics driver must
depend on Nitpicker's graphics support?
_________________
WBR,
Valery V. Sedletski