home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
OS/2 Shareware BBS: 15 Message
/
15-Message.zip
/
oe991120.zip
/
Pr991119.txt
< prev
next >
Wrap
Text File
|
1999-11-20
|
38KB
|
979 lines
OS/2 Programming (Fidonet)
Saturday, 13-Nov-1999 to Friday, 19-Nov-1999
+----------------------------------------------------------------------------+
From: Herbert Rosenau 11-Nov-99 22:05:29
To: Jonathan de Boyne Pollard 13-Nov-99 01:05:25
Subj: PROMPT $I in PMCMD
JdBP> So I'm looking for an efficient way of drawing characters to a
JdBP> presentation space during a WM_PAINT event myself.
If you have a lot of painting you should do it in a separate thread.
That thread should be an PM thread. There you can create a memory presentation
space and paint what ever you have to paint - hidden and asyncronous.
If your real presentation space is object to repaint you can simply do a
GpiBitBlt() and copy the whole region or simple one or more rectangle(s) from
your memory hps into that of your window.
A simple trick to tune up high frequently changes on your screen is to paint
into more memory presentation spaces parallel and copy the one you need to
show into the screen PS.
In case you would use that in WM_PAINT you have to change the lines
hdcScreen = ...
hpsScreen = ...
to
hpsScreen = WinBeginPaint(.....
A sample from GPI Guide and Reference:
----------------------------Abbeißen-----------------------
This example uses GpiBitBlt to copy a bit map from one presentation space to
another. Two presentation spaces are
created: one associated with a memory context, and the other associated with
a screen context. The function copies the
memory context bit map that is 100 pels wide and 100 pels high into a
50-by-50-pel rectangle at the location (300,400) on
the screen, thereby causing the bit map to be visible in the window. Since
the raster operation is ROP_SRCCOPY, GpiBitBlt
replaces the image previously in the target rectangle. The function
compresses the bit map to fit the new rectangle by
discarding extra rows and columns as specified by the BBO_IGNORE option.
#define INCL_GPIBITMAPS /* Bit map functions */
#define INCL_DEV /* Device Function definitions */
#define INCL_GPICONTROL /* GPI control Functions */
#define INCL_WINWINDOWMGR /* Window Manager Functions */
#include <os2.h>
HAB hab; /* anchor-block handle */
HPS hpsMemory; /* presentation-space handle */
HPS hpsScreen; /* presentation-space handle */
HDC hdcScreen; /* Device-context handle */
HDC hdcMemory; /* Device-context handle */
SIZEL sizl={0, 0}; /* use same page size as device */
/* context data structure */
DEVOPENSTRUC dop = {0L, "DISPLAY", NULL, 0L, 0L, 0L, 0L, 0L, 0L};
POINTL aptl[4] = {
300, 400, /* lower-left corner of target */
350, 450, /* upper-right corner of target */
0, 0, /* lower-left corner of source */
100, 100 }; /* upper-right corner of source */
HWND hwnd;
/* create memory device context and presentation space, associating
DC with the PS */
hdcMemory = DevOpenDC(hab, OD_MEMORY, "*", 5L, (PDEVOPENDATA)&dop,
NULLHANDLE);
hpsMemory = GpiCreatePS(hab, hdcMemory, &sizl, GPIA_ASSOC
| PU_PELS);
/* create window device context and presentation space, associating
DC with the PS */
hdcScreen = WinOpenWindowDC(hwnd); /* Open window device context */
hpsScreen = GpiCreatePS(hab, hdcScreen, &sizl, PU_PELS | GPIF_LONG
| GPIA_ASSOC);
/*
.
. get bit map, associate bit map with memory device context,
. draw into bit map
.
*/
/* display the bit map on the screen by copying it from the memory
device context into the screen device context */
GpiBitBlt(hpsScreen, hpsMemory, 4L, aptl, ROP_SRCCOPY, BBO_IGNORE);
----------------------------Abbeißen-----------------------
--- Sqed/32 1.14/development
* Origin: Schont die Umwelt: Vermeidet DOSen (2:2476/493)
+----------------------------------------------------------------------------+
From: Jonathan de Boyne Pollard 11-Nov-99 09:05:13
To: MIKE RUSKAI 13-Nov-99 03:49:18
Subj: Multiple primary HPFS
MR> [This may be a duplicate message. My Fido host had a glitch]
MR> [that prevented mail from going out for an unspecified ]
MR> [length of time, so I have to repost recent messages. ]
They actually did make it out the first time.
» JdeBP «
--- FleetStreet 1.22 NR
* Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)
+----------------------------------------------------------------------------+
From: Fred Springfield 15-Nov-99 12:44:05
To: All 15-Nov-99 21:24:16
Subj: Environment Variables
I recently installed VACPP v3.0 on my system, which has Warp 4 + FP10,
Lotus S/S for OS/2, and VA Basic.
In the config.sys there are conflicting SET statements put in by these
3 programs for TMP, SMTMP, SOMBASE, and SOMRUNTIME.
Do I need to consolidate these some how to eliminate the duplication
and/or conflicts? If so, what is the best way to do it?
Since the TMP directories seem to be empty, I think it is OK to just
use one single directory, such as C:\TMP, without actually deleting
any of the other TMP directories, but what about the others?
Fred Springfield
Plymouth, MN
■ KWQ/2 1.2i ■ Hope makes a good breakfast, but a poor dinner.
--- ProBoard v2.16 [Reg]
* Origin: RiverWorks * ProBoard Beta Site * V34+ * (1:282/4093)
+----------------------------------------------------------------------------+
From: Andrew Grillet 09-Nov-99 17:45:15
To: Kris Steenhaut 15-Nov-99 21:24:16
Subj: Re: Fixpaks
Hi Kris,
-=> Kris Steenhaut wrote to Andrew Grillet <=-
KS> Dag Andrew,
KS> vrijdag 22 oktober 1999 08.19, Bericht van Andrew Grillet aan All:
AG> I was running Warp Connect with fixpack 40, on a VESA bus 486
AG> when my VGA card suffered hardware death.
AG> I have more Vesa VGA cards than is good for a normal
AG> human, so I simply swapped it out. Unfortunately, it was
AG> a different brand. This meant attempting a switch back
AG> to VGA. This failed - the scan rate was bizarre.
AG> Obviously time for a re-install.
KS> Not so, for two reasons:
KS> 1° You only have to delete the syslevel.os2 and syslevel.fpk files in
KS> the \OS2\INSTALL directory.
Unfortunately, there is no obvious way to access this information - especially
when your scan rate is set to one your monitor can't handle.
KS> 2° You should have had no trouble at all, if, after having replaced the
KS> hardware, you'd had rebooted with an alt-F1 --> F3 operation.
That was what I meant by 'switch back to VGA' - I did it, but it did not
function as intended.
KS> Just the basics. Next time, before action, do ask first.
Exactly how am I supposed to ask when my system is dead? I can only access
Fido via OS/2 on that machine.
Despite numerous postings by many people, my origian point remains valid -
that once a fixpack has been applied, a re-install is 'forbidden'. There may
be hacks that get around this, but there are legitimate reasons why a user
may wish to reinstall after a fixpack has been applied, and the user should
be offered a choice, and not a 'refusal to act as needed by the purchaser'.
This type of authoritarian treatment of legit users tends to drive them in
the direction of freeware, while a more flexible and co-operative approach
would give users a warm feeling inside (possibly near the credit card).
Andrew
... Computer Hacker wanted. Must have own axe.
--- Blue Wave/Maximus
* Origin: Me/2 <Meet-You> (2:254/259)
+----------------------------------------------------------------------------+
From: Harald Pollack 10-Nov-99 13:49:15
To: Jonathan de Boyne Pollard 15-Nov-99 21:24:16
Subj: PROMPT $I in PMCMD
Am 03. Nov 99 09:49, schrieb Jonathan de Boyne Pollard (2:257/609.3)
an George White:
Servus Jonathan!
JdBP>>> Actually, what I need to do is to write a control window
JdBP>>> that can be used to display coloured text, rather than
JdBP>>> relying on a standard MLE control.
JdBP> Does anyone here in OS2PROG have any suggestions ?
And how about these ?
hdc = WinOpenWindowDC(hwnd);
hps = GpiCreatePS(hab,hdc,&sizel,
PU_PELS | GPIF_DEFAULT | GPIT_MICRO | GPIA_ASSOC );
VioCreatePS(&hvps,SCREEN_HEIGHT,SCREEN_WIDTH,0,1,0);
VioAssociate(hdc,hvps);
...
and so on.
Herzliche Gruesse, Harald
-+- Message created on Wednesday November, 10 1999 13:51:05 MEZ
--- WarpEd/2 1.11α
* Origin: LFP Schwechat [OS/2] (2:310/14.59)
+----------------------------------------------------------------------------+
From: MIKE RUSKAI 13-Nov-99 12:37:00
To: JONATHAN DE BOYNE POLLARD 15-Nov-99 21:24:16
Subj: Multiple primary HPFS
Some senseless babbling from Jonathan De Boyne Pollard to Mike Ruskai
on 11-11-99 09:05 about Multiple primary HPFS...
MR> [This may be a duplicate message. My Fido host had a glitch]
MR> [that prevented mail from going out for an unspecified ]
MR> [length of time, so I have to repost recent messages. ]
JDBP> They actually did make it out the first time.
Apparently some didn't. The sysop never said when the error occurred (he
forgot to create a subdirectory when moving to a new drive), so I went back
a week.
Mike Ruskai
thannymeister@yahoo.com
... An optimist is a person without much experience in life.
___ Blue Wave/QWK v2.20
--- Platinum Xpress/Win/Wildcat5! v3.0pr2
* Origin: FIDO QWK MAIL & MORE! WWW.DOCSPLACE.ORG (1:3603/140)
+----------------------------------------------------------------------------+
From: Jonathan de Boyne Pollard 12-Nov-99 12:12:28
To: Charles Gaefke 16-Nov-99 03:46:08
Subj: Watcom C++ 11.0 and thunking
Thanks for your 1998 posting on the powersoft news server, by the way. I
spent ages trying to find out why some assembly language code that I wrote to
thunk from 32-bit to 16-bit wasn't working. Then I turned up your posting
where you noted that
#define INCL_VIO
#include <os2.h>
char vm_wherey(void)
{
USHORT row, col;
VioGetCurPos(&row, &col, 0);
return (char)(row + 1);
}
when compiled as a 32-bit application crashes. VioGetCurPos() was the exact
call that I was having trouble with. Knowing that it didn't work using
Watcom's own libraries steered me towards the conclusion that my assembly
language code was in fact correct (which explained why I couldn't find any
mistakes in it despite hours of patient tracing through it with a debugger
(-:) and that it was a linker problem. WATFIX has now fixed the problem (but,
alas, not the linker itself) and my DLL now works. There are a small bunch of
happy VIOCMD users who would probably like to thank you as well. (-:
Ironically, I had actually already noticed the lack of the "ALIAS" flag on
some of the 16:16 import fixups (which is what WATFIX fixes, of course). I
should have pursued that line of investigation further.
» JdeBP «
--- FleetStreet 1.22 NR
* Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)
+----------------------------------------------------------------------------+
From: Jonathan de Boyne Pollard 15-Nov-99 09:41:17
To: Steve Wendt 16-Nov-99 03:46:08
Subj: DESKARC LIST
[ This is a précis of a message in the TAUCMD echo. ]
SW> DESKARC LIST produces no output here.
About three months ago, I posted a question asking if anyone knew the internal
structure of \OS2\ARCHIVES\ARCHIVES.$$$ . Once I know that, I can add code to
DESKARC to pretty-print the information contained in it when the LIST option
is used.
Unfortunately, I've had no replies, and I don't have the time to sit down with
a hex viewer and work out the structure of the file myself. If anyone reading
this wants to do so, I'd be grateful. I gather that there are several people
who are interested in the tools when they are finished but who don't have
enough spare time to cope with the full cycle of installing and using
pre-releases as I shovel them out, even though they would like to contribute
something if they could. This is their chance. If they want to make a more
modest contribution, one which won't be as demanding of their time, figuring
out the structure of ARCHIVES.$$$ can be it.
Let me know what it is, and I'll implement the LIST option of the DESKARC
command.
» JdeBP «
--- FleetStreet 1.22 NR
* Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)
+----------------------------------------------------------------------------+
From: Murray Lesser 15-Nov-99 22:47:00
To: Fred Springfield 15-Nov-99 22:47:00
Subj: Environment Variables
(Excerpts from a message dated 11-15-99, Fred Springfield to All)
Hi Fred--
FS>I recently installed VACPP v3.0 on my system, which has Warp 4 +
>FP10, Lotus S/S for OS/2, and VA Basic.
FS>In the config.sys there are conflicting SET statements put in by
>these 3 programs for TMP, SMTMP, SOMBASE, and SOMRUNTIME.
FS>Do I need to consolidate these some how to eliminate the duplication
>and/or conflicts? If so, what is the best way to do it?
IIRC, in some cases, there are instructions in the README telling
the order in which to install some IBM applications to avoid your
trouble. Unfortunately, I believe those apply only to multiple VA
compiles :-(. I have no experience with the set you have installed, so
I can't tell you whether or not any of the conflicts can be
consolidated.
AFAIAC, the easiest way is to NOT let the installation program
monkey with your CONFIG.SYS file. If you tell it not to modify
CONFIG.SYS, when each program is installed, you will find another
CONFIG.SYS-type file (I've forgotten what it is named, but the install
program will tell you. You may be able to consolidate these three
files, or (better) set up a REXX file to to call the application, but
modify the necessary CONFIG.SYS "SET" commands for that application.
Each app will be in a special session, each with its own environment.
You must remember to use SET BEGINLIBPATH=(whatever) to tell the session
where the DLLs may be beside those in your normal CONFIG.SYS.
I refuse to let anyone else's software diddle my CONFIG.SYS file. I
spent too much time and effort getting it the way I want it :-).
Regards,
--Murray
<Team PL/I>
___
* MR/2 2.25 #120 * Have a frabjous day." he chortled in his joy
--- Maximus/2 2.02
* Origin: OS/2 Shareware BBS, telnet://bbs.os2bbs.com (1:109/347)
+----------------------------------------------------------------------------+
From: MIKE RUSKAI 16-Nov-99 04:34:00
To: FRED SPRINGFIELD 17-Nov-99 00:27:02
Subj: Environment Variables
Some senseless babbling from Fred Springfield to All
on 11-15-99 12:44 about Environment Variables...
FS> I recently installed VACPP v3.0 on my system, which has Warp 4 +
FS> FP10, Lotus S/S for OS/2, and VA Basic.
FS> In the config.sys there are conflicting SET statements put in by these
FS> 3 programs for TMP, SMTMP, SOMBASE, and SOMRUNTIME.
FS> Do I need to consolidate these some how to eliminate the duplication
FS> and/or conflicts? If so, what is the best way to do it?
FS> Since the TMP directories seem to be empty, I think it is OK to just
FS> use one single directory, such as C:\TMP, without actually deleting
FS> any of the other TMP directories, but what about the others?
Your safest bet is probably to use the one pointing to the newest of the
SOM files.
Mike Ruskai
thannymeister@yahoo.com
... Back off man...I'm a scientist.
___ Blue Wave/QWK v2.20
--- Platinum Xpress/Win/Wildcat5! v3.0pr2
* Origin: FIDO QWK MAIL & MORE! WWW.DOCSPLACE.ORG (1:3603/140)
+----------------------------------------------------------------------------+
From: Jonathan de Boyne Pollard 15-Nov-99 12:11:29
To: All 17-Nov-99 03:41:04
Subj: 32-bit console API
It's unfortunate that there's no 32-bit console API in OS/2 Warp 4, and it's
equally unfortunate that there's no standard DLL for thunking down to the
16-bit VIO, KBD, and MOU subsystems. As a consequence, most C/C++
implementations either generate thunking code on the fly (Borland C++, Watcom
C++, IBM VisualAge C++), or have in their libraries pre-written thunks for the
VIO16, KBD16, and MOU16 subsystems that are statically linked into executables
when needed (MetaWare High C++, EMX C++).
And as a consequence of that, many otherwise purely 32-bit OS/2 applications
contain 16-bit code statically linked into them, simply because they want to
do fancy things in text mode.
Of course, there *is* such a 32-bit DLL: the DLL in the 32TEXT package on the
DevCon CD-ROMs. However, it is beta-level code as the documentation states,
highly unlikely *ever* to become a standard part of OS/2 (going by the lack of
movement in this direction over the past 5 or so years), and, as I found out,
it contains some rather vicious bugs that make it practically useless. One
cannot run two processes simultaneously that use that DLL and that call
KbdCharIn(), for example. The processes die with a SYS3175 somewhere inside
the DLL.
If anyone wants a 32-bit wrapper around the most generally used portions of
the 16-bit VIO and KBD subsystems, I've now rolled my own, CON3216.DLL, which
*does* work when used simultaneously in multiple processes. I can provide an
import library and a replacement <bsesub.h> header. I've followed the 32TEXT
API as faithfully as I can (given how little documentation there is -- there's
no description of *what* VK_ codes are returned by KbdCharIn for each key, for
example), even going so far as using the same ordinal numbers for the function
entry points.
Better yet, I have also written a proper, 32-bit, Unicode, console API,
CONCALLS.DLL, and a <bsecon.h> header.
Consider it just one more 16-bit vestige in OS/2 Warp that can now be
eliminated.
» JdeBP «
--- FleetStreet 1.22 NR
* Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)
+----------------------------------------------------------------------------+
From: Murray Lesser 16-Nov-99 19:35:01
To: All 16-Nov-99 19:35:01
Subj: Basic Pds Y2k Ok
In case there is anyone out there besides me who is still using the
vintage-1990 MS BASIC PDS v 7.1 compiler running as a "native OS/2"
application (not in a VDM!):
I made a small test of the DATE$ function (compiled and linked for
both real (VDM) and protected (native OS/2) modes with my system clock
cranked up a year. The full source code of TEST.BAS was: PRINT DATE$.
Both versions returned 11-16-2000, something that was not really
expected!
So, two of my often-used very-old utilities are Y2K safe, so I don't
have to rewrite them in PL/I during the next month and a half :-).
Just shows that MS once was able to do things right!
Regards,
--Murray
<Team PL/I>
___
* MR/2 2.25 #120 * Never send a PM program to do a text-mode job
--- Maximus/2 2.02
* Origin: OS/2 Shareware BBS, telnet://bbs.os2bbs.com (1:109/347)
+----------------------------------------------------------------------------+
From: Rob Basler 16-Nov-99 18:34:16
To: All 17-Nov-99 07:57:14
Subj: sendto() doesn't work on WSeB
I'm trying to make a UDP app that will broadcast on the local LAN to find any
available servers. I have tested this code on Warp 4 and it works fine. It
also works fine if the server is on WSeB, but if the client is on WSeB I get a
TCP/IP error 10065 (No Route to Host) which is pretty strange.
Suggestions? I can ping any and all computers on my lan from any and all. If
I connect to the internet via dialup the client program runs, but of course is
looking at the internet rather than my local lan to find the servers so it
doesn't find anything.
The code (prettified a bit.)
int s, tries, found;
char buf[256], buf2[256];
int nonblocking, errorcode, broadcast;
struct sockaddr_in server, client;
tries=5;
found=0;
while ((tries>0) && (found==0)) {
/* Create a datagram socket in the internet domain and use the default
protocol (UDP). */
if ((s = socket(PF_INET, SOCK_DGRAM, 0)) < 0) {
return(-1);
}
/* Bind the UDP socket to the server address. */
client.sin_family = AF_INET; /* Server is in Internet Domain */
client.sin_port = 0; /* Any port in a storm */
client.sin_addr.s_addr = INADDR_ANY; /* Server's Internet Address */
if (bind(s, (struct sockaddr *)&client, sizeof(client)) < 0) {
return(-1);
}
/* Set up the server name */
server.sin_family = AF_INET; /* Internet Domain
*/
server.sin_port = htons(SERVERBROADCAST_UDP); /* Server Port
*/
server.sin_addr.s_addr = INADDR_BROADCAST; /* broadcast to all
servers */
// Make up our message, the client name and version
strcpy(buf,"CLIENTBXMSG10");
// Set socket to allow broadcasts
broadcast=1;
if
(setsockopt(s,SOL_SOCKET,SO_BROADCAST,(char*)&broadcast,sizeof(broadcast))!=0)
{
return(-3);
}
/* Broadcast the message in buf to the server */
if (sendto(s, buf, (strlen(buf)+1), 0, (struct sockaddr *)&server,
sizeof(server)) < 0) {
return(-2);
}
// Set socket to non-blocking mode
nonblocking=1;
if (ioctl(s,FIONBIO,(caddr_t)&nonblocking,sizeof(nonblocking))!=0) {
return(-3);
}
// Wait for response for 2 seconds.
int32 timeout=TimeGet();
while ((TimeElapsed(timeout)<2000) && (found<maxservers)) {
/* Receive a message on socket udpsock in buf of maximum size 32
from a client. */
int server_address_size = sizeof(server);
if (recvfrom(s,buf,sizeof(buf),0,(struct sockaddr *)
&server,&server_address_size) <0) {
// miscellaneous processing of the received message and closing of the socket.
--- Maximus/2 3.01
* Origin: Frog Hollow Port Moody BC 604-469-0264/0284 (1:153/290)
+----------------------------------------------------------------------------+
From: Charles Gaefke 16-Nov-99 18:30:02
To: Jonathan De Boyne Pollard 17-Nov-99 11:14:25
Subj: Re: Watcom C++ 11.0 and thunking
JD> Thanks for your 1998 posting on the powersoft news server, by the way. I
s
JD> ages trying to find out why some assembly language code that I wrote to
thu
JD> from 32-bit to 16-bit wasn't working. Then I turned up your posting where
JD> noted that
Using Watcom 11.0 I take it? :)
It's a shame Powersoft never fixed Watcom. 10.6 is great. 11.0 is broke.
11.0a is better, but still broke (atleast for OS/2).
I use 10.6 when I develop for OS/2. Saves me a lot of hassle.
I use 11.0a when I develop for Win32.
Oh, and you're welcome. Glad it helped.
C. Gaefke
cdgaefke@earthlink.net
... Are you following your dreams?
--- Renegade 98-310 Dos/CDRMail v1.23.b1.1
* Origin: LOTL/2 * www.icubed.com/~cdgaefke (1:129/230)
+----------------------------------------------------------------------------+
From: Harald Pollack 12-Nov-99 08:10:06
To: MIKE RUSKAI 17-Nov-99 19:18:20
Subj: HPFS freespace bmp list
Am 06. Nov 99 07:20, schrieb MIKE RUSKAI (1:3603/140)
an HARALD POLLACK:
Servus MIKE!
MR> That wouldn't work at all. That space is not necessarily
MR> contigous at all.
Ok, than it is not for a reference partition :-)
MR> It can have two freespace bitmaps right in the middle of
MR> it, depending on the drive layout.
Maybe it is some reserved space for 'HotFix' (whatever this is in reality)
MR> Furthermore, on a 10MB HPFS drive,
On such a drive, a reference partition is not possible.
MR> that area is only 443 sectors, which is not enough for a PS/2 reference
MR> partition
That's also right
MR> (which not very many PS/2's actually have - most use reference
MR> diskettes).
In principel, all PS/2 use reference DISKs, but (almost ?) all 95XX models do
so.
Herzliche Gruesse, Harald
-+- Message created on Friday November, 12 1999 08:13:54 MEZ
--- WarpEd/2 1.11α
* Origin: LFP Schwechat [OS/2] (2:310/14.59)
+----------------------------------------------------------------------------+
From: Jonathan de Boyne Pollard 16-Nov-99 13:48:23
To: Harald Pollack 18-Nov-99 06:15:01
Subj: PROMPT $I in PMCMD
JdBP>>>> Actually, what I need to do is to write a control window
JdBP>>>> that can be used to display coloured text, rather than
JdBP>>>> relying on a standard MLE control.
JdBP>> Does anyone here in OS2PROG have any suggestions ?
HP> And how about these ?
HP>
HP> hdc=WinOpenWindowDC(hwnd);
HP>
hps=GpiCreatePS(hab,hdc,&sizel,PU_PELS|GPIF_DEFAULT|GPIT_MICRO|GPIA_ASSOC);
HP> VioCreatePS(&hvps,SCREEN_HEIGHT,SCREEN_WIDTH,0,1,0);
HP> VioAssociate(hdc,hvps);
HP> ...
As I have said already, in a pure 32-bit application the option of a VIO
presentation space is not open to me. In any case, it seems silly to have a
32-bit application relying on a 16-bit relic from OS/2 version 1.2 .
I'm looking for a solution that is 32-bit. Therefore I'm looking for a
solution that uses the ordinary 32-bit Presentation Manager API. There must
be an efficient way of drawing fixed-width text in multiple colours using the
GPI.
I've been wondering whether to use a memory PS, drawing into it when the
window contents are changed and blitting into the window's PS in a WM_PAINT
event. But I'm worried about if I do so having to handle font and preparams
issues manually (which seem to be taken care of automatically when I use the
cached micro PS supplied by WinBeginPaint).
» JdeBP «
--- FleetStreet 1.22 NR
* Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)
+----------------------------------------------------------------------------+
From: Fred Springfield 18-Nov-99 01:43:05
To: Murray Lesser 18-Nov-99 17:36:09
Subj: Basic Pds Y2k Ok
Murray Lesser said to all:
ML> In case there is anyone out there besides me who is still
ML> using the vintage-1990 MS BASIC PDS v 7.1 compiler running as a
ML> "native OS/2" application (not in a VDM!):
ML>
ML> I made a small test of the DATE$ function (compiled and linked for
ML> both real (VDM) and protected (native OS/2) modes with my system
ML> clock cranked up a year. The full source code of TEST.BAS was:
ML> PRINT DATE$. Both versions returned 11-16-2000, something that was
ML> not really expected!
ML>
ML> So, two of my often-used very-old utilities are Y2K safe, so I don't
ML> have to rewrite them in PL/I during the next month and a half :-).
ML>
ML> Just shows that MS once was able to do things right!
ML>
Yes, I still use mine heavily--3 commercial programs in use now, which
I am still supporting. But, I run it in a VDM on Warp 4 and only
generate DOS .exe's, which my clients run on Win 95/NT. I know you can
generate VIO programs with it, but I went to rexx for that type of thing
because PDS essentially becomes a text program generator in that mode of
operation.
But, surprise, surprise. How do you run it as an OS/2 application?
Fred Springfield
Plymouth, MN
■ KWQ/2 1.2i ■ Working smart beats working hard--try it.
--- ProBoard v2.16 [Reg]
* Origin: RiverWorks * ProBoard Beta Site * V34+ * (1:282/4093)
+----------------------------------------------------------------------------+
From: MIKE RUSKAI 17-Nov-99 19:38:00
To: HARALD POLLACK 18-Nov-99 23:18:15
Subj: HPFS freespace bmp list
Some senseless babbling from Harald Pollack to Mike Ruskai
on 11-12-99 08:10 about HPFS freespace bmp list...
HP> Am 06. Nov 99 07:20, schrieb MIKE RUSKAI (1:3603/140)
HP> an HARALD POLLACK:
HP> Servus MIKE!
MR> That wouldn't work at all. That space is not necessarily
MR> contigous at all.
HP> Ok, than it is not for a reference partition :-)
No, and I've still not found an answer.
MR> It can have two freespace bitmaps right in the middle of
MR> it, depending on the drive layout.
HP> Maybe it is some reserved space for 'HotFix' (whatever this is in
HP> reality)
No, the location and count of hotfix sectors are well-defined. There are
always 100, and they're always at the beginning of the drive.
MR> (which not very many PS/2's actually have - most use reference
MR> diskettes).
HP> In principel, all PS/2 use reference DISKs, but (almost ?) all 95XX
HP> models do so.
I've never used a PS/2 as new as that :)
Mike Ruskai
thannymeister@yahoo.com
... Humor is the ability to laugh at ourselves.
___ Blue Wave/QWK v2.20
--- Platinum Xpress/Win/Wildcat5! v3.0pr2
* Origin: FIDO QWK MAIL & MORE! WWW.DOCSPLACE.ORG (1:3603/140)
+----------------------------------------------------------------------------+
From: Vince Coen 18-Nov-99 00:12:27
To: Charles Gaefke 19-Nov-99 06:08:13
Subj: Watcom C++ 11.0 and thunking
Hello Charles!
Tuesday November 16 1999, Charles Gaefke writes to Jonathan De Boyne Pollard:
JD>> Thanks for your 1998 posting on the powersoft news server, by the
JD>> way. I s ages trying to find out why some assembly language code
JD>> that I wrote to thu from 32-bit to 16-bit wasn't working. Then I
JD>> turned up your posting where noted that
CG> Using Watcom 11.0 I take it? :)
CG> It's a shame Powersoft never fixed Watcom. 10.6 is great. 11.0 is
CG> broke. 11.0a is better, but still broke (atleast for OS/2).
CG> I use 10.6 when I develop for OS/2. Saves me a lot of hassle.
CG> I use 11.0a when I develop for Win32.
CG> Oh, and you're welcome. Glad it helped.
I have 11.0b if anyone needs it.
Vince
--- Maximus v3.01/GoldED/2 2.50+#10UK3 under OS/2
* Origin: Air Applewood; OS/2 Gateway to Essex +44-1279-792300 (2:257/609)
+----------------------------------------------------------------------------+
From: Tobias Ernst 18-Nov-99 10:44:09
To: Jonathan de Boyne Pollard 19-Nov-99 06:08:13
Subj: 32-bit console API
Hallo Jonathan!
JdBP> Better yet, I have also written a proper, 32-bit, Unicode, console
JdBP> API, CONCALLS.DLL, and a <bsecon.h> header.
This is really fine. Where can one get this?
Viele Grüße,
Tobias
--- Msged/BSD TE 06 (pre)
* Origin: Running FreeBSD 3.2 (2:2476/418)
+----------------------------------------------------------------------------+
From: Eddy Thilleman 17-Nov-99 12:59:19
To: Fred Springfield 19-Nov-99 14:48:11
Subj: Environment Variables
Hello Fred,
15 Nov 99 12:44, Fred Springfield wrote to All:
FS> In the config.sys there are conflicting SET statements put in by these
FS> 3 programs for TMP, SMTMP, SOMBASE, and SOMRUNTIME.
You can start them via a (for each) unique batch (or REXX) file and set these
environment variables there to the value they need.
Greetings -=Eddy=- email: eddy.thilleman@net.hcc.nl
... "Tuesday is Human Sacrifice Day at the Sizzler." - Tom Servo
--- GoldED/2 3.0.1
* Origin: Windows95 is a graphic DOS extender (2:500/143.7)
+----------------------------------------------------------------------------+
From: Murray Lesser 19-Nov-99 21:53:01
To: Fred Springfield 19-Nov-99 21:53:01
Subj: Basic Pds Y2k Ok
(Excerpts from a message dated 11-18-99, Fred Springfield to Murray
Lesser)
Hi Fred--
ML> In case there is anyone out there besides me who is still
ml> using the vintage-1990 MS BASIC PDS v 7.1 compiler running as a
ML> "native OS/2" application (not in a VDM!):
ML>
ML> I made a small test of the DATE$ function (compiled and linked for
ML> both real (VDM) and protected (native OS/2) modes with my system
ML> clock cranked up a year. The full source code of TEST.BAS was:
ML> PRINT DATE$. Both versions returned 11-16-2000, something that was
ML> not really expected!
ML>
FS>Yes, I still use mine heavily--3 commercial programs in use now,
>which I am still supporting. But, I run it in a VDM on Warp 4 and
>only generate DOS .exe's, which my clients run on Win 95/NT. I know
>you can generate VIO programs with it, but I went to rexx for that
>type of thing because PDS essentially becomes a text program
>generator in that mode of operation.
It doesn't bother me that BASIC PDS (run under OS/2) produces only
text-mode applications, because that is the only type of program I
write. Nowadays, I program only for my own amazement, and I prefer to
run text-mode applications to their GUI brethren. I no longer write
"new" programs with BASIC PDS, and use the compiler only to update those
currently active applications that I haven't gotten around to rewriting
in PL/I (something on the to-do list, RSN!). At the moment, I have only
three left that I run regularly, but I will have to write a set of
separately compiled procedures for PL/I to display text "windows" within
a text-mode full-screen application before I can rewrite two of them. I
use the compiler so rarely that I have moved it on to a Zip-drive
diskette (the files I have retained use only about 4 MB, including my
"private" link libraries containing separately-compiled and assembled
modules).
REXX is a great programming tool for quick and dirty jobs, or even
for jobs that spend most of their activity manipulating text files, but
I would not use it as a complete substitute for BASIC PDS, even though
there are things that are easier to do in REXX than in any other
language that I know: anything that "needs" the REXX PARSE statement.
But I prefer PL/I to any other language that I know for "real" text-mode
applications. I tried "porting" a few BASIC PDS programs to C (before I
began to learn PL/I), but gave up; C is just too clumsy a language to be
useful for programs with a lot of text manipulation, Kernighan and
Ritchie to the contrary notwithstanding.
FS>But, surprise, surprise. How do you run it as an OS/2 application?
You have to remember that "native OS/2" for the BASIC PDS compiler
(and protected-mode applications written in it) are 16-bit text-mode
OS/2 programs, because the only version of OS/2 that Microsoft
recognized at the time was 1.0. However, since IBM is a very strong
believer in backward compatibility, 16-bit OS/2 programs run fine,
unchanged, in 32-bit OS/2.
It has been over six years since I installed BASIC PDS to run in
"protected mode" and I'm not sure that I could do it today, since I seem
to have lost any "getting started" documentation that came with the
compiler. I suppose, if I had to, I would try by starting with
SETUP.EXE on the first distribution diskette, telling it to load the
BINP directory as well as the others. (A small test this morning
indicated that SETUP would run in a VDM.) My installation includes both
the BINP directory (protected-mode files containing, among other things,
some necessary OS/2 DLLs) as well as the BINB directory (bound
executables that run in either mode). For example, the version of
LINK.EXE as found in BINB will run in either an OS/2 command-line window
or a DOS window, under OS/2. I compile only in "stand-alone" mode (/O
switch on the command line), and when I wish to compile a program that
runs in a VDM (real mode) I must use the command-line switch /LR. I
gather from the "Programming Guide" manual that if I were running the
compiler in DOS mode, I would have to use the /LP (protected mode)
switch to produce a 16-bit "native OS/2" executable program.
Regards,
--Murray
<Team PL/I>
___
* MR/2 2.25 #120 * Never send a PM program to do a text-mode job
--- Maximus/2 2.02
* Origin: OS/2 Shareware BBS, telnet://bbs.os2bbs.com (1:109/347)
+----------------------------------------------------------------------------+
+============================================================================+