comp.os.os2.programmer.misc (Usenet) Saturday, 06-Nov-1999 to Friday, 12-Nov-1999 +----------------------------------------------------------------------------+ From: none@none.net 06-Nov-99 08:44:26 To: All 06-Nov-99 05:25:28 Subj: EARN $1000 TO $5000 WEEKLY!!! 4932 From: none@none.net FINALLY!!! A SIMPLE ONLINE SYSTEM FOR MAKING FAST, EASY, MONEY THAT LASTS !!! A TOTAL NO-BRAINER THAT ANYONE IN THE WORLD CAN DO !!! Go to: http://opportunity.valuenetusa.com/JL2836/ AND GET STARTED TODAY !!! zpgcvnmuscpeoxdwbshcsjszolyetygsrixbhjmikbocsynzpmvxnrhlodtbzhblp --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: AT&T WorldNet Services (1:109/42) +----------------------------------------------------------------------------+ From: mc6530@mclink.it 06-Nov-99 13:50:12 To: All 06-Nov-99 14:36:00 Subj: Re: Max file handles for processes From: mc6530@mclink.it (Yuri Dario) On Fri, 5 Nov 1999 08:32:50, Carsten Thorenz wrote: > Look at the value of "files=xxx" in your config.sys. it should affect only DOS sessions, not OS/2 handles. Bye, Yuri Dario /* * member of TeamOS/2 - Italy * http://www.quasarbbs.com/yuri */ --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: MC-link The World On Line (1:109/42) +----------------------------------------------------------------------------+ From: eric.olson@sympatico.ca 06-Nov-99 21:24:04 To: All 06-Nov-99 20:02:25 Subj: Re: !How get `font size` list inside WPS extension code ? From: eric.olson@sympatico.ca (Eric Olson) On Fri, 5 Nov 1999 21:53:53, Peter Fitzsimons wrote: > GpiQueryFonts(). This will show the screen fonts. Run it like this "sf > >log", then look at the file "log". > > [--- snip: sf.c ----] > > // compile: icc /Q /Smes /W3 /Kb+ /O sf.c /B"/pm:pm" Hi, here is a hack if you would like the sample to work with gcc add the following line: #define INCL_DOS before the line #include and in main after ---- long i, p --- add PTIB thread_block; PPIB process_block; DosGetInfoBlocks( &thread_block, &process_block ); process_block->pib_ultype = 3; You can then compile with gcc -o sf.exe sf.c and run in the same way sf >log Cheers, Eric --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Sympatico (1:109/42) +----------------------------------------------------------------------------+ From: pfitz@ican.net 07-Nov-99 03:58:06 To: All 07-Nov-99 03:28:17 Subj: Re: Patch help From: Peter Fitzsimons John Poltorak wrote: > > I'm trying to build wget.exe by applying the patch from the OS/2 version > to the original source, but I can't get patch (GNU Patch 2.5.4) to work. > > Can some help out with the syntax? > > I'm trying apply the patch using wget-1.5.3-os2.diff from c:\test\wget\os2 > to the source which is in c:\test\wget\wget-1.5.3\src. > Can't help you there, but I do have an os/2 wget.exe (1.4.5) if you want it. --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: @Home Network Canada (1:109/42) +----------------------------------------------------------------------------+ From: Juergen.Dankoweit@T-Online.de 07-Nov-99 10:50:22 To: All 07-Nov-99 05:18:09 Subj: Killing the WPS From: Juergen Dankoweit Hello. I have a great problem in killing the WPS: I use a daemon-program to start the WPS. In this daemon I have thread that starts the WPS via DosStartSession() - which works great - and then waits on DosReadQueue() until the WPS ends. I also use an exception-handler that reacts on DosKillProcess(). In this handler the program waits until the thread with DosReadQueue() ends. My problem is that DosKillProcess() cannot always kill the WPS. Especially then when I use the WPS (opening folders and so on). Does anyone have an idea what to do that the WPS can be killed always? I have an other question: How do I register fonts globally in the system? Are there any API-calls? Many thanks Jrgen Dankoweit ============================================= Juergen Dankoweit TeamOS/2-Member #1086 URL: home.t-online.de/home/Juergen.Dankoweit >> OS/2... it's cool men! << --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: T-Online (1:109/42) +----------------------------------------------------------------------------+ From: jpolt@bradnet.legend.co.uk 07-Nov-99 10:47:23 To: All 07-Nov-99 10:20:14 Subj: Re: Patch help From: jpolt@bradnet.legend.co.uk (John Poltorak) In <3824F8D7.4E64@ican.net>, Peter Fitzsimons writes: >John Poltorak wrote: >> >> I'm trying to build wget.exe by applying the patch from the OS/2 version >> to the original source, but I can't get patch (GNU Patch 2.5.4) to work. >> >> Can some help out with the syntax? >> >> I'm trying apply the patch using wget-1.5.3-os2.diff from c:\test\wget\os2 >> to the source which is in c:\test\wget\wget-1.5.3\src. >> > >Can't help you there, but I do have an os/2 wget.exe (1.4.5) if you want >it. It's OK Peter, I already have 1.5.3. It's just that one of the default locations for .wgetrc is C:\TCPIP\ETC, whereas I'd prefer to use %ETC%. -- John --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Legend Internet Ltd (1:109/42) +----------------------------------------------------------------------------+ From: Cpt.Viper@gmx.net 07-Nov-99 14:11:16 To: All 07-Nov-99 15:15:21 Subj: Re: Detecting MMX processor From: Cpt.Viper@gmx.net (Martin Schuette) NOSPAM_R.Ihle@S-t.De (Ruediger Ihle) wrote : > How does an OS/2 app check, that it runs on an MMX-like > processor in order to take advantage of some new instructions ? By using CPUID and testing the appropriate bit in EAX. -- Martin "It is better to die on your feet than to live on your knees." --- WtrGate+ v0.93.p7 sn 165 * Origin: Origin Line 1 Goes Here (1:109/42) +----------------------------------------------------------------------------+ From: mc6530@mclink.it 07-Nov-99 15:53:15 To: All 07-Nov-99 15:15:21 Subj: Re: Max file handles for processes From: mc6530@mclink.it (Yuri Dario) Hi, > From UNDOC.INF somewhere out on the net (Hobbes ?): > > SHELLHANDLESINC= - This environment variable increments the number of file that's worked. Thanks for help. Bye, Yuri Dario /* * member of TeamOS/2 - Italy * http://www.quasarbbs.com/yuri */ --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: MC-link The World On Line (1:109/42) +----------------------------------------------------------------------------+ From: Johannes.Hromadka@gmx.net 04-Nov-99 22:00:18 To: All 07-Nov-99 15:15:21 Subj: Re: Max file handles for processes From: Hannes Hromadka Hi, > E.g. simply running the following loop > > i = 0; > do { > printf( "try %d\n", i); > fp = fopen( "dummy.txt", "r"); > i++; > } while( fp); > > will open only 10 files when using gcc (without EMXOPT=-hxxx). With > VAC++ the runtime allocates free handles when needed (probably calling > DosSetMaxFH). > > There is a way to raise this limit with a system-wide change? I need > it because I have a couple of programs running out of handles and I > can't recompile them. Try SET EMXOPT=-c -n -h1024 this opens 1028 files before it stops on WSeB Compiling this code with VaCPP seems to produce a program with no limit on file handles. I stopped the test at more than 9000 open files It used a lot of memory: Here is the output of Theseus/2 Memory Utilization for Process with PID = 0197, name = 'TEST': bytes bytes number bytes bytes bytes allocated committed present each present swapped description 0000075C 0000075C 1 075C 0000075C 00000000 PTDA 000002F4 000002F4 1 02F4 000002F4 00000000 TCB 00001000 00001000 1 1000 00001000 00000000 TSD 00010000 00009000 7 1000 00007000 00002000 LDT 000001E0 000001E0 480 01E0 000001E0 00000000 Process Page Directory 00078000 00027000 39 1000 00027000 00000000 Page Tables 05330000 018ED000 987 1000 003DB000 01130000 Accessible Shared memory 01360000 00021000 11 1000 0000B000 00000000 Originated Shared memory 02870000 0278A000 7311 1000 01C8F000 00977000 Private memory 00089C30 00031C30 0002FC30 00002000 Total System 01360000 00021000 0000B000 00000000 Total Shared originated 02870000 0278A000 01C8F000 00977000 Total Private -------- -------- -------- -------- 03C59C30 027DCC30 01CC9C30 00979000 Total RAM/SWAPPER for this Process 61799 40819 29479 9700 (in Kbytes) 60.351 39.863 28.789 9.473 (in Mbytes) < End of THESEUS3 (v 3.000.00) output @ 21:57:05 on 4.11.1999 > ---- General Information about the Process with PID = 0197, name = 'TEST': PTDA address = FF1C52FC Threads for this Process: ---- priority ---- TID Th_# TCB TSD class level actual state 0001 007B FA590574 F9C7A000 02 00 0001 0002 Blocked Exit List: Class RtnAddress Description 0010 FDFF:57B6 PMVIOP #0001 (shared code) 0010 1F5C1BE0 GRE2VMAN #0001 (shared code) 0010 1E9845C8 PMMERGE #0004 (shared code) 0010 F40F:85E4 PMMERGE #0002 (shared code) 00B0 E027:3118 DOSCALL1 #0004 (shared code) 00C0 E027:50F8 DOSCALL1 #0004 (shared code) 0100 1E8E58D0 PMMERGE #0004 (shared code) 01A2 FDFF:56C6 PMVIOP #0001 (shared code) 01A5 1E984CCC PMMERGE #0004 (shared code) 01AB 1E86D968 PMMERGE #0004 (shared code) 01AB F407:16CA PMMERGE #0001 (shared code) 01AB 1E887530 PMMERGE #0004 (shared code) 01AD 1F5C1BD0 GRE2VMAN #0001 (shared code) 01B0 E027:3118 DOSCALL1 #0004 (shared code) 01C0 E027:B674 DOSCALL1 #0004 (shared code) 01C0 E027:5105 DOSCALL1 #0004 (shared code) 01F0 1F784D88 VIDEOPMI #0002 (shared code) 01FF 000140AC TEST #0001 (shared code) Open Files (MaxFH=9128): ---- handles --- Process System Flags File name // Flags... 0000 004F 08 \DEV\CON // console 0001 004F 08 \DEV\CON // console 0002 004F 08 \DEV\CON // console 0003 0147 41 E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT // no_inherit fail_if_error 0004 006E 08 \DEV\KBD$ // console 0005 0138 41 E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT // no_inherit fail_if_error 0006 0132 41 E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT // no_inherit fail_if_error 0007 0145 41 E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT // no_inherit fail_if_error 0008 0043 00 \DEV\OEMHLP$ // 0009 0146 41 E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT // no_inherit fail_if_error 000A 017D 41 E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT // no_inherit fail_if_error 000B 0041 00 \DEV\LANMSG$$ // 000C 0143 41 E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT // no_inherit fail_if_error 000D 0163 41 E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT // no_inherit fail_if_error 000E 0172 41 E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT // no_inherit fail_if_error 000F 014F 41 E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT // no_inherit fail_if_error 0010 0186 41 E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT // no_inherit fail_if_error Hannes --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Global Network Services - Remote Access Mail & Ne (1:109/42) +----------------------------------------------------------------------------+ From: Johannes.Hromadka@gmx.net 07-Nov-99 18:09:18 To: All 07-Nov-99 15:15:21 Subj: Re: Max file handles for processes From: Hannes Hromadka Hi, > E.g. simply running the following loop > > i = 0; > do { > printf( "try %d\n", i); > fp = fopen( "dummy.txt", "r"); > i++; > } while( fp); > > will open only 10 files when using gcc (without EMXOPT=-hxxx). With > VAC++ the runtime allocates free handles when needed (probably calling > DosSetMaxFH). > > There is a way to raise this limit with a system-wide change? I need > it because I have a couple of programs running out of handles and I > can't recompile them. Try SET EMXOPT=-c -n -h1024 this opens 1028 files before it stops on WSeB Compiling this code with VaCPP seems to produce a program with no limit on file handles. I stopped the test at more than 9000 open files It used a lot of memory: Here is the output of Theseus/2 Memory Utilization for Process with PID = 0197, name = 'TEST': bytes bytes number bytes bytes bytes allocated committed present each present swapped description 0000075C 0000075C 1 075C 0000075C 00000000 PTDA 000002F4 000002F4 1 02F4 000002F4 00000000 TCB 00001000 00001000 1 1000 00001000 00000000 TSD 00010000 00009000 7 1000 00007000 00002000 LDT 000001E0 000001E0 480 01E0 000001E0 00000000 Process Page Directory 00078000 00027000 39 1000 00027000 00000000 Page Tables 05330000 018ED000 987 1000 003DB000 01130000 Accessible Shared memory 01360000 00021000 11 1000 0000B000 00000000 Originated Shared memory 02870000 0278A000 7311 1000 01C8F000 00977000 Private memory 00089C30 00031C30 0002FC30 00002000 Total System 01360000 00021000 0000B000 00000000 Total Shared originated 02870000 0278A000 01C8F000 00977000 Total Private -------- -------- -------- -------- 03C59C30 027DCC30 01CC9C30 00979000 Total RAM/SWAPPER for this Process 61799 40819 29479 9700 (in Kbytes) 60.351 39.863 28.789 9.473 (in Mbytes) < End of THESEUS3 (v 3.000.00) output @ 21:57:05 on 4.11.1999 > ---- General Information about the Process with PID = 0197, name = 'TEST': PTDA address = FF1C52FC Threads for this Process: ---- priority ---- TID Th_# TCB TSD class level actual state 0001 007B FA590574 F9C7A000 02 00 0001 0002 Blocked Exit List: Class RtnAddress Description 0010 FDFF:57B6 PMVIOP #0001 (shared code) 0010 1F5C1BE0 GRE2VMAN #0001 (shared code) 0010 1E9845C8 PMMERGE #0004 (shared code) 0010 F40F:85E4 PMMERGE #0002 (shared code) 00B0 E027:3118 DOSCALL1 #0004 (shared code) 00C0 E027:50F8 DOSCALL1 #0004 (shared code) 0100 1E8E58D0 PMMERGE #0004 (shared code) 01A2 FDFF:56C6 PMVIOP #0001 (shared code) 01A5 1E984CCC PMMERGE #0004 (shared code) 01AB 1E86D968 PMMERGE #0004 (shared code) 01AB F407:16CA PMMERGE #0001 (shared code) 01AB 1E887530 PMMERGE #0004 (shared code) 01AD 1F5C1BD0 GRE2VMAN #0001 (shared code) 01B0 E027:3118 DOSCALL1 #0004 (shared code) 01C0 E027:B674 DOSCALL1 #0004 (shared code) 01C0 E027:5105 DOSCALL1 #0004 (shared code) 01F0 1F784D88 VIDEOPMI #0002 (shared code) 01FF 000140AC TEST #0001 (shared code) Open Files (MaxFH=9128): ---- handles --- Process System Flags File name // Flags... 0000 004F 08 \DEV\CON // console 0001 004F 08 \DEV\CON // console 0002 004F 08 \DEV\CON // console 0003 0147 41 E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT // no_inherit fail_if_error 0004 006E 08 \DEV\KBD$ // console 0005 0138 41 E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT // no_inherit fail_if_error 0006 0132 41 E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT // no_inherit fail_if_error 0007 0145 41 E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT // no_inherit fail_if_error 0008 0043 00 \DEV\OEMHLP$ // 0009 0146 41 E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT // no_inherit fail_if_error 000A 017D 41 E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT // no_inherit fail_if_error 000B 0041 00 \DEV\LANMSG$$ // 000C 0143 41 E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT // no_inherit fail_if_error 000D 0163 41 E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT // no_inherit fail_if_error 000E 0172 41 E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT // no_inherit fail_if_error 000F 014F 41 E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT // no_inheritX-Mozilla-Status: 0009010 0186 41 E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT // no_inherit fail_if_error Hannes --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Global Network Services - Remote Access Mail & Ne (1:109/42) +----------------------------------------------------------------------------+ From: mamodeo@stny.rr.com 07-Nov-99 14:08:27 To: All 07-Nov-99 15:15:22 Subj: Re: Detecting MMX processor From: Marty Martin Schuette wrote: > > NOSPAM_R.Ihle@S-t.De (Ruediger Ihle) wrote : > > > How does an OS/2 app check, that it runs on an MMX-like > > processor in order to take advantage of some new instructions ? > > By using CPUID and testing the appropriate bit in EAX. That only works on Pentium class machines or higher. It may be an illegal instruction on a 486 or less. - Marty --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Time Warner Road Runner - Binghamton NY (1:109/42) +----------------------------------------------------------------------------+ From: tsipple@us.iNoSPAMbm.com 07-Nov-99 18:43:18 To: All 07-Nov-99 21:28:08 Subj: Info: Java Media Framework 2.0 Beta 2 From: Timothy Sipples Sun and IBM have released the Java Media Framework Version 2.0 Beta 2. It is available in a pure Java(TM) cross-platform version (compatible with OS/2 Warp). Visit: http://java.sun.com/products/java-media/jmf for more information and/or to download. What's most interesting about this release is the file formats supported for playback, including: - Macromedia Flash 2 - Apple Quicktime (with certain CODECs, such as Cinepak) - MP2 and MP3 Audio - many more In other words, using the Java Media Framework it should be relatively easy to create a "native" Flash plug-in for OS/2 Warp's Netscape Communicator. Has anybody tried this out yet? -- Timothy Sipples IBM Network Computing Software Chicago, Illinois Web: http://www.satdirect.com/aviation --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: IBM Network Computing Software (Chicago) (1:109/42) +----------------------------------------------------------------------------+ From: thorenz@hydromech.uni-hannover.de 08-Nov-99 09:54:23 To: All 08-Nov-99 05:18:18 Subj: Re: Max file handles for processes From: Carsten Thorenz Peter Fitzsimons wrote: > > Carsten Thorenz wrote: > > That's for DOS programs only. Yuck, really. Anyhow I don't know why I can open about 95 files right now. I suggested it was because of the "files" entry ... Bye, Carsten -- Carsten Thorenz Institut fuer Stroemungsmechanik und elektronisches Rechnen im Bauwesen thorenz@hydromech.uni-hannover.de http://www.hydromech.uni-hannover.de/w3-pages-thorenz/thorenz.html --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: RRZN - Newsserver Test (1:109/42) +----------------------------------------------------------------------------+ From: NOSPAM_R.Ihle@S-t.De 08-Nov-99 10:56:21 To: All 08-Nov-99 10:31:26 Subj: Re: Detecting MMX processor From: NOSPAM_R.Ihle@S-t.De (Ruediger Ihle) On Sun, 7 Nov 1999 19:08:55, Marty wrote: > Martin Schuette wrote: > > > > NOSPAM_R.Ihle@S-t.De (Ruediger Ihle) wrote : > > > > > How does an OS/2 app check, that it runs on an MMX-like > > > processor in order to take advantage of some new instructions ? > > > > By using CPUID and testing the appropriate bit in EAX. > > That only works on Pentium class machines or higher. It may be an illegal > instruction on a 486 or less. That's what I was suspecting. To avoid additional CPU detection (and the risk of failing to correctly accomplish this) the exception handler method seems to me most reasonable. Thanks guys -- Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany] http://www.s-t.de Please remove all characters left of the "R" in my email address --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: S&T (1:109/42) +----------------------------------------------------------------------------+ From: bborisov@NOOOSPAMM.teklogix.com 08-Nov-99 14:45:18 To: All 08-Nov-99 20:06:28 Subj: TCP/IP 4.2 Routing table mbufs leak? From: Boris Borissov Hi everybody, Is it a known problem: when a task is trying to reach a destination, but can't do it, then frees and re-allocates a socket and tries again, each attempt cause 2 additional mbufs (see netstat -m) allocated and never freed? Similar problem was fixed in IC18283, but I wonder if it was included in any 86XXX. Boris. --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Teklogix Inc. (1:109/42) +----------------------------------------------------------------------------+ From: lpino@dcc.uchile.cl 08-Nov-99 20:43:29 To: All 08-Nov-99 21:19:01 Subj: Re: WSeb and LDGW and NDS From: Leonardo Pino Werlinger There is a way to attach securyty using realms under WebSphere, at least for Windows. The way you do it is you set Users, Groups and ACLs, after that you use a resource to be protected that means a file or a CGI, servlet ...etc. I don't know if you will be able to see the way Netware uses the security but maybe you could simulate something like a realm under Netware and maybe Websphere will list it, all of this under OS/2 of course. Give it a try. Leonardo Pino Charles Christacopoulos escribi¢: > Hi, > > I would appreciate any pointers, tips, ideas (whatever) to the > following. > > We are primarily a Netware/Solaris house, apart from me being odd with > OS/2. > I run WSeB and Lotus Domino Go web server(s) to provide the www intranet > at our institution. > > Without gettting into any detail, LDGW can call an external program to > validate users when they try to get www "protected" files. I would > like to "one day" have such an external program that would actually > validate users against Netware's NDS tree (thus users would in effect > use the same ID and password for Netware and for viewing files on the > www). > > Where do I start looking for a solution? > Will the LDAP kit that comes with WSeB allow me to do anything like it? > Can it be done? > Has anyone got it (we would be willing to pay :-) ? > > TIA. > Regards > Charles > > Remove REMOVE_ME to reply. > ------------------------------------------------------------------- > Charles Christacopoulos, Secretary's Office, University of Dundee, > Dundee DD1 4HN, (Scotland) United Kingdom. > Tel: +44+(0)1382-344891. Fax: +44+(0)1382-201604. > http://somis.ais.dundee.ac.uk/ (runs on OS/2) > Scottish Search Maestro http://somis2.ais.dundee.ac.uk/ (runs on OS/2 > too) --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: DCC - Universidad de Chile (1:109/42) +----------------------------------------------------------------------------+ From: mads@troest.NEVERMORE.dk 09-Nov-99 00:36:16 To: All 08-Nov-99 21:19:01 Subj: Re: Detecting MMX processor From: mads@troest.NEVERMORE.dk (Mads Orbesen Troest) On Mon, 8 Nov 1999 10:56:42, NOSPAM_R.Ihle@S-t.De (Ruediger Ihle) wrote: > That's what I was suspecting. To avoid additional CPU detection (and the > risk of failing to correctly accomplish this) the exception handler .. or simply make sure it is a >= Pentium processor before using the cpuid method. MMX extensions do not exist for processors below Pentium. These were the incoherent ramblings of ... ... /\/\\ads Orbesen Troest [http://www.sprog.auc.dk/~motr96] (Please remove NEVERMORE from address when replying via email...) --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: SIRIUS Cybernetics (1:109/42) +----------------------------------------------------------------------------+ From: mamodeo@stny.rr.com 08-Nov-99 20:58:20 To: All 09-Nov-99 03:31:28 Subj: Re: Detecting MMX processor From: Marty Mads Orbesen Troest wrote: > > On Mon, 8 Nov 1999 10:56:42, NOSPAM_R.Ihle@S-t.De (Ruediger Ihle) > wrote: > > > That's what I was suspecting. To avoid additional CPU detection (and the > > risk of failing to correctly accomplish this) the exception handler > > .. or simply make sure it is a >= Pentium processor before using the > cpuid method. MMX extensions do not exist for processors below > Pentium. Not good enough, as some Pentium's don't recognize the instruction either. - Marty --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Time Warner Road Runner - Binghamton NY (1:109/42) +----------------------------------------------------------------------------+ From: jstucklex@attglobal.net 09-Nov-99 12:42:00 To: All 09-Nov-99 15:59:29 Subj: Re: VAC++ debugger storage monitor: how to search for specific data? From: Jerry Stuckle Arie, Sorry, you can't search for specific data - I assume part of the reason could be that memory is not necessarily contiguous in OS/2, even with virtual addresses. A trick I've used quite often is to set a pointer to the data I want to monitor, then stop when the pointer is set. This will give me the address of the data, and I can then set a breakpoint on the change. Arie Kazachin wrote: > > Hello! > > I'm attempting to run some program from the debugger found in > VAC++ 3.0. In the "storage" monitor window, there is no option > to search for a specific data, there is only address which I can > enter for the window to scroll to. I need to find some known data > (a string) and to set a breakpoint when it'll be changed. But I don't > know, how to find an address of a known data: I can't find such a > trivial option as "search for ..." that is found in many other debuggers. > It's almost unthinkable that such a trivial option doesn't exists in > VAC++ debugger. Maybe I'm missing something obvious? > > THANKS IN ADVANCE FOR ANY HELP ! ! ! > ****************************************************************************** > * Arie Kazachin, Israel, e-mail: ariek@attglobal3.14159265358979323846.net * > ****************************************************************************** > NOTE: before replying, leave only letters in my domain-name. Sorry, SPAM trap. -- ======================================================= To reply, delete the "x" from my email address Jerry Stuckle jstucklex@attglobal.net JDS Computer Training Corp. Sun Certified Java Programmer VisualAge/Java Certified Advanced Technical Expert VisualAge/C++ Certified Developer ======================================================= --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: JDS Computer Training Corp. (1:109/42) +----------------------------------------------------------------------------+ From: kh@no.spam.munot.demon.co.uk 09-Nov-99 21:58:28 To: All 09-Nov-99 20:25:15 Subj: SYS_DLLS and superclassing native controls From: kh@no.spam.munot.demon.co.uk (Kevin) I have a massive PM application with hundreds and hundreds of entry fields. It is used on 21 inch montiors and users are complaining that they can't see the entry field cursor on the large screens. Subclassing entry fields is not an option in this environment. So I thought I could superclass WC_ENTRYFIELD. I have created a DLL with an initialisation routine that attempts to get the class info for WC_ENTRYFIELD, store the address of the window proc and register a CS_PUBLIC control called WC_ENTRYFIELD. The intention is that when it receives the focus it can call the original WC_ENTRYFIELD wnd proc and then create a new cursor that is more visible. I list my DLL in SYS_DLLS->LoadEachProcess (or whatever it's called). The DLL loads and executes its initialisation. WinQueryClassInfo gets TRUE for WC_ENTRYFIELD. WinRegisterClass for WC_ENTRYFIELD with CS_PUBLIC gets FALSE. But after re-booting, any window with an entry field traps. This tends to indicate that my wndproc is being called, even though I got FALSE on the register. I wonder if the address returned by WinQueryClassInfo is valid in all the other processes. I believe from a search on DEJA that Rich Walsh has done this kind of thing before. What I want to do is register my own wndproc for all WC_ENTRYFIELD controls created and create a different cursor every time an entry field gets the focus. What am I doing wrong? Anything that requires all of the definitions of entry fields to be changed is out of the question. If this isn't possible, I have to tell the users to just live with it. If they want something else they should call IBM OS/2 support! I thought I was the only one still doing real OS/2 apps. I think I know OS/2 pretty well. Rich, where are you? Please help... Kevin Hawkins PMSC onsite at Norwich Union in the UK email: kevin at munot dot demon dot co dot uk. --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Organization (1:109/42) +----------------------------------------------------------------------------+ From: pfitz@ican.net 10-Nov-99 06:30:14 To: All 10-Nov-99 05:30:18 Subj: Re: SYS_DLLS and superclassing native controls From: Peter Fitzsimons > I list my DLL in SYS_DLLS->LoadEachProcess (or whatever it's called). > The DLL loads and executes its initialisation. WinQueryClassInfo gets > TRUE for WC_ENTRYFIELD. WinRegisterClass for WC_ENTRYFIELD with > CS_PUBLIC gets FALSE. But after re-booting, any window with an entry > field traps. This tends to indicate that my wndproc is being called, How are you defining your data segments? ie:"single shared", or what? If you are loading anything (like a pointer/icon/bmp) you have to do it for each app, which probably forces you do use an "initinstance multiple nonshared" dll. So keep your data segment size down, and try to compile /Rn. I have code that subclasses the titlebar for every app with a sys_dll "load once" entry. It installs a msg hook, that looks for WM_CREATE messages; if the window is what I'm looking for, then I subclass it "live". I'm a resource freak and the thought of "loadperprocess" and "mutliple data" offended me at the time (1995, when I only had 24mb of memory I think :). Anyway, you're welcome to the code if you like. --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: @Home Network Canada (1:109/42) +----------------------------------------------------------------------------+ From: Vitus_Jensen@teaparty.fido.de 10-Nov-99 01:42:28 To: All 10-Nov-99 10:29:14 Subj: WSeb and LDGW and NDS From: Vitus_Jensen@teaparty.fido.de (Vitus Jensen) Hello Charles, 08.11.99 18:18, Charles Christacopoulos wrote a message to All : CC> I would appreciate any pointers, tips, ideas (whatever) to the CC> following. CC> We are primarily a Netware/Solaris house, apart from me being odd CC> with OS/2. I run WSeB and Lotus Domino Go web server(s) to CC> provide the www intranet at our institution. CC> Without gettting into any detail, LDGW can call an external CC> program to validate users when they try to get www "protected" CC> files. I would like to "one day" have such an external program CC> that would actually validate users against Netware's NDS tree CC> (thus users would in effect use the same ID and password for CC> Netware and for viewing files on the www). CC> Where do I start looking for a solution? To write a program using the NDS for user validation you need the "Client SDK" for OS/2 from Novell. When I was doing such things (over 4 years ago) it was sold, documentation only readable from WinOS/2. There are a lot of 16 bit functions you may call but to decide which function is used for what purpose isn't simple. CC> Will the LDAP kit that comes with WSeB allow me to do anything CC> like it? Can it be done? Has anyone got it (we would be willing CC> to pay :-) ? If you can manage to synchronize the LAN Server domain with the NDS you would have a much simpler task: just call Net[32]UserValidate(). The server (and requester?) package contains INF, header, lib and samples how to do this. Look for x:\IBMLAN\NETSRC (don't remember the installation option, sorry). C-x C-s Vitus --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Fido.DE domain gateway (Moving Bits e.V. / IN e.V (1:109/42) +----------------------------------------------------------------------------+ From: mikefry@iafrica.nospam.com 10-Nov-99 10:45:22 To: All 10-Nov-99 10:29:14 Subj: XCPT_SPACE_ACCESS Violation in DOSCALL1 From: mikefry@iafrica.nospam.com (Mike Fry) Could someone help me with this entry from the POPUPLOG.OS2 on a Warp 4, FP12 machine? Unfortunately, I didn't write the offending program (it's in 16-bit COBOL of all things), but I have written a lot of underlying routines (Watcom C) that live in DLLs, along with various service programs. All C code is 32-bit. The DLLs used by the COBOL program have equivalent 16-bit and 32-bit entry points (Watcom is good for this sort of thunking ). 11-05-1999 14:30:29 SYS3171 PID 0029 TID 0001 Slot 0053 C:\DLRC\MCHOTB04.EXE c0000005 1bfa0184 P1=00000008 P2=00000134 P3=XXXXXXXX P4=XXXXXXXX EAX=00000079 EBX=000047fc ECX=0000001f EDX=0000eb84 ESI=00002590 EDI=00002800 DS=a447 DSACC=00f3 DSLIM=000047ff ES=a44f ESACC=00f3 ESLIM=00001aef FS=150b FSACC=00f3 FSLIM=00000030 GS=0000 GSACC=**** GSLIM=******** CS:EIP=dfd7:00000184 CSACC=00df CSLIM=0000dc08 SS:ESP=0137:000009f2 SSACC=**** SSLIM=******** EBP=000009f2 FLG=00012202 DOSCALL1.DLL 0003:00000184 I don't really understand the SYS3171 - exception within exception. As far as I know, my DLLs don't use exception handlers apart from what the CRT installs. Is it possible to determine which routine in DOSCALL1.DLL this trap actually occurred in? My suspicion is that this is some kind of application-caused memory leak. Examination of the C & COBOL source code shows that tiled memory objects are being allocated by DosAllocSharedMem in one of my service EXEs and passed to the COBOL program, via a queue, after doing a DosGiveSharedMem to give the COBOL program read/write permission. The service EXE then does a DosFreeMem. At some stage on the COBOL side, an apparently unnecessary DosGetSeg (16-bit remember) is being done. I say unnecessary because the program already has read/write access to the object thru the DosGiveSharedMem call. I can only find a single DosFreeSeg in the COBOL code. Am I right in thinking that OS/2 is unable to 'physically' free the memory objects because of a non-zero reference count? And that over time, OS/2 will actually 'run out' of memory? To me, this is a fairly straight-forward XCPT_ACCESS_VIOLATION. According to my toolkit headers, the P1 value indicates XCPT_SPACE_ACCESS and P2 the selector involved. If OS/2 has actually run out of selectors because of the unnecessary DosGetSeg (missing DosFreeSeg), then I would have expected to find P1 to indicate XCPT_LIMIT_ACCESS. I can't find any explanation in my documentation of what these two access violation codes mean in real terms. Can anybody explain the difference between XCPT_SPACE_ACCESS and XCPT_LIMIT_ACCESS? Does my description of the memory object usage make sense in terms of the trap information that I have supplied? Thanks for listening, MIKE FRY mailto:mikefry@iafrica.com --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: UUNET Internet Africa (1:109/42) +----------------------------------------------------------------------------+ From: yourself@127.0.0.1 10-Nov-99 11:00:29 To: All 10-Nov-99 10:29:15 Subj: Re: SYS_DLLS and superclassing native controls From: yourself@127.0.0.1 (Rich Walsh) On Tue, 9 Nov 1999 21:58:56, kh@no.spam.munot.demon.co.uk (Kevin) wrote: > I have a massive PM application with hundreds and hundreds of entry > fields. It is used on 21 inch montiors and users are complaining that > they can't see the entry field cursor on the large screens. > Subclassing entry fields is not an option in this environment. So I > thought I could superclass WC_ENTRYFIELD. I have created a DLL with an > initialisation routine that attempts to get the class info for > WC_ENTRYFIELD, store the address of the window proc and register a > CS_PUBLIC control called WC_ENTRYFIELD. The intention is that when it > receives the focus it can call the original WC_ENTRYFIELD wnd proc and > then create a new cursor that is more visible. > > I list my DLL in SYS_DLLS->LoadEachProcess (or whatever it's called). > The DLL loads and executes its initialisation. WinQueryClassInfo gets > TRUE for WC_ENTRYFIELD. WinRegisterClass for WC_ENTRYFIELD with > CS_PUBLIC gets FALSE. But after re-booting, any window with an entry > field traps. This tends to indicate that my wndproc is being called, > even though I got FALSE on the register. I wonder if the address > returned by WinQueryClassInfo is valid in all the other processes. > >I believe from a search on DEJA that Rich Walsh has done this kind of >thing before. What I want to do is register my own wndproc for all >WC_ENTRYFIELD controls created and create a different cursor every >time an entry field gets the focus. What am I doing wrong? Do you really want to modify every entryfield in the system or just the ones in your app? Either way, you'll have to deal with odd side-effects your code may have on, say, read-only comboboxes (i.e. no visible cursor). For a global replacement, the superclassing code in your DLL should only be executed once: the first time it's called, when it's operating in the shell process. You shouldn't have to change any flags. You can store the original PFN in global memory because it's valid in all PM processes. The traps you're getting now probably occur because the DLL's instance data hasn't been initialized properly (are you using INITINSTANCE and DATA MULTIPLE NONSHARED ?). Since your needs are so minimal, you may not even need a per-process data segment except to satisfy your compiler. If so, try shedding the runtime environment - or even the runtime itself (YMMV). BTW... are you aware that the function you've exported as ordinal 1 gets called every time your dll is loaded into a new process? For a process-specific solution, forget most everything I just said :-) AFAIK, you can't reregister a CS_PUBLIC class for a particular process. Instead, you can try this strategy (one of several that come to mind): identify whether the message that causes an e/f to create its cursor is posted or sent. Then use either an InputHook or a SendMsgHook on your *own* message queue (HMQ_CURRENT) to intercept it. This will let you put the code in your exe, avoid sub- or superclassing, and generally limit the damage. (IMHO, this is a good solution when you're messing with your own app, and a lousy solution when you're messing other people's.) == == almost usable email address: rlwalshATpacket.net == == ___________________________________________________________________ | - DragText v3.1 - Rich Walsh | A Distinctly Different Desktop Enhancement Ft Myers, FL | New! Pickup & Drop for text, and more... | http://www.usacomputers.net/personal/rlwalsh/ ___________________________________________________________________ --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: http://extra.newsguy.com (1:109/42) +----------------------------------------------------------------------------+ From: kh@no.spam.munot.demon.co.uk 10-Nov-99 21:28:20 To: All 10-Nov-99 20:03:07 Subj: Re: SYS_DLLS and superclassing native controls From: kh@no.spam.munot.demon.co.uk (Kevin) On 10 Nov 1999 11:00:58 GMT, yourself@127.0.0.1 (Rich Walsh) wrote: >On Tue, 9 Nov 1999 21:58:56, kh@no.spam.munot.demon.co.uk (Kevin) wrote: > >> I have a massive PM application with hundreds and hundreds of entry >> fields. It is used on 21 inch montiors and users are complaining that >> they can't see the entry field cursor on the large screens. >> Subclassing entry fields is not an option in this environment. So I >> thought I could superclass WC_ENTRYFIELD. I have created a DLL with an >> initialisation routine that attempts to get the class info for >> WC_ENTRYFIELD, store the address of the window proc and register a >> CS_PUBLIC control called WC_ENTRYFIELD. The intention is that when it >> receives the focus it can call the original WC_ENTRYFIELD wnd proc and >> then create a new cursor that is more visible. >> >> I list my DLL in SYS_DLLS->LoadEachProcess (or whatever it's called). >> The DLL loads and executes its initialisation. WinQueryClassInfo gets >> TRUE for WC_ENTRYFIELD. WinRegisterClass for WC_ENTRYFIELD with >> CS_PUBLIC gets FALSE. But after re-booting, any window with an entry >> field traps. This tends to indicate that my wndproc is being called, >> even though I got FALSE on the register. I wonder if the address >> returned by WinQueryClassInfo is valid in all the other processes. >> >>I believe from a search on DEJA that Rich Walsh has done this kind of >>thing before. What I want to do is register my own wndproc for all >>WC_ENTRYFIELD controls created and create a different cursor every >>time an entry field gets the focus. What am I doing wrong? > >Do you really want to modify every entryfield in the system or just the >ones in your app? Either way, you'll have to deal with odd side-effects >your code may have on, say, read-only comboboxes (i.e. no visible cursor). Users would be happy with every entryfield in the system. This is the only app being used, so I don't have to worry about other people's apps. Didn't thing about the comboboxes, but their entryfields are easy enough to distinguish from ordinary ones. >For a global replacement, the superclassing code in your DLL should only >be executed once: the first time it's called, when it's operating in the >shell process. You shouldn't have to change any flags. You can store >the original PFN in global memory because it's valid in all PM processes. Thanks for clearing that up. The WinRegisterClass call returns FALSE when I try to register with all the parameters from WinGetClassInfo the same except for PFNWP. Haven't done WinGetLastError here yet as I was trying Peter Fitzsimmons' idea today. Don't know if I believe the return value though because I was getting traps on anything that created an entryfield. >The traps you're getting now probably occur because the DLL's instance >data hasn't been initialized properly (are you using INITINSTANCE and >DATA MULTIPLE NONSHARED ?). Since your needs are so minimal, you may >not even need a per-process data segment except to satisfy your compiler. >If so, try shedding the runtime environment - or even the runtime itself >(YMMV). I had INITINSTANCE and DATA MULTIPLE NONSHARED in all cases. Currently using the runtime for fprintf for debugging, but will probably not use it in the end. >BTW... are you aware that the function you've exported as ordinal 1 >gets called every time your dll is loaded into a new process? Hmmm. I am exporting by names, but the first export is my initialisation function. This function does get called on load as my fprintf shows. >For a process-specific solution, forget most everything I just said :-) >AFAIK, you can't reregister a CS_PUBLIC class for a particular process. That is correct according to the documentation. >Instead, you can try this strategy (one of several that come to mind): >identify whether the message that causes an e/f to create its cursor >is posted or sent. Then use either an InputHook or a SendMsgHook on >your *own* message queue (HMQ_CURRENT) to intercept it. This will >let you put the code in your exe, avoid sub- or superclassing, and >generally limit the damage. (IMHO, this is a good solution when >you're messing with your own app, and a lousy solution when you're >messing other people's.) Have been playing with hooks today. Wanted to used Peter's suggestion to use a hook to catch all WM_CREATE messages and subclass WC_ENTRYFIELDS. Have tried all the 'message' type hooks, but so far none seem to get WM_CREATE messages. Hoping Peter's code will help here. The private hook is interesting. The entryfield has to create/destroy the cursor on one of the activate/focuschange type messages. I will look into that more tomorrow. Thanks, Kevin --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Organization (1:109/42) +----------------------------------------------------------------------------+ From: blaschke@us.ibm.com 10-Nov-99 14:15:02 To: All 10-Nov-99 20:03:07 Subj: Re: XCPT_SPACE_ACCESS Violation in DOSCALL1 From: Dave Blaschke Mike Fry wrote: Ahh, Mike Fry, the man who asked me to add yet another executable to the OS2TRACE package. Because it's you I'll try and answer correctly for a change ;-) > Could someone help me with this entry from the POPUPLOG.OS2 on a Warp 4, > FP12 machine? > > Unfortunately, I didn't write the offending program (it's in 16-bit > COBOL of all things), but I have written a lot of underlying routines > (Watcom C) that live in DLLs, along with various service programs. All C > code is 32-bit. The DLLs used by the COBOL program have equivalent > 16-bit and 32-bit entry points (Watcom is good for this sort of thunking > ). > > 11-05-1999 14:30:29 SYS3171 PID 0029 TID 0001 Slot 0053 > C:\DLRC\MCHOTB04.EXE > c0000005 > 1bfa0184 > P1=00000008 P2=00000134 P3=XXXXXXXX P4=XXXXXXXX > EAX=00000079 EBX=000047fc ECX=0000001f EDX=0000eb84 > ESI=00002590 EDI=00002800 > DS=a447 DSACC=00f3 DSLIM=000047ff > ES=a44f ESACC=00f3 ESLIM=00001aef > FS=150b FSACC=00f3 FSLIM=00000030 > GS=0000 GSACC=**** GSLIM=******** > CS:EIP=dfd7:00000184 CSACC=00df CSLIM=0000dc08 > SS:ESP=0137:000009f2 SSACC=**** SSLIM=******** > EBP=000009f2 FLG=00012202 > > DOSCALL1.DLL 0003:00000184 > > I don't really understand the SYS3171 - exception within exception. As > far as I know, my DLLs don't use exception handlers apart from what the > CRT installs. Is it possible to determine which routine in DOSCALL1.DLL > this trap actually occurred in? SYS3171 simply means that a thread did not have enough stack space available to dispatch an exception. When an exception occurs, the OS/2 kernel attempts to "push" an exception report record and context record, along with some other goodies, on top of the user's stack for the ring 3 exception dispatcher: if this fails, a SYS3171 will result. This does not necessarily mean that an exception occurred within a handler. As for the routine, you can't really figure it out without the DOSCALL1.MAP file or some debug tools that can extract the info from DOSCALL1.SYM. In this case, DOSCALL1 object 3 offset 184 is within the DOSSEMWAIT API on FP12. > > > My suspicion is that this is some kind of application-caused memory > leak. Examination of the C & COBOL source code shows that tiled memory > objects are being allocated by DosAllocSharedMem in one of my service > EXEs and passed to the COBOL program, via a queue, after doing a > DosGiveSharedMem to give the COBOL program read/write permission. The > service EXE then does a DosFreeMem. > > At some stage on the COBOL side, an apparently unnecessary DosGetSeg > (16-bit remember) is being done. I say unnecessary because the program > already has read/write access to the object thru the DosGiveSharedMem > call. I can only find a single DosFreeSeg in the COBOL code. Am I right > in thinking that OS/2 is unable to 'physically' free the memory objects > because of a non-zero reference count? And that over time, OS/2 will > actually 'run out' of memory? > > To me, this is a fairly straight-forward XCPT_ACCESS_VIOLATION. > According to my toolkit headers, the P1 value indicates > XCPT_SPACE_ACCESS and P2 the selector involved. If OS/2 has actually run > out of selectors because of the unnecessary DosGetSeg (missing > DosFreeSeg), then I would have expected to find P1 to indicate > XCPT_LIMIT_ACCESS. > > I can't find any explanation in my documentation of what these two > access violation codes mean in real terms. Can anybody explain the > difference between XCPT_SPACE_ACCESS and XCPT_LIMIT_ACCESS? Does my > description of the memory object usage make sense in terms of the trap > information that I have supplied? Both indicate that a trap C occurred. If P1 == XCPT_SPACE_ACCESS, then the trap C occurred with a non-zero error code and P2 = this error code. If P1 == XCPT_LIMIT_ACCESS, then the trap C occurred with a zero error code and P2 = XCPT_DATA_UNKNOWN. The following is from the Intel programmer's reference, where stack fault refers to trap C: A stack fault is generated under two conditions: * As a result of a limit violation in any operation which refers to the SS register. This includes stack-oriented instructions such as POP, PUSH, ENTER, and LEAVE, as well as other memory references which implicitly use the stack (for example, MOV AX,[BP+6]). The ENTER instruction generates this exception when there is too little space for allocating local variables. * When attempting to load the SS register with a descriptor which is marked segment-not-present but is otherwise valid. This can occur in a task switch, a CALL instruction ro a different privilege level, a return to a different privilege level, an LSS instruction, or a MOV or POP instruction to the SS register. When the processor detects a stack exception, it pushes an error code onto the stack of the exception handler. If the exception is due to a not-present stack segment or to overflow of the new stack during an interlevel CALL, the error code contains a selector to the segment which caused the exception (the exception handler can test the present bit in the descriptor to determine which exception occurred); otherwise, the error code is 0. > > > Thanks for listening, > MIKE FRY > mailto:mikefry@iafrica.com --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: IBM Austin (1:109/42) +----------------------------------------------------------------------------+ From: vitus.jensen@fto.de 11-Nov-99 01:47:16 To: All 10-Nov-99 20:03:07 Subj: WSeb and LDGW and NDS From: vitus.jensen@fto.de From: Vitus_Jensen@teaparty.fido.de (Vitus Jensen) Hello Charles, 08.11.99 18:18, Charles Christacopoulos wrote a message to All : CC> I would appreciate any pointers, tips, ideas (whatever) to the CC> following. CC> We are primarily a Netware/Solaris house, apart from me being odd CC> with OS/2. I run WSeB and Lotus Domino Go web server(s) to CC> provide the www intranet at our institution. CC> Without gettting into any detail, LDGW can call an external CC> program to validate users when they try to get www "protected" CC> files. I would like to "one day" have such an external program CC> that would actually validate users against Netware's NDS tree CC> (thus users would in effect use the same ID and password for CC> Netware and for viewing files on the www). CC> Where do I start looking for a solution? To write a program using the NDS for user validation you need the "Client SDK" for OS/2 from Novell. When I was doing such things (over 4 years ago) it was sold, documentation only readable from WinOS/2. There are a lot of 16 bit functions you may call but to decide which function is used for what purpose isn't simple. CC> Will the LDAP kit that comes with WSeB allow me to do anything CC> like it? Can it be done? Has anyone got it (we would be willing CC> to pay :-) ? If you can manage to synchronize the LAN Server domain with the NDS you would have a much simpler task: just call Net[32]UserValidate(). The server (and requester?) package contains INF, header, lib and samples how to do this. Look for x:\IBMLAN\NETSRC (don't remember the installation option, sorry). C-x C-s Vitus --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Skynet Titan (1:109/42) +----------------------------------------------------------------------------+ From: mike.fry@fto.de 11-Nov-99 01:47:17 To: All 10-Nov-99 20:03:07 Subj: XCPT_SPACE_ACCESS Violation in DOSCALL1 From: mike.fry@fto.de From: mikefry@iafrica.nospam.com (Mike Fry) Could someone help me with this entry from the POPUPLOG.OS2 on a Warp 4, FP12 machine? Unfortunately, I didn't write the offending program (it's in 16-bit COBOL of all things), but I have written a lot of underlying routines (Watcom C) that live in DLLs, along with various service programs. All C code is 32-bit. The DLLs used by the COBOL program have equivalent 16-bit and 32-bit entry points (Watcom is good for this sort of thunking ). 11-05-1999 14:30:29 SYS3171 PID 0029 TID 0001 Slot 0053 C:\DLRC\MCHOTB04.EXE c0000005 1bfa0184 P1=00000008 P2=00000134 P3=XXXXXXXX P4=XXXXXXXX EAX=00000079 EBX=000047fc ECX=0000001f EDX=0000eb84 ESI=00002590 EDI=00002800 DS=a447 DSACC=00f3 DSLIM=000047ff ES=a44f ESACC=00f3 ESLIM=00001aef FS=150b FSACC=00f3 FSLIM=00000030 GS=0000 GSACC=**** GSLIM=******** CS:EIP=dfd7:00000184 CSACC=00df CSLIM=0000dc08 SS:ESP=0137:000009f2 SSACC=**** SSLIM=******** EBP=000009f2 FLG=00012202 DOSCALL1.DLL 0003:00000184 I don't really understand the SYS3171 - exception within exception. As far as I know, my DLLs don't use exception handlers apart from what the CRT installs. Is it possible to determine which routine in DOSCALL1.DLL this trap actually occurred in? My suspicion is that this is some kind of application-caused memory leak. Examination of the C & COBOL source code shows that tiled memory objects are being allocated by DosAllocSharedMem in one of my service EXEs and passed to the COBOL program, via a queue, after doing a DosGiveSharedMem to give the COBOL program read/write permission. The service EXE then does a DosFreeMem. At some stage on the COBOL side, an apparently unnecessary DosGetSeg (16-bit remember) is being done. I say unnecessary because the program already has read/write access to the object thru the DosGiveSharedMem call. I can only find a single DosFreeSeg in the COBOL code. Am I right in thinking that OS/2 is unable to 'physically' free the memory objects because of a non-zero reference count? And that over time, OS/2 will actually 'run out' of memory? To me, this is a fairly straight-forward XCPT_ACCESS_VIOLATION. According to my toolkit headers, the P1 value indicates XCPT_SPACE_ACCESS and P2 the selector involved. If OS/2 has actually run out of selectors because of the unnecessary DosGetSeg (missing DosFreeSeg), then I would have expected to find P1 to indicate XCPT_LIMIT_ACCESS. I can't find any explanation in my documentation of what these two access violation codes mean in real terms. Can anybody explain the difference between XCPT_SPACE_ACCESS and XCPT_LIMIT_ACCESS? Does my description of the memory object usage make sense in terms of the trap information that I have supplied? Thanks for listening, MIKE FRY mailto:mikefry@iafrica.com --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Skynet Titan (1:109/42) +----------------------------------------------------------------------------+ From: rich.walsh@fto.de 11-Nov-99 01:47:17 To: All 10-Nov-99 20:03:07 Subj: Re: SYS_DLLS and superclassing native controls From: rich.walsh@fto.de From: yourself@127.0.0.1 (Rich Walsh) On Tue, 9 Nov 1999 21:58:56, kh@no.spam.munot.demon.co.uk (Kevin) wrote: > I have a massive PM application with hundreds and hundreds of entry > fields. It is used on 21 inch montiors and users are complaining that > they can't see the entry field cursor on the large screens. > Subclassing entry fields is not an option in this environment. So I > thought I could superclass WC_ENTRYFIELD. I have created a DLL with an > initialisation routine that attempts to get the class info for > WC_ENTRYFIELD, store the address of the window proc and register a > CS_PUBLIC control called WC_ENTRYFIELD. The intention is that when it > receives the focus it can call the original WC_ENTRYFIELD wnd proc and > then create a new cursor that is more visible. > > I list my DLL in SYS_DLLS->LoadEachProcess (or whatever it's called). > The DLL loads and executes its initialisation. WinQueryClassInfo gets > TRUE for WC_ENTRYFIELD. WinRegisterClass for WC_ENTRYFIELD with > CS_PUBLIC gets FALSE. But after re-booting, any window with an entry > field traps. This tends to indicate that my wndproc is being called, > even though I got FALSE on the register. I wonder if the address > returned by WinQueryClassInfo is valid in all the other processes. > >I believe from a search on DEJA that Rich Walsh has done this kind of >thing before. What I want to do is register my own wndproc for all >WC_ENTRYFIELD controls created and create a different cursor every >time an entry field gets the focus. What am I doing wrong? Do you really want to modify every entryfield in the system or just the ones in your app? Either way, you'll have to deal with odd side-effects your code may have on, say, read-only comboboxes (i.e. no visible cursor). For a global replacement, the superclassing code in your DLL should only be executed once: the first time it's called, when it's operating in the shell process. You shouldn't have to change any flags. You can store the original PFN in global memory because it's valid in all PM processes. The traps you're getting now probably occur because the DLL's instance data hasn't been initialized properly (are you using INITINSTANCE and DATA MULTIPLE NONSHARED ?). Since your needs are so minimal, you may not even need a per-process data segment except to satisfy your compiler. If so, try shedding the runtime environment - or even the runtime itself (YMMV). BTW... are you aware that the function you've exported as ordinal 1 gets called every time your dll is loaded into a new process? For a process-specific solution, forget most everything I just said :-) AFAIK, you can't reregister a CS_PUBLIC class for a particular process. Instead, you can try this strategy (one of several that come to mind): identify whether the message that causes an e/f to create its cursor is posted or sent. Then use either an InputHook or a SendMsgHook on your *own* message queue (HMQ_CURRENT) to intercept it. This will let you put the code in your exe, avoid sub- or superclassing, and generally limit the damage. (IMHO, this is a good solution when you're messing with your own app, and a lousy solution when you're messing other people's.) == == almost usable email address: rlwalshATpacket.net == == ___________________________________________________________________ | - DragText v3.1 - Rich Walsh | A Distinctly Different Desktop Enhancement Ft Myers, FL | New! Pickup & Drop for text, and more... | http://www.usacomputers.net/personal/rlwalsh/ ___________________________________________________________________ --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Skynet Titan (1:109/42) +----------------------------------------------------------------------------+ From: crowsort@fto.de 11-Nov-99 01:47:17 To: All 10-Nov-99 20:03:07 Subj: USE or SPY any distant PC via LAN/INTERNET From: crowsort@fto.de From: "Crowsort" USE or SPY any distant PC via LAN/INTERNET How YOU can Hack Windows 95-98-NT... in seconds! And use or spy any PC via a LAN or the Internet... as if you were there! Platforms concerned: -------------------- => Windows 95/98 => Windows NT Workstation/Server 3.5, 3.51 and 4.0 => Windows 2000 Whether you are a rookie or a seasoned hacker, there are times where you want to do something RAPIDLY. Some of us worked a lot to enhance password cracking but we have to recognize that if passwords have been carefully chosen, it still takes a lot of TIME. Others are using well-known security holes in NT but we also have to recognize that the ways to use those security breaches are not easy and it also takes TIME to understand and to implement them. There is a way to get all the passwords of *any* version of Windows INSTANTLY. There is a way to control a distant machine 'as if you were there'. Netbus and BO2K were good attempts, I used them for months, but despite of what their authors said, using it every day is difficult and frustrating enough to disgust lazy guys like me... the fact that I cannot see the distant screen in real-time is really frustrating! A friend demonstrated me RA. RA (Remote-Anything) is THE solution you were looking for: it shows in real-time the distant desktop (like PC-Anywhere and other MB-based commercial products) BUT the server (the program you install on the PC you want to control) is **80 KB** long... You can install it remotely by using the buffer overflows of Outlook Express or IE4 or simply by sending it as an Email attachment! Better than that: once installed, it does not show in the Task-List, can't be discovered or killed with CTRL-ALT-DEL! Once you poisoned PCs on a LAN, no need to remember which ones: RA is able to find automatically available PCs and displays IP addresses and DNS Names! Just click on one of them to be connected! And it is so fast that you can see any animation playing on the distant PC in real-time! All this from one unique tool... Damned, I got it! ____________________________________________________ Here are some of the functions I picked-up from RA's Doc: o Connect to a new desktop: opens the Connection Dialog Box which allows you to open a new window on a new Desktop (you can watch multiple Desktops at a time). o Monitor only: will toggle the passive-monitoring and active-control modes (active monitoring allows you to type keys and move the mouse on the distant PC while passive monitoring will only allow you to watch only). o Full screen: will enter the full-screen mode. You can exit it by typing CTRL+ESC and then right-clicking the Master's task bar icon to come back to the windowed mode. o Remove wallpaper on distant desktop: is useful to minimize the amount of data sent over the network. It always speedups a connection. o Start Screen Saver: is useful when you want to leave the desktop with a screensaver running: when Remote-Anything moves the mouse cursor on a Slave desktop, it stops the screensaver if it was running. With this option, you can immediately run the screensaver (use this option with the keyboard shortcut to avoid moving the mouse in active mode or switch to passive monitoring to activate this menu option with the mouse). If the screensaver is password protected, this is a way to lock the distant PC. o Play a Sound: will make a sound being played on the distant PC. Usually it is 'ding.wav' but it can be any sound the distant PC registered as the default sound. o Send commands: will display a Dialog Box equivalent to the Start/Run command of Windows 95. o Get Passwords of distant PC: get all the network passwords, the screensaver password, and the Applications passwords Windows has been asked to remember. o Lockup distant PC: Hangs the distant PC which will need to be restarted manually. o Reboot distant PC: will immediately send the order to reboot to the distant PC, this will disconnect you from this Desktop but you can reconnect once the distant Windows session is active again. o Shut Down distant PC: will shut down the distant PC if it supports shut down. You will be disconnected. _____________________________________________________ o How does it work? ----------------- It is as simple as using Windows 98 itself: move the mouse, type keys, the distant PC will do everything you want! It works over LANs and the Internet! o Where can I get it? ------------------- At the moment, you can get it from: http://www.twd-industries.com You'll have to pay a small fee to the authors to get RA. I can tell you that it's worth the price: I simply did things I would never have been able to do without it. If you have access to a local network, RA will allow you to do whatever you want! This tool is so easy to use that every hacker will want it. The more you wait, the less what you can do with it will remain a secret! But as time goes, I guess it will be available from a lot of other places. Have fun! §§§§§§§ §§ §§§ §§ § ~ ~ § @<¤>"<¤>@ ( ~ ) \ 'v=v' / The Crowsort is back. |\____/| _____________________________________________________ --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Skynet Titan (1:109/42) +----------------------------------------------------------------------------+ From: peter.fitzsimons@fto.de 11-Nov-99 01:47:17 To: All 10-Nov-99 20:03:07 Subj: Re: SYS_DLLS and superclassing native controls From: peter.fitzsimons@fto.de From: Peter Fitzsimons > I list my DLL in SYS_DLLS->LoadEachProcess (or whatever it's called). > The DLL loads and executes its initialisation. WinQueryClassInfo gets > TRUE for WC_ENTRYFIELD. WinRegisterClass for WC_ENTRYFIELD with > CS_PUBLIC gets FALSE. But after re-booting, any window with an entry > field traps. This tends to indicate that my wndproc is being called, How are you defining your data segments? ie:"single shared", or what? If you are loading anything (like a pointer/icon/bmp) you have to do it for each app, which probably forces you do use an "initinstance multiple nonshared" dll. So keep your data segment size down, and try to compile /Rn. I have code that subclasses the titlebar for every app with a sys_dll "load once" entry. It installs a msg hook, that looks for WM_CREATE messages; if the window is what I'm looking for, then I subclass it "live". I'm a resource freak and the thought of "loadperprocess" and "mutliple data" offended me at the time (1995, when I only had 24mb of memory I think :). Anyway, you're welcome to the code if you like. --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Skynet Titan (1:109/42) +----------------------------------------------------------------------------+ From: ariek@attglobal3.141592653589793... 10-Nov-99 23:24:17 To: All 10-Nov-99 21:35:27 Subj: Re: VAC++ debugger storage monitor: how to search for specific data? Message sender: ariek@attglobal3.14159265358979323846.net From: ariek@attglobal3.14159265358979323846.net (Arie Kazachin) In message <38285CE8.399C@attglobal.net> - Tue, 09 Nov 1999 12:42:01 -0500Jerry Stuckle writes: > >Arie, > >Sorry, you can't search for specific data - I assume part of the reason >could be that memory is not necessarily contiguous in OS/2, even with >virtual addresses. > >A trick I've used quite often is to set a pointer to the data I want to >monitor, then stop when the pointer is set. This will give me the >address of the data, and I can then set a breakpoint on the change. > Thanks, Jerry. However, this trick only works when debugging a program you write. When attempting to do this with already existing executable (and no sources), it seems I'll have to let go on tha ability to search for data (unless some developing/debugging utilities can do this). Regards, ****************************************************************************** * Arie Kazachin, Israel, e-mail: ariek@attglobal3.14159265358979323846.net * ****************************************************************************** NOTE: before replying, leave only letters in my domain-name. Sorry, SPAM trap. --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Unspecified Organization (1:109/42) +----------------------------------------------------------------------------+ From: heafnerj@interpath.com 10-Nov-99 19:03:05 To: All 10-Nov-99 21:35:27 Subj: sys/param.h and in.h on other systems From: Joe Heafner Hi. I have some software that was designed to work under EMX, DJGPP, and other systems equipped with gcc. It also compiles under VC++ on Win systems. The programs make use of the sys/param.h and in.h header files. When I attempt to compile the code under MingW32 (the Win32 port of gcc 2.9) the compiler complains about not being able to find these header files. Can anyone tell me the header files I should use under MingW23 to compile these programs? Someone else also told me that these particular header files are not part of the ANSI/ISO C standard. All I know is that ever compiler/system I've tested my software on apparently has these files and experiences no problems. The only compiler to have a problem so far is MingW32. If these files are not ANSI compliant, what are the appropriate ANSI header files to use? The software, I belive (I didn't write this particular part), uses these header files for functions needed to check and, if necessary, change byte ordering (big endian vs. little endian) in certain situations. Thanks, -- -- Joe Heafner Joe Heafner, Astronomy and Physics Instructor. Work:(828)327-7000 x4246 my surname with my first initial at interpath dot com http://home.interpath.com/heafnerj/ --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Interpath Communications, Inc. (1:109/42) +----------------------------------------------------------------------------+ From: rde@tavi.co.uk 11-Nov-99 09:28:11 To: All 11-Nov-99 10:44:24 Subj: Re: sys/param.h and in.h on other systems From: rde@tavi.co.uk (Bob Eager) On Thu, 11 Nov 1999 00:03:10, Joe Heafner wrote: > I have some software that was designed to work under EMX, DJGPP, and > other systems equipped with gcc. It also compiles under VC++ on Win > systems. The programs make use of the sys/param.h and in.h header files. > When I attempt to compile the code under MingW32 (the Win32 port of gcc > 2.9) the compiler complains about not being able to find these header > files. Where did you get the header files for the other compilers? If in a toolkit, then if MingW32 can't find them you probably have it looking in the wrong place. > Can anyone tell me the header files I should use under MingW23 to > compile these programs? The same ones you used for the others. > Someone else also told me that these particular header files are not > part of the ANSI/ISO C standard. All I know is that ever compiler/system > I've tested my software on apparently has these files and experiences no > problems. That's right. These headers are non-ANSI. The sys\param.h is essentially a kernel configuration file on UNIX systems. The occasional constant in there escapes for use by programs. The in.h (in netinet\in.h on my system) contains networking stuff. > The only compiler to have a problem so far is MingW32. Sounds like the setup. > If > these files are not ANSI compliant, what are the appropriate ANSI header > files to use? There aren't. > The software, I belive (I didn't write this particular > part), uses these header files for functions needed to check and, if > necessary, change byte ordering (big endian vs. little endian) in > certain situations. I can believe that the files you mention contain these functions. But they aren't part of ANSI. Saying that you've seen them on every system so far doesn' MAKE then suddnly ANSI. I repeat, I think the set of headers you're using with the compiler is incomplete. Or its INCLUDE environment variable isn't picking up the toolkit directory. -- Bob Eager rde at tavi.co.uk PC Server 325; PS/2s 8595*3, 9595*3 (2*P60 + P90), 8535, 8570, 9556*2, 8580*6, 8557*2, 8550, 9577, 8530, P70, PC/AT.. --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Tavi Systems (1:109/42) +----------------------------------------------------------------------------+ From: yourself@127.0.0.1 11-Nov-99 09:32:24 To: All 11-Nov-99 10:44:24 Subj: Re: SYS_DLLS and superclassing native controls From: yourself@127.0.0.1 (Rich Walsh) On Wed, 10 Nov 1999 21:28:40, kh@no.spam.munot.demon.co.uk (Kevin) wrote: > On 10 Nov 1999 11:00:58 GMT, yourself@127.0.0.1 (Rich Walsh) wrote: > >On Tue, 9 Nov 1999 21:58:56, kh@no.spam.munot.demon.co.uk (Kevin) wrote: > > > >> I have a massive PM application with hundreds and hundreds of entry > >> fields. It is used on 21 inch montiors and users are complaining that > >> they can't see the entry field cursor on the large screens. > >> Subclassing entry fields is not an option in this environment. So I > >> thought I could superclass WC_ENTRYFIELD. [big snip] > >Instead, you can try this strategy (one of several that come to mind): > >identify whether the message that causes an e/f to create its cursor > >is posted or sent. Then use either an InputHook or a SendMsgHook on > >your *own* message queue (HMQ_CURRENT) to intercept it. This will > >let you put the code in your exe, avoid sub- or superclassing, and > >generally limit the damage. (IMHO, this is a good solution when > >you're messing with your own app, and a lousy solution when you're > >messing other people's.) > > Have been playing with hooks today. Wanted to used Peter's suggestion > to use a hook to catch all WM_CREATE messages and subclass > WC_ENTRYFIELDS. Have tried all the 'message' type hooks, but so far > none seem to get WM_CREATE messages. Hoping Peter's code will help > here. > > The private hook is interesting. The entryfield has to create/destroy > the cursor on one of the activate/focuschange type messages. I will > look into that more tomorrow. DragText v1.x used the method Peter described (minus the SYS_DLLS entry). It had a flaw that you may consider a feature. Comboboxes and spinbuttons create entryfields which your code subclasses and their code then re-subclasses. They don't bother saving your PFNWP and have their subprocs call the class's base window procedure instead of yours. Unless you subclass these controls too (as DT did), your code will never be called when the entryfield is part of another control. You can do this entirely within your own app by installing a HK_SENDMSG for each thread that creates entryfields (probably only the first). This should eliminate access violations and let you retain your C runtime. Like IBM, you'll have to decide whether to discard each window's PFNWP and use the class's default. FWIW... After I posted my earlier suggestion, I realized it won't work if you have to use a HK_SENDMSG. You want to create a cursor after an e/f has handled a particular message but this hook gives you no way to do so and no way to keep the message from being passed on (with a HK_INPUT, your hook could dispatch the message itself, do its thing on return, then terminate further processing). Sorry 'bout that... == == almost usable email address: rlwalshATpacket.net == == ___________________________________________________________________ | - DragText v3.1 - Rich Walsh | A Distinctly Different Desktop Enhancement Ft Myers, FL | New! Pickup & Drop for text, and more... | http://www.usacomputers.net/personal/rlwalsh/ ___________________________________________________________________ --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: http://extra.newsguy.com (1:109/42) +----------------------------------------------------------------------------+ From: rplyler@us.spamNOT.ibm.com 11-Nov-99 12:52:16 To: All 11-Nov-99 10:44:24 Subj: Re: SYS_DLLS and superclassing native controls From: rplyler@us.spamNOT.ibm.com (Bob Plyler) In <3828955d.97047@news.demon.co.uk>, kh@no.spam.munot.demon.co.uk (Kevin) writes: >I have a massive PM application with hundreds and hundreds of entry >fields. It is used on 21 inch montiors and users are complaining that >they can't see the entry field cursor on the large screens. >Subclassing entry fields is not an option in this environment. So I >thought I could superclass WC_ENTRYFIELD. I have created a DLL with an >initialisation routine that attempts to get the class info for >WC_ENTRYFIELD, store the address of the window proc and register a >CS_PUBLIC control called WC_ENTRYFIELD. The intention is that when it >receives the focus it can call the original WC_ENTRYFIELD wnd proc and >then create a new cursor that is more visible. Simple question. Why not just replace the Cursors? You can replace them with system supplied cursors in the Mouse settings. You can modify these cursors via ICONEDIT Bob Plyler IBM 3890/XP Engineering (not an official IBM spokesperson) --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: IBM Global Services, South, RTP, NC, US (1:109/42) +----------------------------------------------------------------------------+ From: cbzh@my-deja.com 11-Nov-99 13:09:13 To: All 11-Nov-99 14:39:01 Subj: Problems when handling WM_PAINT in a second thread From: cbzh@my-deja.com In a graphics application I am passing all WM_PAINT messages on to a worker thread ("object window") for doing the real painting because it takes some time to complete and I do not want to block the program entirely. The user can issue e.g. a "zoom in" command while the graphics is still being drawn and the response is immediate: Stop the first repaint and start a new one with everything enlarged, etc. Works so far very nicely. However, a problem arises when I want to resize the window: It happens frequently that the size just "jumps" to something completely wrong, e.g. width zero or so. It only happens if the "move whole windows" option is turned on, i.e. resizing means a whole avalanche of WM_PAINT messages are arriving and competing with each other. I found a way to handle this, with partial success, trying to set a flag "don't repaint" while a resize action is on the way. In most cases this prevents the strange "jumping resize", but still not always. OTOH sometimes the final repaint doesn't seem to work and has to be forced somehow manually. There is a certain chance that the problem even has something to do with the multiple desktop feature of OD which I am running (v1.52 "professional"). QUESTION: Does anybody see an entirely different setup for achieving the responsiveness I want while long repaints are going on without running into the problems I got? Greetings and thanks for any hints, Cornelis Bockemühl e-mail: cbockem@datacomm.ch author of "PmAs - Astronomy for the Presentation Manager" at http://www.datacomm.ch/cobo Sent via Deja.com http://www.deja.com/ Before you buy. --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Deja.com - Before you buy. (1:109/42) +----------------------------------------------------------------------------+ From: jstucklex@attglobal.net 11-Nov-99 09:21:22 To: All 11-Nov-99 14:39:02 Subj: Re: Problems when handling WM_PAINT in a second thread From: Jerry Stuckle I've done a lot with painting like this - especially things which take a long time like changing the sizes of bitmaps. I've found the easiest way to do it is to do your painting to a memory PS. Then when you get the WM_PAINT messages, just BitBlt the memPS to the window PS. cbzh@my-deja.com wrote: > > In a graphics application I am passing all WM_PAINT messages on to a > worker thread ("object window") for doing the real painting because it > takes some time to complete and I do not want to block the program > entirely. The user can issue e.g. a "zoom in" command while the graphics > is still being drawn and the response is immediate: Stop the first > repaint and start a new one with everything enlarged, etc. Works so far > very nicely. > > However, a problem arises when I want to resize the window: It happens > frequently that the size just "jumps" to something completely wrong, > e.g. width zero or so. It only happens if the "move whole windows" > option is turned on, i.e. resizing means a whole avalanche of WM_PAINT > messages are arriving and competing with each other. I found a way to > handle this, with partial success, trying to set a flag "don't repaint" > while a resize action is on the way. In most cases this prevents the > strange "jumping resize", but still not always. OTOH sometimes the final > repaint doesn't seem to work and has to be forced somehow manually. > > There is a certain chance that the problem even has something to do with > the multiple desktop feature of OD which I am running (v1.52 > "professional"). > > QUESTION: > > Does anybody see an entirely different setup for achieving the > responsiveness I want while long repaints are going on without running > into the problems I got? > > Greetings and thanks for any hints, > > Cornelis Bockemhl > > e-mail: cbockem@datacomm.ch > author of "PmAs - Astronomy for the Presentation Manager" > at http://www.datacomm.ch/cobo > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- ======================================================= To reply, delete the "x" from my email address Jerry Stuckle jstucklex@attglobal.net JDS Computer Training Corp. Sun Certified Java Programmer VisualAge/Java Certified Advanced Technical Expert VisualAge/C++ Certified Developer ======================================================= --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: JDS Computer Training Corp. (1:109/42) +----------------------------------------------------------------------------+ From: cbzh@my-deja.com 11-Nov-99 16:02:17 To: All 11-Nov-99 14:39:02 Subj: Re: Problems when handling WM_PAINT in a second thread From: cbzh@my-deja.com In article <382AD0F8.2936@attglobal.net>, jstucklex@global.net wrote: > I've done a lot with painting like this - especially things which take a > long time like changing the sizes of bitmaps. > > I've found the easiest way to do it is to do your painting to a memory > PS. Then when you get the WM_PAINT messages, just BitBlt the memPS to > the window PS. Hmm, could be worth a try. However I see one disadvantage: The user doesn't see the image as it is being drawed. Sometimes you see e.g. the first outline, see that it is too small and immediately zoom in, etc. This viewing might be of less interest for bitmaps... But if the procedure solves the problem... Or maybe with a modification: The "object window" draws into a memory PS and from time to time sends a message to the main thread telling it to copy the current image to the screen... (??!) Cornelis Bockemühl > cbzh@my-deja.com wrote: > > > > In a graphics application I am passing all WM_PAINT messages on to a > > worker thread ("object window") for doing the real painting because it > > takes some time to complete and I do not want to block the program > > entirely. The user can issue e.g. a "zoom in" command while the graphics > > is still being drawn and the response is immediate: Stop the first > > repaint and start a new one with everything enlarged, etc. Works so far > > very nicely. > > > > However, a problem arises when I want to resize the window: It happens > > frequently that the size just "jumps" to something completely wrong, > > e.g. width zero or so. It only happens if the "move whole windows" > > option is turned on, i.e. resizing means a whole avalanche of WM_PAINT > > messages are arriving and competing with each other. I found a way to > > handle this, with partial success, trying to set a flag "don't repaint" > > while a resize action is on the way. In most cases this prevents the > > strange "jumping resize", but still not always. OTOH sometimes the final > > repaint doesn't seem to work and has to be forced somehow manually. > > > > There is a certain chance that the problem even has something to do with > > the multiple desktop feature of OD which I am running (v1.52 > > "professional"). > > > > QUESTION: > > > > Does anybody see an entirely different setup for achieving the > > responsiveness I want while long repaints are going on without running > > into the problems I got? > > > > Greetings and thanks for any hints, > > > > Cornelis Bockemühl > > > > e-mail: cbockem@datacomm.ch > > author of "PmAs - Astronomy for the Presentation Manager" > > at http://www.datacomm.ch/cobo > > > > Sent via Deja.com http://www.deja.com/ > > Before you buy. > > -- > > ======================================================= > To reply, delete the "x" from my email address > > Jerry Stuckle > jstucklex@attglobal.net > JDS Computer Training Corp. > Sun Certified Java Programmer > VisualAge/Java Certified Advanced Technical Expert > VisualAge/C++ Certified Developer > > ======================================================= > Sent via Deja.com http://www.deja.com/ Before you buy. --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Deja.com - Before you buy. (1:109/42) +----------------------------------------------------------------------------+ From: lorne.sunley@fto.de 12-Nov-99 01:45:29 To: All 11-Nov-99 16:48:03 Subj: Re: USE or SPY any distant PC via LAN/INTERNET From: lorne.sunley@fto.de From: lsunley@mb.sympatico.ca (Lorne Sunley) On Wed, 10 Nov 1999 16:41:16, "Crowsort" wrote: > USE or SPY any distant PC via LAN/INTERNET > > How YOU can Hack Windows 95-98-NT... in seconds! > And use or spy any PC via a LAN or the Internet... as if you were there! > > Platforms concerned: > -------------------- > => Windows 95/98 > => Windows NT Workstation/Server 3.5, 3.51 and 4.0 > => Windows 2000 Yet another reason to resist the wiles of Microsoft. If Outlook doesn't get you, something like this will Lorne Sunley --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Skynet Titan (1:109/42) +----------------------------------------------------------------------------+ From: bstzdl@fto.de 12-Nov-99 01:46:00 To: All 11-Nov-99 16:48:03 Subj: Get Noticed!! From: bstzdl@fto.de From: bstzdl@datawise.net http:/www.mightybiz.com --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Skynet Titan (1:109/42) +----------------------------------------------------------------------------+ From: peter.fitzsimons@fto.de 12-Nov-99 01:46:00 To: All 11-Nov-99 16:48:03 Subj: Re: SYS_DLLS and superclassing native controls From: peter.fitzsimons@fto.de From: peter.fitzsimons@fto.de From: Peter Fitzsimons > I list my DLL in SYS_DLLS->LoadEachProcess (or whatever it's called). > The DLL loads and executes its initialisation. WinQueryClassInfo gets > TRUE for WC_ENTRYFIELD. WinRegisterClass for WC_ENTRYFIELD with > CS_PUBLIC gets FALSE. But after re-booting, any window with an entry > field traps. This tends to indicate that my wndproc is being called, How are you defining your data segments? ie:"single shared", or what? If you are loading anything (like a pointer/icon/bmp) you have to do it for each app, which probably forces you do use an "initinstance multiple nonshared" dll. So keep your data segment size down, and try to compile /Rn. I have code that subclasses the titlebar for every app with a sys_dll "load once" entry. It installs a msg hook, that looks for WM_CREATE messages; if the window is what I'm looking for, then I subclass it "live". I'm a resource freak and the thought of "loadperprocess" and "mutliple data" offended me at the time (1995, when I only had 24mb of memory I think :). Anyway, you're welcome to the code if you like. --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Skynet Titan (1:109/42) +----------------------------------------------------------------------------+ From: vitus.jensen@fto.de 12-Nov-99 01:46:00 To: All 11-Nov-99 16:48:03 Subj: WSeb and LDGW and NDS From: vitus.jensen@fto.de From: vitus.jensen@fto.de From: Vitus_Jensen@teaparty.fido.de (Vitus Jensen) Hello Charles, 08.11.99 18:18, Charles Christacopoulos wrote a message to All : CC> I would appreciate any pointers, tips, ideas (whatever) to the CC> following. CC> We are primarily a Netware/Solaris house, apart from me being odd CC> with OS/2. I run WSeB and Lotus Domino Go web server(s) to CC> provide the www intranet at our institution. CC> Without gettting into any detail, LDGW can call an external CC> program to validate users when they try to get www "protected" CC> files. I would like to "one day" have such an external program CC> that would actually validate users against Netware's NDS tree CC> (thus users would in effect use the same ID and password for CC> Netware and for viewing files on the www). CC> Where do I start looking for a solution? To write a program using the NDS for user validation you need the "Client SDK" for OS/2 from Novell. When I was doing such things (over 4 years ago) it was sold, documentation only readable from WinOS/2. There are a lot of 16 bit functions you may call but to decide which function is used for what purpose isn't simple. CC> Will the LDAP kit that comes with WSeB allow me to do anything CC> like it? Can it be done? Has anyone got it (we would be willing CC> to pay :-) ? If you can manage to synchronize the LAN Server domain with the NDS you would have a much simpler task: just call Net[32]UserValidate(). The server (and requester?) package contains INF, header, lib and samples how to do this. Look for x:\IBMLAN\NETSRC (don't remember the installation option, sorry). C-x C-s Vitus --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Skynet Titan (1:109/42) +----------------------------------------------------------------------------+ From: kevin@fto.de 12-Nov-99 01:46:00 To: All 11-Nov-99 16:48:03 Subj: Re: SYS_DLLS and superclassing native controls From: kevin@fto.de From: kh@no.spam.munot.demon.co.uk (Kevin) On 10 Nov 1999 11:00:58 GMT, yourself@127.0.0.1 (Rich Walsh) wrote: >On Tue, 9 Nov 1999 21:58:56, kh@no.spam.munot.demon.co.uk (Kevin) wrote: > >> I have a massive PM application with hundreds and hundreds of entry >> fields. It is used on 21 inch montiors and users are complaining that >> they can't see the entry field cursor on the large screens. >> Subclassing entry fields is not an option in this environment. So I >> thought I could superclass WC_ENTRYFIELD. I have created a DLL with an >> initialisation routine that attempts to get the class info for >> WC_ENTRYFIELD, store the address of the window proc and register a >> CS_PUBLIC control called WC_ENTRYFIELD. The intention is that when it >> receives the focus it can call the original WC_ENTRYFIELD wnd proc and >> then create a new cursor that is more visible. >> >> I list my DLL in SYS_DLLS->LoadEachProcess (or whatever it's called). >> The DLL loads and executes its initialisation. WinQueryClassInfo gets >> TRUE for WC_ENTRYFIELD. WinRegisterClass for WC_ENTRYFIELD with >> CS_PUBLIC gets FALSE. But after re-booting, any window with an entry >> field traps. This tends to indicate that my wndproc is being called, >> even though I got FALSE on the register. I wonder if the address >> returned by WinQueryClassInfo is valid in all the other processes. >> >>I believe from a search on DEJA that Rich Walsh has done this kind of >>thing before. What I want to do is register my own wndproc for all >>WC_ENTRYFIELD controls created and create a different cursor every >>time an entry field gets the focus. What am I doing wrong? > >Do you really want to modify every entryfield in the system or just the >ones in your app? Either way, you'll have to deal with odd side-effects >your code may have on, say, read-only comboboxes (i.e. no visible cursor). Users would be happy with every entryfield in the system. This is the only app being used, so I don't have to worry about other people's apps. Didn't thing about the comboboxes, but their entryfields are easy enough to distinguish from ordinary ones. >For a global replacement, the superclassing code in your DLL should only >be executed once: the first time it's called, when it's operating in the >shell process. You shouldn't have to change any flags. You can store >the original PFN in global memory because it's valid in all PM processes. Thanks for clearing that up. The WinRegisterClass call returns FALSE when I try to register with all the parameters from WinGetClassInfo the same except for PFNWP. Haven't done WinGetLastError here yet as I was trying Peter Fitzsimmons' idea today. Don't know if I believe the return value though because I was getting traps on anything that created an entryfield. >The traps you're getting now probably occur because the DLL's instance >data hasn't been initialized properly (are you using INITINSTANCE and >DATA MULTIPLE NONSHARED ?). Since your needs are so minimal, you may >not even need a per-process data segment except to satisfy your compiler. >If so, try shedding the runtime environment - or even the runtime itself >(YMMV). I had INITINSTANCE and DATA MULTIPLE NONSHARED in all cases. Currently using the runtime for fprintf for debugging, but will probably not use it in the end. >BTW... are you aware that the function you've exported as ordinal 1 >gets called every time your dll is loaded into a new process? Hmmm. I am exporting by names, but the first export is my initialisation function. This function does get called on load as my fprintf shows. >For a process-specific solution, forget most everything I just said :-) >AFAIK, you can't reregister a CS_PUBLIC class for a particular process. That is correct according to the documentation. >Instead, you can try this strategy (one of several that come to mind): >identify whether the message that causes an e/f to create its cursor >is posted or sent. Then use either an InputHook or a SendMsgHook on >your *own* message queue (HMQ_CURRENT) to intercept it. This will >let you put the code in your exe, avoid sub- or superclassing, and >generally limit the damage. (IMHO, this is a good solution when >you're messing with your own app, and a lousy solution when you're >messing other people's.) Have been playing with hooks today. Wanted to used Peter's suggestion to use a hook to catch all WM_CREATE messages and subclass WC_ENTRYFIELDS. Have tried all the 'message' type hooks, but so far none seem to get WM_CREATE messages. Hoping Peter's code will help here. The private hook is interesting. The entryfield has to create/destroy the cursor on one of the activate/focuschange type messages. I will look into that more tomorrow. Thanks, Kevin --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Skynet Titan (1:109/42) +----------------------------------------------------------------------------+ From: dave.blaschke@fto.de 12-Nov-99 01:46:00 To: All 11-Nov-99 16:48:03 Subj: Re: XCPT_SPACE_ACCESS Violation in DOSCALL1 From: dave.blaschke@fto.de From: Dave Blaschke Mike Fry wrote: Ahh, Mike Fry, the man who asked me to add yet another executable to the OS2TRACE package. Because it's you I'll try and answer correctly for a change ;-) > Could someone help me with this entry from the POPUPLOG.OS2 on a Warp 4, > FP12 machine? > > Unfortunately, I didn't write the offending program (it's in 16-bit > COBOL of all things), but I have written a lot of underlying routines > (Watcom C) that live in DLLs, along with various service programs. All C > code is 32-bit. The DLLs used by the COBOL program have equivalent > 16-bit and 32-bit entry points (Watcom is good for this sort of thunking > ). > > 11-05-1999 14:30:29 SYS3171 PID 0029 TID 0001 Slot 0053 > C:\DLRC\MCHOTB04.EXE > c0000005 > 1bfa0184 > P1=00000008 P2=00000134 P3=XXXXXXXX P4=XXXXXXXX > EAX=00000079 EBX=000047fc ECX=0000001f EDX=0000eb84 > ESI=00002590 EDI=00002800 > DS=a447 DSACC=00f3 DSLIM=000047ff > ES=a44f ESACC=00f3 ESLIM=00001aef > FS=150b FSACC=00f3 FSLIM=00000030 > GS=0000 GSACC=**** GSLIM=******** > CS:EIP=dfd7:00000184 CSACC=00df CSLIM=0000dc08 > SS:ESP=0137:000009f2 SSACC=**** SSLIM=******** > EBP=000009f2 FLG=00012202 > > DOSCALL1.DLL 0003:00000184 > > I don't really understand the SYS3171 - exception within exception. As > far as I know, my DLLs don't use exception handlers apart from what the > CRT installs. Is it possible to determine which routine in DOSCALL1.DLL > this trap actually occurred in? SYS3171 simply means that a thread did not have enough stack space available to dispatch an exception. When an exception occurs, the OS/2 kernel attempts to "push" an exception report record and context record, along with some other goodies, on top of the user's stack for the ring 3 exception dispatcher: if this fails, a SYS3171 will result. This does not necessarily mean that an exception occurred within a handler. As for the routine, you can't really figure it out without the DOSCALL1.MAP file or some debug tools that can extract the info from DOSCALL1.SYM. In this case, DOSCALL1 object 3 offset 184 is within the DOSSEMWAIT API on FP12. > > > My suspicion is that this is some kind of application-caused memory > leak. Examination of the C & COBOL source code shows that tiled memory > objects are being allocated by DosAllocSharedMem in one of my service > EXEs and passed to the COBOL program, via a queue, after doing a > DosGiveSharedMem to give the COBOL program read/write permission. The > service EXE then does a DosFreeMem. > > At some stage on the COBOL side, an apparently unnecessary DosGetSeg > (16-bit remember) is being done. I say unnecessary because the program > already has read/write access to the object thru the DosGiveSharedMem > call. I can only find a single DosFreeSeg in the COBOL code. Am I right > in thinking that OS/2 is unable to 'physically' free the memory objects > because of a non-zero reference count? And that over time, OS/2 will > actually 'run out' of memory? > > To me, this is a fairly straight-forward XCPT_ACCESS_VIOLATION. > According to my toolkit headers, the P1 value indicates > XCPT_SPACE_ACCESS and P2 the selector involved. If OS/2 has actually run > out of selectors because of the unnecessary DosGetSeg (missing > DosFreeSeg), then I would have expected to find P1 to indicate > XCPT_LIMIT_ACCESS. > > I can't find any explanation in my documentation of what these two > access violation codes mean in real terms. Can anybody explain the > difference between XCPT_SPACE_ACCESS and XCPT_LIMIT_ACCESS? Does my > description of the memory object usage make sense in terms of the trap > information that I have supplied? Both indicate that a trap C occurred. If P1 == XCPT_SPACE_ACCESS, then the trap C occurred with a non-zero error code and P2 = this error code. If P1 == XCPT_LIMIT_ACCESS, then the trap C occurred with a zero error code and P2 = XCPT_DATA_UNKNOWN. The following is from the Intel programmer's reference, where stack fault refers to trap C: A stack fault is generated under two conditions: * As a result of a limit violation in any operation which refers to the SS register. This includes stack-oriented instructions such as POP, PUSH, ENTER, and LEAVE, as well as other memory references which implicitly use the stack (for example, MOV AX,[BP+6]). The ENTER instruction generates this exception when there is too little space for allocating local variables. * When attempting to load the SS register with a descriptor which is marked segment-not-present but is otherwise valid. This can occur in a task switch, a CALL instruction ro a different privilege level, a return to a different privilege level, an LSS instruction, or a MOV or POP instruction to the SS register. When the processor detects a stack exception, it pushes an error code onto the stack of the exception handler. If the exception is due to a not-present stack segment or to overflow of the new stack during an interlevel CALL, the error code contains a selector to the segment which caused the exception (the exception handler can test the present bit in the descriptor to determine which exception occurred); otherwise, the error code is 0. > > > Thanks for listening, > MIKE FRY > mailto:mikefry@iafrica.com --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Skynet Titan (1:109/42) +----------------------------------------------------------------------------+ From: rich.walsh@fto.de 12-Nov-99 01:46:01 To: All 11-Nov-99 16:48:03 Subj: Re: SYS_DLLS and superclassing native controls From: rich.walsh@fto.de From: rich.walsh@fto.de From: yourself@127.0.0.1 (Rich Walsh) On Tue, 9 Nov 1999 21:58:56, kh@no.spam.munot.demon.co.uk (Kevin) wrote: > I have a massive PM application with hundreds and hundreds of entry > fields. It is used on 21 inch montiors and users are complaining that > they can't see the entry field cursor on the large screens. > Subclassing entry fields is not an option in this environment. So I > thought I could superclass WC_ENTRYFIELD. I have created a DLL with an > initialisation routine that attempts to get the class info for > WC_ENTRYFIELD, store the address of the window proc and register a > CS_PUBLIC control called WC_ENTRYFIELD. The intention is that when it > receives the focus it can call the original WC_ENTRYFIELD wnd proc and > then create a new cursor that is more visible. > > I list my DLL in SYS_DLLS->LoadEachProcess (or whatever it's called). > The DLL loads and executes its initialisation. WinQueryClassInfo gets > TRUE for WC_ENTRYFIELD. WinRegisterClass for WC_ENTRYFIELD with > CS_PUBLIC gets FALSE. But after re-booting, any window with an entry > field traps. This tends to indicate that my wndproc is being called, > even though I got FALSE on the register. I wonder if the address > returned by WinQueryClassInfo is valid in all the other processes. > >I believe from a search on DEJA that Rich Walsh has done this kind of >thing before. What I want to do is register my own wndproc for all >WC_ENTRYFIELD controls created and create a different cursor every >time an entry field gets the focus. What am I doing wrong? Do you really want to modify every entryfield in the system or just the ones in your app? Either way, you'll have to deal with odd side-effects your code may have on, say, read-only comboboxes (i.e. no visible cursor). For a global replacement, the superclassing code in your DLL should only be executed once: the first time it's called, when it's operating in the shell process. You shouldn't have to change any flags. You can store the original PFN in global memory because it's valid in all PM processes. The traps you're getting now probably occur because the DLL's instance data hasn't been initialized properly (are you using INITINSTANCE and DATA MULTIPLE NONSHARED ?). Since your needs are so minimal, you may not even need a per-process data segment except to satisfy your compiler. If so, try shedding the runtime environment - or even the runtime itself (YMMV). BTW... are you aware that the function you've exported as ordinal 1 gets called every time your dll is loaded into a new process? For a process-specific solution, forget most everything I just said :-) AFAIK, you can't reregister a CS_PUBLIC class for a particular process. Instead, you can try this strategy (one of several that come to mind): identify whether the message that causes an e/f to create its cursor is posted or sent. Then use either an InputHook or a SendMsgHook on your *own* message queue (HMQ_CURRENT) to intercept it. This will let you put the code in your exe, avoid sub- or superclassing, and generally limit the damage. (IMHO, this is a good solution when you're messing with your own app, and a lousy solution when you're messing other people's.) == == almost usable email address: rlwalshATpacket.net == == ___________________________________________________________________ | - DragText v3.1 - Rich Walsh | A Distinctly Different Desktop Enhancement Ft Myers, FL | New! Pickup & Drop for text, and more... | http://www.usacomputers.net/personal/rlwalsh/ ___________________________________________________________________ --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Skynet Titan (1:109/42) +----------------------------------------------------------------------------+ From: mike.fry@fto.de 12-Nov-99 01:46:01 To: All 11-Nov-99 16:48:03 Subj: XCPT_SPACE_ACCESS Violation in DOSCALL1 From: mike.fry@fto.de From: mike.fry@fto.de From: mikefry@iafrica.nospam.com (Mike Fry) Could someone help me with this entry from the POPUPLOG.OS2 on a Warp 4, FP12 machine? Unfortunately, I didn't write the offending program (it's in 16-bit COBOL of all things), but I have written a lot of underlying routines (Watcom C) that live in DLLs, along with various service programs. All C code is 32-bit. The DLLs used by the COBOL program have equivalent 16-bit and 32-bit entry points (Watcom is good for this sort of thunking ). 11-05-1999 14:30:29 SYS3171 PID 0029 TID 0001 Slot 0053 C:\DLRC\MCHOTB04.EXE c0000005 1bfa0184 P1=00000008 P2=00000134 P3=XXXXXXXX P4=XXXXXXXX EAX=00000079 EBX=000047fc ECX=0000001f EDX=0000eb84 ESI=00002590 EDI=00002800 DS=a447 DSACC=00f3 DSLIM=000047ff ES=a44f ESACC=00f3 ESLIM=00001aef FS=150b FSACC=00f3 FSLIM=00000030 GS=0000 GSACC=**** GSLIM=******** CS:EIP=dfd7:00000184 CSACC=00df CSLIM=0000dc08 SS:ESP=0137:000009f2 SSACC=**** SSLIM=******** EBP=000009f2 FLG=00012202 DOSCALL1.DLL 0003:00000184 I don't really understand the SYS3171 - exception within exception. As far as I know, my DLLs don't use exception handlers apart from what the CRT installs. Is it possible to determine which routine in DOSCALL1.DLL this trap actually occurred in? My suspicion is that this is some kind of application-caused memory leak. Examination of the C & COBOL source code shows that tiled memory objects are being allocated by DosAllocSharedMem in one of my service EXEs and passed to the COBOL program, via a queue, after doing a DosGiveSharedMem to give the COBOL program read/write permission. The service EXE then does a DosFreeMem. At some stage on the COBOL side, an apparently unnecessary DosGetSeg (16-bit remember) is being done. I say unnecessary because the program already has read/write access to the object thru the DosGiveSharedMem call. I can only find a single DosFreeSeg in the COBOL code. Am I right in thinking that OS/2 is unable to 'physically' free the memory objects because of a non-zero reference count? And that over time, OS/2 will actually 'run out' of memory? To me, this is a fairly straight-forward XCPT_ACCESS_VIOLATION. According to my toolkit headers, the P1 value indicates XCPT_SPACE_ACCESS and P2 the selector involved. If OS/2 has actually run out of selectors because of the unnecessary DosGetSeg (missing DosFreeSeg), then I would have expected to find P1 to indicate XCPT_LIMIT_ACCESS. I can't find any explanation in my documentation of what these two access violation codes mean in real terms. Can anybody explain the difference between XCPT_SPACE_ACCESS and XCPT_LIMIT_ACCESS? Does my description of the memory object usage make sense in terms of the trap information that I have supplied? Thanks for listening, MIKE FRY mailto:mikefry@iafrica.com --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Skynet Titan (1:109/42) +----------------------------------------------------------------------------+ From: rich.walsh@fto.de 12-Nov-99 01:46:02 To: All 11-Nov-99 16:48:03 Subj: Re: SYS_DLLS and superclassing native controls From: rich.walsh@fto.de From: yourself@127.0.0.1 (Rich Walsh) On Wed, 10 Nov 1999 21:28:40, kh@no.spam.munot.demon.co.uk (Kevin) wrote: > On 10 Nov 1999 11:00:58 GMT, yourself@127.0.0.1 (Rich Walsh) wrote: > >On Tue, 9 Nov 1999 21:58:56, kh@no.spam.munot.demon.co.uk (Kevin) wrote: > > > >> I have a massive PM application with hundreds and hundreds of entry > >> fields. It is used on 21 inch montiors and users are complaining that > >> they can't see the entry field cursor on the large screens. > >> Subclassing entry fields is not an option in this environment. So I > >> thought I could superclass WC_ENTRYFIELD. [big snip] > >Instead, you can try this strategy (one of several that come to mind): > >identify whether the message that causes an e/f to create its cursor > >is posted or sent. Then use either an InputHook or a SendMsgHook on > >your *own* message queue (HMQ_CURRENT) to intercept it. This will > >let you put the code in your exe, avoid sub- or superclassing, and > >generally limit the damage. (IMHO, this is a good solution when > >you're messing with your own app, and a lousy solution when you're > >messing other people's.) > > Have been playing with hooks today. Wanted to used Peter's suggestion > to use a hook to catch all WM_CREATE messages and subclass > WC_ENTRYFIELDS. Have tried all the 'message' type hooks, but so far > none seem to get WM_CREATE messages. Hoping Peter's code will help > here. > > The private hook is interesting. The entryfield has to create/destroy > the cursor on one of the activate/focuschange type messages. I will > look into that more tomorrow. DragText v1.x used the method Peter described (minus the SYS_DLLS entry). It had a flaw that you may consider a feature. Comboboxes and spinbuttons create entryfields which your code subclasses and their code then re-subclasses. They don't bother saving your PFNWP and have their subprocs call the class's base window procedure instead of yours. Unless you subclass these controls too (as DT did), your code will never be called when the entryfield is part of another control. You can do this entirely within your own app by installing a HK_SENDMSG for each thread that creates entryfields (probably only the first). This should eliminate access violations and let you retain your C runtime. Like IBM, you'll have to decide whether to discard each window's PFNWP and use the class's default. FWIW... After I posted my earlier suggestion, I realized it won't work if you have to use a HK_SENDMSG. You want to create a cursor after an e/f has handled a particular message but this hook gives you no way to do so and no way to keep the message from being passed on (with a HK_INPUT, your hook could dispatch the message itself, do its thing on return, then terminate further processing). Sorry 'bout that... == == almost usable email address: rlwalshATpacket.net == == ___________________________________________________________________ | - DragText v3.1 - Rich Walsh | A Distinctly Different Desktop Enhancement Ft Myers, FL | New! Pickup & Drop for text, and more... | http://www.usacomputers.net/personal/rlwalsh/ ___________________________________________________________________ --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Skynet Titan (1:109/42) +----------------------------------------------------------------------------+ From: crowsort@fto.de 12-Nov-99 01:46:01 To: All 11-Nov-99 16:48:03 Subj: USE or SPY any distant PC via LAN/INTERNET From: crowsort@fto.de From: crowsort@fto.de From: "Crowsort" USE or SPY any distant PC via LAN/INTERNET How YOU can Hack Windows 95-98-NT... in seconds! And use or spy any PC via a LAN or the Internet... as if you were there! Platforms concerned: -------------------- => Windows 95/98 => Windows NT Workstation/Server 3.5, 3.51 and 4.0 => Windows 2000 Whether you are a rookie or a seasoned hacker, there are times where you want to do something RAPIDLY. Some of us worked a lot to enhance password cracking but we have to recognize that if passwords have been carefully chosen, it still takes a lot of TIME. Others are using well-known security holes in NT but we also have to recognize that the ways to use those security breaches are not easy and it also takes TIME to understand and to implement them. There is a way to get all the passwords of *any* version of Windows INSTANTLY. There is a way to control a distant machine 'as if you were there'. Netbus and BO2K were good attempts, I used them for months, but despite of what their authors said, using it every day is difficult and frustrating enough to disgust lazy guys like me... the fact that I cannot see the distant screen in real-time is really frustrating! A friend demonstrated me RA. RA (Remote-Anything) is THE solution you were looking for: it shows in real-time the distant desktop (like PC-Anywhere and other MB-based commercial products) BUT the server (the program you install on the PC you want to control) is **80 KB** long... You can install it remotely by using the buffer overflows of Outlook Express or IE4 or simply by sending it as an Email attachment! Better than that: once installed, it does not show in the Task-List, can't be discovered or killed with CTRL-ALT-DEL! Once you poisoned PCs on a LAN, no need to remember which ones: RA is able to find automatically available PCs and displays IP addresses and DNS Names! Just click on one of them to be connected! And it is so fast that you can see any animation playing on the distant PC in real-time! All this from one unique tool... Damned, I got it! ____________________________________________________ Here are some of the functions I picked-up from RA's Doc: o Connect to a new desktop: opens the Connection Dialog Box which allows you to open a new window on a new Desktop (you can watch multiple Desktops at a time). o Monitor only: will toggle the passive-monitoring and active-control modes (active monitoring allows you to type keys and move the mouse on the distant PC while passive monitoring will only allow you to watch only). o Full screen: will enter the full-screen mode. You can exit it by typing CTRL+ESC and then right-clicking the Master's task bar icon to come back to the windowed mode. o Remove wallpaper on distant desktop: is useful to minimize the amount of data sent over the network. It always speedups a connection. o Start Screen Saver: is useful when you want to leave the desktop with a screensaver running: when Remote-Anything moves the mouse cursor on a Slave desktop, it stops the screensaver if it was running. With this option, you can immediately run the screensaver (use this option with the keyboard shortcut to avoid moving the mouse in active mode or switch to passive monitoring to activate this menu option with the mouse). If the screensaver is password protected, this is a way to lock the distant PC. o Play a Sound: will make a sound being played on the distant PC. Usually it is 'ding.wav' but it can be any sound the distant PC registered as the default sound. o Send commands: will display a Dialog Box equivalent to the Start/Run command of Windows 95. o Get Passwords of distant PC: get all the network passwords, the screensaver password, and the Applications passwords Windows has been asked to remember. o Lockup distant PC: Hangs the distant PC which will need to be restarted manually. o Reboot distant PC: will immediately send the order to reboot to the distant PC, this will disconnect you from this Desktop but you can reconnect once the distant Windows session is active again. o Shut Down distant PC: will shut down the distant PC if it supports shut down. You will be disconnected. _____________________________________________________ o How does it work? ----------------- It is as simple as using Windows 98 itself: move the mouse, type keys, the distant PC will do everything you want! It works over LANs and the Internet! o Where can I get it? ------------------- At the moment, you can get it from: http://www.twd-industries.com You'll have to pay a small fee to the authors to get RA. I can tell you that it's worth the price: I simply did things I would never have been able to do without it. If you have access to a local network, RA will allow you to do whatever you want! This tool is so easy to use that every hacker will want it. The more you wait, the less what you can do with it will remain a secret! But as time goes, I guess it will be available from a lot of other places. Have fun! §§§§§§§ §§ §§§ §§ § ~ ~ § @<¤>"<¤>@ ( ~ ) \ 'v=v' / The Crowsort is back. |\____/| _____________________________________________________ --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Skynet Titan (1:109/42) +----------------------------------------------------------------------------+ From: bob.plyler@fto.de 12-Nov-99 01:46:02 To: All 11-Nov-99 16:48:03 Subj: Re: SYS_DLLS and superclassing native controls From: bob.plyler@fto.de From: rplyler@us.spamNOT.ibm.com (Bob Plyler) Reply-To: rplyler@us.spamNOT.ibm.com (Bob Plyler) In <3828955d.97047@news.demon.co.uk>, kh@no.spam.munot.demon.co.uk (Kevin) writes: >I have a massive PM application with hundreds and hundreds of entry >fields. It is used on 21 inch montiors and users are complaining that >they can't see the entry field cursor on the large screens. >Subclassing entry fields is not an option in this environment. So I >thought I could superclass WC_ENTRYFIELD. I have created a DLL with an >initialisation routine that attempts to get the class info for >WC_ENTRYFIELD, store the address of the window proc and register a >CS_PUBLIC control called WC_ENTRYFIELD. The intention is that when it >receives the focus it can call the original WC_ENTRYFIELD wnd proc and >then create a new cursor that is more visible. Simple question. Why not just replace the Cursors? You can replace them with system supplied cursors in the Mouse settings. You can modify these cursors via ICONEDIT Bob Plyler IBM 3890/XP Engineering (not an official IBM spokesperson) --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Skynet Titan (1:109/42) +----------------------------------------------------------------------------+ From: ariek3.14159265358979323846@fto.de 12-Nov-99 01:46:01 To: All 11-Nov-99 16:48:03 Subj: Re: VAC++ debugger storage monitor: how to search for specific data? From: ariek3.14159265358979323846@fto.de From: ariek@attglobal3.14159265358979323846.net (Arie Kazachin) Reply-To: ariek3.14159265358979323846@ibm.net In message <38285CE8.399C@attglobal.net> - Tue, 09 Nov 1999 12:42:01 -0500Jerry Stuckle writes: > >Arie, > >Sorry, you can't search for specific data - I assume part of the reason >could be that memory is not necessarily contiguous in OS/2, even with >virtual addresses. > >A trick I've used quite often is to set a pointer to the data I want to >monitor, then stop when the pointer is set. This will give me the >address of the data, and I can then set a breakpoint on the change. > Thanks, Jerry. However, this trick only works when debugging a program you write. When attempting to do this with already existing executable (and no sources), it seems I'll have to let go on tha ability to search for data (unless some developing/debugging utilities can do this). Regards, ********************************************************************** ******* * Arie Kazachin, Israel, e-mail: ariek@attglobal3.14159265358979323846.net * ********************************************************************** ******* NOTE: before replying, leave only letters in my domain-name. Sorry, SPAM trap. --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Skynet Titan (1:109/42) +----------------------------------------------------------------------------+ From: joe.heafner@fto.de 12-Nov-99 01:46:01 To: All 11-Nov-99 16:48:03 Subj: sys/param.h and in.h on other systems From: joe.heafner@fto.de From: Joe Heafner Hi. I have some software that was designed to work under EMX, DJGPP, and other systems equipped with gcc. It also compiles under VC++ on Win systems. The programs make use of the sys/param.h and in.h header files. When I attempt to compile the code under MingW32 (the Win32 port of gcc 2.9) the compiler complains about not being able to find these header files. Can anyone tell me the header files I should use under MingW23 to compile these programs? Someone else also told me that these particular header files are not part of the ANSI/ISO C standard. All I know is that ever compiler/system I've tested my software on apparently has these files and experiences no problems. The only compiler to have a problem so far is MingW32. If these files are not ANSI compliant, what are the appropriate ANSI header files to use? The software, I belive (I didn't write this particular part), uses these header files for functions needed to check and, if necessary, change byte ordering (big endian vs. little endian) in certain situations. Thanks, -- -- Joe Heafner Joe Heafner, Astronomy and Physics Instructor. Work:(828)327-7000 x4246 my surname with my first initial at interpath dot com http://home.interpath.com/heafnerj/ --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Skynet Titan (1:109/42) +----------------------------------------------------------------------------+ From: bob.eager@fto.de 12-Nov-99 01:46:02 To: All 11-Nov-99 16:48:03 Subj: Re: sys/param.h and in.h on other systems From: bob.eager@fto.de From: rde@tavi.co.uk (Bob Eager) On Thu, 11 Nov 1999 00:03:10, Joe Heafner wrote: > I have some software that was designed to work under EMX, DJGPP, and > other systems equipped with gcc. It also compiles under VC++ on Win > systems. The programs make use of the sys/param.h and in.h header files. > When I attempt to compile the code under MingW32 (the Win32 port of gcc > 2.9) the compiler complains about not being able to find these header > files. Where did you get the header files for the other compilers? If in a toolkit, then if MingW32 can't find them you probably have it looking in the wrong place. > Can anyone tell me the header files I should use under MingW23 to > compile these programs? The same ones you used for the others. > Someone else also told me that these particular header files are not > part of the ANSI/ISO C standard. All I know is that ever compiler/system > I've tested my software on apparently has these files and experiences no > problems. That's right. These headers are non-ANSI. The sys\param.h is essentially a kernel configuration file on UNIX systems. The occasional constant in there escapes for use by programs. The in.h (in netinet\in.h on my system) contains networking stuff. > The only compiler to have a problem so far is MingW32. Sounds like the setup. > If > these files are not ANSI compliant, what are the appropriate ANSI header > files to use? There aren't. > The software, I belive (I didn't write this particular > part), uses these header files for functions needed to check and, if > necessary, change byte ordering (big endian vs. little endian) in > certain situations. I can believe that the files you mention contain these functions. But they aren't part of ANSI. Saying that you've seen them on every system so far doesn' MAKE then suddnly ANSI. I repeat, I think the set of headers you're using with the compiler is incomplete. Or its INCLUDE environment variable isn't picking up the toolkit directory. -- Bob Eager rde at tavi.co.uk PC Server 325; PS/2s 8595*3, 9595*3 (2*P60 + P90), 8535, 8570, 9556*2, 8580*6, 8557*2, 8550, 9577, 8530, P70, PC/AT.. --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Skynet Titan (1:109/42) +----------------------------------------------------------------------------+ From: cbzh@fto.de 12-Nov-99 01:46:03 To: All 11-Nov-99 16:48:03 Subj: Problems when handling WM_PAINT in a second thread From: cbzh@fto.de From: cbzh@my-deja.com In a graphics application I am passing all WM_PAINT messages on to a worker thread ("object window") for doing the real painting because it takes some time to complete and I do not want to block the program entirely. The user can issue e.g. a "zoom in" command while the graphics is still being drawn and the response is immediate: Stop the first repaint and start a new one with everything enlarged, etc. Works so far very nicely. However, a problem arises when I want to resize the window: It happens frequently that the size just "jumps" to something completely wrong, e.g. width zero or so. It only happens if the "move whole windows" option is turned on, i.e. resizing means a whole avalanche of WM_PAINT messages are arriving and competing with each other. I found a way to handle this, with partial success, trying to set a flag "don't repaint" while a resize action is on the way. In most cases this prevents the strange "jumping resize", but still not always. OTOH sometimes the final repaint doesn't seem to work and has to be forced somehow manually. There is a certain chance that the problem even has something to do with the multiple desktop feature of OD which I am running (v1.52 "professional"). QUESTION: Does anybody see an entirely different setup for achieving the responsiveness I want while long repaints are going on without running into the problems I got? Greetings and thanks for any hints, Cornelis Bockemühl e-mail: cbockem@datacomm.ch author of "PmAs - Astronomy for the Presentation Manager" at http://www.datacomm.ch/cobo Sent via Deja.com http://www.deja.com/ Before you buy. --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Skynet Titan (1:109/42) +----------------------------------------------------------------------------+ From: jstucklex@fto.de 12-Nov-99 01:46:03 To: All 11-Nov-99 16:48:03 Subj: Re: Problems when handling WM_PAINT in a second thread From: jstucklex@fto.de From: Jerry Stuckle Reply-To: jstucklex@global.net I've done a lot with painting like this - especially things which take a long time like changing the sizes of bitmaps. I've found the easiest way to do it is to do your painting to a memory PS. Then when you get the WM_PAINT messages, just BitBlt the memPS to the window PS. cbzh@my-deja.com wrote: > > In a graphics application I am passing all WM_PAINT messages on to a > worker thread ("object window") for doing the real painting because it > takes some time to complete and I do not want to block the program > entirely. The user can issue e.g. a "zoom in" command while the graphics > is still being drawn and the response is immediate: Stop the first > repaint and start a new one with everything enlarged, etc. Works so far > very nicely. > > However, a problem arises when I want to resize the window: It happens > frequently that the size just "jumps" to something completely wrong, > e.g. width zero or so. It only happens if the "move whole windows" > option is turned on, i.e. resizing means a whole avalanche of WM_PAINT > messages are arriving and competing with each other. I found a way to > handle this, with partial success, trying to set a flag "don't repaint" > while a resize action is on the way. In most cases this prevents the > strange "jumping resize", but still not always. OTOH sometimes the final > repaint doesn't seem to work and has to be forced somehow manually. > > There is a certain chance that the problem even has something to do with > the multiple desktop feature of OD which I am running (v1.52 > "professional"). > > QUESTION: > > Does anybody see an entirely different setup for achieving the > responsiveness I want while long repaints are going on without running > into the problems I got? > > Greetings and thanks for any hints, > > Cornelis Bockemühl > > e-mail: cbockem@datacomm.ch > author of "PmAs - Astronomy for the Presentation Manager" > at http://www.datacomm.ch/cobo > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- ======================================================= To reply, delete the "x" from my email address Jerry Stuckle jstucklex@attglobal.net JDS Computer Training Corp. Sun Certified Java Programmer VisualAge/Java Certified Advanced Technical Expert VisualAge/C++ Certified Developer ======================================================= --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Skynet Titan (1:109/42) +----------------------------------------------------------------------------+ From: awremovethismg@yesic.com 11-Nov-99 14:45:04 To: All 11-Nov-99 16:48:03 Subj: SOMobjects Toolkit Availability? From: "andrew g" If you know where on IBM I can find the SOMobjects toolkit, please let me know. Thanks, andrew --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Introits and Graduals Co. (1:109/42) +----------------------------------------------------------------------------+ From: kh@no.spam.munot.demon.co.uk 11-Nov-99 21:32:23 To: All 11-Nov-99 19:59:17 Subj: Re: SYS_DLLS and superclassing native controls From: kh@no.spam.munot.demon.co.uk (Kevin) On 11 Nov 1999 12:52:33 GMT, rplyler@us.spamNOT.ibm.com (Bob Plyler) wrote: >In <3828955d.97047@news.demon.co.uk>, kh@no.spam.munot.demon.co.uk (Kevin) writes: >>I have a massive PM application with hundreds and hundreds of entry >>fields. It is used on 21 inch montiors and users are complaining that >>they can't see the entry field cursor on the large screens. >>Subclassing entry fields is not an option in this environment. So I >>thought I could superclass WC_ENTRYFIELD. I have created a DLL with an >>initialisation routine that attempts to get the class info for >>WC_ENTRYFIELD, store the address of the window proc and register a >>CS_PUBLIC control called WC_ENTRYFIELD. The intention is that when it >>receives the focus it can call the original WC_ENTRYFIELD wnd proc and >>then create a new cursor that is more visible. > >Simple question. Why not just replace the Cursors? >You can replace them with system supplied cursors in >the Mouse settings. You can modify these cursors via ICONEDIT You're thinking of pointers. I want to replace the cursors - those blinking lines you see in entry fields. These are drawn dynamically by the system - there is no bitmap for them. > >Bob Plyler > >IBM 3890/XP Engineering (not an official IBM spokesperson) --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Organization (1:109/42) +----------------------------------------------------------------------------+ From: kh@no.spam.munot.demon.co.uk 11-Nov-99 21:32:24 To: All 11-Nov-99 19:59:17 Subj: Re: SYS_DLLS and superclassing native controls From: kh@no.spam.munot.demon.co.uk (Kevin) Peter, Thanks so much for your code. I took the advice from you and Rich and used the SENDMSG hook. I intercept WM_CONTROL messages for EN_SETFOCUS/MLN_SETFOCUS and create my cursor. Had to add code for WM_BUTTON1UP, but it works like a charm. Your code helped me find my fatal error - the hook procedure has to be EXPENTRY, not APIENTRY. I hate when that happens! So that made a mess of the stack. Just have some fine tuning for MLEs (imagine that) and a setup utility and its done. Now that I don't need the fprintfs any more, I can also drop the C runtime. Could you possibly post me an OBJ for your ASM entry point code? I don't have access to MASM and without it I have to use the C runtime and its _DLL_InitTerm function to do my own initialisation procedure. Would post the code somewhere, if I only knew where or thought that any but the hard core were still doing OS/2! thanks again, Kevin On Fri, 12 Nov 1999 01:46:01 GMT, peter.fitzsimons@fto.de wrote: >From: peter.fitzsimons@fto.de > >From: Peter Fitzsimons > >> I list my DLL in SYS_DLLS->LoadEachProcess (or whatever it's > called). >> The DLL loads and executes its initialisation. WinQueryClassInfo > gets >> TRUE for WC_ENTRYFIELD. WinRegisterClass for WC_ENTRYFIELD with >> CS_PUBLIC gets FALSE. But after re-booting, any window with an > entry >> field traps. This tends to indicate that my wndproc is being > called, > >How are you defining your data segments? ie:"single shared", or > what? > >If you are loading anything (like a pointer/icon/bmp) you have to do > it >for each app, which probably forces you do use an "initinstance > multiple >nonshared" dll. So keep your data segment size down, and try to > compile >/Rn. > >I have code that subclasses the titlebar for every app with a sys_dll >"load once" entry. It installs a msg hook, that looks for WM_CREATE >messages; if the window is what I'm looking for, then I subclass it >"live". I'm a resource freak and the thought of "loadperprocess" and >"mutliple data" offended me at the time (1995, when I only had 24mb > of >memory I think :). > >Anyway, you're welcome to the code if you like. > > > --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Organization (1:109/42) +----------------------------------------------------------------------------+ From: jstucklex@attglobal.net 11-Nov-99 15:39:17 To: All 11-Nov-99 19:59:17 Subj: Re: Problems when handling WM_PAINT in a second thread From: Jerry Stuckle Cornelis, > > Or maybe with a modification: The "object window" draws into a memory PS > and from time to time sends a message to the main thread telling it to > copy the current image to the screen... (??!) > Yes - after drawing into the object window, the object thread invalidates the main window, causing a WM_PAINT message to be posted and the main window redrawn. -- ======================================================= To reply, delete the "x" from my email address Jerry Stuckle jstucklex@attglobal.net JDS Computer Training Corp. Sun Certified Java Programmer VisualAge/Java Certified Advanced Technical Expert VisualAge/C++ Certified Developer ======================================================= --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: JDS Computer Training Corp. (1:109/42) +----------------------------------------------------------------------------+ From: uno@40th.com 11-Nov-99 21:51:15 To: All 11-Nov-99 19:59:17 Subj: Re: SYS_DLLS and superclassing native controls From: uno@40th.com (uno@40th.com) Kevin? (kh@no.spam.munot.demon.co.uk?) wrote (Thu, 11 Nov 1999 21:32:47 GMT): >You're thinking of pointers. I want to replace the cursors - those >blinking lines you see in entry fields. These are drawn dynamically by You're thinking of the caret. The mouse cursor is a cursor. The text cursor is a caret. '`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' Corne1 Huth - http://40th.com/ Bullet database engines/servers 3.1 Win32-WinCE-OS2-Linux+ --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Yanaguana (1:109/42) +----------------------------------------------------------------------------+ From: bvermo@powertech.no 11-Nov-99 22:18:21 To: All 11-Nov-99 19:59:17 Subj: Re: Detecting MMX processor From: =?iso-8859-1?Q?Bj=F8rn?= Vermo Mads Orbesen Troest wrote: > > .. or simply make sure it is a >= Pentium processor before using the > cpuid method. MMX extensions do not exist for processors below > Pentium. > The old IIT 80c287 had something very like it. I have one in my old OS/2 1.3 computer. --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Norbionics (1:109/42) +----------------------------------------------------------------------------+ From: bschwand@dvart.com 11-Nov-99 15:30:04 To: All 11-Nov-99 21:27:04 Subj: redirect stdio from program for rexx processing From: bruno schwander Hi all, I need to write a rexx script that will start an executable program and communicate with this program through its standard input/output. How do I do this ? I know how to redirect the program's output to a file, but I'd like to redirect it to (for example) a rexx queue, so that the rexx script can just pull the output from that queue. And the same for the input of the program. Any idea how to do this ? bruno --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Posted via Supernews, http://www.supernews.com (1:109/42) +----------------------------------------------------------------------------+ From: joe_heafner@my-deja.com 11-Nov-99 18:17:08 To: All 12-Nov-99 03:36:02 Subj: Re: sys/param.h and in.h on other systems From: joe_heafner@my-deja.com In article <176uZD2KcidF-pn2-mfXb5X5VVrhc@rikki>, rde@tavi.co.uk (Bob Eager) wrote: > On Thu, 11 Nov 1999 00:03:10, Joe Heafner > wrote: > > > I have some software that was designed to work under EMX, DJGPP, and > > other systems equipped with gcc. It also compiles under VC++ on Win > > systems. The programs make use of the sys/param.h and in.h header files. > > When I attempt to compile the code under MingW32 (the Win32 port of gcc > > 2.9) the compiler complains about not being able to find these header > > files. > > Where did you get the header files for the other compilers? If in a > toolkit, then if MingW32 can't find them you probably have it looking > in the wrong place. > These header files are part of the standard distributions. I'm not using any toolkits (don't even have any). > > Can anyone tell me the header files I should use under MingW23 to > > compile these programs? > > The same ones you used for the others. > Aha....but they don't exist. > > The only compiler to have a problem so far is MingW32. > > Sounds like the setup. > I followed the setup docs to the letter. Basically, all I had to do was unzip the package into its home directory. > > The software, I belive (I didn't write this particular > > part), uses these header files for functions needed to check and, if > > necessary, change byte ordering (big endian vs. little endian) in > > certain situations. > > I can believe that the files you mention contain these functions. But > they aren't part of ANSI. Saying that you've seen them on every system > so far doesn' MAKE then suddnly ANSI. > Sure, I know that. But it is kinda weird that only one compiler doesn't seem to have then. > I repeat, I think the set of headers you're using with the compiler is > incomplete. Or its INCLUDE environment variable isn't picking up the > toolkit directory. > This is a possibility. I'll check into it. Thanks! -- Joe Heafner -- Astronomer http://home.interpath.com/heafnerj/ Sent via Deja.com http://www.deja.com/ Before you buy. --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Deja.com - Before you buy. (1:109/42) +----------------------------------------------------------------------------+ From: zachmcleod@earthlink.net 12-Nov-99 14:49:22 To: All 12-Nov-99 21:25:09 Subj: Real Modem From: Don McLeod I have a 3Com/USR Internet Voice/Fax modem. I can't get the thing to run under OS/2 Warp 4. It's NOT a WINMODEM. I can get it to run fine under DOS, or Linux, but not Warp 4. Does anyone have any suggestions? I've tried copying the initialize strings and using different modems types but nothing seems to work. Thank-you, Zach McLeod zachmcleod@earthlink.net --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: EarthLink Network, Inc. (1:109/42) +----------------------------------------------------------------------------+ From: awremovethismg@yesic.com 12-Nov-99 18:37:01 To: All 12-Nov-99 21:25:09 Subj: Re: SOMobjects Toolkit Availability? From: "andrew g" On 12 Nov 1999 17:51:06 +0100, Martin Schaff”ner wrote: >You can't anymore. The 2.1 version is included with os/2 toolkits, >and the 3.0 version, which is corba 2.0 compliant and which never >officially got released, is no more available for download. I found the version 3 SOMobjects Toolkit at http://www-4.ibm.com/software/ad/som/som30tk.html but it's version 2 I want, as my compiler is CSET++ 2.01. I can't find this version on IBM at all. andrew --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Introits and Graduals Co. (1:109/42) +----------------------------------------------------------------------------+ From: jpolt@bradnet.legend.co.uk 12-Nov-99 23:26:15 To: All 12-Nov-99 21:25:09 Subj: Re: Problem installing a modem on an OS/2 workstation From: jpolt@bradnet.legend.co.uk (John Poltorak) In <19991112153602.05576.00000465@ng-cq1.aol.com>, sruli87202@aol.com (SRuli87202) writes: >Can somebody help me out here? > >I am trying to install a modem on an IBM 730 MT:6877-KAE PC that is running >OS/2 WARP 4. I have already installed of the TCPIP/ Internet software and the >modem card. > >When I click on the Dial button on the OS/2 Internet dialer, I get this error >message: > PPP Driver Failure. > Connection ERROR > >I have already verified that the COM port and IRQ settings are correctly set up >on the jumper settings on the card and that the right COM port was selected on >the dialer. The COM.SYS driver in the CONFIG.SYS file is set to >DEVICE=D:\OS2\BOOT\COM.SYS(3,3e8,5). COM Port 3 IRQ5. > >I figured that it should be okay to use IRQ5 since there is no sound card >installed on this computer. > >I am fairly sure this means that I need to load a driver for this modem. This >however is a first for me. I have never had to load a driver for a modem >before. All of the other modem that I installed worked without having to load >anything. Maybe it's because this modem has Plug and Play capability. This is >the Name, Type and Model number of the modem that I installed. > > Name & Type. > ACCURA Hayes 33.6 Internal modem > These numbers were taken off of the back of the modem. > Acc336 > 5636US > V1.510 > >The modem did come with a diskette that had device drivers but none of them >were for OS/2. There was one written for windows 3.1 that I tried to load for >WIN-OS/2 thinking that I could just set it all up under WIN-OS/2 but I kept >getting an error messages when I tried to install it. > > >So here's my question or questions. > 1 Am I correct in thinking that this error message means > that I need to load a driver? Unless it's a WinModem you don't need any device drivers. Just get hold of a terminal emulator/comms program such as TE/2. Start it up, and after set up the com port, speed etc., type ATZ and see if returns OK. If that works use the command to display the modems current settings - ATI5 on a USR modem - not sure how standard this is though... You'd need to consult your modem manual. If this works, you know your computer is talking to your modem, so you can then look at any problems you may have setting up the dialer. > 2 If I do need to load a driver in order for this modem >to work, is there one available for OS/2? > >Of course any help that you could give me regarding this would be greatly >appreciated. > >Thank you for taking the time to read this post. > >Sincerely, >Steve Rulison > --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Legend Internet Ltd (1:109/42) +----------------------------------------------------------------------------+ +============================================================================+